Erfassen von Speicherabbildern auf der Azure-App-Dienstplattform

Artikel
11/20/2024

Dieser Artikel enthält Anleitungen zu Microsoft Azure-App Dienstdebuggingfeatures zum Erfassen von Speicherabbildern. Die von Ihnen verwendete Aufnahmemethode wird durch das Szenario bestimmt, in dem Sie ein Speicherabbild für die Problembehandlung eines Leistungs- oder Verfügbarkeitsproblems erfassen. Das Erfassen eines Speicherabbilds unterscheidet sich z. B. von einem Prozess, bei dem ein übermäßiger Speicherverbrauch auftritt, als bei einem Prozess, bei dem Ausnahmen ausgelöst oder langsam reagiert werden. Der Prozess in diesem Kontext ist der Internetinformationsdienste (IIS)-Arbeitsprozess (W3WP, der als w3wp.exe ausgeführt wird).

Zuordnen von Speicherabbildszenarien zu Azure-App Dienstdebuggingfeatures

Die folgende Tabelle enthält Empfehlungen zu den Befehlen, die von jedem App-Dienst-Feature ausgeführt werden, um ein Speicherabbild zu generieren. Es gibt so viele Ansätze zum Erfassen eines Speicherabbilds, das der Prozess möglicherweise verwirrend sein kann. Wenn Sie bereits ein W3WP-Speicherabbild erfassen, sind diese Informationen nicht dazu gedacht, Ihren Ansatz zu ändern. Stattdessen hoffen wir, anleitungen für unerfahrene Benutzer bereitzustellen, die noch keine Vorliebe entwickelt haben.

Szenario	Azure-App Dienstdebuggingfunktion	Get-Help
Nicht reagierend oder langsam	Automatisches Heilen (Anforderungsdauer)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`
Absturz (Prozessbeendigung)	Absturzüberwachung	Verwendet DbgHost zum Erfassen eines Speicherabbilds
Absturz (behandelte Ausnahmen)	Ablaufverfolgungen in Application Insights/Log Analytics	Keine
Absturz (unbehandelte Ausnahmen)	Application Insights-Momentaufnahmedebugger	Keine
Übermäßige CPU-Auslastung	Proaktive CPU-Überwachung	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`
Übermäßiger Arbeitsspeicherverbrauch	Automatisches Heilen (Speicherlimit)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`

Notiz

Wir haben eine sekundäre Empfehlung zum Erfassen eines W3WP-Prozessspeicherabbilds im nicht reagierenden oder langsamen Szenario. Wenn dieses Szenario reproduzierbar ist und Sie das Dump sofort erfassen möchten, können Sie das Diagnosetool zum Sammeln eines Speicherabbilds verwenden. Dieses Tool befindet sich auf der Seite "Diagnostizieren und Lösen von Problemen" für die angegebene App Service Web App im Azure-Portal. Ein weiterer Speicherort, an dem auf allgemeine Ausnahmen überprüft werden soll und die Leistung schlecht ist, befindet sich auf der Seite "Anwendungsereignisprotokolle ". (Sie können auch über die Seite "Probleme diagnostizieren und lösen".) Im Abschnitt "Erweiterte Azure-App Dienstdebuggingfeaturebeschreibungen" werden alle verfügbaren Methoden behandelt.

Beschreibungen des erweiterten Prozessszenarios

Dieser Abschnitt enthält detaillierte Beschreibungen der sechs Szenarien, die in der vorherigen Tabelle dargestellt sind.

Nicht reagierende oder langsame Szenarien

Wenn eine Anforderung an einen Webserver gestellt wird, muss in der Regel ein Code ausgeführt werden. Die Codeausführung erfolgt innerhalb des w3wp.exe Prozesses in Threads. Jeder Thread verfügt über einen Stapel, der anzeigt, was derzeit ausgeführt wird.

Ein nicht reagierendes Szenario kann entweder dauerhaft (und wahrscheinlich zeitlos) oder langsam sein. Daher ist das nicht reagierende Szenario ein Szenario, in dem eine Anforderung länger dauert als erwartet ausgeführt wird. Was Sie als langsam betrachten können, hängt davon ab, was der Code tut. Für einige Personen ist eine Drei-Sekunden-Verzögerung langsam. Für andere ist eine Verzögerung von 15 Sekunden akzeptabel. Wenn Leistungsmetriken angezeigt werden, die auf Langsamkeit hinweisen, oder ein Superbenutzer gibt an, dass der Server langsamer reagiert als normal, dann haben Sie ein nicht reagierender oder langsames Szenario.

Absturzszenario (Prozessbeendigung)

In vielen Jahren hat Microsoft .NET Framework die Behandlung von Ausnahmen verbessert. In der aktuellen Version von .NET ist die Ausnahmebehandlung noch besser.

Wenn ein Entwickler Codeausschnitte in einem Try-Catch-Block nicht platziert hat und eine Ausnahme ausgelöst wurde, wurde der Prozess beendet. In diesem Fall wurde der Prozess durch eine unbehandelte Ausnahme im Code des Entwicklers beendet. Modernere Versionen von .NET behandeln einige dieser "unbehandelten" Ausnahmen, sodass der Prozess, der den Code ausführt, nicht abstürzt. Allerdings werden nicht alle unbehandelten Ausnahmen direkt aus dem benutzerdefinierten Code ausgelöst. Beispielsweise können Zugriffsverletzungen (z. B. 0xC0000005 und 0x80070005) oder ein Stapelüberlauf den Prozess beenden.

Absturzszenario (behandelte Ausnahmen)

Obwohl ein Softwareentwickler besonders darauf bedacht ist, alle möglichen Szenarien zu bestimmen, unter denen der Code ausgeführt wird, kann etwas Unerwartetes auftreten. Die folgenden Fehler können eine Ausnahme auslösen:

Unerwartete Nullwerte
Ungültige Umwandlung
Ein fehlendes instanziiertes Objekt

Es ist eine bewährte Methode, codeausführung in Try-Catch-Codeblöcke zu setzen. Wenn ein Entwickler diese Blöcke verwendet, hat der Code die Möglichkeit, ordnungsgemäß fehlzuschlagen, indem er insbesondere verwaltet, was auf das unerwartete Ereignis folgt. Eine behandelte Ausnahme ist eine Ausnahme, die innerhalb eines Try-Blocks ausgelöst wird und im entsprechenden Catch-Block abgefangen wird. In diesem Fall hat der Entwickler erwartet, dass eine Ausnahme auftreten und einen geeigneten Try-Catch-Block um diesen Codeabschnitt codiert hat.

Im Catch-Block ist es hilfreich, genügend Informationen in einer Protokollierungsquelle zu erfassen, damit das Problem reproduziert und letztendlich behoben werden kann. Ausnahmen sind teure Codepfade in Bezug auf die Leistung. Daher wirkt sich das Auftreten vieler Ausnahmen auf die Leistung aus.

Absturzszenario (nicht behandelte Ausnahmen)

Unbehandelte Ausnahmen treten auf, wenn Code versucht, eine Aktion auszuführen, die nicht erwartet wird. Wie im Szenario "Absturz" (Prozessbeendigung) ist dieser Code nicht in einem Try-Catch-Codeblock enthalten. In diesem Fall hat der Entwickler nicht erwartet, dass eine Ausnahme in diesem Codeabschnitt auftreten könnte.

Dieses Szenario unterscheidet sich von den vorherigen beiden Ausnahmeszenarien. Im Szenario "Absturz" (unbehandelte Ausnahmen) ist der fragliche Code der Code, den der Entwickler geschrieben hat. Es handelt sich nicht um den Frameworkcode, der die Ausnahme auslöst, und es handelt sich nicht um eine der nicht behandelten Ausnahmen, die den w3wp.exe Prozess beenden. Da der Code, der eine Ausnahme auslöst, nicht innerhalb eines Try-Catch-Blocks liegt, gibt es keine Möglichkeit, die Ausnahme ordnungsgemäß zu behandeln. Die Problembehandlung für den Code ist zunächst etwas komplexer. Ihr Ziel wäre es, den Ausnahmetext, den Typ und den Stapel zu finden, der die Methode identifiziert, die diese unbehandelte Ausnahme auslöst. Mit diesen Informationen können Sie ermitteln, wo Sie den Try-Catch-Codeblock hinzufügen müssen. Anschließend kann der Entwickler die ähnliche Logik hinzufügen, um Ausnahmedetails zu protokollieren, die im Szenario "Absturz" (nicht behandelte Ausnahmen) vorhanden sein sollten.

Szenario mit übermäßiger CPU-Auslastung

Was ist eine übermäßige CPU-Auslastung? Diese Situation hängt von der Funktionsweise des Codes ab. Wenn die CPU-Auslastung des w3wp.exe Prozesses 80 Prozent beträgt, befindet sich Ihre Anwendung in einer kritischen Situation, die verschiedene Symptome verursachen kann. Einige mögliche Symptome sind:

Verzögerungen
Fehler
Anderes undefiniertes Verhalten

Selbst eine 20-Prozent-CPU-Auslastung kann als übermäßig angesehen werden, wenn die Website nur statische HTML-Dateien liefert. Nach der Mortem-Problembehandlung einer übermäßigen CPU-Spitzen durch das Generieren eines Speicherabbilds können Sie wahrscheinlich nicht die spezifische Methode ermitteln, die sie verwendet. Am besten können Sie ermitteln, welche Anforderungen wahrscheinlich die längste Zeit in Anspruch nehmen, und versuchen Sie dann, das Problem zu reproduzieren, indem Sie die identifizierte Methode testen. Bei diesem Verfahren wird davon ausgegangen, dass Sie keine Leistungsmonitore auf den Leistungssystemen ausführen, die diesen Platz erfasst haben. In vielen Fällen können Sie Leistungsprobleme verursachen, indem Monitore ständig in Echtzeit ausgeführt werden.

Szenario mit übermäßigem Arbeitsspeicherverbrauch

Wenn eine Anwendung in einem 32-Bit-Prozess ausgeführt wird, kann eine übermäßige Speicherauslastung ein Problem darstellen. Selbst eine kleine Menge an Aktivitäten kann die 2-3 GB des zugewiesenen virtuellen Adressraums verbrauchen. Ein 32-Bit-Prozess kann niemals insgesamt 4 GB überschreiten, unabhängig von der verfügbaren Menge an physischem Arbeitsspeicher.

Ein 64-Bit-Prozess wird mehr Arbeitsspeicher zugewiesen als ein 32-Bit-Prozess. Es ist wahrscheinlicher, dass der 64-Bit-Prozess den physischen Speicher auf dem Server verbraucht, als dass der Prozess seinen zugewiesenen virtuellen Adressraum verbraucht.

Daher hängt das Problem einer übermäßigen Speicherauslastung von den folgenden Faktoren ab:

Prozessbitanzahl (32-Bit oder 64-Bit)
Die Arbeitsspeicherauslastung, die als "normal" betrachtet wird.

Wenn Ihr Prozess mehr Arbeitsspeicher verbraucht als erwartet, sammeln Sie ein Speicherabbild für die Analyse, um zu ermitteln, was Arbeitsspeicherressourcen verbraucht. Weitere Informationen finden Sie unter Erstellen eines Speicherabbilds Ihres App-Diensts, wenn zu viel Arbeitsspeicher verbraucht wird.

Da Sie nun etwas mehr Kontext zu den verschiedenen Prozessszenarien haben, die ein Speicherabbild Ihnen bei der Problembehandlung helfen kann, besprechen wir das empfohlene Tool zum Erfassen von Speicherabbildern auf der Azure-App-Dienstplattform.

Erweiterte Beschreibungen Azure-App Dienstdebuggingfeatures

In der Tabelle im Abschnitt "Zuordnen von Speicherabbildszenarien zu Azure-App Dienstdebuggingfeatures" haben wir sechs Debugfeatures identifiziert, die auf das Sammeln von Speicherabbildern abzielen. Auf jede dieser Features kann innerhalb der Azure-Portal auf der Seite "Diagnose" und "Probleme lösen" zugegriffen werden, wenn Sie die Kachel "Diagnosetools" auswählen.

In den folgenden Abschnitten werden die einzelnen Debugfeatures ausführlicher erläutert.

Feature "Automatisches Heilen" (Anforderungsdauer)

Das Feature zum automatischen Heilen (Anforderungsdauer) eignet sich zum Erfassen eines Speicherabbilds, wenn die Antwort länger dauert als erwartet. Sie können den Link zur automatischen Heilung in der Kachel "Diagnosetools " im vorherigen Screenshot sehen. Wählen Sie diesen Link aus, um direkt zur Funktion zu wechseln, oder wählen Sie die Kachel "Diagnosetools " aus, um alle verfügbaren Tools auf der Seite "Diagnosetools " zu überprüfen. Informationen zum Konfigurieren dieses Features finden Sie in den folgenden Artikeln:

Die Funktion zum automatischen Heilen wird im folgenden Screenshot gezeigt.

Ein weiteres Feature mit dem Namen "Speicherabbild sammeln" ist in diesem Szenario hilfreich, wenn das Problem derzeit auftritt oder reproduzierbar ist. Dieses Feature sammelt schnell ein Speicherabbild bei manueller Anforderung.

Sammeln eines Speicherabbildfeatures

Informationen zur Konfiguration der Funktion "Speicherabbild sammeln" finden Sie unter "Speicherabbild-App-Dienste sammeln". Für diesen Ansatz ist ein manueller Eingriff erforderlich. Der folgende Screenshot zeigt die Seite "Speicherabbild sammeln".

Um das Feature zu verwenden, wählen Sie ein Speicherkonto aus, in dem das Speicherabbild gespeichert werden soll. Wählen Sie dann die Serverinstanz aus, von der Sie das Speicherabbild erfassen möchten. Wenn Sie mehr als eine einzelne Instanz haben, stellen Sie sicher, dass das Problem, das Sie debuggen, in dieser Instanz auftritt. Beachten Sie, dass ein Neustart für eine Produktionsanwendung, die in Betrieb ist, möglicherweise nicht optimal ist.

Absturzüberwachungsfeature

Das Feature "Absturzüberwachung" eignet sich zum Erfassen eines Speicherabbilds, wenn eine unbehandelte Ausnahme dazu führt, dass der W3WP-Prozess beendet wird. Der folgende Screenshot zeigt die Seite "Absturzüberwachung " in den Diagnosetools:

Informationen zum Konfigurieren des Absturzüberwachungsfeatures in Azure-App Service finden Sie unter Absturzüberwachung in Azure-App Dienst.

Ablaufverfolgungen in Application Insights/Log Analytics-Feature

Eine behandelte Ausnahme ist ein Szenario, in dem der Code, der in einem Try-Catch-Block enthalten ist, versucht, eine unerwartete oder nicht unterstützte Aktion auszuführen. Der folgende Codeausschnitt versucht beispielsweise, eine Zahl durch Null zu dividieren, obwohl dies ein unzulässiger Vorgang ist:

decimal percentage = 0, number = 1000, total = 0;
try
{
  percentage = number / total;
}
catch (DivideByZeroException divEx)
{
  _logger.LogError("A handled exception just happened: -> {divEx.Message}", divEx.Message);
}

Dieser Codeausschnitt verursacht eine Teilungs-durch-Null-Ausnahme, die behandelt wird, da der nicht unterstützte mathematische Vorgang in einem Try-Catch-Block platziert wird. Application Insights protokolliert keine behandelten Ausnahmen, es sei denn, Sie fügen absichtlich das Microsoft.ApplicationInsights NuGet-Paket in Ihren Anwendungscode ein, und fügen Sie dann den Code zum Protokollieren der Informationen hinzu. Wenn die Ausnahme nach dem Hinzufügen des Codes auftritt, können Sie den Eintrag in Log Analytics anzeigen, wie im folgenden Screenshot gezeigt.

Der folgende Kusto-Code enthält die Abfrage, die zum Extrahieren der Daten aus Log Analytics verwendet wird:

traces
| where message has "handled"
 | project timestamp, severityLevel, message, operation_Name, cloud_RoleInstance

Die message Spalte ist der Speicherort, an dem Sie die Details speichern können, die erforderlich sind, um die Ursache der Ausnahme zu finden. Der Code, der zum Schreiben dieser Abfrage verwendet wird, befindet sich im Codeausschnitt "Division by Zero". Der Softwareentwickler, der diesen Code geschrieben hat, ist die beste Person, um diese Arten von Ausnahmen und die Attribute zu fragen, die für die Analyse von Stammursachen erforderlich sind.

Der beste Ansatz zum Hinzufügen dieser Funktionalität zu Ihrem Anwendungscode hängt vom Anwendungscodestapel und der version ab (z. B. ASP.NET, ASP.NET Core, MVC, Razor usw.). Überprüfen Sie die Application Insights-Protokollierung mit .NET, um den besten Ansatz für Ihr Szenario zu ermitteln.

Feature für Anwendungsereignisprotokolle (behandelte Ausnahmen)

Außerdem finden Sie unbehandelte Ausnahmen in der behandelten Ausnahme auf der Seite "Anwendungsereignisprotokolle" der Diagnosetools im Azure-Portal, wie im folgenden Screenshot gezeigt.

In diesem Fall erhalten Sie dieselbe Fehlermeldung, die Sie über Ihren Code protokolliert haben. Sie verlieren jedoch einige Flexibilität bei der Anpassung der Abfragen in Application Insights-Ablaufverfolgungsprotokollen.

Feature "Momentaufnahmedebugger für Application Insights"

Unbehandelte Ausnahmen werden auch auf der Seite "Anwendungsereignisprotokolle " protokolliert, wie im Ausgabetext im nächsten Abschnitt gezeigt. Sie können jedoch auch den Momentaufnahmedebugger "Application Insights" aktivieren. Bei diesem Ansatz müssen Sie Ihrer Anwendung keinen Code hinzufügen.

Feature für Anwendungsereignisprotokolle (nicht behandelte Ausnahmen)

Die folgende Ausgabe stammt von der Seite "Anwendungsereignisprotokolle" der Diagnosetools im Azure-Portal. Es zeigt beispieltext einer unbehandelten Anwendungs ausnahme:

Category: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
EventId: 1
SpanId: 311d8cb5d10b1a6e
TraceId: 041929768411c12f1c3f1ccbc91f6751
ParentId: 0000000000000000
RequestId: 8000006d-0001-bf00-b63f-84710c7967bb
RequestPath: /Unhandled

An unhandled exception has occurred while executing the request.

Exception:
System.DivideByZeroException: Attempted to divide by zero.
   at System.Decimal.DecCalc.VarDecDiv(DecCalc& d1, DecCalc& d2)
   at System.Decimal.op_Division(Decimal d1, Decimal d2)
   at contosotest.Pages.Pages Unhandled.ExecuteAsync()
     in C:\Users\contoso\source\repos\contosorepo\contosorepo\Pages\Unhandled.cshtml:line 12

Ein Unterschied hier von der behandelten Ausnahme im Anwendungsprotokoll ist das Vorhandensein des Stapels, der die Methode und die Zeile identifiziert, aus der die Ausnahme ausgelöst wird. Außerdem können Sie sicher davon ausgehen, dass die Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware-Funktionalität Code enthält, um diese unbehandelte Ausnahme abzufangen, sodass das Beenden des Prozesses vermieden wird. Die Ausnahme wird auf der Registerkarte "Ausnahmen" auf der Seite "Fehler" in Application Insights angezeigt, wie im folgenden Screenshot gezeigt.

In dieser Ansicht werden alle Ausnahmen und nicht nur die Ausnahmen angezeigt, nach denen Sie suchen. Die grafische Darstellung aller Ausnahmen, die in Ihrer Anwendung auftreten, ist hilfreich, um einen Überblick über die Integrität Ihres Systems zu erhalten. Das Application Insights-Dashboard ist im Vergleich zu den Anwendungsereignisprotokollen visuell hilfreich.

Proaktives CPU-Überwachungsfeature

Bei übermäßigen CPU-Auslastungsszenarien können Sie das proaktive CPU-Überwachungstool verwenden. Informationen zu diesem Tool finden Sie unter "Minimieren der CPU-Probleme vor dem Auftreten". Die folgende Abbildung zeigt die Seite "Proaktive CPU-Überwachung " in den Diagnosetools.

Sie sollten die CPU-Auslastung von 80 Prozent oder mehr als eine kritische Situation betrachten, die eine sofortige Untersuchung erfordert. Auf der Seite "Proaktive CPU-Überwachung " können Sie das Szenario festlegen, für das Sie ein Speicherabbild basierend auf den folgenden Datenüberwachungskategorien erfassen möchten:

CPU-Schwellenwert
Schwellenwerte Sekunden
Monitorhäufigkeit

Der CPU-Schwellenwert gibt an, wie viel Computer CPU der zielorientierte Prozess verwendet (in diesem Fall W3WP). Schwellenwert sekunden ist die Zeitspanne, in der die CPU beim CPU-Schwellenwert verwendet wurde. Wenn beispielsweise eine CPU-Auslastung von 75 Prozent insgesamt 30 Sekunden beträgt, wird das Speicherabbild erfasst. Wie auf der Seite "Proaktive CPU-Überwachung " konfiguriert, wird der Prozess alle 15 Sekunden auf Schwellenwertverletzungen überprüft.

Feature "Automatisches Heilen" (Speicherlimit)

Das Feature zum automatischen Heilen (Speicherlimit) ist nützlich, um ein Speicherabbild zu erfassen, wenn der Prozess mehr Arbeitsspeicher belegt als erwartet. Achten Sie auch hier auf die Bitanzahl (32 oder 64). Wenn im 32-Bit-Prozesskontext Arbeitsspeicherdruck auftreten und die Speicherauslastung erwartet wird, können Sie die Bitanzahl in 64 ändern. Wenn Sie die Bitanzahl ändern, müssen Sie die Anwendung in der Regel auch neu kompilieren.

Das Ändern der Bitanzahl verringert nicht die Menge des verwendeten Arbeitsspeichers. Es ermöglicht dem Prozess, mehr als 4 GB Gesamtspeicher zu verwenden. Wenn der Arbeitsspeicherverbrauch jedoch nicht wie erwartet ist, können Sie dieses Feature verwenden, um zu bestimmen, was den Arbeitsspeicher verbraucht. Anschließend können Sie eine Aktion ausführen, um den Arbeitsspeicherverbrauch zu steuern.

Im Abschnitt "Erweiterte Azure-App Dienstdebugging-Featurebeschreibungen" können Sie den Link zur Automatischen Heilung in der Kachel "Diagnosetools" im ersten Screenshot sehen. Wählen Sie diesen Link aus, um direkt zum Feature zu wechseln, oder wählen Sie die Kachel aus, und überprüfen Sie alle verfügbaren Tools auf der Seite "Diagnosetools ". Weitere Informationen hierzu können Sie im Abschnitt "Auto-Healing" Azure-App Dienstdiagnoseübersicht anzeigen.

Die Funktion zum automatischen Heilen wird im folgenden Screenshot gezeigt.

Wenn Sie die Kachel "Speicherbeschränkung " auswählen, haben Sie die Möglichkeit, einen Speicherwert einzugeben, der die Erfassung eines Speicherabbilds auslöst, wenn dieser Speichergrenzwert verletzt wird. Wenn Sie z. B. 6291456 als Wert eingeben, wird ein Speicherabbild des W3WP-Prozesses verwendet, wenn 6 GB Arbeitsspeicher verbraucht wird.

Das Feature "Speicherabbild sammeln" ist in diesem Szenario nützlich, wenn das Problem derzeit auftritt oder reproduzierbar ist. Dieses Feature sammelt schnell ein Speicherabbild bei manueller Anforderung. Weitere Informationen finden Sie im Abschnitt "Sammeln eines Speicherabbilds" .

Erweiterte Befehlsbeschreibungen

Die Kunst der Speicherabbildsammlung benötigt etwas Zeit, um zu studieren, zu erleben und perfekt zu sein. Wie Sie gelernt haben, basieren unterschiedliche Verfahren auf den Symptomen, die der Prozess anzeigt, wie in der Tabelle im Abschnitt "Erweiterte Prozessszenariobeschreibungen" aufgeführt. Im Gegensatz dazu vergleicht die folgende Tabelle den Speicherabbilderfassungsbefehl des Azure-App Diensts mit dem Befehl "Procdump", den Sie manuell über die Kudu-Konsole ausführen.

Szenario	Befehl "Azure-App Dienst"	Allgemeiner Befehl "Procdump"
Nicht reagierend oder langsam	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # <PID>`
Absturz (Prozessbeendigung)	Verwendet DbgHost zum Erfassen des Speicherabbilds	`procdump -accepteula -ma -t <PID>`
Absturz (behandelte Ausnahmen)	None (Application Insights)	`procdump -accepteula -ma -e 1 -f <filter> <PID>`
Absturz (unbehandelte Ausnahmen)	None (Application Insights Snapshot Debugger)	`procdump -accepteula -ma -e <PID>`
Übermäßige CPU-Auslastung	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # -c 80 <PID>`
Übermäßiger Arbeitsspeicherverbrauch	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -m 2000 <PID>`

Die Befehle, die Sie in den Speicherabbilderfassungsfeatures in Azure-App Dienst verwenden, unterscheiden sich von den Procdump-Befehlen, die Sie verwenden würden, wenn Sie Dumps manuell erfasst haben. Wenn Sie den vorherigen Abschnitt überprüfen, sollten Sie feststellen, dass die Speicherabbildsammlungsportalfunktion in Azure-App Dienst die Konfiguration verfügbar macht. Beispielsweise enthält der Befehl, der von der Plattform ausgeführt wird, im Szenario mit übermäßigem Arbeitsspeicherverbrauch keinen Speicherschwellenwert. Der Befehl, der in der allgemeinen Befehlsspalte procdump angezeigt wird, gibt jedoch einen Speicherschwellenwert an.

Ein Tool namens DaaS (Diagnose as a Service) ist für die Verwaltung und Überwachung der Konfiguration verantwortlich, die im Azure-App Dienstdebuggingportal angegeben ist. Dieses Tool wird als Webauftrag auf den virtuellen Computern (VMs) ausgeführt, die Ihre Web-App ausführen. Ein Vorteil dieses Tools besteht darin, dass Sie auf einen bestimmten virtuellen Computer in Ihrer Webfarm abzielen können. Wenn Sie versuchen, ein Speicherabbild mithilfe von Procdump direkt zu erfassen, kann es schwierig sein, diesen Befehl in einer bestimmten Instanz zu identifizieren, darauf zuzugreifen und auszuführen. Weitere Informationen zu DaaS finden Sie unter DaaS – Diagnose as a Service für Azure-Websites.

Übermäßige CPU-Auslastung ist ein weiterer Grund, warum die Plattform die Speicherabbildsammlung verwaltet, damit sie den empfohlenen Prokdumpmustern entsprechen. Der Befehl "Procdump", wie in der vorherigen Tabelle dargestellt, sammelt drei (-n 3) vollständige Speicherabbilder (-ma) 30 Sekunden auseinander (-s #wobei # 30 sind), wenn die CPU-Auslastung größer oder gleich 80 Prozent (-c 80) ist. Schließlich geben Sie die Prozess-ID (<PID>) für den Befehl an: procdump -accepteula -ma -n 3 -s # -c 80 <PID>.

Die Portalkonfiguration finden Sie im Abschnitt "Proaktive CPU-Überwachung" . Aus Platzgründen zeigte dieser Abschnitt nur die ersten drei Konfigurationsoptionen: CPU-Schwellenwert (), Schwellenwerte (-s-c) und Monitorhäufigkeit. Der folgende Screenshot zeigt, dass " Aktion konfigurieren", "Maximale Aktionen " (-n) und "Maximale Dauer " zusätzliche features zur Verfügung stehen.

Nachdem Sie die verschiedenen Ansätze zum Erfassen von Speicherabbildern untersucht haben, besteht der nächste Schritt darin, Aufzeichnungen zu üben. Sie können Codebeispiele auf GitHub in Verbindung mit IIS-Debuglabors und Azure Functions verwenden, um die einzelnen Szenarien zu simulieren, die in den beiden Tabellen aufgeführt sind. Nachdem Sie den Code auf der Azure-App-Dienstplattform bereitgestellt haben, können Sie diese Tools verwenden, um das Speicherabbild unter jedem bestimmten Szenario zu erfassen. Im Laufe der Zeit und nach der Übung können Sie Ihren Ansatz für die Erfassung von Speicherabbildern mithilfe der Azure-App Dienstdebuggingfeatures optimieren. Die folgende Liste enthält einige Vorschläge, die Sie berücksichtigen sollten, wenn Sie weiterhin mehr über die Speicherabbildsammlung erfahren:

Das Erfassen eines Speicherabbilds verbraucht erhebliche Systemressourcen und stört die Leistung noch weiter.
Das Erfassen von Speicherabbildern bei der ersten Chance ist nicht optimal, da Sie wahrscheinlich zu viele erfassen. Diese Speicherabbilder der ersten Chance sind höchstwahrscheinlich irrelevant.
Es wird empfohlen, Application Insights zu deaktivieren, bevor Sie ein W3WP-Speicherabbild erfassen.

Nachdem das Speicherabbild erfasst wurde, besteht der nächste Schritt darin, das Speicherabbild zu analysieren, um die Ursache des Problems zu ermitteln und dann dieses Problem zu beheben.

Nächste Schritte (Analysieren des Speicherabbilds)

Die Erläuterung, wie Speicherabbilder analysiert werden, liegt außerhalb des Umfangs dieses Artikels. Es gibt jedoch viele Ressourcen für diesen Betreff, z. B. die Schulungsreihe " Defrag Tools " und eine Liste der winDbg-Befehle, die sie benötigen.

Möglicherweise haben Sie die Option "Aktion konfigurieren" im vorherigen Screenshot bemerkt. Die Standardeinstellung für diese Option ist CollectAndKill. Diese Einstellung bedeutet, dass der Prozess nach der Erfassung des Speicherabbilds getötet wird. Eine Einstellung mit dem Namen CollectKillAndAnalyze analysiert das gesammelte Speicherabbild. In diesem Szenario kann die Plattformanalyse das Problem finden, sodass Sie das Speicherabbild in WinDbg nicht öffnen und analysieren müssen.

Es gibt weitere Optionen für die Problembehandlung und Diagnose von Leistungsproblemen auf der Azure-App-Dienstplattform. Dieser Artikel konzentriert sich auf die Sammlung von Speicherabbildern und gibt einige Empfehlungen für die Behandlung der Diagnose mithilfe dieser Methoden. Wenn Sie ihre Sammlungsverfahren bereits studiert, erfahren und perfektioniert haben und sie für Sie gut funktionieren, sollten Sie diese Verfahren weiterhin verwenden.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.

Freigeben über