2

我正在调查一个 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 文档，我们可以看到当前的老年代大小 ( OGC ) 已经达到了最大老年代大小 ( OGCMX )。然而，第一行告诉我们“旧空间利用率占空间当前容量的百分比”（O）“仅”为 88%。

我的问题是：

  • 什么机制将老一代限制设置为 jstat 输出中的 OGCMX？
  • 是什么阻止旧空间增长并用完剩余的约 12% 的堆？

我们有 JVM 参数，用于设置总堆、新空间和永久空间 ( -Xms -Xmx -XX:NewSize -XX:MaxNewSize -XX:PermSize -XX:MaxPermSize) 的最小/最大值。但是对旧空间没有设置限制（我不知道这些参数是否存在）。

关于NewRatio的编辑：
这是我的理解，这里也提到JVM 不会强制执行新旧空间之间的比率，尤其是在MaxNewSize使用参数的情况下。并且该MaxNewSize参数被接受，因为上面的值 (301056.0KB) 实际上正是我们指定的 294MB MaxNewSize。此外，NewRatio 的默认值为2（参见此处），这根本不是 jstat 列出的上述任何值之间的比率。

4

1 回答 1

3

我觉得这个问题真的很重要。我正在寻找完全相同的答案。就我而言，情况更糟。我们有 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 没有使用它，它也会占用全部容量......

于 2015-01-20T09:20:19.213 回答