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

时间:2012-02-07 05:33:48

标签: java garbage-collection jstat

最近尝试增加堆空间和新旧大小的比例,我看到jstat -gccapacity的混乱结果显示出比我预期的小得多的容量。

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

观察jstat -gcutil我观察到所有代人都填满了几次导致垃圾收集。 E.g:

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)。令我困惑的是新一代的能力。所以我的问题:

  1. 为什么EC + S0C + S1C = = NGC? (41,920!= 86016)
  2. 为什么NGC明显小于NGCMN / MGCMX?
    • 这是因为最大堆大小被击中(从NGC + OGC + PGC将其置于1,488MB),如果是这样会导致下限?我能找到的所有文档都说Solaris 64位JVM应该能够使用4GB。
  3. 如果最大堆大小被击中,为什么新一代的容量会发生变化(全部增加或全部减少),而不会更改老一代以补偿)。

  4. 其他可能有用的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
    

1 个答案:

答案 0 :(得分:2)

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

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

  

收集者保存的统计数据(例如,平均暂停时间)   在集合结束时更新。测试确定是否   然后制定目标,并进行任何必要的调整   一代人的规模。

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