Dela via

Problem med omstart av appar som orsakas av problem med minnesbrist

Kommentar

Planerna Basic, Standardoch Enterprise gick in i en pensionsperiod den 17 mars 2025. Mer information finns i meddelandet om azure Spring Apps-pensionering.

Planen Standard consumption och den dedikerade gick in i en pensionsperiod den 30 september 2024, med en fullständig avstängning i slutet av mars 2025. Mer information finns i Migrera Azure Spring Apps standardförbrukning och dedikerad plan till Azure Container Apps.

Den här artikeln gäller för:✅ Basic/Standard ✅ Enterprise

Den här artikeln beskriver OOM-problem (out-of-memory) för Java-program i Azure Spring Apps.

Typer av problem med slut på minne

Det finns två typer av problem med minnesbrist: container-OOM och JVM OOM.

  • Container-OOM, även kallat system-OOM, inträffar när det tillgängliga appminnet har tagit slut. Problem med container-OOM orsakar omstartshändelser för appar, som rapporteras i avsnittet Resource Health i Azure Portal. Normalt orsakas container-OOM av felaktiga konfigurationer av minnesstorlek.

  • JVM OOM inträffar när mängden använt minne har nått den maximala storleken som anges i JVM-alternativ. JVM OOM gör inte att en app startas om. Normalt är JVM OOM ett resultat av felaktig kod, som du kan hitta genom att söka java.lang.OutOfMemoryError efter undantag i programloggen. JVM OOM har en negativ effekt på program- och Java-profileringsverktyg, till exempel Java Flight Recorder.

Den här artikeln fokuserar på hur du åtgärdar problem med container-OOM. Om du vill åtgärda JVM OOM-problem kontrollerar du verktyg som heap-dump, tråddump och Java Flight Recorder. Mer information finns i Avbilda heap dump och tråddumpning manuellt och använd Java Flight Recorder i Azure Spring Apps.

Åtgärda problem med omstart av appar på grund av OOM

I följande avsnitt beskrivs de verktyg, mått och JVM-alternativ som du kan använda för att diagnostisera och åtgärda problem med container-OOM.

Visa aviseringar på sidan Resurshälsa

Sidan Resurshälsa på Azure Portal visar händelser för omstart av appen på grund av containerns OOM, enligt följande skärmbild:

Skärmbild av Azure Portal som visar sidan Resurshälsa för Azure Spring Apps med OOM-meddelande markerat.

Konfigurera minnesstorlek

Måtten Appminnesanvändning, jvm.memory.usedoch jvm.memory.committed ger en vy över minnesanvändning. Mer information finns i avsnittet Mått i Verktyg för att felsöka minnesproblem. Konfigurera de maximala minnesstorlekarna i JVM-alternativen för att säkerställa att minnet ligger under gränsen.

Summan av de maximala minnesstorlekarna för alla delar i Java-minnesmodellen ska vara mindre än det verkliga tillgängliga appminnet. Om du vill ange maximala minnesstorlekar kan du läsa den typiska minneslayouten som beskrivs i avsnittet Minnesanvändningslayout i Java-minneshantering.

Hitta en balans när du anger den maximala minnesstorleken. När du anger den maximala minnesstorleken för hög finns det en risk för containerns OOM. När du anger den maximala minnesstorleken för lågt finns det en risk för JVM OutOfMemoryError, och skräpinsamlingen kommer att påverkas och kommer att sakta ned appen.

Kontrollera heapminne

Du kan ange den maximala heapstorleken med hjälp av JVM-alternativen -Xms, -Xmx, -XX:InitialRAMPercentage och -XX:MaxRAMPercentage.

Du kan behöva justera inställningarna för maximal heap när värdet av jvm.memory.used är för högt i metrik. Mer information finns i avsnittet jvm.memory.used/committed/max i Verktyg för att felsöka minnesproblem.

Kontrollera direktminne

Det är viktigt att ange -XX:MaxDirectMemorySize JVM-alternativet av följande skäl:

  • Du kanske inte märker när ramverk som nio och gzip använder direkt minne.
  • Avfallshantering av direktminne utförs endast under en fullständig avfallshantering, och en fullständig avfallshantering sker endast när högen nästan är full.

Normalt kan du ange MaxDirectMemorySize ett värde som är mindre än appens minnesstorlek minus heapminnet minus minnet som inte är heapminnet.

Kontrollera metaområde

Du kan ställa in den maximala metarymdsstorleken genom JVM-alternativet -XX:MaxMetaspaceSize. Alternativet -XX:MetaspaceSize anger tröskelvärdet för att utlösa fullständig skräpinsamling.

Metaområdesminnet är vanligtvis stabilt.

Se även