GC completo non necessario con il garbage collector G1 in Java 8?

Question

Abbiamo notato occasionalmente GC completi con garbage collector G1 con overflow del segno simultaneo. Una volta, c'è un overflow del segno simultaneo per overflow, questo overflow continuerà nelle prossime fasi di mark simultanei. Alla fine, conduce al GC completo poiché il marchio simultaneo sembra non funzionare più.

Abbiamo quattro macchine che eseguono la stessa applicazione basata su Apache Storm con lo stesso traffico di dati. Solo una delle macchine ha questa esperienza una volta alla settimana.

È questo relativo al bug: 'G1 non si espande marcatura stack quando marchio di overflow dello stack accade durante la marcatura concurrent' https://bugs.openjdk.java.net/browse/JDK-8065402

Secondo il suggerimento dalla pagina di cui sopra, abbiamo raddoppiato i fili contrassegno simultaneo da 4 a 8 e le dimensioni dell'heap da 8 GB a 16 GB. Tuttavia, il GC completo continua a verificarsi e l'unica differenza è che gli eventi vengono ritardati.

Altri suggerimenti?

Ecco il log GC:

Java HotSpot(TM) 64-Bit Server VM (25.65-b01) for linux-amd64 JRE(1.8.0_65b17), 
built on Oct 6 2015 17:16:12 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8) 
Memory: 4k page, physical 529167668k(69283408k free), swap 33554424k(33552380k free) 
CommandLine flags: -XX:ConcGCThreads=8 -XX:G1ReservePercent=20 -XX:GCLogFileSize=104857600 
-XX:InitialHeapSize=17179869184 -XX:InitiatingHeapOccupancyPercent=45 -XX:MaxGCPauseMillis=100 
-XX:MaxHeapSize=17179869184 -XX:NumberOfGCLogFiles=10 -XX:ParallelGCThreads=30 
-XX:+PrintAdaptiveSizePolicy -XX:PrintFLSStatistics=2 -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime 
-XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC 
-XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC -XX:+UseGCLogFileRotation 
... 
... 
2016-04-13T22:06:37.254-0400: 19839.175: [GC concurrent-root-region-scan-start] 
2016-04-13T22:06:37.313-0400: 19839.234: [GC concurrent-root-region-scan-end, 0.0592966 secs] 
2016-04-13T22:06:37.313-0400: 19839.234: [GC concurrent-mark-start] 
2016-04-13T22:06:38.569-0400: 19840.490: [GC concurrent-mark-reset-for-overflow] 
... 
2016-04-13T22:06:42.810-0400: 19844.731: [GC concurrent-mark-reset-for-overflow] 
... 
2016-04-13T22:11:19.253-0400: 20121.175: [GC concurrent-mark-reset-for-overflow] 
... 
... 
... 
2016-04-14T01:58:17.254-0400: 33739.176: [GC concurrent-mark-reset-for-overflow] 
... 
2016-04-14T01:58:36.957-0400: 33758.878: [Full GC (Allocation Failure) 

Answer 1

da Oracle g1_gc blog:

GC concurrent-mark-reset-for-overflow: Questo indica che la pila di marcatura globale era diventato pieno e c'era un overflow dello stack. La marcatura simultanea ha rilevato questo overflow e ha dovuto ripristinare le strutture di dati per iniziare nuovamente la marcatura

Quindi aumentare -XX:MarkStackSize è una rapida vittoria.

Pochi osservazione dai vostri parametri VM:

1. Il G1 GC è un garbage collector adattivo con le impostazioni predefinite che gli permettono di lavorare in modo efficiente senza modifiche. Dai un'occhiata alla documentazione Oracle page su G1GC
2. Parametri chiave da impostare: -XX:MaxGCPauseMillis, -XX:G1HeapRegionSize,-XX:ParallelGCThreads=n, -XX:ConcGCThreads=n Lascia tutto il resto ai valori predefiniti.
3. Se la dimensione dell'heap è 16 GB, la dimensione della regione ideale deve essere 8 MB. Assicurati di mantenere le regioni 2048.
4. Rivisita il tuo obiettivo di tempo di pausa. -XX:MaxGCPauseMillis. Se 200ms non è realistico per l'heap da 16 GB, impostare questo valore correttamente.

5. La pagina di documentazione ufficiale consiglia di impostare XX:ParallelGCThreads=n, -XX:ConcGCThreads=n in base al numero di core della macchina.

   -XX:ParallelGCThreads=n: imposta il valore dei thread di lavoro STW. Imposta il valore di n sul numero di processori logici. Il valore di n è uguale al numero di processori logici fino a un valore di 8.

   -XX:ConcGCThreads=n: imposta il numero di fili di contrassegno paralleli. Imposta n a circa 1/4 del numero di thread di raccolta dati obsoleti paralleli (ParallelGCThreads).

6. Revisit -XX:InitialHeapSize=17179869184 -XX:InitiatingHeapOccupancyPercent=45 -XX:G1ReservePercent=20 parametri. Lasciali ai valori predefiniti a meno che non si abbia bisogno di cambiarli.

Visitare questa pagina per una migliore comprensione dei registri G1GC.