2

適度にビジーな実稼働サーバー (50 のアプリ スレッド、30% の CPU 使用率) では、CMS コレクターが古い世代にプロモートされたオブジェクトに追いつかないシナリオが見られます。

私の最初の考えでは、これらのオブジェクトは明らかにまだ参照されているため、コレクションの対象にはなりませんでしたが、Old Gen がシリアル コレクションに入力してプロンプトを表示すると、6 GiB のうち 5.5 GiB が回復されました。

Eden スペースのサイズは 3 GiB で、若いコレクションのプロンプトを表示するのに十分な量がいっぱいになるまでに約 20 ～ 30 秒かかります。Survivor スペースの使用量は、800 から 1250 MiB の間で変動し、最大 1.5 GiB (それぞれ) です。

コレクションの対象となる古い世代のオブジェクトと、サーバーに十分な (明らかな) リソースがあるため、CMS コレクターが古い世代のサイズを維持していない理由がわかりません。

ビジュアル VM

このシナリオの原因は何ですか?解決策はありますか?

私は占有率を認識していますが、その意味を理解していませんCMSIncrementalSafetyFactor.Oracleのドキュメントをいくつか読んだことがありますが、「デューティサイクルを計算するときに保守主義を追加する」ことが実際に何を意味するのかわかりません。 .?

代替案

並列/スループット コレクターに切り替えると、GC オーバーヘッドは非常に低くなります (1.8%) が、時折 (1 日あたり 50 回) 長い一時停止が発生します (完全な GC ごとに約 20 秒)。多少の調整を行っても、最大一時停止の目標を達成できない可能性があります。

理想的な世界では、G1 コレクタを試してみることができますが、さまざまな理由から Java 6 JVM に行き詰まっています。

4

1 に答える 1

1

CMS コレクターがオブジェクトの昇格率に追いついていないということは、GC ログに「同時モードの失敗」が表示されるはずであることを意味します。これらは、CMS コレクターが「競合に負け」、完了する前にメモリが不足した場合に得られるものです。

2014-02-27T01:09:52.408-0600: 847.004: [GC 847.005: [ParNew 
(promotion failed)
Desired survivor size 78512128 bytes, new threshold 2 (max 15)
- age   1:   60284680 bytes,   60284680 total
- age   2:   32342648 bytes,   92627328 total
: 1380096K->1380096K(1380096K), 0.7375510 secs]847.743: 
[CMS2014-02-27T01:09:54.133-0600: 848.729: [CMS-concurrent-s
weep: 5.467/6.765 secs] [Times: user=21.59 sys=0.73, real=6.76 
secs]
  (concurrent mode failure): 2363866K->1763900K(4409856K),
10.6658960 secs] 3697627K->1763900K(5789952K), [CMS Perm : 
118666K->117980K(125596K)], 11.4061610 secs] 
[Times: user=11.34 sys=0.02, real=11.57 secs]

デフォルトでは、旧世代では CMS コレクターは占有率 92% でトリガーされます。古い世代の使用状況のグラフのメモリ増加率から判断すると、5 分ごとに約 500 MB 増加しています。6GB の 92% で約 500 MB のヘッドルームが得られます。これは、CMS が 5 分以内にレースに勝たなければならないことを意味します。そうでもなければ...

...グラフに表示されているスムーズなトラフィック プロファイル以外に、舞台裏で何かが起こっています。たとえば、キャッシュなどのメモリ内データ構造を更新するバックグラウンド プロセスはありますか? これらのタイプのアクティビティは、古い世代に昇格する必要がある、長期間有効な新しいオブジェクトを突然大量に作成します。滑らかなグラフが突然垂直になり、使用可能なメモリがすぐに使い果たされる可能性があります。CMS コレクタは、スムーズで安定したトラフィックの処理に優れていますが、アクティビティの急激なバーストに対して非常に脆弱です。ガベージ生成率の緩やかな変化に対応するのは得意ですが、「バースト」動作を予測できず、このような競合に負けるケースを数多く見てきました。

新しいオブジェクトの突然のバーストを生成するバックグラウンド プロセスを完全に回避することとは別に、CMSInitiatingOccupancyFraction パラメーターをデフォルトの 92% ではなく 60 ～ 80 の間に減らすことで、CMS コレクターに有利なスタートを切ることができます。

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#cms.starting_a_cycle

また、PermGen スペースにも注意してください。Parallel Throughput Collector とは異なり、CMS コレクターはデフォルトで PermGen を収集しないため、PermGen がいっぱいになると、ストップ ザ ワールド フル GC になります。このパラメーターにより、CMS コレクターは PermGen スペースも収集します: CMSClassUnloadingEnabled。

それ以外では、GC ロギングと設定をオンにすることをお勧めします: -XX:+PrintGCDetails は、すべてのマイナーおよびメジャー ガベージ コレクションの詳細を出力します。

これは、起動時にすべての JVM 設定を確認できる優れたパラメーターです。 -XX:+PrintFlagsFinal は、起動時にすべての JVM 構成オプションの値を出力します。

于 2015-08-18T03:28:45.120 に答える