【发布时间】:2014-09-15 08:49:22
【问题描述】:
我正在调查一个 EE 应用程序的性能问题,这可能是由于垃圾收集器未经过优化调整造成的。
在查看jstat 日志时,我在繁重的负载下收集到了以下发现:
S0 S1 E O P
7.39 0.00 41.81 88.89 53.93
NGCMN NGCMX NGC S0C S1C
131072.0 301056.0 301056.0 30080.0 30080.0
EC OGCMN OGCMX OGC
240896.0 1441792.0 2058240.0 2058240.0
根据官方的 jstat 文档here,我们可以看到当前的老年代大小(OGC)已经达到了老年代的最大大小(OGCMX)。然而,第一行告诉我们“旧空间利用率占空间当前容量的百分比”(O)“仅”为 88%。
我的问题是:
- 什么机制将老年代限制设置为 jstat 输出中的 OGCMX?
- 是什么阻止了旧空间增长并耗尽了剩余的约 12% 的堆?
我们有 JVM 参数,用于设置总堆、新空间和永久空间 (-Xms -Xmx -XX:NewSize -XX:MaxNewSize -XX:PermSize -XX:MaxPermSize) 的最小/最大值。
但是旧空间没有设置限制(我不知道这样的参数是否存在)。
编辑 NewRatio:
这是我的理解并且还提到了here JVM 不会强制执行新旧空间之间的比率,尤其是在使用MaxNewSize 参数时。并且MaxNewSize 参数被接受,因为上面的值 (301056.0KB) 实际上正是我们为MaxNewSize 指定的 294MB。此外,NewRatio 的默认值为 2(请参阅here),这根本不是 jstat 列出的上述任何值之间的比率。
【问题讨论】:
-
这些问题在 Stackoverflow 上已经被问过很多次了,快速搜索会在这里和谷歌上弹出很多信息。也就是说,我建议您查看 jclarity.com,他们的 gc log scrapper 对于帮助调整 GC 设置非常有价值。
-
我不同意副本。我已阅读链接的问题和许多相关资源。但是从我收集到的(参见链接的问题)来看,年轻一代和老一代的大小之间没有 no 固定比率,因此不应该仅仅因为明确的年轻一代大小限制就存在老一代大小限制设置。
-
@ChrisK:我使用的是 jClarity 的 Censum,它首先为我指明了正确的方向。
标签: java garbage-collection jstat