Schnelle Dinge, die Sie überprüfen sollten, wenn hohe Speicherebenen in ASP.NET

  • Artikel
  • 6 Minuten Lesedauer

In diesem Artikel werden die schnellen Dinge beschrieben, die Sie überprüfen sollten, wenn in Microsoft ASP.NET hoher Arbeitsspeicher vorhanden ist.

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

Dieser Artikel beginnt mit einigen allgemeinen Problemen, Maßnahmen 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 eine Verknüpfung mit der vom Webdienst zurückgegebenen XML-Datei erstellt. Dieser Link wurde korrigiert. Wenn Sie den Artikel mit der richtigen Datei lesen möchten, lesen Sie dynamische Seitenupdates mitHILFE von XMLHTTP.

Was als hoher Arbeitsspeicher betrachtet wird

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

Allgemein gilt, dass eine komfortable Ebene unter 600 MB im standardmäßigen 2-GB-Adressraum des Benutzerspeichers wäre. Sobald die Speicherebene höher als die komfortable Ebene ist, wird weniger ausgeführt, 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 ihrer Webfarm (oder einer Webfarm) möglicherweise mehr Arbeitsspeicher hinzufügen oder einen anderen Server hinzufügen. In diesen Fällen wird auch die Profilerstellung empfohlen. Dadurch können Entwickler schlankere Anwendungen erstellen. In diesem Artikel sehen wir uns eine Situation an, in der Der Arbeitsspeicher ständig ansteigt, bis der Server nicht mehr funktioniert.

Für das Debuggen eingerichtete Anwendung

Ein Grund für hohen Speicher, den wir hier im Support sehen, ist, wenn Sie Debuggen, Ablaufverfolgung oder beides für Ihre Anwendung aktiviert haben. Das Aktivieren von Debugging 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 ausführen, stellen Sie außerdem sicher, dass Sie dies im Releasemodus und nicht im Debugmodus durchführen. Sobald Sie sich in der Produktion befinden, sollte das Debuggen nicht mehr erforderlich sein. Es kann ihre Leistung erheblich verlangsamen und Den Arbeitsspeicher auffressen. Das Festlegen dieses Attributs bedeutet, dass Sie einige Dinge zum Umgang mit Ihrer Anwendung ändern.

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

Zweitens wird das executionTimeout Attribut ( <httpRuntime> Element) auf eine hohe Zahl festgelegt, die den Standardwert von 90 Sekunden überschreibt. Beim Debuggen ist es in Ordnung, da sie keine Zeitüberschreitung für die Anwendung haben können, während Sie den Code durchgehen, um Ihre Fehler zu finden. Dies ist jedoch ein erhebliches Risiko in der Produktion. Dies bedeutet, dass bei einer nicht autorisierten Anforderung aus irgendeinem Grund diese für einen Thread gilt und alle schädlichen Verhaltensweisen für Tage statt für einige Minuten fortgesetzt werden.

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 leistungsbeeinträchtigungen führen kann.

Wenn Sie nichts anderes aus diesem Artikel erhalten, kann ich hoffen, dass Sie diese Informationen erhalten. Das Debuggen ist falsch. Wir sehen dieses Verhalten zu oft, und es ist so einfach, sich zu ändern. Denken Sie daran, dass es auf Seitenebene festgelegt werden kann. Stellen Sie sicher, dass sie nicht auf allen Seiten festgelegt werden.

Zeichenfolgenverknüpfung

Es gibt Anwendungen, die eine HTML-Ausgabe mithilfe von serverseitigem Code erstellen und nur eine große HTML-Zeichenfolge erstellen, die an den Browser gesendet werden kann. Es ist in Ordnung, aber wenn Sie die Zeichenfolge mithilfe + 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 erscheint harmlos genug, aber hier ist das, was Sie im Speicher speichern:

<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 dies aus der Hand gehen kann, insbesondere beim Erstellen einer großen Tabelle, z. B. durch Durchlaufen eines großen Recordsets. Wenn Sie dies tun, verwenden Sie unsere System.Text.StringBuilder Klasse, damit Sie nur 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 den .NET Framework SP1 noch nicht ausführen, installieren Sie diesen SP, wenn Arbeitsspeicherprobleme auftreten. Ich gehe nicht sehr detailliert darauf ein, aber im Grunde genommen werden wir mit SP1 jetzt viel effizienter Arbeitsspeicher zuweisen. Im Grunde werden jeweils 16 MB für große Objekte statt jeweils 64 MB zugeordnet. Wir haben alle verschoben, und wir alle wissen, dass wir viel mehr in ein Auto oder einen Wagen packen können, wenn wir viele kleine Schachteln anstelle einiger großer Schachteln verwenden. Es ist die Idee hier.

Keine Ängstlich sein, regelmäßig wiederzuverwenden

Anwendungspools werden standardmäßig alle 29 Stunden in IIS wiederverwendet. Der Aspnet_wp.exe Prozess wird fortgesetzt, bis Sie die Aufgabe beenden, IIS neu starten oder den Computer neu starten. Dieses Verhalten bedeutet, dass dieser Prozess monatelang ausgeführt werden kann. Für einige Anwendungen empfiehlt es sich, den Arbeitsprozess nur alle paar Tage oder so zu einem geeigneten Zeitpunkt neu zu starten.

Zu stellende Fragen

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

  • Verwende ich viele große Objekte? Mehr als 85.000 KB werden in einem Heap für große Objekte gespeichert.

  • Speichere ich Objekte im Sitzungsstatus? Diese Objekte bleiben viel länger im Speicher, als wenn Sie sie verwenden und verwerfen.

  • Verwende ich das Cache Objekt? Wenn es weise verwendet wird, ist dies ein großer Vorteil für die Leistung. Wenn sie jedoch unklug verwendet wird, wird viel Arbeitsspeicher verbraucht, der nie freigegeben wird.

  • Werde ich recordsets für eine Webanwendung zu groß zurückgegeben? Niemand möchte 1.000 Datensätze auf einer Webseite betrachten. Sie sollten Ihre Anwendung so entwerfen, dass Sie nie mehr als 50 bis 100 Datensätze auf einer Reise erhalten.

Debugging

Ich kann WinDbg nicht einrichten. Sie können jedoch die folgenden Befehle verwenden, um zu sehen, was sich genau in Ihrem Speicher befindet, wenn Sie kompliziertere Probleme beheben möchten.

!eeheap -gc

Mit diesem Befehl wird angezeigt, über wie viel verwalteten Speicher Sie verfügen. Wenn dieser Wert hoch ist, erstellt Ihr verwalteter Code etwas.

!dumpheap -stat

Dieser Befehl dauert eine Weile, bis er ausgeführt wird, auch Stunden, wenn ihr Arbeitsspeicher groß ist. Mit diesem Befehl erhalten Sie jedoch eine Liste aller Objekte, wie viele der einzelnen Typen und wie viel Arbeitsspeicher jeweils verwendet wird. (For example, for the StringBuilder class, you'll see many System.String objects)

Sobald Sie ein Objekt gefunden haben, das viel Arbeitsspeicher benötigt, gehen Sie mit dem folgenden Befehl weiter:

!do <addr>

Sie können die Adresse des Objekts, nach dem Sie suchen, im dumpheap Befehl abrufen.

Wir werden versuchen, weitere Möglichkeiten zur Verwendung dieses Diagnosetools für bestimmte Situationen in diesen Spalten zu integrieren. Teilen Sie uns mit, ob wir einen guten Job machen!

Artikel zu Arbeitsspeicher und Leistung

Grundlagen und Leistungshinweise des Garbage Collectors

Entwickeln von High-Performance ASP.NET-Anwendungen

ASP.NET- und Benachrichtigungsadministratoren

Verbessern der Leistung und Skalierbarkeit von .NET-Anwendungen