Schnelle Überprüfungen bei hohen Arbeitsspeicherebenen in ASP.NET

Artikel
03/10/2024

In diesem Artikel werden die schnellen Schritte beschrieben, die Sie bei hoher Arbeitsspeicherauslastung in Microsoft ASP.NET überprüfen müssen.

Originale Produktversion: ASP.NET
Ursprüngliche KB-Nummer: 893660

Dieser Artikel beginnt mit einigen häufigen Problemen, Aktionen zur Behebung dieser Probleme und einer kurzen Erläuterung, warum diese Situationen Probleme verursachen können.

Spalte "ASP.NET Support Voice"

In der Spalte "Support Voice" vom April 2005 haben wir versehentlich einen Link zur falschen Datei bereitgestellt. Anstatt eine Verknüpfung mit einem Download für den Webdienst zu erstellen, haben wir mit der xml-Datei verknüpft, die vom Webdienst zurückgegeben wird. Dieser Link wurde korrigiert. Wenn Sie den Artikel mit der richtigen angefügten Datei lesen möchten, lesen Sie Dynamische Seitenaktualisierungen mithilfe von XMLHTTP.

Was als hoher Arbeitsspeicher gilt

Diese Frage hängt natürlich vom Umfang und der Aktivität bestimmter Anwendungen ab. Im Allgemeinen ist ein hoher Arbeitsspeicher, wenn der Arbeitsspeicher des ASP.NET Arbeitsprozesses (Aspnet_wp.exe) oder des IIS-Arbeitsprozesses (internetinformationsdienste) (W3wp.exe) ständig zunimmt und nicht zu einem komfortablen Niveau zurückkehrt.

Im Allgemeinen würde eine komfortable Ebene unter 600 MB im Standardmäßigen 2-GB-Benutzerspeicheradressraum liegen. Sobald die Speicherebene höher als diese komfortable Ebene ist, tun wir weniger, als wir sollten. Dieses Verhalten kann sich auf andere Anwendungen auswirken, die auf dem System ausgeführt werden.

Der Schlüssel besteht darin, zu verstehen, dass einige Anwendungen mehr Arbeitsspeicher benötigen als andere. Wenn Sie diese Grenzwerte überschreiten, können Sie mehr Arbeitsspeicher hinzufügen oder Ihrer Webfarm einen anderen Server hinzufügen (oder eine Webfarm in Betracht ziehen). In diesen Fällen wird auch die Profilerstellung empfohlen. Es kann Entwicklern ermöglichen, schlankere Anwendungen zu erstellen. In diesem Artikel sehen wir uns eine Situation an, in der der Arbeitsspeicher ständig zunimmt, bis der Server nicht mehr funktioniert.

Anwendungssetup für das Debuggen

Ein Grund für den hohen Arbeitsspeicher, den wir hier unter Unterstützung sehen, ist, dass Sie Debuggen, Ablaufverfolgung oder beides für Ihre Anwendung aktiviert haben. Das Aktivieren von Debuggen und Ablaufverfolgung ist eine Notwendigkeit, wenn Sie Ihre Anwendung entwickeln. Wenn Sie Ihre Anwendung in Visual Studio .NET erstellen, wird standardmäßig das folgende Attribut in Ihrer Web.config Datei festgelegt:

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

oder

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

Wenn Sie einen endgültigen Build Ihrer Anwendung durchführen, stellen Sie außerdem sicher, dass Sie dies im Releasemodus und nicht im Debugmodus tun. Sobald Sie sich in der Produktion befinden, sollte das Debuggen nicht mehr erforderlich sein. Es kann Ihre Leistung wirklich verlangsamen und Ihren Arbeitsspeicher auffressen. Das Festlegen dieses Attributs bedeutet, dass Sie einige Dinge an der Behandlung Ihrer Anwendung ändern.

Zunächst wird die Batchkompilierung deaktiviert, auch wenn sie in diesem compilation Element festgelegt ist. Dies bedeutet, dass Sie eine Assembly für jede Seite in Ihrer Anwendung erstellen, damit Sie sie einteilen können. Diese Assemblys können nach dem Zufallsprinzip in Ihrem Arbeitsspeicher verteilt werden, wodurch es schwieriger wird, den zusammenhängenden Speicherplatz zum Zuweisen von Arbeitsspeicher zu finden.

Zweitens wird das executionTimeout Attribut (<httpRuntime-Element>) auf eine hohe Zahl festgelegt, wodurch der Standardwert von 90 Sekunden überschrieben wird. Beim Debuggen ist dies in Ordnung, da für die Anwendung kein Timeout möglich ist, während Sie den Code geduldig durchlaufen, um Fehler zu finden. Dies ist jedoch ein erhebliches Risiko in der Produktion. Dies bedeutet, dass, wenn Sie eine nicht autorisierte Anforderung aus irgendeinem Grund haben, sie an einem Thread festhält und jedes schädliche Verhalten für Tage und nicht für einige Minuten fortbehält.

Schließlich erstellen Sie weitere Dateien im Ordner "Temporäre ASP.NET Dateien". Und der System.Diagnostics.DebuggableAttribute (System.Diagnostics-Namespace wird dem gesamten generierten Code hinzugefügt, was zu Leistungseinbußen führen kann.

Wenn Sie nichts anderes von diesem Artikel erhalten, hoffe ich, dass Sie diese Informationen erhalten. Das Debuggen aktiviert zu lassen, ist schlecht. Wir sehen dieses Verhalten allzu oft, und es ist so einfach zu ändern. Denken Sie daran, dass sie auf Seitenebene festgelegt werden kann. Stellen Sie sicher, dass sie nicht auf allen Seiten festgelegt wird.

Zeichenfolgenverknüpfung

Es gibt Anwendungen, die html-Ausgabe mithilfe von serverseitigem Code und durch einfaches Erstellen einer großen HTML-Zeichenfolge erstellen, die an den Browser gesendet werden soll. Es ist in Ordnung, aber wenn Sie die Zeichenfolge mithilfe + von und & Verkettung erstellen, wissen Sie möglicherweise nicht, wie viele große Zeichenfolgen Sie erstellen. Zum Beispiel:

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

Dieser Code scheint harmlos genug zu sein, aber Sie speichern Folgendes im Arbeitsspeicher:

<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>

Sie denken vielleicht, dass Sie nur die letzte Zeile speichern, aber Sie speichern alle diese Zeilen. Sie können sehen, wie es aus der Hand gehen könnte, insbesondere wenn Sie eine große Tabelle erstellen, indem Sie vielleicht ein großes Recordset durchlaufen. Wenn Sie dies tun, verwenden Sie unsere System.Text.StringBuilder -Klasse, damit Sie nur die eine große Zeichenfolge speichern. Weitere Informationen finden Sie unter Verwenden von Visual C#, um die Leistung der Zeichenfolgenverkettung zu verbessern.

.NET Framework Service Pack 1 (SP1)

Wenn Sie die .NET Framework SP1 noch nicht ausführen, installieren Sie diesen SP, wenn Speicherprobleme auftreten. Ich werde nicht ins Detail gehen, aber im Grunde nehmen wir mit SP1 jetzt viel effizienter Speicher zu. Im Grunde werden 16 MB gleichzeitig für große Objekte zugewiesen, anstatt 64 MB gleichzeitig. Wir sind alle umgezogen, und wir alle wissen, dass wir viel mehr in ein Auto oder einen Lkw packen können, wenn wir viele kleine Schachteln anstelle einiger großer Kisten verwenden. Es ist die Idee hier.

Scheuen Sie sich nicht, regelmäßig zu recyceln

Anwendungspools in IIS werden standardmäßig alle 29 Stunden wiederverwendet. Der Aspnet_wp.exe Prozess wird so lange ausgeführt, bis Sie die Aufgabe beenden, IIS neu starten oder den Computer neu starten. Dieses Verhalten bedeutet, dass dieser Prozess möglicherweise monatelang ausgeführt wird. Es ist eine gute Idee, dass einige Anwendungen den Arbeitsprozess alle paar Tage oder so zu einem geeigneten Zeitpunkt neu starten.

Zu stellende Fragen

Die vorherigen waren alles Dinge, die Sie schnell beheben können. Wenn jedoch Speicherprobleme auftreten, stellen Sie sich die folgenden Fragen:

Verwende ich viele große Objekte? Mehr als 85.000 KB werden in einem großen Objektheap gespeichert.
Speichere ich Objekte im Sitzungszustand? Diese Objekte bleiben viel länger im Arbeitsspeicher, als wenn Sie sie verwenden und löschen.
Verwende ich das Cache -Objekt? Wenn es mit Bedacht verwendet wird, ist dies ein großer Vorteil für die Leistung. Wenn sie jedoch unklug verwendet wird, wird viel Arbeitsspeicher verwendet, der nie freigegeben wird.
Bin ich recordsets zu groß für eine Webanwendung? Niemand möchte 1.000 Datensätze auf einer Webseite anzeigen. Sie sollten Ihre Anwendung so entwerfen, dass Sie nie mehr als 50 bis 100 Datensätze auf einer Fahrt erhalten.

Debugging

Ich werde nicht damit beginnen, WinDbg einzurichten. Sie können jedoch die folgenden Befehle verwenden, um zu sehen, was genau in Ihrem Speicher enthalten ist, wenn Sie komplexere Probleme beheben möchten.

!eeheap -gc

Dieser Befehl zeigt Ihnen, wie viel verwalteter Arbeitsspeicher Sie haben. Wenn dieser Wert hoch ist, wird von Ihrem verwalteten Code etwas erstellt.

!dumpheap -stat

Die Ausführung dieses Befehls dauert eine ganze Weile, auch stundenlang, wenn Ihr Arbeitsspeicher groß ist. Mit diesem Befehl erhalten Sie jedoch eine Liste aller Objekte, wie viele der einzelnen Typen und wie viel Arbeitsspeicher die einzelnen Objekte verwenden. (Für die StringBuilder -Klasse werden z. B. viele System.String Objekte angezeigt.)

Wenn Sie ein Objekt gefunden haben, das viel Arbeitsspeicher benötigt, können Sie den folgenden Befehl verwenden:

!do <addr>

Sie können die Adresse des gesuchten Objekts im dumpheap Befehl abrufen.

Wir werden versuchen, weitere Möglichkeiten zur Verwendung dieses Diagnosetools für bestimmte Situationen in diesen Spalten zu integrieren. Lassen Sie uns wissen, ob wir gute Arbeit leisten!