{"id":50483,"date":"2019-08-11T06:00:00","date_gmt":"2019-08-11T04:00:00","guid":{"rendered":"http:\/\/smeupnew.it\/magazine\/blog\/heap-dump-situazioni-critiche\/"},"modified":"2021-03-30T11:36:32","modified_gmt":"2021-03-30T09:36:32","slug":"heap-dump-situazioni-critiche","status":"publish","type":"post","link":"https:\/\/www.smeup.com\/magazine\/blog\/heap-dump-situazioni-critiche\/","title":{"rendered":"Heap dump in situazioni critiche – parte 6"},"content":{"rendered":"

Nel precedente articolo sull\u2019argomento dei performance monitoring tools (vedere articolo monitoring jvm<\/a>) abbiamo trattato il concetto di JVM, fondamentale in ambito di applicazioni Java, e offerto una panoramica delle funzionalit\u00e0 di monitoring della JVM presenti nell\u2019APM Glowroot.\u00a0<\/span><\/p>\n

Vedremo ora nei prossimi articoli due casi concreti di come l\u2019indagine interna alla JVM effettuata all\u2019interno del Laboratorio di Sme.UP<\/a> abbia consentito di risolvere due rilevanti problemi di perfomance.<\/span><\/p>\n

In questa parte tratteremo dell\u2019esame dell\u2019heap dump in situazioni critiche, nel successivo ci concentreremo sull\u2019esame del thread dump.<\/span><\/p>\n

Heap della JVM<\/h2>\n

L’<\/span>heap<\/b> della JVM \u00e8 l’area di memoria in cui risiedono gli oggetti Java. Quando un’applicazione Java crea un oggetto esso viene memorizzato nell’heap. Esso pu\u00f2 poi essere referenziato da altri oggetti all’interno dell’applicazione. Periodicamente viene effettuato un processo di <\/span>garbage collection<\/b> (letteralmente raccolta dei rifiuti) che ripulisce l’heap da oggetti non pi\u00f9 in uso, facendo spazio a nuovi oggetti. Un oggetto \u00e8 in uso quando \u00e8 referenziato, ovvero quando parti dell’applicazione mantengono ancora un puntamento a quell’oggetto.\u00a0<\/span><\/p>\n

L’utilizzo dell’heap nella JVM segue generalmente il cosiddetto <\/span>sawtooth pattern<\/b> (comportamento a dente di sega). La memoria sale progressivamente per la creazione di nuovi oggetti. La maggioranza di tali oggetti hanno solitamente una vita breve quindi quando passa la garbage collection (per esattezza quella denominata di Major GC) la memoria viene liberata dagli oggetti non pi\u00f9 utilizzati e il grafico mostra una ripida caduta.\u00a0\u00a0<\/span><\/p>\n

Nella seguente immagine \u00e8 mostrato un andamento di una memoria in salute.<\/span><\/p>\n

Immagine 1 – Heap in buona salute
\nFonte: https:\/\/plumbr.io\/blog\/memory-leaks\/memory-leaks-fallacies-and-misconceptions<\/a>\u00a0<\/span><\/i><\/p>\n

 <\/p>\n

Un andamento come quello nella figura sottostante \u00e8 invece indicativo di una memoria non in buona salute e in particolare della presenza di un <\/span>memory leak<\/b>. Qui l’occupazione minima di memoria dopo il passaggio della garbage collection sale costantemente nel tempo. Se l’applicazione rimane attiva per periodi di tempo prolungato l’area di memoria occupata tender\u00e0 progressivamente a crescere finch\u00e8 prima o poi l’heap verr\u00e0 saturato. Quando l’heap arriva ad alti livelli di saturazione si possono manifestare anche problemi di alta cpu, perch\u00e8 il sistema cerca di effettuare la garbage collection con maggiore frequenza e sforzo, senza esito.\u00a0<\/span><\/p>\n

In una situazione del genere il riavvio dell’application server Java (o chiaramente dell’intera macchina su cui \u00e8 hostata l’applicazione) risolve momentaneamente il problema, ma ovviamente una soluzione del genere \u00e8 solo temporanea perch\u00e8 il problema si riverificher\u00e0 ancora col passare del tempo. Inoltre il riavvio di un server o di una macchina in sistemi non clusterizzati pu\u00f2 generare disagi anche gravi dato che l’applicazione rimane momentaneamente indisponibile.<\/span><\/p>\n

Immagine 2 – Heap in presenza di memory leak
\nFonte: https:\/\/plumbr.io\/blog\/memory-leaks\/memory-leaks-fallacies-and-misconceptions<\/a><\/span><\/i><\/p>\n

 <\/p>\n

Heap dump e strumenti di analisi<\/h2>\n

I grafici dell\u2019andamento dell\u2019heap possono dare indicazioni sulla presenza di un memory leak ma non danno informazioni sulla sua causa. Per individuarla si pu\u00f2 ricorrere al <\/span>dump<\/b> (scarico) della memoria. Questo processo salva la memoria su un file che pu\u00f2 essere analizzato con appositi strumenti. Uno dei pi\u00f9 completi si chiama <\/span>Eclipse Memory Analyzer (MAT)<\/b> (<\/span>https:\/\/www.eclipse.org\/mat\/<\/span><\/a>), un progetto rilasciato sotto licenza Open Source e concepito appositamente per l\u2019analisi di dumps dell\u2019heap.\u00a0\u00a0<\/span><\/p>\n

Eclipse Memory Analyzer dispone di molte features. Tra le pi\u00f9 utili citiamo il <\/span>Dominator Tree<\/b>.\u00a0<\/span><\/p>\n

Esso mostra gli oggetti che occupano maggior memoria nell’heap secondo una struttura gerarchica in cui i sottolivelli sono gli oggetti referenziati dai padri. Grazie ad esso \u00e8 possibile investigare quali oggetti ne tengono vivi altri perch\u00e8 li referenziano.\u00a0<\/span><\/p>\n

Altre features interessanti sono il Top Consumers, che mostra gli oggetti pi\u00f9 ingombranti raggruppati per classe e il Leak Suspects, una analisi dei leak sospetti eseguita sulla base degli anti patterns pi\u00f9 conosciuti riguardanti l\u2019uso della memoria.<\/span><\/p>\n

Nel prossimo articolo parleremo di un caso reale di Memory Leak.
\nSe vuoi rimanere aggiornato anche sulle scorse puntate eccole:<\/p>\n