Verktyg för att felsöka minnesproblem
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 olika verktyg som är användbara för att felsöka Problem med Java-minne. Du kan använda dessa verktyg i många scenarier som inte är begränsade till minnesproblem, men den här artikeln fokuserar bara på minnesämnet.
Aviseringar och diagnostik
I följande avsnitt beskrivs resurshälsoaviseringar och diagnostik som är tillgängliga via Azure Portal.
Resurshälsa
Du kan övervaka händelser i appens livscykel och konfigurera aviseringar med Azure Activity Log och Azure Service Health. Mer information finns i Övervaka applivscykelhändelser med hjälp av Azure-aktivitetsloggen och Azure Service Health.
Resurshälsa skickar aviseringar om appomstartshändelser på grund av OOM-problem (out-of-memory). Mer information finns i Problem med omstart av appar som orsakas av minnesbrist.
Följande skärmbild visar en hälsoavisering för appresurser som anger ett OOM-problem.
Diagnostisera och lösa problem
Azure Spring Apps-diagnostik är en interaktiv upplevelse för att felsöka din app utan konfiguration. Mer information finns i Självdiagnostisera och lösa problem i Azure Spring Apps.
I Azure Portal hittar du minnesanvändning under Diagnostisera och lösa problem, som du ser i följande skärmbild.
Minnesanvändning ger en enkel diagnos för appminnesanvändning, enligt följande skärmbild.
Mått
I följande avsnitt beskrivs mått som omfattar problem med hög minnesanvändning, hög minnesanvändning som är för stort och onormal skräpinsamling onormal (för ofta eller inte tillräckligt ofta). Mer information finns i Snabbstart: Övervaka Azure Spring Apps-appar med loggar, mått och spårning.
Användning av appminne
Appminnesanvändningen är en procentandel som är lika med det appminne som används dividerat med appens minnesgräns. Det här värdet visar hela appminnet.
jvm.memory.used/committed/max
För JVM-minne finns det tre mått: jvm.memory.used
, jvm.memory.committed
och jvm.memory.max
, som beskrivs i följande lista.
"JVM-minne" är inte ett tydligt definierat begrepp. jvm.memory
Här är summan av heapminnet och den tidigare permGen-delen av icke-heapminnet. JVM-minnet innehåller inte direkt minne eller annat minne som trådstacken. Spring Boot-aktuatorn samlar in dessa tre mått och avgör omfånget jvm.memory
för .
jvm.memory.used
är mängden använt JVM-minne, inklusive använt heapminne och använt tidigare permGen i icke-heapminne.jvm.memory.used
är en stor återspegling av förändringen av heapminnet, eftersom den tidigare permGen-delen vanligtvis är stabil.Om du tycker att det är
jvm.memory.used
för stort kan du överväga att ange en mindre maximal minnesstorlek för heap.jvm.memory.committed
är mängden minne som har checkats in för den JVM som ska användas. Storleken påjvm.memory.committed
är i princip gränsen för användbart JVM-minne.jvm.memory.max
är den maximala mängden JVM-minne, som inte ska förväxlas med den verkliga tillgängliga mängden.Värdet för
jvm.memory.max
kan ibland vara förvirrande eftersom det kan vara mycket högre än det tillgängliga appminnet. För att klargöra,jvm.memory.max
är summan av alla maximala storlekar av heapminne och den tidigare permGen delen av icke-heap minne, oavsett det verkliga tillgängliga minnet. Om en app till exempel har angetts med 1 GB minne i Azure Spring Apps-portalen är standardstorleken för heapminnet 0,5 GB. Mer information finns i avsnittet Maximal heapstorlek för standard i Java-minneshantering.Om standardstorleken för komprimerat klassutrymme är 1 GB är värdet
jvm.memory.max
för större än 1,5 GB oavsett om appens minnesstorlek är 1 GB. Mer information finns i Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide: Andra överväganden i Oracle-dokumentationen .
jvm.gc.memory.allocated/promoted
Dessa två mått är till för att observera Java-skräpinsamling (GC). Mer information finns i avsnittet Java-skräpinsamling i Java-minneshantering. Den maximala heapstorleken påverkar frekvensen för mindre GC och fullständig GC. Den maximala metarymden och den maximala direkta minnesstorleken påverkar fullständig GC. Om du vill justera frekvensen för skräpinsamling bör du överväga att ändra följande maximala minnesstorlekar.
jvm.gc.memory.allocated
är mängden ökning av storleken på den unga generationens minnespool efter en GC och före nästa. Det här värdet återspeglar mindre GC.jvm.gc.memory.promoted
är mängden ökning av storleken på den gamla generationens minnespool efter GC. Det här värdet återspeglar fullständig GC.
Du hittar den här funktionen på Azure Portal, som du ser i följande skärmbild. Du kan välja specifika mått och lägga till filter för en specifik app, distribution eller instans. Du kan också använda delning.
Ytterligare felsökning
För ytterligare felsökning kan du manuellt samla in heapdumpar och tråddumpar och använda Java Flight Recorder (JFR). Mer information finns i Avbilda heapdump och tråddumpning manuellt och använda Java Flight Recorder i Azure Spring Apps.
Heap dumpar registrerar tillståndet för Java-heapminnet. Tråddumpar registrerar staplarna för alla aktiva trådar. Dessa verktyg är tillgängliga via Azure CLI och på appsidan för Azure Portal, som du ser i följande skärmbild.
Mer information finns i Avbilda heapdump och tråddumpning manuellt och använda Java Flight Recorder i Azure Spring Apps. Du kan också använda verktyg från tredje part som Memory Analyzer för att analysera heapdumpar.
Ändra konfigurationer för att åtgärda problem
Några problem som du kan identifiera är container-OOM, heapminne som är för stort och onormal skräpinsamling. Om du identifierar något av dessa problem kan du behöva konfigurera den maximala minnesstorleken i JVM-alternativen. Mer information finns i avsnittet Viktiga JVM-alternativ i Java-minneshantering.
Du kan ändra JVM-alternativen med hjälp av Azure Portal eller Azure CLI.
I Azure Portal navigerar du till din app och väljer sedan Konfiguration i avsnittet Inställningar i navigeringsmenyn. På fliken Allmänna inställningar uppdaterar du fältet JVM-alternativ enligt följande skärmbild: