Snelle dingen om te controleren wanneer u een hoog geheugenniveau in ASP.NET

Artikel
03/10/2024

In dit artikel worden de snelle dingen beschreven die u kunt controleren wanneer u een hoog geheugengebruik hebt in Microsoft ASP.NET.

Oorspronkelijke productversie: ASP.NET
Origineel KB-nummer: 893660

Dit artikel begint met enkele veelvoorkomende problemen, acties om deze problemen op te lossen en een korte uitleg van waarom deze situaties problemen kunnen veroorzaken.

kolom ASP.NET Support Voice

In de kolom Support Voice van april 2005 hebben we per ongeluk een koppeling naar het verkeerde bestand opgegeven. In plaats van een koppeling te maken naar een download voor de webservice, zijn we gekoppeld aan het XML-bestand dat door de webservice wordt geretourneerd. Deze koppeling is gecorrigeerd. Als u het artikel met het juiste bestand wilt bekijken, raadpleegt u Dynamische pagina-updates met xmlHTTP.

Wat wordt beschouwd als hoog geheugen

Uiteraard hangt deze vraag af van het volume en de activiteit van specifieke toepassingen. Over het algemeen treedt een hoog geheugen op wanneer het geheugen van uw ASP.NET werkproces (Aspnet_wp.exe) of iis-werkproces (Internet Information Services) (W3wp.exe) consistent toeneemt en niet terugkeert naar een comfortabel niveau.

In het algemeen is een comfortabel niveau minder dan 600 MB in de standaardadresruimte van 2 GB gebruikersgeheugen. Zodra het geheugenniveau hoger is dan dat comfortabele niveau, doen we minder dan we zouden moeten doen. Dit gedrag kan van invloed zijn op andere toepassingen die op het systeem worden uitgevoerd.

De sleutel is om te begrijpen dat sommige toepassingen meer geheugen nodig hebben dan andere. Als u deze limieten overschrijdt, kunt u meer geheugen toevoegen of een andere server toevoegen aan uw webfarm (of een webfarm overwegen). Profilering wordt in deze gevallen ook aanbevolen. Hiermee kunnen ontwikkelaars slankere toepassingen maken. In dit artikel kijken we naar een situatie waarin u consistent ziet dat het geheugen toeneemt totdat de server niet meer wordt uitgevoerd.

Toepassing ingesteld voor foutopsporing

Een reden voor een hoog geheugen dat we hier in Ondersteuning veel zien, is wanneer u foutopsporing, tracering of beide hebt ingeschakeld voor uw toepassing. Het inschakelen van foutopsporing en tracering is een noodzaak wanneer u uw toepassing ontwikkelt. Wanneer u uw toepassing maakt in Visual Studio .NET, ziet u standaard het volgende kenmerk dat is ingesteld in uw Web.config-bestand :

<compilation
 ...
 debug="true"
 />

 <trace
 enabled="true"
 ...
 />

Wanneer u een definitieve build van uw toepassing uitvoert, moet u er ook voor zorgen dat u dit doet in de releasemodus, niet in de foutopsporingsmodus. Zodra u in productie bent, is foutopsporing niet meer nodig. Het kan uw prestaties echt vertragen en uw geheugen opeten. Als u dit kenmerk instelt, wijzigt u een aantal dingen met betrekking tot de manier waarop u uw toepassing verwerkt.

Eerst wordt batchcompilatie uitgeschakeld, zelfs als deze is ingesteld in dit compilation element. Dit betekent dat u een assembly maakt voor elke pagina in uw toepassing, zodat u erin kunt inbreken. Deze assembly's kunnen willekeurig worden verspreid over uw geheugenruimte, waardoor het moeilijker is om de aaneengesloten ruimte te vinden om geheugen toe te wijzen.

Ten tweede wordt het executionTimeout kenmerk (<httpRuntime> Element) ingesteld op een hoog getal, waarbij de standaardwaarde van 90 seconden wordt overschreven. Het is prima bij foutopsporing, omdat u geen time-out voor de toepassing kunt krijgen terwijl u de code geduldig doorloopt om uw blunders te vinden. Het is echter een aanzienlijk risico in de productie. Het betekent dat als u om wat voor reden dan ook een rogue-aanvraag hebt, deze een thread vasthoudt en elk schadelijk gedrag gedurende dagen zal voortzetten in plaats van enkele minuten.

Ten slotte maakt u meer bestanden in de map Tijdelijke ASP.NET bestanden. En de System.Diagnostics.DebuggableAttribute (System.Diagnostics-naamruimte wordt toegevoegd aan alle gegenereerde code, wat kan leiden tot prestatievermindering.

Als je niets anders uit dit artikel krijgt, hoop ik dat je deze informatie krijgt. Foutopsporing ingeschakeld laten is slecht. We zien dit gedrag maar al te vaak en het is zo gemakkelijk te veranderen. Vergeet niet dat deze kan worden ingesteld op paginaniveau. Zorg ervoor dat deze niet op al uw pagina's wordt ingesteld.

Tekenreekssamenvoeging

Er zijn toepassingen die HTML-uitvoer bouwen met behulp van code aan de serverzijde en door slechts één grote HTML-tekenreeks te bouwen om naar de browser te verzenden. Het is prima, maar als u de tekenreeks bouwt met behulp van + en & samenvoeging, weet u misschien niet hoeveel grote tekenreeksen u bouwt. Bijvoorbeeld:

string mystring = "<html>";
mystring = mystring + "<table><tr><td>";
mystring = mystring + "First Cell";
mystring = mystring + "</td></tr></table>";
mystring = mystring + "</html>";

Deze code lijkt onschuldig genoeg, maar dit is wat u opslaat in het geheugen:

<html>
<html><table><tr><td>
<html><table><tr><td>First Cell
<html><table><tr><td>First Cell</td></tr></table>
<html><table><tr><td>First Cell</td></tr></table></html>

Misschien denkt u dat u alleen de laatste regel opslaat, maar u slaat al deze regels op. U kunt zien hoe het uit de hand kan lopen, met name wanneer u een grote tabel bouwt, misschien door een grote recordset te doorlopen. Als het is wat u doet, gebruikt u onze System.Text.StringBuilder klasse, zodat u alleen de ene grote tekenreeks opslaat. Zie Visual C# gebruiken om de prestaties van tekenreekssamenvoeging te verbeteren

.NET Framework Service Pack 1 (SP1)

Als u de .NET Framework SP1 nog niet uitvoert, installeert u deze SP als u geheugenproblemen ondervindt. Ik zal niet in detail treden, maar met SP1 geven we het geheugen nu op een veel efficiëntere manier toe. Kortom, we wijzen 16 MB tegelijk toe voor grote objecten in plaats van 64 MB tegelijk. We zijn allemaal verhuisd en we weten allemaal dat we veel meer in een auto of vrachtwagen kunnen inpakken als we veel kleine dozen gebruiken in plaats van een paar grote dozen. Het is het idee hier.

Wees niet bang om periodiek te recyclen

We recyclen standaard elke 29 uur toepassingsgroepen in IIS. Het Aspnet_wp.exe proces blijft doorgaan totdat u de taak beëindigt, IIS opnieuw start of de computer opnieuw opstart. Dit gedrag betekent dat dit proces maanden kan worden uitgevoerd. Het is een goed idee voor sommige toepassingen om het werkproces om de paar dagen opnieuw te starten, op een geschikt moment.

Vragen om te stellen

De vorige waren allemaal dingen die u snel kunt oplossen. Als u echter geheugenproblemen ondervindt, stelt u uzelf de volgende vragen:

Gebruik ik veel grote objecten? Meer dan 85.000 kB wordt opgeslagen in een grote object-heap.
Bewaar ik objecten in sessiestatus? Deze objecten blijven veel langer in het geheugen dan wanneer u ze gebruikt en weggooien.
Gebruik ik het Cache object? Wanneer het verstandig wordt gebruikt, is het een groot voordeel voor de prestaties. Maar wanneer het onverstandig wordt gebruikt, wordt er veel geheugen gebruikt dat nooit wordt vrijgegeven.
Retourneert recordsets ik te groot voor een webtoepassing? Niemand wil 1000 records op een webpagina bekijken. U moet uw toepassing zo ontwerpen dat u nooit meer dan 50 tot 100 records in één reis krijgt.

Debugging

Ik ga niet aan de slag met het instellen van WinDbg. Maar u kunt de volgende opdrachten gebruiken om te zien wat er precies in uw geheugen zit, als u complexere problemen wilt oplossen.

!eeheap -gc

Met deze opdracht ziet u hoeveel beheerd geheugen u hebt. Als deze waarde hoog is, is er iets dat uw beheerde code bouwt.

!dumpheap -stat

Het uitvoeren van deze opdracht duurt enige tijd, zelfs uren als uw geheugen groot is. Met deze opdracht krijgt u echter een lijst met al uw objecten, hoeveel van elk type en hoeveel geheugen elk gebruikt. (Voor de StringBuilder klasse ziet u bijvoorbeeld veel System.String objecten)

Zodra u hebt vastgesteld dat een object veel geheugen in beslag neemt, graaft u verder met behulp van de volgende opdracht:

!do <addr>

U kunt het adres van het object dat u zoekt, ophalen in de dumpheap opdracht.

We proberen meer manieren op te nemen om dit diagnostische hulpprogramma te gebruiken voor specifieke situaties in deze kolommen. Laat ons weten of we het goed doen!