Erstellen von Speicherabbildern auf der Azure-App-Service-Plattform

Zusammenfassung

Dieser Artikel bietet eine Anleitung zu den Debuggingfunktionen des Microsoft Azure App Service für die Erfassung von Speicherabbildern. Das Szenario, in dem Sie ein Speicherabbild zur Behebung eines Leistungs- oder Verfügbarkeitsproblems erfassen, bestimmt die Aufnahmemethode, die Sie verwenden. Das Erfassen eines Speicherabbilds unterscheidet sich z. B. für einen Prozess mit übermäßigem Speicherverbrauch von einem Prozess, der Ausnahmen auslöst oder langsam reagiert. Der Prozess in diesem Kontext ist der Internetinformationsdienste (IIS)-Arbeitsprozess (W3WP, der als w3wp.exe ausgeführt wird).

Zuordnen von Speicherabbildszenarien zu den Debuggingfunktionen des Azure-App-Diensts

Die folgende Tabelle enthält Empfehlungen zu den Befehlen, die von jedem App Service-Feature ausgeführt werden, um ein Speicherabbild zu erstellen. 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, dass wir Anleitungen für unerfahrene Benutzer bereitstellen, die noch keine Vorliebe haben.

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 sein (und wahrscheinlich zu einem Timeout führen) oder langsam. Daher ist ein Szenario ohne Reaktion eines, in dem eine Anforderung länger dauert als erwartet, um ausgeführt zu werden. 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.

Historisch, wenn Entwickler Codeausschnitte nicht in einem Try-Catch-Block platzierten 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, die Codeausführung in Try-Catch-Codeblöcken zu kapseln. Wenn ein Entwickler diese Blöcke verwendet, hat der Code die Möglichkeit, kontrolliert zu fehlschlagen, indem er insbesondere handhabt, 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 vorausgesehen, dass eine Ausnahme auftreten könnte und einen geeigneten Try-Catch-Block um diesen Codeabschnitt implementiert.

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 hinsichtlich der Leistung kostspielige Codepfade. 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 Fehlersuche im Code ist anfangs etwas komplizierter. 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 nachträglichen Fehlerbehebung eines starken CPU-Anstiegs durch das Erstellen eines Speicherabbilds können Sie wahrscheinlich nicht die spezifische Methode ermitteln, die ihn 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 diese Spitzen 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 Menge der 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. Sehen wir uns das empfohlene Tool zum Erfassen von Speicherabbildern auf der Azure App Service-Plattform an.

Erweiterte Funktionsbeschreibungen der Debugging-Features des Azure App Service

In der Tabelle im Abschnitt "Zuordnen von Speicherabbildszenarien zu Azure App Dienste-Debuggingfunktionen" haben wir sechs Debuggingfunktionen identifiziert, die zum Sammeln von Speicherabbildern bestimmt sind. Auf jede dieser Funktionen kann innerhalb des Azure-Portals 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 "Auto-Heal" (Anforderungsdauer)

Das Auto-Heal-Feature (Anforderungsdauer) ist hilfreich, um ein Speicherabbild zu erfassen, 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:

• Ankündigung der neuen automatischen Heilungserfahrung in der App-Dienst-Diagnose

• Ankündigung von Auto Heal für Linux

• Sammeln und Automatisieren von Diagnoseaktionen mit Azure-App Services

Die Funktion "Automatisches Heilen " wird im folgenden Screenshot gezeigt.

Eine weitere Funktion namens "Speicherabbild sammeln" ist in diesem Szenario hilfreich, wenn das Problem derzeit auftritt oder reproduzierbar ist. Diese Funktion ermöglicht das schnelle Erstellen eines Speicherabbilds auf manuelle Anforderung.

Speicherabbildfunktion sammeln

Für diesen Ansatz ist ein manueller Eingriff erforderlich. Der folgende Screenshot zeigt die Seite "Speicherabbild sammeln".

Um die Funktion zu nutzen, wählen Sie ein Speicherkonto aus, in dem das Speicherabbild abgelegt 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überwachungsfunktion

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 Diagnose-Tools:

Informationen dazu, wie Sie die Absturzüberwachungsfunktion in Azure App Service konfigurieren können, finden Sie unter Absturzüberwachung in Azure App Service.

Ablaufverfolgungen in 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 es sich um einen unzulässigen Vorgang handelt:

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);
}

In diesem Codeausschnitt wird die Teilungs-durch-Null-Ausnahme behandelt, 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 Ansprechperson, um nach diesen Arten von Ausnahmen und den Attributen zu fragen, die für die Ursachenanalyse erforderlich sind.

Der beste Ansatz zum Hinzufügen dieser Funktionalität zu Ihrem Anwendungscode hängt vom Anwendungscodestapel und der version ab, die Sie haben. Beispiel: ASP.NET, ASP.NET Core, das MVC-Framework (Model-View-Controller), 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 wird die gleiche Fehlermeldung empfangen, 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 Application Insights Snapshot Debugger 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 einen Beispieltext einer unbehandelten Anwendungsausnahme.

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 über einen Zeitraum von 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.

Auto-Heal-Funktion (Speicherlimit)

Das Feature "Auto-Heal " (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 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.

In dem Abschnitt "Erweiterte Azure App Service Debugging-Featurebeschreibungen" können Sie den Link zu Auto-Heal 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 finden Sie im Abschnitt "Auto-Healing" der Azure App Service-Diagnoseübersicht.

Die Funktion "Automatisches Heilen " wird im folgenden Screenshot gezeigt.

Wenn Sie die Kachel " Speicherbeschränkung " auswählen, können Sie einen Speicherwert eingeben, 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 erstellt, wenn 6 GB Arbeitsspeicher verbraucht werden.

Die Funktion "Speicherabbild sammeln" ist in diesem Szenario nützlich, wenn das Problem aktuell auftritt oder reproduzierbar ist. Diese Funktion ermöglicht das schnelle Erstellen eines Speicherabbilds auf manuelle Anforderung. Weitere Informationen finden Sie im Abschnitt "Sammeln eines Speicherabbilds" .

Erweiterte Befehlsbeschreibungen

Die Kunst der Speicherabbilderfassung benötigt etwas Zeit, um sie zu studieren, zu erleben und zu perfektionieren. Wie in den vorherigen Abschnitten erläutert, 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.

Die Befehle, die Sie in den Speicherabbild-Erfassungsfunktionen in Azure App Service verwenden, unterscheiden sich von den Procdump-Befehlen, die Sie verwenden würden, wenn Sie Dumps manuell erfassen. Wenn Sie den vorherigen Abschnitt überprüfen, sollten Sie feststellen, dass die Speicherabbild-Sammlungs-Portal-Funktion im Azure App Service die Konfiguration einsehbar 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 Service-Debuggingportal 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 wurden in diesem Abschnitt nur die ersten drei Konfigurationsoptionen gezeigt: CPU-Schwellenwert (-c), Schwellenwert in Sekunden (-s) und Überwachungsfrequenz. 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 GitHub-Codebeispiele zusammen mit IIS-Debuglabors und Azure Functions verwenden, um jedes der in den beiden Tabellen aufgeführten Szenarien zu simulieren. 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 mit Übung können Sie Ihren Ansatz für die Erfassung von Speicherabbildern mithilfe der Azure App Service-Dienst-Debuggingfeatures 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 beeinträchtigt die Leistung zusätzlich.

• Das Erfassen von Speicherabbildern bei der ersten Gelegenheit ist nicht optimal, da Sie möglicherweise zu viele erfassen. Diese Speicherabbilder der ersten Chance sind höchstwahrscheinlich irrelevant.

• Wir empfehlen, Application Insights zu deaktivieren, bevor Sie einen W3WP-Speicherauszug 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 zum Thema, z. B. die Schulungsreihe " Defrag Tools " und eine Liste der winDbg-Befehle, die sie benötigen.

Möglicherweise stellen Sie im vorherigen Screenshot die Option " Aktion konfigurieren" fest. Die Standardeinstellung für diese Option ist CollectAndKill. Diese Einstellung bedeutet, dass der Prozess nach der Erfassung des Speicherabbilds getötet wird. Die Einstellung "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 zur Herangehensweise zur Diagnose mit diesen Methoden. Sobald Sie Ihre Sammlungsverfahren studieren, erleben und perfekt gestalten, und sie funktionieren gut für Sie, sollten Sie diese Verfahren weiterhin verwenden.