为什么G1GC在开始混合收藏之前缩小年轻一代？ [英] Why does G1GC shrink the young generation before starting mixed collections?

问题描述

当G1决定需要开始混合收藏时，它将我们的Eden空间从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名幸存者（90112K）
Metaspace使用37327K，容量37826K，承诺38096K，保留1083392K
使用空间3935K，容量4081K，承诺4096K，保留1048576K
2016-03-31T20 ：57：31.002 + 0000：7196.427：[GC暂停（G1撤离暂停）（年轻）
所需的幸存者大小717225984字节，新阈值1（最大1）
- 年龄1：41346816字节，总计41346816
7196.427：[G1人体工程学（CSet构造）开始选择CSet，_pending_cards：144693，预计基准时间：48.88毫秒，剩余时间：951.12毫秒，目标暂停时间：1000.00毫秒]
7196.427： G1人机工程学（CSet Construction）将年轻区域添加到CSet，eden：1352个地区，幸存者：11个地区，预测年轻地区时间：20.72 ms]
7196.427：[G1人机工程学（CSet Construction）完成CSet，eden：1352个地区，幸存者：11个地区，旧地区：0个地区，预计暂停时间：69.60毫秒，目标暂停时间：1000.00毫秒]
7196.494：[G1人机工程学（混合GC）开始混合GCs，原因：候选老区域可用， ：789个区域，可回收：4703761904个字节（22.43％），阈值：5.00％]
，0.0673540秒]
[并行时间：60.1毫秒，GC工作人员：18]
[ （毫秒）：最小值：7196427.8，平均值：7196428.1，最大值：7196428.2，差值：0.4]
[最小值：7.3，平均值：7.5，最大值：7.7，Diff：0.4， [更新RS（ms）：最小：28.2，平均：28.8，最大：29.9，Diff：1.7，总和：518.4]
[已处理的缓冲区：最小值：41，平均值：57.7，最大值：80，Diff：39，Sum：1039]
[Scan RS（ms）：Min：0.1，Avg：0.2，最大值：0.5，差值：0.4，总和：3.7]
[代码根扫描（ms）：最小值：0.0，平均值：0.0，最大值：0.0，差值：0.0，总和值：0.1]
[复制（ms）：Min：22.1，Avg：23.1，Max：23.4，Diff：1.3，Sum：416.2]
[终止（ms）：最小值：0.0，平均值：0.0，最大值：0.0，Diff：0.0 ，总和：0.1]
[终止尝试次数：最小值：1，平均值：1.0，最大值：1，差值：0，总和：18]
[GC Worker Other（ms）：Min：0.0，Avg ：0.1，最大值：0.2，差值：0.2，总和值：2.5]
[GC工作总数（毫秒）：最小值：59.5，平均值：59.7，最大值：60.0，差值：0.5，总和：1075.1] b [GC工作结束时间（ms）：最小值：7196487.7，平均值：7196487.8，最大值：7196487.9，Diff：0.2]
[代码根修正：0.2 ms]
[代码根净化：0.0 ms] $
[其他：5.2 ms]
[选择CSet：0.0 ms]
[Ref CT：0.5 ms]
[Ref Enq： 0.0毫秒]
[累加卡数：0.5毫秒]
[累加寄存器：0.2毫秒]
[累加回收次数：0.1 ms]
[Free CSet：2.3 ms]
[E 10.6G（10.6G）→0.0B（848.0M）幸存者：88.0M-> 152.0M堆：17.5G（19.5G）→7128.3M（19.5G）〕
堆后GC调用= 295（全0）：
垃圾优先堆总计20480000K，使用7299344K [0x00000002de000000,0x00000002de804e20,0x00000007c0000000）
区域大小8192K，19个年轻人（155648K），19个幸存者（155648K）
Metaspace使用37327K，容量37826K，承诺38096K，保留1083392K
使用空间3935K，容量4081K，承诺4096K，保留1048576K
}
[Times：user = 1.09 sys = 0.00，实际= 0.07秒]
2016-03-31T20：57：31.070 + 0000：7196.495：应用线程停止的总时间：0.0699324秒，停止线程花费：0.0003462秒


这是在10-11g伊甸园运行60个或更多集合之后。

以下是我们正在运行的相应JVM GC参数
$ b

  -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
  

根据此演示文稿的第55页，它需要调整Eden的大小以便最大暂停目标占据整个堆，而不仅仅是到新一代。为什么收藏家如此激进？

堆大小为10g时，平均年轻代停顿时间在50-150毫秒之间。如果演示文稿是正确的（我还没有发现其他任何内容来支持该声明），我预计会缩小一半（20g堆），而不是10x。

方案

您可以在幻灯片no中找到您的查询答案：56

年轻一代收缩了20倍

因此10X工厂的缩小并不意外。

从 infoQ 有关调整G1GC技巧的文章由Monica Beckwith提供： b
$ b

Full GC可以通过让幼儿园/幼儿园缩小到默认最小值（总Java堆的5％）

由于您没有明确设置年轻的gen大小，因此默认值为

  -XX：G1NewSizePercent = 5 
  

设置堆的百分比作为年轻一代规模的最小值。

因此，要尊重您的暂停时间目标

p>

  -XX：MaxGCPauseMillis = 1000 
  

年轻的gen可以缩小至总堆的5％。

我已经在$ b $中找到了一篇关于G1GC的优秀谷歌组文章b https://groups.google.com/a/jclarity.com/forum/#!msg/friends/hsZiz6HTm9M/klrRjBclCwAJ

如果G1预测的暂停时间目标大于目标暂停时间目标，然后缩小年轻代，但不超过当前Java堆大小（不是最大大小）的 G1NewSizePercent 。同样，根据计算出的GC时间比值与 GCTimeRatio 的值，整个Java堆将会增长（或缩小）。注意： > G1NewSizePercent 和 G1MaxNewSizePercent 不要与 NewSize 或 MaxNewSize 混淆。

G1MaxNewSizePercent 和 G1MaxNewSizePercent 分别给出了一个较小和较大的界限，通过G1。

在不同的说明中，您已经配置了许多可能不必要的参数正弦G1GC工作正常，如果大多数默认参数已设置为默认值。有关更多详情，请参阅此SE问题。

总结 strong>：根据暂停时间的目标，年轻的gen会缩小。如果您真的担心年轻人的收缩值会降低，请配置 -XX：G1NewSizePercent 。但只要 -XX：MaxGCPauseMillis 得到满足，我不会推荐它。

编辑：

从G1GC ergonomics page，

随着垃圾收集器试图满足相互竞争的目标，垃圾堆将会振荡。 即使应用程序已达到稳定状态，也是如此。达到吞吐量目标（可能需要更大的堆）的压力与最大暂停时间和最小占用空间（这两者可能需要一个小堆）竞争目标。

When G1 decides it needs to start doing mixed collections, it aggressively shrinks our Eden space from 10g to about 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

This is after it's been running with 10-11g of Eden for 60 or more collections.

Here are the appropriate JVM GC parameters we're running with

-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"

According to page 55 of this presentation, it needs to resize Eden so that max pause target accounts for the entire heap, not just to the new generation. Why is the collector being so aggressive?

Average young generation pause times are between 50-150ms for a heap size of 10g. If the presentation is correct (I haven't found anything else to support the statement), I would expect shrinking by half (20g heap), not 10x.

解决方案

You can find answer for your query in slide no : 56

Young generation shrunk by a factor of 20X

So shrinking by a factory of 10X is not a surprise.

From infoQ article by Monica Beckwith on tips for tuning G1GC :

The Full GC could have been avoided by letting the nursery / young gen shrink to the default minimum (5% of the total Java heap)

Since you have not set young gen size explicitly, default value is

-XX:G1NewSizePercent=5

Sets the percentage of the heap to use as the minimum for the young generation size.

So to respect your pause time goal of

-XX:MaxGCPauseMillis=1000 

the young gen can shrink up-to 5% of total heap.

I have found one good google group article regarding G1GC at https://groups.google.com/a/jclarity.com/forum/#!msg/friends/hsZiz6HTm9M/klrRjBclCwAJ

If G1 predicted pause time goal is larger than the target pause time goal, then shrink young generation, but no more than G1NewSizePercent of the current Java heap size, (not the max size). Again, overall Java heap will grow (or shrink) based on the value computed GC time ratio versus value of GCTimeRatio.

Note: G1NewSizePercent, and G1MaxNewSizePercent are not to be confused with NewSize or MaxNewSize.

G1NewSizePercent and G1MaxNewSizePercent put a lower and upper bound respectively on how small or how large young gen can be sized by G1.

On a different note, you have configured many parameters which may be un-necessary sine G1GC works fine if most of the default parameters have been set to default values. Refer to this SE question for more details.

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

In summary: Depending on pause time goal, young gen will shrink. If you are really worried about shrinking of young gen to low value, configure -XX:G1NewSizePercent. But I won't recommend it as long as -XX:MaxGCPauseMillis has been met

EDIT:

From G1GC ergonomics page,

It is typical that the size of the heap will oscillate as the garbage collector tries to satisfy competing goals. This is true even if the application has reached a steady state. The pressure to achieve a throughput goal (which may require a larger heap) competes with the goals for a maximum pause time and a minimum footprint (which both may require a small heap).

这篇关于为什么G1GC在开始混合收藏之前缩小年轻一代？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！