Probleme beim Neustart von Apps, die durch „Nicht genügend Arbeitsspeicher“-Probleme verursacht werden
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 „Nicht genügend Arbeitsspeicher“-Probleme (Out-of-Memory, OOM) bei Java-Anwendungen in Azure Spring Apps beschrieben.
Typen von „Nicht genügend Arbeitsspeicher“-Problemen (OOM)
Es gibt zwei Arten von OOM-Problemen: Container OOM und JVM OOM.
Container OOM, auch als System OOM bezeichnet, tritt auf, wenn der verfügbare App-Speicher ausgegangen ist. Das „Container OOM“-Problem verursacht App-Neustartereignisse, die im Abschnitt Ressourcenintegrität (Resource Health) des Azure-Portals gemeldet werden. Normalerweise wird Container OOM durch fehlerhafte Konfigurationen der Speichergröße verursacht.
JVM OOM tritt auf, wenn die Menge des verwendeten Arbeitsspeichers die in JVM-Optionen festgelegte maximale Größe erreicht hat. JVM OOM führt zu keinen Neustarts von Apps. Normalerweise ist JVM OOM ein Ergebnis von schlechtem Code, den Sie finden können, indem Sie nach
java.lang.OutOfMemoryError-Ausnahmen im Anwendungsprotokoll suchen. JVM OOM wirkt sich negativ auf Anwendungen und Java-Profilerstellungstools wie Java Flight Recorder aus.
Dieser Artikel konzentriert sich darauf, wie „Container OOM“-Probleme behoben werden. Um „JVM OOM“-Probleme zu beheben, überprüfen Sie Tools wie Heapabbild, Threadabbild und Java Flight Recorder. Weitere Informationen finden Sie unter Manuelles Erfassen von Heap- und Threadabbildern und Verwenden von JFR in Azure Spring Apps.
Beheben von Problemen durch Neustarts von Apps wegen OOM
In den folgenden Abschnitten werden die Tools, Metriken und JVM-Optionen beschrieben, mit denen Sie „Container OOM“-Probleme diagnostizieren und beheben können.
Anzeigen von Warnungen auf der Seite „Ressourcenintegrität“ (Resource Health)
Auf der Seite Ressourcenintegrität im Azure-Portal werden App-Neustartereignisse aufgrund von Container OOM angezeigt, wie im folgenden Screenshot gezeigt:
Konfigurieren der Arbeitsspeichergröße
Die Metriken App-Arbeitsspeicherauslastung, jvm.memory.used und jvm.memory.committed bieten eine Ansicht der Arbeitsspeicherauslastung. Weitere Informationen finden Sie im Abschnitt Metriken von Tools zum Behandeln von Arbeitsspeicherproblemen. Konfigurieren Sie die maximalen Speichergrößen mit JVM-Optionen, um sicherzustellen, dass der Arbeitsspeicher unter dem Grenzwert liegt.
Die Summe der maximalen Speichergrößen aller Bereiche im Java-Speichermodell sollte kleiner als der tatsächlich verfügbare App-Arbeitsspeicher sein. Informationen zum Festlegen der maximalen Speichergrößen finden Sie in dem typischen Speicherlayout, das im Abschnitt Speichernutzungslayout von Java-Speicherverwaltung beschrieben ist.
Suchen Sie ein Gleichgewicht, wenn Sie die maximale Speichergröße festlegen. Wenn Sie die maximale Speichergröße zu hoch festlegen, besteht ein Risiko für Container OOM. Wenn Sie die maximale Speichergröße zu niedrig festlegen, besteht ein Risiko für JVM OOM, und die Garbage Collection wird die App verlangsamen.
Steuern des Heapspeichers
Sie können die maximale Heapgröße mithilfe der JVM-Optionen -Xms, -Xmx, -XX:InitialRAMPercentage und -XX:MaxRAMPercentage festlegen.
Möglicherweise müssen Sie die Einstellungen für die maximale Heapgröße anpassen, wenn der Wert von jvm.memory.used in den Metriken zu hoch ist. Weitere Informationen finden Sie im Abschnitt jvm.memory.used/commit/max von Tools zum Behandeln von Arbeitsspeicherproblemen.
Steuern des direkten Speichers
Es ist aus folgenden Gründen wichtig, die JVM-Option -XX:MaxDirectMemorySize festzulegen:
- Sie können möglicherweise nicht feststellen, wenn Frameworks wie nio und gzip direkten Arbeitsspeicher verwenden.
- Die Garbage Collection des direkten Speichers wird nur während der Full GC erledigt, und Full GC tritt nur auf, wenn der Heap nahezu voll ist.
Normalerweise können Sie MaxDirectMemorySize auf einen Wert festlegen, der niedriger als die App-Speichergröße, abzüglich des Heapspeichers und abzüglich des Nicht-Heapspeichers ist.
Steuern des Metaspace
Sie können die maximale Größe des Metaspace festlegen, indem Sie die JVM-Option -XX:MaxMetaspaceSize festlegen. Die Option -XX:MetaspaceSize legt den Schwellenwert fest, um Full GC auszulösen.
Der Metaspace-Speicher ist in der Regel stabil.