gpt4 book ai didi

java - permgen 垃圾收集需要多次 Full GC

转载 作者:塔克拉玛干 更新时间:2023-11-03 05:33:05 25 4
gpt4 key购买 nike

我们正在运行 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。

最佳答案

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

增量模式不会增量释放内存,它只是在标记清除算法的标记阶段进行长时间 sleep 。

-XX:+CMSPermGenSweepingEnabled 已弃用,与 -XX:+CMSClassUnloadingEnabled 同义

增量模式在某种程度上隐藏了死对象检测,我会成为一个问题。

此外,如果任何类(待卸载)有 finilazer 这也可以解释 2 个集合(JVM 不能卸载单个类,整个类加载器被卸载,所以它的任何类都可以阻止收集)。

如果您想保持堆利用率水平,我会建议您适当调整堆和永久代的大小,并将 CMS 配置得更积极。在 my blog您几乎找不到调整 CMS 的建议。

但是,如果您的运行时正在积极生产并放弃类加载器,调整 GC 可能还不够。

我在自动化测试中遇到了类似的问题(为了隔离,每个测试都在专用类加载器中加载相同的类)。测试通常不稳定,在 perm gen 中抛出 OOME。解决方案是通过用垃圾数据 (here is snippet of code) 污染它来强制 JVM 清理 perm gen。虽然它会导致 Full GC - 可能不是您希望看到的。

顺便说一句还有 -XX:CMSClassUnloadingMaxInterval=N 标志让 JVM 仅在每 N 次收集时收集 Perm 代。但这不是你的情况,因为 perm gen 已满。

关于java - permgen 垃圾收集需要多次 Full GC,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16970027/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com