14

G1 ガベージ コレクタを使用しているアプリケーションでフル GC が時々発生することに気付き、その原因を突き止めようとしています。

ある領域スキャン開始から次の領域スキャン開始までのサイクルを以下に抜粋します。61807.406 で、完全な GC がログに記録され、その後に、concurrent-mark-abort のエントリが続きます。私が知りたいのは、GC が完全なストップ・ザ・ワールドのガベージ コレクションを実行する必要性を感じた理由と、それを回避する方法です。

この質問は、OpenJDK メーリング リストで以前に質問されたようですが、回答がありません。

簡潔にするために若い GC の詳細を切り詰めましたが、必要に応じて完全なチャンクをどこかに投稿できます。

61805.878: [GC concurrent-root-region-scan-start]
61805.882: [GC concurrent-root-region-scan-end, 0.0033586]
61805.882: [GC concurrent-mark-start]
61806.133: [GC pause (young), 0.02836202 secs]
   [Eden: 498M(498M)->0B(478M) Survivors: 14M->34M Heap: 3025M(4096M)->2548M(4096M)]
 [Times: user=0.19 sys=0.00, real=0.03 secs] 
61806.426: [GC pause (young), 0.02766222 secs]
   [Eden: 478M(478M)->0B(480M) Survivors: 34M->32M Heap: 3050M(4096M)->2576M(4096M)]
 [Times: user=0.19 sys=0.00, real=0.03 secs] 
61806.717: [GC pause (young), 0.02214895 secs]
   [Eden: 480M(480M)->0B(502M) Survivors: 32M->10M Heap: 3056M(4096M)->2571M(4096M)]
 [Times: user=0.09 sys=0.00, real=0.02 secs] 
61807.000: [GC pause (young), 0.01899188 secs]
   [Eden: 502M(502M)->0B(502M) Survivors: 10M->10M Heap: 3074M(4096M)->2573M(4096M)]
 [Times: user=0.09 sys=0.00, real=0.02 secs] 
61807.201: [GC pause (young), 0.02619259 secs]
   [Eden: 162M(502M)->0B(500M) Survivors: 10M->12M Heap: 3036M(4096M)->2876M(4096M)]
 [Times: user=0.11 sys=0.00, real=0.03 secs] 
61807.283: [GC pause (young), 0.02068515 secs]
   [Eden: 102M(500M)->0B(500M) Survivors: 12M->12M Heap: 3058M(4096M)->2957M(4096M)]
 [Times: user=0.09 sys=0.00, real=0.02 secs] 
61807.350: [GC pause (young), 0.01606520 secs]
   [Eden: 52M(500M)->0B(498M) Survivors: 12M->14M Heap: 3020M(4096M)->2969M(4096M)]
 [Times: user=0.11 sys=0.00, real=0.02 secs] 
61807.389: [GC pause (young), 0.01573865 secs]
   [Eden: 42M(498M)->0B(500M) Survivors: 14M->12M Heap: 3021M(4096M)->2978M(4096M)]
 [Times: user=0.09 sys=0.00, real=0.02 secs] 
61807.406: [Full GC 2978M->2498M(4096M), 4.8896638 secs]
 [Times: user=6.37 sys=0.08, real=4.89 secs] 
61812.296: [GC concurrent-mark-abort]
61812.542: [GC pause (young), 0.01526403 secs]
   [Eden: 512M(500M)->0B(510M) Survivors: 0B->2048K Heap: 3018M(4096M)->2506M(4096M)]
 [Times: user=0.09 sys=0.00, real=0.02 secs] 
61812.793: [GC pause (young) (initial-mark), 0.01391544 secs]
   [Eden: 510M(510M)->0B(508M) Survivors: 2048K->4096K Heap: 3016M(4096M)->2508M(4096M)]
 [Times: user=0.09 sys=0.00, real=0.01 secs] 
61812.807: [GC concurrent-root-region-scan-start]

これは、次の興味深い設定で Java Hotspot 1.7.0_7 リリースを使用しています。

-XX:PermSize=128m
-XX:MaxPermSize=128m
-XX:NewSize=512m
-XX:MaxNewSize=512m
-Xms4096m
-Xmx4096m
-XX:+UnlockDiagnosticVMOptions
-XX:+UnsyncloadClass
-XX:+UseTLAB
-XX:+UseG1GC
-XX:SurvivorRatio=10
-Xloggc:./workspace/gc.log
-verbose:gc
-XX:+PrintGC
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
4

1 に答える 1

8

私はあなたがこの参照について知っていると思います. このページも参考になります。

フル GC は、保有オブジェクト (一時的な (若い) 世代のコレクションで生き残ったオブジェクト) が割り当てられたスペースを埋めるときに発生します。完全な GC が発生すると、進行中の一時的なマーキングはすべて中止する必要があります。

Tenured世代がいっぱいになる速度を下げるには、ヒープ/RAMを追加するか、TenuredスペースとYoungスペースの間で使用可能なメモリの分割をいじる必要があります。パラメータNewSize、MaxNewSizeおよびNewRatioは後者用です。実験は何がうまくいくかを見つける唯一の方法です。

比率をシフトして Tenured 世代を大きくすると、完全なコレクションの数が減少するというのが一般的な考えです。多くの場合、これは当てはまりますが、常にそうとは限りません。多くの Tenured オブジェクトが、Tenured の直後に死んでいるという状況があります。つまり、若い頃に集められるべきだったのですが、そのためには寿命が少し遅かったのです。この場合、若い世代を大きくすることで、これらのオブジェクトを保有するのではなく、そこに集めることができます。この症状は、完全なコレクションであり、割り当てられたスペースが大幅に減少します。

それはあなたの場合ではないようです: 2978M->2498M. あなたの唯一の方法は、必要に応じてより多くのメモリを購入して、ヒープを大きくすることかもしれません。それでも、長時間稼働するほぼすべてのシステムでは、完全なコレクションが時々発生します。

于 2012-11-01T03:06:52.293 に答える