Analisi dei file di log del Garbage Collector (GC) per monitorare i problemi della memoria
Si consiglia di attivare la registrazione del GC negli ambienti di produzione. Per ulteriori informazioni su come attivare la registrazione del GC, vedere la sezione Monitorare l'utilizzo della memoria di un server ThingWorx. Una volta attivata la registrazione del GC, tutta l'attività che lo riguarda viene registrata sul server. Se la JVM non risponde per lunghi periodi di tempo, strumenti esterni, quali VisualVM, potrebbero non essere in grado di raccogliere i dati della memoria. La JVM può tuttavia stampare l'attività del GC, consentendo di identificare la causa del problema.
Lettura dei log del GC
Per analizzare i log del GC, è possibile utilizzare strumenti quali GCEasy.io e Chewiebug GC Viewer. I log possono anche essere analizzati manualmente in un editor di testo per rilevare problemi comuni.
In genere ogni operazione di pulizia della memoria viene stampata, come illustrato nell'esempio seguente.
1. Tempo dall'avvio della JVM
2. Tipo di GC
3. Motivo del GC
4. Young generation ripulita da 549 M a 4 M
5. Dimensione totale young generation
6. Tempo complessivo di completamento del GC
7. Heap allocato
8. Memoria totale della soluzione pulita da Java
Per ulteriori informazioni sulle operazioni del GC, vedere la documentazione Oracle.
Uno strumento di analisi del GC converte la rappresentazione di testo delle pulizie in un grafico più facilmente leggibile.
L'analisi dei dati nel log del GC consente di identificare gli scenari riportati di seguito, che indicano problemi di memoria nella soluzione ThingWorx.
• Operazioni del GC complete estremamente lunghe (oltre 45 secondi) - Si tratta di operazioni "stop the world" assolutamente non auspicabili. Ad esempio, il GC completo riportato di seguito impiega 46 secondi. Durante questo intervallo di tempo, tutte le altre attività utente vengono interrotte:
272646.952: [Full GC: 7683158K->4864182K(8482304K) 46.204661 secs]
• GC completi che si verificano in un loop - Si tratta di GC completi che si verificano in rapida successione.
Ad esempio, per la risoluzione delle quattro Garbage Collection consecutive successive sono necessari quasi due minuti.
16121.092: [Full GC: 7341688K->4367406K(8482304K), 38.774491 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
• Nel grafico seguente i triangoli rossi sui picchi del grafico indicano che in un loop sono in esecuzione GC completi:
• Perdite di memoria - Si verificano quando nella memoria viene mantenuto un numero crescente di oggetti e non è possibile pulirla.
Nell'esempio seguente la memoria aumenta costantemente, nonostante i garbage collector:
Consiglio - Se non sono disponibili strumenti automatici per monitorare e registrare l'utilizzo della memoria nel tempo, controllare i file di log del GC ogni giorno per i problemi di memoria. Quando si verificano problemi di memoria, raccogliere i dump degli heap o i dump dei thread della JVM per identificare le operazioni a esecuzione prolungata. Queste operazioni possono generare problemi della memoria sottostante nella soluzione ThingWorx.