Problemen met opnieuw opstarten van apps die worden veroorzaakt door problemen met onvoldoende geheugen
Notitie
De Basic-, Standard- en Enterprise-abonnementen worden afgeschaft vanaf medio maart 2025, met een pensioenperiode van 3 jaar. We raden u aan om over te stappen naar Azure Container Apps. Zie de aankondiging over buitengebruikstelling van Azure Spring Apps voor meer informatie.
Het standaardverbruik en het speciale abonnement worden vanaf 30 september 2024 afgeschaft, met een volledige afsluiting na zes maanden. We raden u aan om over te stappen naar Azure Container Apps. Zie Azure Spring Apps Standard-verbruik en toegewezen abonnement migreren naar Azure Container Apps voor meer informatie.
Dit artikel is van toepassing op: ✔️ Basic/Standard ✔️ Enterprise
In dit artikel worden problemen met onvoldoende geheugen (OOM) voor Java-toepassingen in Azure Spring Apps beschreven.
Typen problemen met onvoldoende geheugen
Er zijn twee soorten problemen met onvoldoende geheugen: container OOM en JVM OOM.
Container OOM, ook wel systeem-OOM genoemd, treedt op wanneer het beschikbare app-geheugen is opgelopen. Container OOM-probleem veroorzaakt opnieuw opstarten van apps, die worden gerapporteerd in de sectie Resource Health van Azure Portal. Normaal gesproken wordt container-OOM veroorzaakt door onjuiste configuraties van de geheugengrootte.
JVM OOM treedt op wanneer de hoeveelheid gebruikt geheugen de maximale grootte heeft bereikt die is ingesteld in JVM-opties. JVM OOM zorgt er niet voor dat een app opnieuw wordt opgestart. Normaal gesproken is JVM OOM een resultaat van ongeldige code, die u kunt vinden door te zoeken naar
java.lang.OutOfMemoryErroruitzonderingen in het toepassingslogboek. JVM OOM heeft een negatief effect op de hulpprogramma's voor toepassings- en Java-profilering, zoals Java Flight Recorder.
Dit artikel is gericht op het oplossen van problemen met container-OOM. Als u JVM OOM-problemen wilt oplossen, controleert u hulpprogramma's zoals heapdump, threaddump en Java Flight Recorder. Zie Capture heapdump en threaddump handmatig en gebruik Java Flight Recorder in Azure Spring Apps voor meer informatie.
Problemen met opnieuw opstarten van apps oplossen vanwege OOM
In de volgende secties worden de hulpprogramma's, metrische gegevens en JVM-opties beschreven die u kunt gebruiken om problemen met container-OOM vast te stellen en op te lossen.
Waarschuwingen weergeven op de pagina Resourcestatus
Op de pagina Resourcestatus in Azure Portal worden gebeurtenissen voor het opnieuw opstarten van apps weergegeven vanwege container-OOM, zoals wordt weergegeven in de volgende schermopname:
Geheugengrootte configureren
Het geheugengebruikjvm.memory.used van de app voor metrische gegevens en jvm.memory.committed geeft een overzicht van het geheugengebruik. Zie de sectie Metrische gegevens van Hulpprogramma's voor het oplossen van geheugenproblemen voor meer informatie. Configureer de maximale geheugengrootten in JVM-opties om ervoor te zorgen dat het geheugen onder de limiet valt.
De som van de maximale geheugengrootten van alle onderdelen in het Java-geheugenmodel moet kleiner zijn dan het werkelijke beschikbare app-geheugen. Als u de maximale geheugengrootten wilt instellen, raadpleegt u de typische geheugenindeling die wordt beschreven in de sectie Geheugengebruik van Java-geheugenbeheer.
Zoek een balans wanneer u de maximale geheugengrootte instelt. Wanneer u de maximale geheugengrootte te hoog instelt, is er een risico op container-OOM. Wanneer u de maximale geheugengrootte te laag instelt, bestaat het risico op JVM OOM en wordt de garbagecollection van de app vertraagd.
Heap-geheugen beheren
U kunt de maximale heapgrootte instellen met behulp van de -Xmsopties , -Xmxen -XX:MaxRAMPercentage -XX:InitialRAMPercentageJVM.
Mogelijk moet u de instellingen voor de maximale heapgrootte aanpassen wanneer de waarde jvm.memory.used te hoog is in de metrische gegevens. Zie de sectie jvm.memory.used/commit/max van Tools voor het oplossen van geheugenproblemen voor meer informatie.
Direct geheugen beheren
Het is belangrijk om de -XX:MaxDirectMemorySize JVM-optie in te stellen om de volgende redenen:
- U ziet mogelijk niet wanneer frameworks zoals nio en gzip direct geheugen gebruiken.
- Garbagecollection van direct geheugen wordt alleen verwerkt tijdens volledige garbagecollection en volledige garbagecollection vindt alleen plaats wanneer de heap bijna vol is.
Normaal gesproken kunt u instellen MaxDirectMemorySize op een waarde die kleiner is dan de grootte van het app-geheugen min het heap-geheugen minus het niet-heapgeheugen.
Besturingselementmetaruimte
U kunt de maximale grootte van de metaruimte instellen door de -XX:MaxMetaspaceSize JVM-optie in te stellen. Met -XX:MetaspaceSize de optie wordt de drempelwaarde ingesteld om volledige garbagecollection te activeren.
Metaspacegeheugen is meestal stabiel.