Question

我们正在运行grails，我们注意到需要多个完整的垃圾收集来清除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]

第一个只收集64K，第二个收集什么然后最后，第三个收集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

另外，有没有告诉让垃圾收集器对permgen空间进行增量扫描？我们只看到permgen在完整收藏期间被减少。

Answer 1

让我澄清一下Concurrent Mark Sweep和它的增量模式算法。引入CMS增量模式是为了避免在后台GC运行时单核服务器上的CPU饥饿。不鼓励使用增量CMS。

增量模式不会逐渐释放内存，它只是在标记扫描算法的标记阶段进行长时间休眠。

-XX:+CMSPermGenSweepingEnabled已弃用且与-XX:+CMSClassUnloadingEnabled

同义

增量模式有点隐藏了死对象检测，我的问题就出现了。

此外，如果任何类（要卸载）都有finilazer，这也可以解释2个集合（JVM无法卸载单个类，整个类加载器被卸载，因此它的任何类都可以阻止收集）。

我建议您正确调整堆和perm gen的大小，如果要保持堆级利用率，请将CMS配置为更具攻击性。在my blog中，您可以找到很少有关于调整CMS的建议。

但是，如果你运行时正在积极地生成和放弃类加载器，那么调整GC可能还不够。

我遇到了类似的自动化测试问题（为了隔离，每个测试都在专用的类加载器中加载相同的类）。测试通常是不稳定的，将OOME扔进了烫发器。解决方案是强制JVM通过使用垃圾数据（here is snippet of code）进行污染来清理它。它导致了Full GC - 可能不是你想看的东西。

顺便说一句还有-XX:CMSClassUnloadingMaxInterval=N标志，让JVM只收集每个第N个集合的Perm gen。但这不是你的情况，因为烫发已经满了。

Answer 2

确定最后一个FullGC集合中收集内容的一种方法是在Full GC之前/之后打印类直方图：-XX:+PrintClassHistogramBeforeFullGC -XX:+PrintClassHistogramAfterFullGC。

通过这种方式，您可以比较所有集合中的直方图，并确定最后一个集合中收集的类。

对于考虑到PermGen的第二个问题，通常的建议是为您的应用程序/工作负载确定足够大小的PermGen并坚持使用它。您需要调查为什么有这么多对象被放入PermGen。

permgen垃圾收集需要多个Full GC

2 个答案: