Hej!
Jag har en web service som skickar ut filer till klienter. Problemet är att aspnet_wp.exe ökar stadigt i minnesanvändning. Den släpper alltså inte ifrån sig alla resurser. Koden jag använder för att skicka filer är följande:
<code>
Dim close As Boolean = False
Dim fs As FileStream
Dim lngLen As Long
Dim abytBuffer() As Byte
Try
fs = File.Open(strFile, FileMode.Open, FileAccess.Read)
lngLen = fs.Length
ReDim abytBuffer(CInt(lngLen - 1))
fs.Read(abytBuffer, 0, CInt(lngLen))
Return abytBuffer
Catch exp As Exception
Return Nothing
Finally
If Not fs Is Nothing Then
fs.Close()
End If
fs = Nothing
abytBuffer = Nothing
GC.Collect()
End Try
</code>
Nån som ser någonting konstigt eller har några tips?

/Peter

Testa att ta bort GC.Collect() och se om det gör någon skillnad.

Den har jag lagt till i efterhand, samm fel både innan och efter jag lade till den.

Kan det vara något att en connection eller någon slags 'state' ligger kvar från användaren. Kanske att den cachar något?

Körs verkligen Finally när du har en return i koden? Har du kollat att du verkligen kommer dit?

Jo.. Finally körs väl alltid? Om finally inte körs har jag ju ingen möjlighet att sätta returnerade variabler till nothing?

När du får exception kan du även sätta alla objekten till nothing - eller vet du att den aldrig hamnar där?
Finally körs inte om du skriver return ... - då hoppar den ur på en gång.

Angående att sätta saker till Nothing. Det är sällan som ni behöver tänka på det mer med anledning av att variabler har scope. Deklarerar du variabler inne i en metod så när du lämnar den metoden så hamnar de ur scope och alla referenser till dessa variabler försvinner (med anledning av att den stack framen poppas från stacken). Märk väl att detta inte behöver vara sant om du skickat vidare variabler ByRef (ref och out i C#), då det kan finnas aktiva referenser till minnesarean på andra ställen.

När Garbage Collectorn sedan kör så hittar den minnet och samtidigt ser den att det inte finns några aktiva referenser till det - voilá så kan det minner återanvändas.

Kan även tillägga att Finally är tänk att användas för att rensa upp evt resurser man använder sig av, så som strömmar, connections, filer etc. och inte för att "tömma variabler".

Kontrollera med en breakpoint ifall du faktiskt hamnar i finally. Tror inte att du gör det eftersom du har en return. Finally är till för att städa upp om ett exception triggas.

Du gör en fs.Close() i Finally så den bör du kanske kopiera upp från finally innan du gör en return. Men att också ha den kvar i finally om du skulle få ett exception innan du hinner till close.

Jenny: Jo visst körs Finally, prova skall du se :)

Peter: Va du du skulle kunna göra är att köra Flush metoden på ditt objekt innan du stänger det, men jag tror inte att det är lösningen. En varning - kör (nästan) aldrig GC.Collect själv, det är otroligt sällan som det är befogat =) Och vad menar du med att den växer? Hur mycket snackar vi om ? Någon megabyte? Oändligt? Vad kör du på för maskin ?

Det var väl det jag trodde om Finally. :)

Flush kan jag prova. Den växer bra mycket, kan gå från 40 till 500mb (oändligt) och körs på en 2000-server med mycket ram.

Tre saker,

1) FileStream implementerar IDisposable, och du bör alltså anropa fs.Dispose() i Finally. Jag vet inte om detta orsakar minnesproblem i just det här fallet, men risken finns.

2) En av finesserna med skräpinsamlaren i .NET är att den körs "vid behov". Om du har en dator med mycket RAM och där inget annat program tävlar om minne, kommer skräpinsamlaren att köras sällan. Detta är avsiktligt. Mao, kanske ser det mysko ut att allt minne käkas upp av asp.net, men om detta inte i sig orsakar problem någon annanstans är allt normalt.

3) En kollega bloggade idag en rekommendation om när man bör anropa GC.Collect() själv: http://blogs.msdn.com/ricom/archive/2004/11/29/271829.aspx. Kort och gott, "Rule #1: Don't."

För att klargöra:

a) Finally körs ALLTID!

<code>
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim a As Integer
Dim b As Integer

Try
a = b / 0
Catch ex As Exception

MessageBox.Show("FEL")

'Oavsett vilket man skrivit, så kommer "slut..." att visas INNAN programmet avslutas.
Return
Exit Sub
Application.Exit()

Finally

MessageBox.Show("slut...")

End Try
End Sub

</code>

b) Har man mycket RAM så tar programmet mycket RAM. GarbageCollectorn går igång på begäran, inte tidsstyrt. Finns det minne som applikationen kan allokera, så gör den det. Börjar det bli klent med minne kvar, så drar den igång en GC-runda. Det kan dröja! Jag testade att skapa 10 objekt som sedan kastades. De hade fortfarande inte blivit hanterade efter lunch. Direkt när jag stängde programmet, så kördes/förstördes alla 10.

/micke

Tack för alla bra svar!

Dispose ska jag testa.

ASP.net-processen har vid flera tillfällen tagit så pass mycket minne att servern slöats ner. Därför verkar inte gc.collect vara problemet (den borde köras men det hjälper inte).

Ska göra om file.open till filestream och köra dispose och se om det hjälper.

Har också fått ett tips om att köra starta upp en tråd vid startpunkten på web-applikationen med while-slinga och gc.collect med en viss tidsintervall. Kanske en idé om man är rädd för minnesläckor och inte tycker att garbage-collectorn körs tillräckligt ofta..?

Jag skulle inte rekommendera att köra en tråd som anropar GC.Collect(). Problemet ligger med all säkerhet någon annanstans.

Tips för att felsöka:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt17.asp
eller varför inte
http://www.google.com/search?hl=en&q=site%3Amicrosoft.com+troubleshoot+asp.net+performance