Un caso reale di memory leak – parte 7

Ti sei perso le scorse puntate? Guarda qui:

• Introduzione ai performance monitoring tool – parte 1
• Esempio di un APM open source per un’app web Java J2EE: Glowroot – parte 2
• Glowroot – Profilazione e transazioni web – parte 3
• Glowroot Slow traces – parte 4
• Glowroot: monitoring della JVM – parte 5
• Heap dump in situazioni critiche – parte 6

Caso reale di memory leak

A settembre del 2018 in una nostra azienda cliente, in cui è installata una versione di Web.UP utilizzata oltre che come client per i dipendenti amministrativi anche come console a bordo macchina per indicazioni sulla produzione e sul turno dell’operatore, ha iniziato a manifestarsi un comportamento anomalo. 

Verso fine settimana, prima del riavvio della domenica (viene effettuato un riavvio settimanale), la macchina server ha iniziato a manifestare un problema di alta CPU e alta memoria sul processo Java dell’application server che gestisce Web.UP. In particolare il server diventava pian piano sempre più lento nel mostrare le schermate richieste dagli utenti fino a non essere più responsivo. A questo punto per non bloccare la produzione era necessario riavviare il server.

Tale problema comportava quindi un periodo di disagio per gli utenti sia durante il rallentamento che durante il riavvio del server, per l’indisponibilità dei servizi.  

Per risolvere il problema si è operato in questo modo.

Innanzitutto sono stati creati degli eseguibili sulla macchina server, da chiamare rapidamente e facilmente, in grado di effettuare il dump sia della memoria che dei thread della JVM. Il cliente, nel momento del verificarsi del problema, prima di spegnere il server, ha potuto quindi eseguire gli script per salvare tali file fondamentali di dump, prima che il riavvio resettasse tutto. 

I file di heap dump e thread dump sono stati poi consegnati a Sme.UP LAB e analizzati. 

Il tool Eclipse Memory Analizer è stato fondamentale nella risoluzione del problema. Indagando il Dominator Tree sull’heap dump si è notato che una data classe manteneva in vita oggetti che avrebbero dovuto essere ripuliti, perchè non più utilizzati. 

Lo si vede nell’immagine seguente. La classe si chiama VariableLogger e manteneva in vita componenti grafici non più attivi, perchè facenti capo a vecchie view (vecchie schermate). Tali componenti mantenevano in vita altri oggetti a cascata, producendo un memory leak.  

Immagine 3 – Dominator tree su heap dump con memory leak

Il VariableLogger è nel codice di Web.UP un oggetto di monitoring mantenuto in memoria, utile nel registrare informazioni storiche sulle variabili di smeup. La correzione è stata duplice. 

In primo luogo si è intervenuto nel non referenziare nel VariableLogger oggetti ma stringhe (servivano solo poche tipologie di informazioni). Questo ha spezzato la catena di riferimenti ad altri oggetti.

In secondo luogo è stato definito un numero massimo dei record contenuti nell’oggetto VariableLogger: quando viene raggiunto il limite le informazioni più vecchie lasciano spazio a quelle nuove. 

Grazie a queste due correzioni il memory leak e di conseguenza i disagi avuti dal cliente sono felicemente spariti.

Chiara Zambelli
Responsabile CI/CD – smeup
My LinkedIn Profile