Erfassen von Speicherabbildern auf der Azure App Service-Plattform

Artikel
06/03/2024

Dieser Artikel enthält Anleitungen zu Den Debugfeatures von Microsoft Azure App Service zum Erfassen von Speicherabbildern. Die von Ihnen verwendete Erfassungsmethode wird durch das Szenario vorgegeben, in dem Sie ein Speicherabbild zur Behandlung eines Leistungs- oder Verfügbarkeitsproblems erfassen. Beispielsweise unterscheidet sich das Erfassen eines Speicherabbilds für einen Prozess, bei dem ein übermäßiger Arbeitsspeicherverbrauch auftritt, als für einen Prozess, der Ausnahmen auslöst oder langsam reagiert. Der Prozess in diesem Kontext ist der IIS-Workerprozess (W3WP, Internetinformationsdienste), der als w3wp.exeausgeführt wird.

Zuordnen von Speicherabbildszenarien zu Azure App Service-Debugfeatures

Die folgende Tabelle enthält Empfehlungen zu den Befehlen, die jedes App Service-Feature ausführt, um ein Speicherabbild zu generieren. Es gibt so viele Ansätze zum Erfassen eines Speicherabbilds, dass der Prozess verwirrend sein kann. Wenn Sie bereits mit der Erfassung eines W3WP-Speicherabbilds auskennen, sind diese Informationen nicht dazu gedacht, Ihren Ansatz zu ändern. Stattdessen hoffen wir, anleitungen für unerfahrene Benutzer bereitzustellen, die noch keine Präferenz entwickelt haben.

Szenario	Azure App Service-Debugfeature	Befehl
Nicht reagierend oder langsam	Automatische Reparatur (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 (nicht behandelte Ausnahmen)	Application Insights-Momentaufnahmedebugger	Keine
Übermäßige CPU-Auslastung	Proaktive CPU-Überwachung	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`
Übermäßiger Arbeitsspeicherverbrauch	Automatische Reparatur (Speicherlimit)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`

Hinweis

Wir haben eine sekundäre Empfehlung für die Erfassung eines W3WP-Prozessspeicherabbilds in einem Szenario, das nicht reagiert oder langsam ist. Wenn dieses Szenario reproduzierbar ist und Sie das Speicherabbild sofort erfassen möchten, können Sie das Diagnosetool Speicherabbild sammeln verwenden. Dieses Tool befindet sich auf der Toolsetseite Diagnose und Problembehandlung für die angegebene App Service-Web-App im Azure-Portal. Ein weiterer Speicherort, an dem Sie auf allgemeine Ausnahmen und schlechte Leistung überprüfen können, finden Sie auf der Seite Anwendungsereignisprotokolle . (Sie können auch auf der Seite Probleme diagnostizieren und beheben auf Anwendungsprotokolle zugreifen.) Alle verfügbaren Methoden werden im Abschnitt "Beschreibungen der erweiterten Azure App Service-Debugfeatures" erläutert.

Erweiterte Beschreibungen des Prozessszenarios

Dieser Abschnitt enthält ausführliche Beschreibungen der sechs Szenarien, die in der vorherigen Tabelle aufgeführt sind.

Nicht reagierendes oder langsames Szenario

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

Ein Nicht reagierendes Szenario kann entweder dauerhaft (und wahrscheinlich ein Timeout) oder langsam sein. Daher ist das nicht reagierende Szenario ein Szenario, in dem die Ausführung einer Anforderung länger dauert als erwartet. Was Sie als langsam betrachten, hängt davon ab, was der Code tut. Für einige Personen ist eine Verzögerung von drei Sekunden langsam. Für andere ist eine Verzögerung von 15 Sekunden akzeptabel. Wenn Leistungsmetriken angezeigt werden, die auf Langsamkeit hinweisen, oder wenn ein Superuser angibt, dass der Server langsamer als normal reagiert, haben Sie ein Szenario, das nicht reagiert oder langsam ist.

Absturzszenario (Prozessbeendigung)

Über viele Jahre hinweg hat Microsoft .NET Framework die Behandlung von Ausnahmen verbessert. In der aktuellen Version von .NET ist die Ausnahmebehandlung noch besser.

In der Vergangenheit wurde der Prozess beendet, wenn ein Entwickler keine Codeausschnitte innerhalb eines try-catch-Blocks platziert hat und eine Ausnahme ausgelöst wurde. In diesem Fall wurde der Prozess durch eine nicht behandelte Ausnahme im Code des Entwicklers beendet. Modernere Versionen von .NET behandeln einige dieser "unbehandelten" Ausnahmen, damit der Prozess, der den Code ausführt, nicht abstürzt. Allerdings werden nicht alle nicht behandelten 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 besondere Sorgfalt darauf legt, alle möglichen Szenarien zu bestimmen, in denen der Code ausgeführt wird, kann etwas Unerwartetes auftreten. Die folgenden Fehler können eine Ausnahme auslösen:

Unerwartete NULL-Werte
Ungültige Umwandlung
Ein fehlendes instanziiertes Objekt

Es ist eine bewährte Methode, Codeausführung in try-catch-Codeblöcken zu platzieren. Wenn ein Entwickler diese Blöcke verwendet, hat der Code die Möglichkeit, ordnungsgemäß fehlzuschlagen, indem er speziell 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 davon ausgegangen, dass eine Ausnahme auftreten könnte, und einen geeigneten try-catch-Block um diesen Codeabschnitt codiert.

Im Catch-Block ist es nützlich, genügend Informationen in einer Protokollierungsquelle zu erfassen, damit das Problem reproduziert und letztendlich behoben werden kann. Ausnahmen sind in Bezug auf die Leistung teure Codepfade. Viele Ausnahmen wirken sich daher auf die Leistung aus.

Absturzszenario (Ausnahmefehler)

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 in diesem Codeabschnitt eine Ausnahme auftreten könnte.

Dieses Szenario unterscheidet sich von den beiden vorherigen Ausnahmeszenarien. Im Szenario Absturz (Ausnahmefehler) handelt es sich bei dem betreffenden Code um den Code, den der Entwickler geschrieben hat. Es ist nicht der Frameworkcode, der die Ausnahme auslöst, und es ist keine der nicht behandelten Ausnahmen, die den w3wp.exe Prozess beenden. Da sich der Code, der eine Ausnahme auslöst, nicht innerhalb eines try-catch-Blocks befindet, 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, -typ und -stapel zu finden, der die Methode identifiziert, die diese unbehandelte Ausnahme auslöst. Anhand dieser 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 im Allgemeinen in einer kritischen Situation, die verschiedene Symptome verursachen kann. Einige mögliche Symptome sind:

Langsamkeit
Fehler
Anderes undefiniertes Verhalten

Selbst eine CPU-Auslastung von 20 Prozent kann als übermäßig angesehen werden, wenn die Website nur statische HTML-Dateien bereitstellt. Die Post-Mortem-Problembehandlung bei einer übermäßigen CPU-Spitze durch Das Generieren eines Speicherabbilds hilft Ihnen wahrscheinlich nicht, die spezifische Methode zu bestimmen, die sie verwendet. Am besten können Sie ermitteln, welche Anforderungen wahrscheinlich die längste Zeit in Anspruch genommen haben, und dann zu versuchen, 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 Burst 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 ein übermäßiger Arbeitsspeicherverbrauch ein Problem darstellen. Selbst eine kleine Menge an Aktivitäten kann die 2-3 GB des zugeordneten virtuellen Adressraums verbrauchen. Ein 32-Bit-Prozess darf niemals insgesamt 4 GB überschreiten, unabhängig davon, wie viel physischer Arbeitsspeicher verfügbar ist.

Einem 64-Bit-Prozess wird mehr Arbeitsspeicher zugeordnet als ein 32-Bit-Prozess. Es ist wahrscheinlicher, dass der 64-Bit-Prozess die Menge des physischen Arbeitsspeichers auf dem Server beansprucht, als dass der Prozess den zugeordneten virtuellen Adressraum nutzt.

Daher hängt es von den folgenden Faktoren ab, was ein Problem mit übermäßigem Arbeitsspeicherverbrauch darstellt:

Prozessbitanzahl (32-Bit oder 64-Bit)
Die Menge der Arbeitsspeicherauslastung, die als "normal" angesehen 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 Ihrer App Service-Instanz, wenn zu viel Arbeitsspeicher verbraucht wird.

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

Erweiterte Beschreibungen des Azure App Service-Debugfeatures

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

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

Feature für automatische Reparatur (Anforderungsdauer)

Das Feature für die automatische Reparatur (Anforderungsdauer) ist nützlich, um ein Speicherabbild zu erfassen, wenn die Antwort länger dauert als erwartet. Sie können den Link zur automatischen Reparatur auf der Kachel Diagnosetools im vorherigen Screenshot sehen. Wählen Sie diesen Link aus, um direkt zum Feature zu gelangen, 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:

Das Feature zur automatischen Reparatur wird im folgenden Screenshot gezeigt.

Ein weiteres Feature namens "Speicherabbild sammeln" ist in diesem Szenario nützlich, wenn das Problem derzeit auftritt oder reproduzierbar ist. Dieses Feature sammelt bei manueller Anforderung schnell ein Speicherabbild.

Sammeln eines Speicherabbildfeatures

Informationen zur Konfiguration der Funktion "Speicherabbild sammeln" finden Sie unter Sammeln von Speicherabbild-App-Diensten. Dieser Ansatz erfordert manuelle Eingriffe. 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 aus, von welcher Serverinstanz Sie das Speicherabbild erfassen möchten. Wenn Sie über mehr als eine einzelne Instanz verfügen, stellen Sie sicher, dass das Problem, das Sie debuggen, auf dieser Instanz auftritt. Beachten Sie, dass ein Neustart in einer Produktionsanwendung, die in Betrieb ist, möglicherweise nicht optimal ist.

Absturzüberwachungsfeature

Das Feature Absturzüberwachung ist nützlich, um ein Speicherabbild zu erfassen, wenn eine nicht behandelte Ausnahme dazu führt, dass der W3WP-Prozess beendet wird. Der folgende Screenshot zeigt die Seite "Absturzüberwachung" in den Diagnosetools:

Eine geführte exemplarische Vorgehensweise zum Konfigurieren des Absturzüberwachungsfeatures in Azure App Service finden Sie unter Absturzüberwachung in Azure App Service.

Ablaufverfolgungen im Application Insights-/Log Analytics-Feature

Eine behandelte Ausnahme ist ein Szenario, in dem der in einem try-catch-Block enthaltene Code 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 Dividierung durch Null, die behandelt wird, da die nicht unterstützte mathematische Operation in einem try-catch-Block platziert wird. Application Insights protokolliert behandelte Ausnahmen nur, wenn Sie das NuGet-Paket Microsoft.ApplicationInsights absichtlich in Ihren Anwendungscode einschließen und dann den Code hinzufügen, um die Informationen zu protokollieren. Wenn die Ausnahme auftritt, nachdem Sie den Code hinzugefügt haben, 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 Grundursache 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 nach diesen Arten von Ausnahmen und den Attributen zu fragen, die für die Analyse der Grundursachen erforderlich sind.

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

Anwendungsereignisprotokolle (behandelte Ausnahmen)

Nicht behandelte Ausnahmen finden Sie auch 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 etwas Flexibilität beim Anpassen der Abfragen für Application Insights-Ablaufverfolgungsprotokolle.

Application Insights-Momentaufnahmedebugger

Nicht behandelte Ausnahmen werden auch auf der Seite Anwendungsereignisprotokolle protokolliert, wie im Ausgabetext im nächsten Abschnitt gezeigt. Sie können jedoch auch den Application Insights-Momentaufnahmedebugger aktivieren. Für diesen 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 einen Beispieltext für eine Ausnahme einer nicht behandelten Anwendung:

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 zur behandelten Ausnahme im Anwendungsprotokoll besteht darin, dass der Stapel vorhanden ist, der die Methode identifiziert, und die Zeile, aus der die Ausnahme ausgelöst wird. Außerdem können Sie sicher davon ausgehen, dass die Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware-Funktionalität Code zum Abfangen dieser nicht behandelten Ausnahme enthält, damit das Beenden des Prozesses vermieden wird. Die Ausnahme wird in Application Insights auf der Registerkarte Ausnahmen der Seite Fehler angezeigt, wie im folgenden Screenshot gezeigt.

In dieser Ansicht werden alle Ausnahmen angezeigt, nicht nur die Ausnahmen, 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 hilfreicher.

Proaktive CPU-Überwachung

In Szenarien mit übermäßiger CPU-Auslastung können Sie das Tool für die proaktive CPU-Überwachung verwenden. Informationen zu diesem Tool finden Sie unter Beheben von CPU-Problemen, bevor sie auftreten. Die folgende Abbildung zeigt die Seite Proaktive CPU-Überwachung in 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, für das Sie ein Speicherabbild erfassen möchten, basierend auf den folgenden Datenüberwachungskategorien festlegen:

CPU-Schwellenwert
Schwellenwert sekunden
Überwachungshäufigkeit

CPU-Schwellenwert gibt an, wie viel Computer-CPU der Zielprozess verwendet (in diesem Fall W3WP). Schwellenwert Sekunden ist die Zeitspanne, für die die CPU am CPU-Schwellenwert verwendet wurde. Wenn beispielsweise eine CPU-Auslastung von 75 Prozent für insgesamt 30 Sekunden besteht, wird das Speicherabbild erfasst. Wie auf der Seite Proaktive CPU-Überwachung konfiguriert, wird der Prozess alle 15 Sekunden auf Schwellenwertverletzungen überprüft.

Feature für automatisches Heilen (Speicherlimit)

Das Feature zur automatischen Reparatur (Speicherlimit) ist nützlich, um ein Speicherabbild zu erfassen, wenn der Prozess mehr Arbeitsspeicher verbraucht als erwartet. Achten Sie auch hier auf die Bitanzahl (32 oder 64). Wenn im 32-Bit-Prozesskontext arbeitsspeicherauslastungen auftreten und der Arbeitsspeicherverbrauch erwartet wird, sollten Sie erwägen, die Bitanzahl in 64 zu ändern. Wenn Sie die Bitanzahl ändern, müssen Sie in der Regel auch die Anwendung neu kompilieren.

Wenn Sie die Bitanzahl ändern, wird die Menge des verwendeten Arbeitsspeichers nicht reduziert. Dadurch kann der Prozess mehr als 4 GB Arbeitsspeicher insgesamt verwenden. Wenn der Arbeitsspeicherverbrauch jedoch nicht den Erwartungen entspricht, können Sie dieses Feature verwenden, um zu bestimmen, was den Arbeitsspeicher verbraucht. Anschließend können Sie eine Aktion ausführen, um den Speicherverbrauch zu steuern.

Im Abschnitt "Beschreibungen des erweiterten Azure App Service-Debugfeatures" wird der Link zur automatischen Reparatur auf der Kachel Diagnosetools im ersten Screenshot angezeigt. Wählen Sie diesen Link aus, um direkt zum Feature zu gelangen, oder wählen Sie die Kachel aus, und überprüfen Sie alle verfügbaren Tools auf der Seite Diagnosetools . Weitere Informationen findest du im Abschnitt "Automatische Reparatur" der Übersicht über die Azure App Service-Diagnose.

Das Feature zur automatischen Reparatur wird im folgenden Screenshot gezeigt.

Wenn Sie die Kachel Arbeitsspeicherlimit auswählen, haben Sie die Möglichkeit, einen Speicherwert einzugeben, der die Erfassung eines Speicherabbilds auslöst, wenn dieses Speicherlimit überschritten wird. Wenn Sie beispielsweise 6291456 als Wert eingeben, wird ein Speicherabbild des W3WP-Prozesses erstellt, wenn 6 GB Arbeitsspeicher verbraucht werden.

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

Erweiterte Befehlsbeschreibungen

Die Kunst der Speicherabbildsammlung braucht einige Zeit, um zu lernen, zu erfahren und zu perfekten. Wie Sie gelernt haben, basieren verschiedene Prozeduren auf den Symptomen, die der Prozess anzeigt, wie in der Tabelle im Abschnitt "Beschreibungen zu erweiterten Prozessszenarios" aufgeführt. Im Gegensatz dazu vergleicht die folgende Tabelle den Speicherabbilderfassungsbefehl von Azure App Service mit dem Befehl procdump , den Sie manuell über die Kudu-Konsole ausführen.

Szenario	Azure App Service-Befehl	Befehl "General 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)	Keine (Application Insights)	`procdump -accepteula -ma -e 1 -f <filter> <PID>`
Absturz (nicht behandelte Ausnahmen)	Keine (Application Insights-Momentaufnahmedebugger)	`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 Service verwenden, unterscheiden sich von den Procdump-Befehlen, die Sie verwenden würden, wenn Sie Speicherabbilder manuell erfassen würden. Wenn Sie sich den vorherigen Abschnitt ansehen, sollten Sie feststellen, dass die Konfiguration vom Portal für die Speicherabbildsammlung in Azure App Service verfügbar gemacht wird. Im Szenario mit übermäßigem Arbeitsspeicherverbrauch in der Tabelle enthält der von der Plattform ausgeführte Befehl beispielsweise keinen Arbeitsspeicherschwellenwert. Der Befehl, der in der Befehlsspalte "general procdump" angezeigt wird, gibt jedoch einen Arbeitsspeicherschwellenwert an.

Ein Tool mit dem Namen DaaS (Diagnostics as a Service) ist für die Verwaltung und Überwachung der Konfiguration verantwortlich, die im Azure App Service-Debugportal angegeben ist. Dieses Tool wird als Webauftrag auf den virtuellen Computern (VMs) ausgeführt, auf denen Ihre Web-App ausgeführt wird. Ein Vorteil dieses Tools besteht darin, dass Sie eine bestimmte VM in Ihrer Webfarm als Ziel verwenden können. Wenn Sie versuchen, ein Speicherabbild mithilfe von procdump direkt zu erfassen, kann es schwierig sein, diesen Befehl für eine bestimmte Instanz zu identifizieren, als Ziel festzulegen, darauf zuzugreifen und ihn auszuführen. Weitere Informationen zu DaaS finden Sie unter DaaS – Diagnose als Dienst für Azure-Websites.

Eine übermäßige CPU-Auslastung ist ein weiterer Grund, warum die Plattform die Speicherabbildsammlung so verwaltet, dass sie den empfohlenen Prokdumpmustern entspricht. Der Procdump-Befehl, wie in der vorherigen Tabelle gezeigt, erfasst drei (-n 3) vollständige Speicherabbilder (-ma) im Abstand von 30 Sekunden (-s #, in denen # 30 sind), wenn die CPU-Auslastung größer als 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 wird im Abschnitt "Proaktive CPU-Überwachung" angezeigt . Aus Gründen der Übersichtlichkeit wurden in diesem Abschnitt nur die ersten drei Konfigurationsoptionen angezeigt: CPU-Schwellenwert (-c), Schwellenwertsekunden (-s) und Überwachungshäufigkeit. Der folgende Screenshot zeigt, dass "Aktion konfigurieren", "Maximale Aktionen " (-n) und " Maximale Dauer " zusätzliche Verfügbare Features sind.

Nachdem Sie die verschiedenen Ansätze zum Erfassen von Speicherabbildern untersucht haben, besteht der nächste Schritt darin, die Erstellung von Aufzeichnungen zu üben. Sie können Codebeispiele auf GitHub in Verbindung mit IIS-Debuglabs und Azure Functions verwenden, um jedes szenario zu simulieren, das in den beiden Tabellen aufgeführt ist. Nachdem Sie den Code auf der Azure App Service-Plattform bereitgestellt haben, können Sie diese Tools verwenden, um das Speicherabbild für jedes szenario zu erfassen. Im Laufe der Zeit und nach dem Üben können Sie Ihren Ansatz zum Erfassen von Speicherabbildern mithilfe der Debugfeatures von Azure App Service optimieren. Die folgende Liste enthält einige Vorschläge, die Sie berücksichtigen sollten, wenn Sie mehr über die Speicherabbildsammlung erfahren:

Das Erfassen eines Speicherabbilds beansprucht erhebliche Systemressourcen und beeinträchtigt 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)

Das Analysieren von Speicherabbildern wird in diesem Artikel nicht behandelt. Es gibt jedoch viele Ressourcen für dieses Thema, z. B. die Defragment-Tools-Trainingsreihe und eine Liste der unbedingt benötigten WinDbg-Befehle.

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 beendet wird, nachdem das Speicherabbild erfasst wurde. Eine Einstellung mit dem Namen CollectKillAndAnalyze analysiert das gesammelte Speicherabbild. In diesem Szenario kann die Plattformanalyse das Problem finden, sodass Sie das Speicherabbild nicht in WinDbg öffnen und analysieren müssen.

Es gibt weitere Optionen für die Problembehandlung und Diagnose von Leistungsproblemen auf der Azure App Service-Plattform. Dieser Artikel konzentriert sich auf die Speicherabbildsammlung und gibt einige Empfehlungen für die Behandlung der Diagnose mithilfe dieser Methoden. Wenn Sie Ihre Sammlungsverfahren bereits studiert, erfahren und perfektioniert haben und diese gut für Sie 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