为什么G1GC在开始混合收藏之前缩小了年轻一代?

时间:2016-03-31 23:14:05

标签: java garbage-collection heap-memory g1gc

当G1决定需要开始进行混合收藏时,它会将我们的伊甸园空间从10g大幅缩小到约1g。

{Heap before GC invocations=294 (full 0):
 garbage-first heap   total 20480000K, used 18304860K [0x00000002de000000, 0x00000002de804e20, 0x00000007c0000000)
  region size 8192K, 1363 young (11165696K), 11 survivors (90112K)
 Metaspace       used 37327K, capacity 37826K, committed 38096K, reserved 1083392K
  class space    used 3935K, capacity 4081K, committed 4096K, reserved 1048576K
2016-03-31T20:57:31.002+0000: 7196.427: [GC pause (G1 Evacuation Pause) (young)
Desired survivor size 717225984 bytes, new threshold 1 (max 1)
- age   1:   41346816 bytes,   41346816 total
 7196.427: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 144693, predicted base time: 48.88 ms, remaining time: 951.12 ms, target pause time: 1000.00 ms]
 7196.427: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 1352 regions, survivors: 11 regions, predicted young region time: 20.72 ms]
 7196.427: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 1352 regions, survivors: 11 regions, old: 0 regions, predicted pause time: 69.60 ms, target pause time: 1000.00 ms]
 7196.494: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: candidate old regions available, candidate old regions: 789 regions, reclaimable: 4703761904 bytes (22.43 %), threshold: 5.00 %]
, 0.0673540 secs]
   [Parallel Time: 60.1 ms, GC Workers: 18]
      [GC Worker Start (ms): Min: 7196427.8, Avg: 7196428.1, Max: 7196428.2, Diff: 0.4]
      [Ext Root Scanning (ms): Min: 7.3, Avg: 7.5, Max: 7.7, Diff: 0.4, Sum: 134.2]
      [Update RS (ms): Min: 28.2, Avg: 28.8, Max: 29.9, Diff: 1.7, Sum: 518.4]
         [Processed Buffers: Min: 41, Avg: 57.7, Max: 80, Diff: 39, Sum: 1039]
      [Scan RS (ms): Min: 0.1, Avg: 0.2, Max: 0.5, Diff: 0.4, Sum: 3.7]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [Object Copy (ms): Min: 22.1, Avg: 23.1, Max: 23.4, Diff: 1.3, Sum: 416.2]
      [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
         [Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 18]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 2.5]
      [GC Worker Total (ms): Min: 59.5, Avg: 59.7, Max: 60.0, Diff: 0.5, Sum: 1075.1]
      [GC Worker End (ms): Min: 7196487.7, Avg: 7196487.8, Max: 7196487.9, Diff: 0.2]
   [Code Root Fixup: 0.2 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 1.9 ms]
   [Other: 5.2 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 0.5 ms]
      [Ref Enq: 0.0 ms]
      [Redirty Cards: 0.5 ms]
      [Humongous Register: 0.2 ms]
      [Humongous Reclaim: 0.1 ms]
      [Free CSet: 2.3 ms]
   [Eden: 10.6G(10.6G)->0.0B(848.0M) Survivors: 88.0M->152.0M Heap: 17.5G(19.5G)->7128.3M(19.5G)]
Heap after GC invocations=295 (full 0):
 garbage-first heap   total 20480000K, used 7299344K [0x00000002de000000, 0x00000002de804e20, 0x00000007c0000000)
  region size 8192K, 19 young (155648K), 19 survivors (155648K)
 Metaspace       used 37327K, capacity 37826K, committed 38096K, reserved 1083392K
  class space    used 3935K, capacity 4081K, committed 4096K, reserved 1048576K
}
 [Times: user=1.09 sys=0.00, real=0.07 secs]
2016-03-31T20:57:31.070+0000: 7196.495: Total time for which application threads were stopped: 0.0699324 seconds, Stopping threads took: 0.0003462 seconds

这是在它使用10-11克Eden运行60个或更多集合之后。

以下是我们使用

运行的相应JVM GC参数
-Xms20000m -Xmx20000m
-XX:+UseG1GC 
-XX:G1RSetUpdatingPauseTimePercent=5 
-XX:MaxGCPauseMillis=1000 
-XX:GCTimeRatio=99 
-XX:InitiatingHeapOccupancyPercent=35 
-XX:MaxTenuringThreshold=1 
-XX:G1ConcRefinementThreads=6 
-XX:ConcGCThreads=18 
-XX:ParallelGCThreads=18

-XX:+PrintGCDetails"
-XX:+PrintGCDateStamps"
-XX:+PrintHeapAtGC"
-XX:+PrintTenuringDistribution"
-XX:+PrintGCApplicationStoppedTime"
-XX:+PrintPromotionFailure"
-XX:+PrintAdaptiveSizePolicy"

根据page 55 of this presentation,它需要调整Eden的大小,以便最大暂停目标占整个堆,而不仅仅是新一代。为什么收藏家如此咄咄逼人?

对于10g的堆大小,平均年轻代停顿时间在50-150ms之间。如果演示文稿是正确的(我还没有找到支持该声明的其他内容),我预计会缩减一半(20g堆),而不是10x。

2 个答案:

答案 0 :(得分:8)

您可以在幻灯片编号:56

中找到查询的答案
  

年轻一代萎缩了20倍

一家10倍的工厂萎缩并不令人意外。

来自Monica Beckwith的infoQ文章关于调整G1GC的提示:

  

通过让托儿所/年轻人缩小到默认最小值(占Java总堆数的5%),可以避免使用Full GC。

由于您未明确设置年轻基因大小,因此默认值为

-XX:G1NewSizePercent=5

设置要用作年轻代大小的最小值的堆的百分比。

所以要尊重你的暂停时间目标

-XX:MaxGCPauseMillis=1000 

年轻人可以萎缩到总堆积的5%。

我找到了一篇关于G1GC的好的谷歌小组文章 https://groups.google.com/a/jclarity.com/forum/#!msg/friends/hsZiz6HTm9M/klrRjBclCwAJ

如果G1预测暂停时间目标大于目标暂停时间目标,则缩小年轻代,但不超过当前Java堆大小的 G1NewSizePercent (不是最大大小)。同样,整体Java堆将根据计算的GC时间比值与 GCTimeRatio 的值增长(或收缩)。

注意: G1NewSizePercent G1MaxNewSizePercent 不得与 NewSize MaxNewSize 混淆。

G1NewSizePercent G1MaxNewSizePercent 分别对G1的大小或大小的大小或大小进行了下限和上限。

另一方面,您已经配置了许多参数,这些参数可能是不必要的,如果大多数默认参数已设置为默认值,则G1GC可以正常工作。有关详细信息,请参阅此SE问题。

Java 7 (JDK 7) garbage collection and documentation on G1

总结根据暂停时间目标,年轻的gen会缩小。如果您真的担心将年轻人缩小到低值,请配置-XX:G1NewSizePercent。但只要符合-XX:MaxGCPauseMillis

,我就不会推荐它

修改

来自G1GC ergonomics页面,

  

当垃圾收集器试图满足竞争目标时,堆的大小通常会振荡。 即使应用程序已达到稳定状态也是如此。实现吞吐量目标(可能需要更大的堆)的压力与目标竞争最大暂停时间和最小占用空间(两者都可能需要一小堆)。

答案 1 :(得分:0)

在MaxTenuringThreshold = 1的情况下,您要告诉GC在仅存活1个GC周期后将对象提升为旧一代。在大多数应用程序中,这将导致许多过早的升级。如果提早推广了太多对象,那么您的老一代将迅速增长,因此必须缩小青年一代才能为老一代腾出空间