Dela via

Problem med omstart av appar som orsakas av problem med minnesbrist

  • Artikel

Kommentar

Basic-, Standard- och Enterprise-planerna kommer att vara inaktuella från och med mitten av mars 2025, med en 3-årig pensionsperiod. Vi rekommenderar att du övergår till Azure Container Apps. Mer information finns i meddelandet om azure Spring Apps-pensionering.

Standardförbrukningen och den dedikerade planen kommer att vara inaktuell från och med den 30 september 2024, med en fullständig avstängning efter sex månader. Vi rekommenderar att du övergår till Azure Container Apps. Mer information finns i Migrera Azure Spring Apps Standard-fö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 heapdump, tråddumpning och Java Flight Recorder. Mer information finns i Avbilda heapdump och tråddumpning manuellt och använda 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åg finns det en risk för JVM OOM, och skräpinsamlingen kommer att vara av och saktar ned appen.

Kontrollera heapminne

Du kan ange maximal heapstorlek med hjälp -Xmsav alternativen , -Xmx, -XX:InitialRAMPercentageoch -XX:MaxRAMPercentage JVM.

Du kan behöva justera inställningarna för maximal heapstorlek när värdet jvm.memory.used för är för högt i måtten. 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.
  • Skräpinsamling av direktminne hanteras endast under fullständig skräpinsamling, och fullständig skräpinsamling sker endast när heapen är nästan 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 ange den maximala metarymdsstorleken genom att -XX:MaxMetaspaceSize ange JVM-alternativet. Alternativet -XX:MetaspaceSize anger tröskelvärdet för att utlösa fullständig skräpinsamling.

Metaområdesminnet är vanligtvis stabilt.

Se även