调整 JVM 堆大小后解释 jstat 输出答案

【问题标题】：Interpreting jstat output after tuning JVM heap size调整 JVM 堆大小后解释 jstat 输出
【发布时间】：2012-02-07 05:33:48
【问题描述】：

最近尝试增加堆空间和新旧 gen 大小的比率，我看到来自 jstat -gccapacity 的令人困惑的结果，它显示的容量比我预期的要小得多。

JVM (1.5.0_16) 以-server -Xms2048m -Xmx2048m -XX:NewRatio=2 启动。它在 Solaris 5.10 amd64 主机上运行。有大约 10GB 的可用内存。所以从我读过的内容来看，JVM 应该能够利用完整的 2GB 堆空间。

观看jstat -gcutil 我观察到所有代都填满了几次导致垃圾收集。例如：

Timestamp         S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
        66150.4   0.00  51.09  56.95  90.33  54.85   6291   58.922     7   22.826   81.748

我原以为这会导致 JVM 将所有代扩展到它们的完整大小。但是，jstat -gccapacity 会产生：

 NGCMN    NGCMX     NGC     S0C   S1C       EC      OGCMN      OGCMX       OGC         OC      PGCMN    PGCMX     PGC       PC     YGC    FGC
700416.0 700416.0  86016.0 1408.0 1408.0  39104.0  1398784.0  1398784.0  1398784.0  1398784.0  16384.0  65536.0  38912.0  38912.0   6338     7

后续运行显示 NGC/S0C/S1C/EC 值发生变化：

 NGCMN    NGCMX     NGC     S0C   S1C       EC      OGCMN      OGCMX       OGC         OC      PGCMN    PGCMX     PGC       PC     YGC    FGC
700416.0 700416.0  86016.0 1472.0 1472.0  39104.0  1398784.0  1398784.0  1398784.0  1398784.0  16384.0  65536.0  38912.0  38912.0   6380     7
700416.0 700416.0 106496.0 1792.0 1856.0  97024.0  1398784.0  1398784.0  1398784.0  1398784.0  16384.0  65536.0  38912.0  38912.0   6433     7
700416.0 700416.0 106496.0 1792.0 1792.0  96064.0  1398784.0  1398784.0  1398784.0  1398784.0  16384.0  65536.0  38912.0  38912.0   6436     7

据我了解，容量数字是一代的总规模，而利用率数字显示的是一代内的分配。所以上面的结果告诉我，新的最小和最大容量的组合都是（NGCMN/MGCMX）684MB，而旧的最小和最大容量是 1,366MB（OGCMN/OGCMX）。令我困惑的是新一代的能力。所以我的问题：

为什么不 EC + S0C + S1C == NGC？ (41,920 != 86016)
为什么 NGC 明显小于 NGCMN/MGCMX？
- 这是因为达到了最大堆大小（从 NGC+OGC+PGC 将其设置为 1,488MB），如果是这样，什么会导致下限？我能找到的所有文档都说 Solaris 64 位 JVM 应该能够使用 4GB。
如果达到最大堆大小，为什么新生代会改变容量（全部增加或全部减少），而老一代却没有改变以进行补偿）。

其他可能有用的 jstat 结果：

$ jstat -gcnew 20167
 S0C    S1C    S0U    S1U   TT MTT  DSS      EC       EU     YGC     YGCT
1536.0 1600.0 1300.3    0.0 13  15 1600.0  82880.0  30892.6   6482   60.540

$ jstat -gcnewcapacity 20167
  NGCMN      NGCMX       NGC      S0CMX     S0C     S1CMX     S1C       ECMX        EC      YGC   FGC
  700416.0   700416.0   106496.0   1472.0 233472.0 233472.0   1408.0   700288.0    81088.0  6489     7

$ jstat -gcold 20167
   PC       PU        OC          OU       YGC    FGC    FGCT     GCT
 38912.0  21426.5   1398784.0   1375651.6   6503     7   22.826   83.627

$ jstat -gcoldcapacity 20167
   OGCMN       OGCMX        OGC         OC       YGC   FGC    FGCT     GCT
  1398784.0   1398784.0   1398784.0   1398784.0  6517     7   22.826   83.779

$ jstat -gcpermcapacity 20167
  PGCMN      PGCMX       PGC         PC      YGC   FGC    FGCT     GCT
   16384.0    65536.0    38912.0    38912.0  6531     7   22.826   83.925

【问题讨论】：

标签： java garbage-collection jstat

【解决方案1】：

事实证明这是吞吐量收集器的故意行为：

Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine > 5.2.2.2 Adjusting Generation Sizes

收集器保存的统计信息（例如，平均暂停时间）是在集合结束时更新。测试以确定是否目标已经实现，然后进行任何必要的调整一代的大小。

在 JVM 处于峰值负载时观察 GC 容量确实显示组合的年轻代当前容量等于最小/最大容量值。

【讨论】：