Permgen Garbage Collection dauert mehrere Full GC

Question

Wir laufen Grails und wir bemerken, dass mehrere vollständige Garbage Collection benötigt werden, um den Permgen-Speicherplatz zu löschen.

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] 

Der erste sammelt nur 64K, sammelt die zweite nichts und dann schließlich die dritte ist in der Lage 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 

auch zu sammeln, wird es trotzdem zu sagen, der Garbage Collector erhalten eine inkrementelle zu tun Schwung des Permgenraums? Wir sehen nur Permgen während der vollständigen Sammlungen reduziert werden.

Answer 1

Eine Möglichkeit zu identifizieren, was in dieser letzten FullGC-Sammlung gesammelt wird, ist Klasse Klassenhistogramme vor/nach Full GC: -XX:+PrintClassHistogramBeforeFullGC -XX:+PrintClassHistogramAfterFullGC drucken.

Auf diese Weise können Sie Histogramme aus allen Sammlungen vergleichen und identifizieren, welche Klassen in der letzten gesammelt werden.

Zu Ihrer zweiten Frage in Bezug auf PermGen, die üblichen Beratung ist die ausreichende Größe des PermGen für Ihre Anwendung/Arbeitsbelastung zu identifizieren und dabei zu bleiben. Sie müssen untersuchen, warum so viele Objekte in PermGen platziert werden.

Answer 2

Lassen Sie mich eine Erklärung über Concurrent Mark Sweep und es ist inkrementellen Modus Algorithmus. Der inkrementelle CMS-Modus wurde eingeführt, um CPU-Hunger auf Einzel-Core-Servern zu vermeiden, während der Hintergrund-GC läuft. Die Verwendung von inkrementellen CMS wird abgeraten.

Inkrementalmodus gibt den Speicher nicht inkrementell frei, sondern nur während der Markierungsphase des Mark-Sweep-Algorithmus.

-XX:+CMSPermGenSweepingEnabled ist veraltet und auch auf -XX:+CMSClassUnloadingEnabled

Inkremental-Modus etwas Getauchten tot Objekterkennung und mein Problem sein.

Wenn eine der zu entladenden Klassen finilizer hat, könnte dies auch 2 Collections erklären (JVM kann einzelne Klassen nicht entladen, der ganze Classloader wird entladen, so dass alle Klassen die Erfassung verhindern können).

Ich würde Ihnen raten, Heap und Perm gen richtig zu dimensionieren und CMS so zu konfigurieren, dass es aggressiver wird, wenn Sie diese Heap-Auslastung beibehalten wollen. In my blog finden Sie einige Tipps zum Tuning von CMS.

Wenn Sie jedoch Zeit laufen ist aktiv produzieren und Verlassen der Klasse Loader Tuning GC möglicherweise nicht genug.

Ich war mit ähnlichen Problemen konfrontiert mit automatisierten Tests (jeder Test wurden die gleichen Klassen in dedizierten Klassenlader aus Gründen der Isolierung geladen). Der Test war im Allgemeinen instabil und warf OOME in Dauerwelle. Die Lösung bestand darin, die JVM dazu zu zwingen, Perm gen zu reinigen, indem sie mit Mülldaten verschmutzt wurde (here is snippet of code). Es verursachte jedoch Full GC - wahrscheinlich nicht etwas, das du gerne sehen würdest.

BTW Es gibt auch -XX:CMSClassUnloadingMaxInterval=N Flag, die JVM Perm gen nur jede N-te Sammlung sammeln lassen. Aber das ist nicht dein Fall, weil Dauerwelle voll ist.