Strumenti per risolvere i problemi di memoria
Nota
I piani Basic, Standard ed Enterprise saranno deprecati a partire dalla metà di marzo 2025, con un periodo di ritiro di 3 anni. È consigliabile eseguire la transizione ad App Azure Container. Per altre informazioni, vedere l'annuncio di ritiro di Azure Spring Apps.
Il piano Standard a consumo e dedicato sarà deprecato a partire dal 30 settembre 2024, con un arresto completo dopo sei mesi. È consigliabile eseguire la transizione ad App Azure Container. Per altre informazioni, vedere Eseguire la migrazione del consumo di Azure Spring Apps Standard e del piano dedicato alle app Azure Container.
Questo articolo si applica a:✅ Basic/Standard ✅ Enterprise
Questo articolo descrive vari strumenti utili per la risoluzione dei problemi di memoria Java. È possibile usare questi strumenti in molti scenari non limitati ai problemi di memoria, ma questo articolo è incentrato solo sull'argomento della memoria.
Avvisi e diagnostica
Le sezioni seguenti descrivono gli avvisi di integrità delle risorse e la diagnostica disponibile tramite il portale di Azure.
Integrità delle risorse
È possibile monitorare gli eventi del ciclo di vita delle app e configurare gli avvisi con il log attività di Azure e Integrità dei servizi di Azure. Per altre informazioni, vedere Monitorare gli eventi del ciclo di vita delle app usando il log attività di Azure e Integrità dei servizi di Azure.
Integrità risorse invia avvisi sugli eventi di riavvio dell'app dovuti a problemi di memoria insufficiente del contenitore. Per altre informazioni, vedere Problemi di riavvio delle app causati da problemi di memoria insufficiente.
Lo screenshot seguente mostra un avviso di integrità delle risorse dell'app che indica un problema di OOM.
Diagnostica e risoluzione dei problemi
La diagnostica di Azure Spring Apps è un'esperienza interattiva per risolvere i problemi dell'app senza configurazione. Per altre informazioni, vedere Diagnostica automatica e risoluzione dei problemi in Azure Spring Apps.
Nel portale di Azure è possibile trovare Utilizzo memoria in Diagnostica e risoluzione dei problemi, come illustrato nello screenshot seguente.
Utilizzo memoria fornisce una diagnosi semplice per l'utilizzo della memoria dell'app, come illustrato nello screenshot seguente.
Metrica
Le sezioni seguenti descrivono le metriche che illustrano i problemi, tra cui utilizzo elevato della memoria, memoria heap troppo grande e Garbage Collection anomali (troppo frequenti o non abbastanza frequenti). Per altre informazioni, vedere Avvio rapido: Monitoraggio delle app di Azure Spring Apps con log, metriche e traccia.
Utilizzo memoria dell'app
L'utilizzo della memoria dell'app è una percentuale pari alla memoria dell’app utilizzata divisa per il limite di memoria dell’app. Questo valore mostra l'intera memoria dell'app.
jvm.memory.used/committed/max
Per la memoria JVM sono disponibili tre metriche: jvm.memory.used, jvm.memory.committed e jvm.memory.max, descritte nell'elenco seguente.
"Memoria JVM" non è un concetto chiaramente definito. In questo contesto, jvm.memory è la somma della memoria heap e della parte permGen precedente della memoria non heap. La memoria JVM non include memoria diretta o altra memoria come lo stack di thread. L'attuatore Spring Boot raccoglie queste tre metriche e determina l'ambito di jvm.memory.
jvm.memory.usedè la quantità di memoria JVM usata, inclusa la memoria heap usata e la permGen precedente usata nella memoria non heap.jvm.memory.usedè una riflessione importante della modifica della memoria dell'heap, perché la parte precedente permGen è in genere stabile.Se si ritiene
jvm.memory.useddi dimensioni troppo grandi, è consigliabile impostare dimensioni massime di memoria heap inferiori.jvm.memory.committedè la quantità di memoria impegnata per l'uso della JVM. Le dimensioni dijvm.memory.committedsono fondamentalmente il limite di memoria JVM utilizzabile.jvm.memory.maxè la quantità massima di memoria JVM, da non confondere con la quantità disponibile reale.Il valore di
jvm.memory.maxpuò talvolta generare confusione perché può essere molto più alto rispetto alla memoria dell'app disponibile. Per chiarire,jvm.memory.maxè la somma di tutte le dimensioni massime della memoria heap e della parte precedente permGen della memoria non heap, indipendentemente dalla memoria disponibile reale. Ad esempio, se un'app è impostata con 1 GB di memoria nel portale di Azure Spring Apps, le dimensioni di memoria heap predefinite sono pari a 0,5 GB. Per altre informazioni, vedere la sezione Dimensioni massime predefinite dell'heap di Gestione della memoria Java.Se la dimensione predefinita dello spazio della classe compressa è 1 GB, il valore di
jvm.memory.maxè maggiore di 1,5 GB indipendentemente dal fatto che la dimensione della memoria dell'app sia 1 GB. Per altre informazioni, vedere Piattaforma Java, guida alla regolazione della Garbage Collection macchina virtuale HotSpot Standard Edition: altre considerazioni nella documentazione di Oracle.
jvm.gc.memory.allocated/promoted
Queste due metriche sono destinate all'osservazione di Java Garbage Collection (GC). Per altre informazioni, vedere la sezione Garbage Collection Java di Gestione della memoria Java. Le dimensioni massime dell'heap influiscono sulla frequenza di esecuzione di GC secondario e GC completo. Le dimensioni massime del metaspazio e della memoria diretta influiscono su GC completo. Se si vuole modificare la frequenza di Garbage Collection, è consigliabile modificare le dimensioni massime di memoria seguenti.
jvm.gc.memory.allocatedè la quantità di aumento delle dimensioni del pool di memoria di giovane generazione dopo una GC e prima della successiva. Questo valore riflette una GC secondaria.jvm.gc.memory.promotedè la quantità di aumento delle dimensioni del pool di memoria di generazione precedente dopo GC. Questo valore riflette una GC completa.
Questa funzionalità è disponibile nel portale di Azure, come illustrato nello screenshot seguente. È possibile scegliere metriche specifiche e aggiungere filtri per un'app, una distribuzione o un'istanza specifiche. È possibile anche applicare la separazione.
Ulteriore debug
Per altre operazioni di debug, è possibile acquisire manualmente dump dell'heap e dump dei thread e usare Java Flight Recorder (JFR). Per altre informazioni, vedere Acquisire manualmente dump dell'heap e dump del thread e usare Java Flight Recorder in Azure Spring Apps.
I dump dell'heap registrano lo stato della memoria dell'heap Java. I dump del thread registrano gli stack di tutti i thread in tempo reale. Questi strumenti sono disponibili tramite l'interfaccia della riga di comando di Azure e nella pagina dell'app del portale di Azure, come illustrato nello screenshot seguente.
Per altre informazioni, vedere Acquisire manualmente dump dell'heap e dump del thread e usare Java Flight Recorder in Azure Spring Apps. È inoltre possibile usare strumenti di terze parti come Memory Analyzer per analizzare i dump dell'heap.
Modificare le configurazioni per risolvere i problemi
Alcuni problemi che possono essere identificati includono l’OOM del contenitore, la memoria heap troppo grande e un'operazione di Garbage Collection anomala. Se si identifica uno di questi problemi, potrebbe essere necessario configurare le dimensioni massime della memoria nelle opzioni JVM. Per altre informazioni, vedere la sezione Opzioni JVM importanti di Gestione della memoria Java.
È possibile modificare le opzioni JVM usando il portale di Azure o l'interfaccia della riga di comando di Azure.
Nel portale di Azure passare all'app, quindi selezionare Configurazione nella sezione Impostazioni del menu di spostamento. Nella scheda Impostazioni generali aggiornare il campo Opzioni JVM, come illustrato nello screenshot seguente:
