Tools zum Behandeln von Arbeitsspeicherproblemen
Hinweis
Die Pläne Basic, Standard und Enterprise gelten ab Mitte März 2025 als veraltet und werden über einen Zeitraum von drei Jahren eingestellt. Es wird empfohlen, auf Azure Container Apps umzustellen. Weitere Informationen finden Sie in der Ankündigung zur Einstellung von Azure Spring Apps.
Der Plan Standardverbrauch und dediziert gilt ab dem 30. September 2024 als veraltet und wird nach sechs Monaten vollständig eingestellt. Es wird empfohlen, auf Azure Container Apps umzustellen. Weitere Informationen finden Sie unter Migrieren des Plans „Standardverbrauch und dediziert“ von Azure Spring Apps zu Azure Container Apps.
Dieser Artikel gilt für:✅ Basic/Standard ✅ Enterprise
In diesem Artikel werden verschiedene Tools beschrieben, die für die Behandlung von Java-Arbeitsspeicherproblemen nützlich sind. Sie können diese Tools in vielen Szenarien verwenden, die nicht auf Arbeitsspeicherprobleme beschränkt sind, aber dieser Artikel konzentriert sich nur auf das Thema Arbeitsspeicher.
Warnungen und Diagnosen
In den folgenden Abschnitten werden Ressourcenintegritätswarnungen und Diagnosen beschrieben, die über das Azure-Portal verfügbar sind.
Ressourcenintegrität
Mit dem Azure-Aktivitätsprotokoll und Azure Service Health können Sie App-Lebenszyklusereignisse überwachen und Warnungen einrichten. Weitere Informationen finden Sie unter Überwachen von App-Lebenszyklusereignissen mithilfe des Azure-Aktivitätsprotokolls und der Azure Service Health.
Die Ressourcenintegrität sendet Warnungen zu App-Neustartereignissen aufgrund von „Nicht genügend Arbeitsspeicher“-Containerproblemen (OOM). Weitere Informationen finden Sie unter App-Neustartprobleme wegen „Nicht genügend Arbeitsspeicher“-Problemen.
Der folgende Screenshot zeigt eine App-Ressourcenintegritätswarnung, die ein OOM-Problem angibt.
Diagnose und Problembehandlung
Die Azure Spring Apps-Diagnose ist ein interaktives Verfahren, das Sie bei der Problembehandlung Ihrer App ohne Konfiguration unterstützt. Weitere Informationen finden Sie unter Selbstdiagnose und Lösungen von Problemen in Azure Spring Apps.
Im Azure-Portal finden Sie die Arbeitsspeicherauslastung unter Diagnose und Problembehandlung, wie im folgenden Screenshot gezeigt.
Die Arbeitsspeicherauslastung bietet eine einfache Diagnose für die Auslastung des App-Arbeitsspeichers, wie im folgenden Screenshot gezeigt.
Metriken
In den folgenden Abschnitten werden Metriken beschrieben, die Probleme einschließlich hoher Arbeitsspeicherauslastung, zu großem Heapspeicher und Garbage Collection-Anomalie (zu häufig oder nicht häufig genug) abdecken. Weitere Informationen finden Sie unter Schnellstart: Überwachen von Azure Spring Apps-Apps mit Protokollen, Metriken und Ablaufverfolgung.
App-Arbeitsspeicherauslastung
Die App-Arbeitsspeicherauslastung ist ein Prozentsatz, der dem App-Speicher, dividiert durch den App-Arbeitsspeichergrenzwert, entspricht. Dieser Wert zeigt den gesamten App-Arbeitsspeicher an.
jvm.memory.used/committed/max
Für den JVM-Speicher gibt es drei Metriken: jvm.memory.used, jvm.memory.committed und jvm.memory.max, die in der folgenden Liste beschrieben werden.
„JVM-Speicher“ (jvm.memory) ist kein klar definiertes Konzept. Hier ist jvm.memory die Summe aus dem Heapspeicher und dem früheren permGen-Teil des Nicht-Heapspeichers. JVM-Speicher enthält keinen direkten Arbeitsspeicher oder anderen Speicher wie den Threadstapel. Spring Boot Actuator sammelt diese drei Metriken und bestimmt den Geltungsbereich von jvm.memory.
jvm.memory.usedist die Menge des verwendeten JVM-Speichers, einschließlich des verwendeten Heapspeichers und des verwendeten früheren permGen-Teils im Nicht-Heapspeicher.jvm.memory.usedist eine wichtige Repräsentation der Veränderung des Heapspeichers, da der frühere permGen-Teil in der Regel stabil ist.Wenn Sie
jvm.memory.usedzu groß finden, erwägen Sie, eine kleinere maximale Heapspeichergröße festzulegen.jvm.memory.committedist die Menge des Arbeitsspeichers, der zur Nutzung für JVM reserviert ist. Die Größe vonjvm.memory.committedist im Grunde der Grenzwert des nutzbaren JVM-Speichers.jvm.memory.maxist die maximale Menge an JVM-Speicher, nicht zu verwechseln mit der tatsächlich verfügbaren Menge.Der Wert von
jvm.memory.maxkann manchmal verwirrend sein, da er wesentlich höher als der verfügbare App-Arbeitsspeicher sein kann. Um dies zu erläutern:jvm.memory.maxist die Summe aller maximalen Größen des Heapspeichers und des früheren permGen-Teil des Nicht-Heapspeichers, unabhängig vom tatsächlich verfügbaren Arbeitsspeicher. Wenn beispielsweise für eine App im Azure Spring Apps-Portal 1 GB Arbeitsspeicher festgelegt ist, beträgt die Standardgröße des Heapspeichers 0,5 GB. Weitere Informationen finden Sie im Abschnitt Standardmäßige maximale Heapgröße von Java-Speicherverwaltung.Wenn die Standardgröße des komprimierten Klassenspeicherplatzes 1 GB beträgt, ist der Wert von
jvm.memory.maxgrößer als 1,5 GB, unabhängig davon, ob die App-Speichergröße 1 GB beträgt. Weitere Informationen finden Sie in der Oracle-Dokumentation unter Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide: Other Considerations.
jvm.gc.memory.allocated/promoted
Diese beiden Metriken dienen der Beobachtung der Java Garbage Collection (GC). Weitere Informationen finden Sie im Abschnitt Java Garbage Collection von Java-Speicherverwaltung. Die maximale Heapgröße beeinflusst die Häufigkeit der geringfügigen GC und der vollständigen GC. Die maximale Größe des Metaspace und des direkten Speichers beeinflussen Full GC. Wenn Sie die Häufigkeit der Garbage Collection anpassen möchten, erwägen Sie eine Änderung der folgenden maximalen Speichergrößen.
jvm.gc.memory.allocatedist die Menge, um die der Speicherpool der neuen Generation nach einer Garbage Collection und vor der nächsten vergrößert wird. Dieser Wert gibt die geringfügige GC wieder.jvm.gc.memory.promotedist die Menge, um die der Speicherpool der alten Generation nach einer GC vergrößert wird. Dieser Wert gibt die vollständige GC wieder.
Sie finden dieses Feature im Azure-Portal, wie im folgenden Screenshot gezeigt. Sie können bestimmte Metriken auswählen und Filter für eine bestimmte App, Bereitstellung oder Instanz hinzufügen. Sie können auch eine Teilung anwenden.
Weiteres Debuggen
Für ein weiteres Debuggen können Sie Heapabbilder und Threadabbilder manuell erfassen und Java Flight Recorder (JFR) verwenden. Weitere Informationen finden Sie unter Manuelles Erfassen von Heap- und Threadabbildern und Verwenden von JFR in Azure Spring Apps.
Heapspeicherabbilder zeichnen den Zustand des Java-Heapspeichers auf. Threadspeicherabbilder zeichnen die Stapel aller Livethreads auf. Diese Tools sind über die Azure CLI und auf der App-Seite des Azure-Portals verfügbar, wie im folgenden Screenshot gezeigt.
Weitere Informationen finden Sie unter Manuelles Erfassen von Heap- und Threadabbildern und Verwenden von JFR in Azure Spring Apps. Sie können auch Tools von Drittanbietern wie Memory Analyzer verwenden, um Heapabbilder zu analysieren.
Ändern von Konfigurationen zum Beheben von Problemen
Einige Probleme, die Sie möglicherweise identifizieren, umfassen Container-OOM, zu großen Heapspeicher und Garbage Collection-Anomalien. Wenn Sie eins dieser Probleme identifizieren, müssen Sie möglicherweise die maximale Arbeitsspeichergröße in den JVM-Optionen konfigurieren. Weitere Informationen finden Sie im Abschnitt Wichtige JVM-Optionen von Java-Speicherverwaltung.
Sie können die JVM-Optionen mithilfe des Azure-Portals oder der Azure CLI ändern.
Navigieren Sie im Azure-Portal zu Ihrer App, und wählen Sie dann im Abschnitt Einstellungen des Navigationsmenüs die Option Konfiguration aus. Aktualisieren Sie auf der Registerkarte Allgemeine Einstellungen das Feld JVM-Optionen, wie im folgenden Screenshot gezeigt:
