La garbage collection permgen richiede più GC completi

Question

Stiamo eseguendo graal e notiamo che sono necessarie più raccolte di dati inutili per eliminare lo spazio permgen.

2013-06-06T16:11:27.016+0000: 32582.145: [Full GC 32582.145: [CMS2013-06-06T16:11:45.404+0000:  32600.532: [CMS-concurrent-mark: 21.403/86.063 secs] [Times: user=48.44 sys=0.63, real=86.07 secs] 
(concurrent mode failure): 7585874K->7290466K(10145024K), 57.9230770 secs] 7866094K->7290466K(10451712K), [CMS Perm : 261766K->261702K(262144K)] icms_dc=30 , 57.9232150 secs] [Times: user=57.97 sys=0.00, real=57.93 secs] 
2013-06-06T16:12:25.183+0000: 32640.311: [GC [1 CMS-initial-mark: 7290466K(10145024K)] 7385976K(10451712K), 0.0880890 secs] [Times: user=0.09 sys=0.00, real=0.08 secs] 
2013-06-06T16:12:25.271+0000: 32640.400: [CMS-concurrent-mark-start] 
2013-06-06T16:12:25.427+0000: 32640.555: [GC 32640.556: [ParNew: 272640K->10006K(306688K), 0.0622620 secs] 7563106K->7300472K(10451712K) icms_dc=30 , 0.0624140 secs] [Times: user=0.24 sys=0.00, real=0.06 secs] 
2013-06-06T16:12:25.734+0000: 32640.863: [GC 32640.863: [ParNew: 282646K->13476K(306688K), 0.0648770 secs] 7573112K->7303942K(10451712K) icms_dc=30 , 0.0650170 secs] [Times: user=0.26 sys=0.00, real=0.07 secs] 
2013-06-06T16:12:26.013+0000: 32641.142: [GC 32641.142: [ParNew: 286116K->11277K(306688K), 0.0607460 secs] 7576582K->7301743K(10451712K) icms_dc=30 , 0.0608870 secs] [Times: user=0.25 sys=0.00, real=0.06 secs] 
2013-06-06T16:12:32.449+0000: 32647.577: [GC 32647.577: [ParNew: 283917K->17560K(306688K), 0.0672260 secs] 7574383K->7308026K(10451712K) icms_dc=30 , 0.0673710 secs] [Times: user=0.27 sys=0.00, real=0.07 secs] 
2013-06-06T16:12:33.107+0000: 32648.236: [GC 32648.236: [ParNew: 290200K->22523K(306688K), 0.0686820 secs] 7580666K->7312989K(10451712K) icms_dc=30 , 0.0688200 secs] [Times: user=0.28 sys=0.00, real=0.07 secs] 
2013-06-06T16:12:33.845+0000: 32648.974: [Full GC 32648.974: [CMS2013-06-06T16:12:52.516+0000: 32667.645: [CMS-concurrent-mark: 21.346/27.245 secs] [Times: user=27.55 sys=0.14, real=27.25 secs] 
(concurrent mode failure): 7290466K->7293289K(10145024K), 57.7092090 secs] 7523492K->7293289K(10451712K), [CMS Perm : 262143K->262143K(262144K)] icms_dc=30 , 57.7093560 secs] [Times: user=57.76 sys=0.00, real=57.71 secs] 
2013-06-06T16:13:31.557+0000: 32706.686: [Full GC 32706.686: [CMS: 7293289K->6960613K(10145024K), 37.1325250 secs] 7293289K->6960613K(10451712K), [CMS Perm : 262143K->91949K(262144K)] icms_dc=30 , 37.1326670 secs] [Times: user=37.19 sys=0.00, real=37.14 secs] 

Il primo raccoglie solo 64 KB, la seconda raccoglie nulla e poi finalmente, il terzo non è in grado di raccogliere 170194K

JAVA_OPTIONS: 
-XX:+CMSClassUnloadingEnabled 
-XX:+CMSPermGenSweepingEnabled 
-XX:+UseConcMarkSweepGC 
-XX:MaxPermSize=256m 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDateStamps 
-verbose:gc,sizes 
-XX:+UseConcMarkSweepGC 
-XX:CMSInitiatingOccupancyFraction=80 
-XX:+DisableExplicitGC 
-XX:+CMSIncrementalMode 
-XX:+UseParNewGC 
-Xms10g -Xmx10g 

Inoltre, è in ogni caso a dire ottenere il garbage collector di fare un incrementale spazzata dello spazio permgen? Vediamo solo la riduzione di permgen durante le raccolte complete.

Answer 1

Un modo per identificare ciò che viene raccolto in quest'ultima raccolta FullGC è a istogrammi di classe di stampa prima/dopo GC completo: -XX:+PrintClassHistogramBeforeFullGC -XX:+PrintClassHistogramAfterFullGC.

In questo modo è possibile confrontare gli istogrammi di tutte le raccolte e identificare quali classi vengono raccolte nell'ultima.

Per la seconda domanda relativa a PermGen, il consueto consiste nell'identificare la dimensione sufficiente del PermGen per l'applicazione/il carico di lavoro e attenersi a questa. È necessario indagare sul motivo per cui sono stati posizionati così tanti oggetti nel PermGen.

Answer 2

Lasciatemi fare un chiarimento su Concurrent Mark Sweep e sul suo algoritmo in modalità incrementale. È stata introdotta la modalità incrementale CMS per evitare l'esaurimento della CPU su server single core mentre GC in background è in esecuzione. L'uso del CMS incrementale è sconsigliato.

La modalità incrementale non libera la memoria in modo incrementale, ma fa solo lunghi periodi di sonno durante la fase di mark dell'algoritmo mark-sweep.

-XX:+CMSPermGenSweepingEnabled è deprecato e sinonimo di -XX:+CMSClassUnloadingEnabled

modalità incrementale po 'spegni fiamma rilevamento di oggetti morti e il mio essere un problema.

Inoltre, se una delle classi (da scaricare) ha finilazer, ciò potrebbe anche spiegare 2 raccolte (JVM non può scaricare singole classi, l'intero classloader è scaricato, quindi una qualsiasi delle sue classi può impedire la raccolta).

Si consiglia di dimensionare correttamente heap e perm gen e configurare CMS in modo che sia più aggressivo se si desidera mantenere tale livello di utilizzo dell'heap. In my blog puoi trovare alcuni consigli per la messa a punto di CMS.

Se tuttavia il tempo di esecuzione sta producendo e abbandonando attivamente i programmi di caricamento classe, l'ottimizzazione di GC potrebbe non essere sufficiente.

Mi trovavo ad affrontare problemi simili con test automatici (ogni test caricava le stesse classi in un caricatore di classe dedicato per motivi di isolamento). I test erano generalmente instabili, lanciando OOME nella perm gen. La soluzione consisteva nel forzare la JVM a pulire il perm gen inquinandolo con dati inutili (here is snippet of code). Stava però causando il GC completo, probabilmente non qualcosa che ti piacerebbe vedere.

BTW C'è anche il flag -XX:CMSClassUnloadingMaxInterval=N che consente a JVM di raccogliere Perm gen solo ogni ennesima raccolta. Ma questo non è il tuo caso, perché perm gen è pieno.