6

私たちは grails を実行しており、permgen スペースをクリアするために複数のフル ガベージ コレクションが必要であることに気付きました。

2013-06-06T16:11:27.016+0000: 32582.145: [Full GC 32582.145: [CMS2013-06-06T16:11:45.404+0000:     32600.532: [CMS-concurrent-mark: 21.403/86.063 secs] [Times: user=48.44 sys=0.63, real=86.07 secs]
(concurrent mode failure): 7585874K->7290466K(10145024K), 57.9230770 secs] 7866094K->7290466K(10451712K), [CMS Perm : 261766K->261702K(262144K)] icms_dc=30 , 57.9232150 secs] [Times: user=57.97 sys=0.00, real=57.93 secs]
2013-06-06T16:12:25.183+0000: 32640.311: [GC [1 CMS-initial-mark: 7290466K(10145024K)] 7385976K(10451712K), 0.0880890 secs] [Times: user=0.09 sys=0.00, real=0.08 secs]
2013-06-06T16:12:25.271+0000: 32640.400: [CMS-concurrent-mark-start]
2013-06-06T16:12:25.427+0000: 32640.555: [GC 32640.556: [ParNew: 272640K->10006K(306688K), 0.0622620 secs] 7563106K->7300472K(10451712K) icms_dc=30 , 0.0624140 secs] [Times: user=0.24 sys=0.00, real=0.06 secs]
2013-06-06T16:12:25.734+0000: 32640.863: [GC 32640.863: [ParNew: 282646K->13476K(306688K), 0.0648770 secs] 7573112K->7303942K(10451712K) icms_dc=30 , 0.0650170 secs] [Times: user=0.26 sys=0.00, real=0.07 secs]
2013-06-06T16:12:26.013+0000: 32641.142: [GC 32641.142: [ParNew: 286116K->11277K(306688K), 0.0607460 secs] 7576582K->7301743K(10451712K) icms_dc=30 , 0.0608870 secs] [Times: user=0.25 sys=0.00, real=0.06 secs]
2013-06-06T16:12:32.449+0000: 32647.577: [GC 32647.577: [ParNew: 283917K->17560K(306688K), 0.0672260 secs] 7574383K->7308026K(10451712K) icms_dc=30 , 0.0673710 secs] [Times: user=0.27 sys=0.00, real=0.07 secs]
2013-06-06T16:12:33.107+0000: 32648.236: [GC 32648.236: [ParNew: 290200K->22523K(306688K), 0.0686820 secs] 7580666K->7312989K(10451712K) icms_dc=30 , 0.0688200 secs] [Times: user=0.28 sys=0.00, real=0.07 secs]
2013-06-06T16:12:33.845+0000: 32648.974: [Full GC 32648.974: [CMS2013-06-06T16:12:52.516+0000: 32667.645: [CMS-concurrent-mark: 21.346/27.245 secs] [Times: user=27.55 sys=0.14, real=27.25 secs]
(concurrent mode failure): 7290466K->7293289K(10145024K), 57.7092090 secs] 7523492K->7293289K(10451712K), [CMS Perm : 262143K->262143K(262144K)] icms_dc=30 , 57.7093560 secs] [Times: user=57.76 sys=0.00, real=57.71 secs]
2013-06-06T16:13:31.557+0000: 32706.686: [Full GC 32706.686: [CMS: 7293289K->6960613K(10145024K), 37.1325250 secs] 7293289K->6960613K(10451712K), [CMS Perm : 262143K->91949K(262144K)] icms_dc=30 , 37.1326670 secs] [Times: user=37.19 sys=0.00, real=37.14 secs]

1 つ目は 64K のみを収集し、2 つ目は何も収集せず、最後に 3 つ目は 170194K を収集できます。

JAVA_OPTIONS:
-XX:+CMSClassUnloadingEnabled 
-XX:+CMSPermGenSweepingEnabled 
-XX:+UseConcMarkSweepGC
-XX:MaxPermSize=256m 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDateStamps 
-verbose:gc,sizes 
-XX:+UseConcMarkSweepGC 
-XX:CMSInitiatingOccupancyFraction=80 
-XX:+DisableExplicitGC 
-XX:+CMSIncrementalMode 
-XX:+UseParNewGC  
-Xms10g -Xmx10g

また、ガベージ コレクターに permgen スペースのインクリメンタル スイープを実行させるように指示する方法はありますか? 完全なコレクション中に permgen が削減されるのを確認するだけです。

4

2 に答える 2

1

Concurrent Mark Sweep とそのインクリメンタル モード アルゴリズムについて説明します。CMS インクリメンタル モードは、バックグラウンド GC の実行中にシングル コア サーバーでの CPU 不足を回避するために導入されました。インクリメンタル CMS の使用は推奨されません。

増分モードは、メモリを増分的に解放するのではなく、マーク スイープ アルゴリズムのマーク フェーズ中に長いスリープを行うだけです。

-XX:+CMSPermGenSweepingEnabled非推奨であり、同義です-XX:+CMSClassUnloadingEnabled

インクリメンタル モードでは、デッド オブジェクトの検出がやや隠され、問題になる可能性があります。

さらに、(アンロードされる) クラスのいずれかにフィニライザーがある場合、これは 2 つのコレクションを説明することもできます (JVM は個々のクラスをアンロードできず、クラスローダー全体がアンロードされるため、そのクラスのいずれかがコレクションを防止できます)。

そのレベルのヒープ使用率を維持したい場合は、ヒープと perm gen のサイズを適切に設定し、CMS をより積極的に構成することをお勧めします。私のブログでは、CMS のチューニングに関するいくつかのアドバイスを見つけることができます。

ただし、ランタイムがアクティブに生成され、GC をチューニングするクラス ローダーを放棄するだけでは不十分な場合があります。

自動テストで同様の問題に直面していました（各テストは、分離のために専用のクラスローダーに同じクラスをロードしていました）。テストは一般的に不安定で、perm gen で OOME がスローされました。解決策は、JVM をガベージ データで汚染して perm gen を強制的にクリーンにすることでした (ここにコードのスニペットがあります)。ただし、それは Full GC を引き起こしていました - おそらくあなたが見たいものではありません。

ところで-XX:CMSClassUnloadingMaxInterval=N、JVM が Perm gen を N 番目のコレクションごとに収集できるようにするフラグもあります。しかし、これはあなたのケースではありません.perm genがいっぱいです.

于 2013-06-07T20:32:03.520 に答える