2016-03-31 6 views
6

G1が混合コレクションの実行を開始する必要があると判断した場合、Eden領域を積極的に10gから約1gに縮小します。なぜG1GCは混合コレクションを開始する前に若い世代を縮小しますか?

{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 

これは、60以上のコレクションで10-11gのEdenで実行された後です。ここで

たちはpage 55 of this presentationによる

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

で実行している適切なJVMのGCのパラメータであり、それはので、最大のポーズターゲットだけではなく、新しい世代に、ヒープ全体を占めエデンのサイズを変更する必要があります。コレクターはなぜそんなに攻撃的なのですか?

ヒープサイズが10gの場合、平均若い世代休止時間は50〜150msです。プレゼンテーションが正しい場合(私はそのステートメントをサポートするために他に何かを見つけられませんでした)、半分(20gのヒープ)の縮小が10倍ではないことが予想されます。

+0

私はちょうどそのプレゼンテーションを読んだことがありますが(実際にはかなり良いですが)、あなたの記事で言及しているスライド55には同じことはありません。そして、edenが12.5gbから1gbに削減された例を示しています。これはあなたのものに似ています。なぜあなたはedenがそれよりも小さく収縮すると予想するのか、もっと詳しく説明できますか? –

+0

さらに、print-adaptive-size-policyフラグを追加することを検討してください。 –

+0

@EngineerDollery 'PrintAdaptiveSizePolicy'パラメータが有効です(質問に追加されています)。プレゼンテーションでは、問題#3、それは "若いだけでなく、若い世代を縮小する、古い領域を考慮しなければならない"と述べている。理想的には、世代がまったく縮小するとは思わないでしょう。私たちは休止の目標を1000msに設定しました。コレクションはそれよりはるかに高速です。既にマークされているゴミの2倍を収集することは、2倍以上かかることはありません。 – Savior

答えて

5

あなたはスライドなしでクエリの答えを見つけることができます。

20Xだから10倍の工場で縮小倍に縮小し56

若い世代に驚きではありません。フルGCは保育園/若い世代は、デフォルトの最小値(合計Javaヒープの5%)に縮小させることによって回避されている可能性が

:G1GCをチューニングするためのヒント上のモニカ・ベックウィズによってinfoQ記事から

明示的に若い世代のサイズを設定していないので、デフォルト値はpercentagを設定します

-XX:G1NewSizePercent=5 
ですeを若い世代のサイズの最小値として使用することができます。だから、若い世代がヒープ全体のアップに5%を縮小することができます

-XX:MaxGCPauseMillis=1000 

のあなたの休止時間の目標を尊重する

は私が G1の予測停止時間の目標は、それから、若い世代を縮小し、目標休止時間の目標よりも大きい場合https://groups.google.com/a/jclarity.com/forum/#!msg/friends/hsZiz6HTm9M/klrRjBclCwAJ

でG1GCに関する一つの良いのGoogleグループの記事を見つけましたが、これ以上以下G1NewSizePercentのき現在のJavaヒープサイズ(最大サイズではありません)。ここでも、全体のJavaヒープは、計算されたGC時間比対値GCTimeRatioの値に基づいて増加または縮小します。

注:G1NewSizePercent、およびG1MaxNewSizePercentNewSizeパラメータまたはMaxNewSizeと混同してはなりません。

G1NewSizePercentG1MaxNewSizePercent下に置くと、上の世代は、G1によってサイズにすることができるどのように小さなまたはどのように大規模な若者にそれぞれ結合しました。

多くのパラメータを必要に応じて設定しました。ほとんどのデフォルトパラメータがデフォルト値に設定されていれば、G1GCは正常に動作します。詳細については、このSEの質問を参照してください。要約で

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

休止時間の目標に応じて、若い世代が縮小されます。若い世代が低い価値に縮小することを本当に心配している場合は、-XX:G1NewSizePercentと設定してください。しかし、私は-XX:MaxGCPauseMillisが満たされている限り、それをお勧めしません

EDIT: G1GC ergonomicsページから

ヒープのサイズのように振動するのが典型的ですガベージコレクタは競合するゴールを満たそうとします。 アプリケーションが定常状態に達した場合でも、これは当てはまります。スループット目標(より大きなヒープが必要な可能性があります)を達成するというプレッシャーは、最大休止時間と最小フットプリント(いずれも小さなヒープが必要な場合があります)の目標と競合します。

+0

それができるからですか?それは私を満足させるものではなく、現時点ではいかなる文書でもそれをサポートしていません。印刷されたGCの詳細からわかるように、休止時間は既に最大休止時間目標内に収まっています。そんなに大きなサイズを変更する理由はありません。サイズをあまり大きくすると、アプリケーションに大きな負担がかかります。現在、このアプリケーションは2〜3秒で10gのゴミを生成することができます。新しいヒープが800mの場合、JVMは数百ミリ秒ごとにgc'ingされます。これはスループットに悪影響を与えます。 – Savior

+0

oracleのドキュメント・ページから:G1 GCには、(ソフト・リアルタイムで)会うことを試みる休止時間ターゲットがあります。若いコレクションの間、G1 GCは若い世代(エデンとサバイバーのサイズ)をソフトリアルタイムターゲットに合わせて調整します。混在収集中、G1 GCは、混在ガベージコレクションの目標数、ヒープの各領域内のライブオブジェクトの割合、および全体として許容されるヒープ廃棄率に基づいて収集される古い領域の数を調整します。 –

+0

この記事とinfoqの記事は、証明を提供しています。 –

関連する問題