Schnelles Überprüfen, wenn in ASP.NET hohe Arbeitsspeicherebenen auftreten

In diesem Artikel werden die schnellen Punkte beschrieben, die Sie überprüfen können, wenn sie in Microsoft ASP.NET hohen Arbeitsspeicher haben.

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

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

ASP.NET Spalte "VoIP unterstützen"

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, wurde eine Verknüpfung mit der vom Webdienst zurückgegebenen XML-Datei verknüpft. Dieser Link wurde korrigiert. Wenn Sie den Artikel mit der richtigen angefügten Datei überprüfen möchten, lesen Sie dynamische Seitenaktualisierungen mithilfe von XMLHTTP.

Was gilt als hoher Arbeitsspeicher?

Diese Frage hängt natürlich von Volumen und Aktivität bestimmter Anwendungen ab. Im Allgemeinen erhöht sich der arbeitsspeicherreiche Arbeitsspeicher, wenn ihr ASP.NET Arbeitsprozess (Aspnet_wp.exe) oder Internetinformationsdienste (IIS)-Arbeitsprozess (W3wp.exe) immer größer wird und nicht zu einem komfortablen Niveau zurückkehrt.

Im Allgemeinen würde ein komfortabler Wert unter 600 MB im Standardmäßigen 2-GB-Benutzerspeicherspeicherplatz betragen. Sobald die Speicherebene höher als diese komfortable Ebene ist, tun wir weniger, als wir sein 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 mehr Arbeitsspeicher hinzufügen oder einen anderen Server hinzufügen (oder eine Webfarm in Betracht ziehen). Die Profilerstellung wird auch in diesen Fällen empfohlen. Es kann Entwicklern ermöglichen, schlankere Anwendungen zu erstellen. In diesem Artikel sehen wir uns eine Situation an, in der der Arbeitsspeicher konsistent steigt, bis der Server nicht mehr ausgeführt wird.

Anwendung für das Debuggen eingerichtet

Ein Grund für hohen Arbeitsspeicher, den wir hier im Support sehen, ist, wenn Sie Debugging, 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 Der Datei "Web.config " festgelegt:

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

oder

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

Wenn Sie auch einen endgültigen Build Ihrer Anwendung ausführen, stellen Sie sicher, dass Sie dies im Releasemodus ausführen, nicht im Debugmodus. Sobald Sie sich in der Produktion befinden, sollte das Debuggen nicht mehr erforderlich sein. Es kann Ihre Leistung wirklich verlangsamen und Ihren Speicher nach oben essen. Das Festlegen dieses Attributs bedeutet, dass Sie einige Dinge darüber ändern, wie Sie Ihre Anwendung behandeln.

Zuerst 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 in sie einbrechen können. Diese Assemblys können zufällig über Ihren Arbeitsspeicher verteilt werden, wodurch es schwieriger wird, den zusammenhängenden Speicherplatz zu finden, um Arbeitsspeicher zuzuweisen.

Zweitens wird das executionTimeout Attribut (<httpRuntime-Element>) auf eine hohe Zahl festgelegt, wobei der Standardwert von 90 Sekunden überschrieben wird. Es ist in Ordnung beim Debuggen, da Sie das Zeitlimit der Anwendung nicht haben können, während Sie den Code geduldig durchgehen, um Ihre Fehler zu finden. Es ist jedoch ein erhebliches Risiko bei der Produktion. Dies bedeutet, dass, wenn Sie eine rogue-Anforderung aus irgendeinem Grund haben, an einem Thread festhalten und ein schädliches Verhalten für Tage statt für wenige Minuten fortsetzen.

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

Wenn Sie nichts anderes aus diesem Artikel erhalten, hoffe ich, dass Sie diese Informationen erhalten. Das Verlassen des aktivierten Debuggings ist ungültig. 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 alle Ihre Seiten sie nicht festlegen.

Zeichenfolgenverkettung

Es gibt Anwendungen, die die HTML-Ausgabe mithilfe von serverseitigem Code erstellen und nur eine große HTML-Zeichenfolge erstellen, die an den Browser gesendet werden soll. 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 scheint harmlos genug, aber hier sehen Sie, 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>

Möglicherweise denken Sie, 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, vielleicht durch eine Schleife durch ein großes Recordset. Wenn Sie dies tun, verwenden Sie unsere System.Text.StringBuilder Klasse, damit Sie nur die eine große Zeichenfolge speichern. Siehe Verwenden von Visual C# zur Verbesserung der Zeichenfolgenverkettungsleistung

.NET Framework Service Pack 1 (SP1)

Wenn Sie .NET Framework SP1 noch nicht ausführen, installieren Sie diesen SP, wenn Arbeitsspeicherprobleme auftreten. Ich werde nicht ins Detail gehen, aber im Grunde, mit SP1 werden wir jetzt Speicher auf viel effizientere Weise zuordnen. Grundsätzlich werden gleichzeitig 16 MB für große Objekte und nicht für 64 MB gleichzeitig zugeordnet. Wir haben alle bewegt, und wir alle wissen, dass wir viel mehr in ein Auto oder einen Lkw packen können, wenn wir viele kleine Boxen anstelle einiger großer Boxen verwenden. Hier ist die Idee.

Keine Angst, regelmäßig wiederzuverwenden

Wir recyceln Anwendungspools in IIS standardmäßig alle 29 Stunden. Der Aspnet_wp.exe Prozess wird weiterhin ausgeführt, bis Sie die Aufgabe beenden, IIS neu starten oder den Computer neu starten. Dieses Verhalten bedeutet, dass dieser Prozess monatelang ausgeführt werden kann. Es ist eine gute Idee für einige Anwendungen, den Arbeitsprozess alle paar Tage neu zu starten.

Wichtige Fragen

Das vorherige waren alle 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 Heap für große Objekte gespeichert.

• Speichert ich Objekte im Sitzungszustand? Diese Objekte bleiben viel länger im Arbeitsspeicher, als wenn Sie sie verwenden und verwerfen.

• Verwende ich das Cache Objekt? Wenn es klug verwendet wird, ist es ein großer Vorteil für die Leistung. Aber wenn es unweise verwendet wird, werden Sie mit viel Arbeitsspeicher aufgewinden, der nie freigegeben wird.

• Gibt ich für eine Webanwendung zu groß zurück recordsets ? 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 in einer Reise erhalten.

Debuggen

Ich werde mich nicht in die Einrichtung von WinDbg einsteigen. Sie können jedoch die folgenden Befehle verwenden, um zu sehen, was genau im Arbeitsspeicher ist, wenn Sie kompliziertere Probleme beheben möchten.

!eeheap -gc

Dieser Befehl zeigt Ihnen, wie viel verwalteter Arbeitsspeicher Sie haben. Wenn dieser Wert hoch ist, gibt es etwas, das Ihr verwalteter Code erstellt.

!dumpheap -stat

Dieser Befehl dauert eine weile Ausführung, auch wenn der Arbeitsspeicher groß ist. Mit diesem Befehl erhalten Sie jedoch eine Liste aller Objekte, wie viele der einzelnen Typen und wie viel Arbeitsspeicher sie verwenden. (Für die StringBuilder Klasse werden beispielsweise viele System.String Objekte angezeigt)

Nachdem Sie ein Objekt gefunden haben, das viel Arbeitsspeicher belegt, graben Sie mithilfe des folgenden Befehls weiter:

!do <addr>

Sie können die Adresse des objekts abrufen, das Sie im dumpheap Befehl suchen.

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 einen guten Job machen!

Artikel zu Speicher und Leistung

Garbage Collector-Grundlagen und Tipps zur Leistung

Entwickeln leistungsstarker ASP.NET-Anwendungen

ASP.NET Leistungsmonitor ing und wann Administratoren benachrichtigt werden sollen

Verbessern der Leistung und Skalierbarkeit von .NET-Anwendungen