【问题标题】:Java heap: What is limiting maximum old generation capacity?Java 堆:什么限制了老年代的最大容量?
【发布时间】: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


【解决方案1】:

我觉得这个问题真的很重要。我正在寻找完全相同的答案。就我而言,情况更糟。我们有 6GB 作为 Xmx,gccapacity 选项的输出显示它正在使用几乎 100% 的内存:

[ec2-user@ip ~]$ sudo jstat -gccapacity 2416
OGCMX: 6121088.0
OGC:   6084776.0

以及 gcutil 选项的输出:

[ec2-user@ip ~]$ sudo jstat -gcutil 2416
  S0     S1     E      O      P     YGC 
  0.00 100.00  26.01  58.81  59.90   8555

这意味着它应该只使用大约 59% 的老年代。 我不明白这一点。这意味着 JVM 正在占用全部容量,即使它没有使用它...

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-05-10
    • 2021-07-08
    • 1970-01-01
    • 2021-12-17
    • 2023-03-08
    • 2022-07-21
    相关资源
    最近更新 更多