Ho configurato java per scaricare le informazioni di raccolta dei rifiuti nei registri ( GC dettagliato ). Non sono sicuro di cosa significano le voci della raccolta dei dati inutili nei log. Un esempio di queste voci è pubblicato qui sotto. Ho cercato su Google e non ho trovato spiegazioni solide.
Ho alcune ipotesi ragionevoli, ma sto cercando risposte che forniscano definizioni rigorose di cosa significano i numeri nelle voci, supportate da fonti credibili. Un +1 automatico a tutte le risposte che citano la documentazione solare. Le mie domande sono:
8109.128: [GC [PSYoungGen: 109884K-> 14201K (139904K)] 691015K-> 595332K (1119040K), 0.0454530 sec]
8112.111: [GC [PSYoungGen: 126649K-> 15528K (142336K)] 707780K-> 605892K (1121472K), 0,0934560 sec]
8112.802: [GC [PSYoungGen: 130344K-> 3732K (118592K)] 720708K-> 607895K (1097728K), 0,0682690 sec]
- Modifica dynamic del livello di log log4j
- Registrazione, programmazione orientata all'aspetto e iniezione delle dipendenze - Cercando di dare un senso a tutto
- Impostazione di un nome file di registro per includere la data corrente in Log4j
- Come utilizzare AOP con AspectJ per la registrazione?
- Primavera: aspetto di registrazione standard (intercettore)
La maggior parte è spiegata nella GC Tuning Guide (che faresti comunque bene a leggere).
L’opzione della riga di comando
-verbose:gc
genera informazioni sull’heap e sulla garbage collection da stampare in ogni raccolta. Ad esempio, qui viene prodotto da un’applicazione server di grandi dimensioni:[GC 325407K->83000K(776768K), 0.2300771 secs] [GC 325816K->83372K(776768K), 0.2454258 secs] [Full GC 267628K->83769K(776768K), 1.8479984 secs]
Qui vediamo due collezioni secondarie seguite da una raccolta importante. I numeri prima e dopo la freccia (ad es.
325407K->83000K
dalla prima riga) indicano rispettivamente la dimensione combinata degli oggetti live prima e dopo la garbage collection. Dopo raccolte secondarie la dimensione include alcuni oggetti che sono spazzatura (non più in vita) ma che non possono essere recuperati. Questi oggetti sono contenuti nella generazione di tenured o referenziati dalle generazioni di ruolo o permanenti.Il prossimo numero tra parentesi (ad esempio,
(776768K)
nuovo dalla prima riga) è la dimensione impegnata dell’heap: la quantità di spazio utilizzabile per gli oggetti java senza richiedere più memoria dal sistema operativo. Si noti che questo numero non include uno degli spazi sopravvissuti, poiché solo uno può essere utilizzato in un dato momento e inoltre non include la generazione permanente, che contiene i metadati utilizzati dalla macchina virtuale.L’ultimo elemento sulla linea (ad es.
0.2300771 secs
) indica il tempo impiegato per eseguire la raccolta; in questo caso circa un quarto di secondo.Il formato per la collezione principale nella terza riga è simile.
Il formato dell’output prodotto da
-verbose:gc
è sobject a modifiche nelle versioni future.
Non sono sicuro del perché ci sia un PSYoungGen nel tuo; hai cambiato il garbage collector?
Un esempio di un GC completo associato mostra anche i raccoglitori usati per le generazioni vecchie e permanenti:
3.757: [Full GC [PSYoungGen: 2672K->0K(35584K)] [ParOldGen: 3225K->5735K(43712K)] 5898K->5735K(79296K) [PSPermGen: 13533K->13516K(27584K)], 0.0860402 secs]
Infine, analizzando una riga dell’output del registro di esempio:
8109.128: [GC [PSYoungGen: 109884K->14201K(139904K)] 691015K->595332K(1119040K), 0.0454530 secs]
Volevo solo dire che si può ottenere il registro dettagliato di GC con il
-XX:+PrintGCDetails
parametro. Quindi vedi l’output PSYoungGen o PSPermGen come nella risposta.
Inoltre -Xloggc:gc.log
sembra generare lo stesso output come -verbose:gc
ma puoi specificare un file di output nel primo.
Esempio di utilizzo:
java -Xloggc:./memory.log -XX:+PrintGCDetails Memory
Per visualizzare meglio i dati puoi provare gcviewer (una versione più recente può essere trovata su github ).
Abbi cura di scrivere correttamente i parametri, ho dimenticato il “+” e il mio JBoss non si avviava, senza alcun messaggio di errore!