5

こんにちは、インメモリ データ グリッドを使用した 150GB ヒープ メモリ プログラムのケースがあります。運用部門から、単一のマシンを使用するというクレイジーな要件があります。これで、並列ガベージ コレクタが 150GB を超えて使用された場合に何が起こるかがわかりました。おそらく、FULL GC が呼び出された場合、数十分のガベージ コレクションになります。

私の希望は、Java 9 で Shenandoah 低一時停止 GC が来ることでした。残念ながら、私が見たところ、Java 9 での配信にはリストされていません。それについて何か知っている人はいますか?

とはいえ、G1 GC がこの量のヒープ メモリに対してどのように機能するのか気になります。

そして最後の質問です。2時間で完了するはずの非インタラクティブなバッチアプリケーションがあるので、言ってみましょう。ここでの主な目標は、フル GC が開始されないようにすることです。メモリが十分にあることを確認した場合、到達可能な最大ヒープが 150 で、250 GB を割り当てると、自信を持ってフル GC がGC が開始されることはありませんか? 通常、新しい世代と古い世代が最大ヒープに達すると、フル GC がトリガーされます。別の方法でトリガーできますか？

この質問が重複していない理由をここで説明しようとします。最初に、150GB ヒープについて話します。これは、質問にまったく異なる次元を追加します。次に、前述の質問にあるように RMI を使用していません。3 つ目は、行間にある G1 ガベージ コレクタについて質問しています。 <32GB ヒープに関する質問は、ヒープ >32GB に関する質問と同じです Java 7 からインスタンス PermSpace が存在しないため、状況が少し変わったことは言うまでもありません。

4

1 に答える 1

5

圧縮 GC の経験則では、毎秒コアあたり1 GB のライブ オブジェクトを処理できる必要があります。

Haswell i7 (4 コア/8 スレッド) と並列コレクターを使用した 20GB ヒープの例:

[24.757s][info][gc,heap        ] GC(109) PSYoungGen: 129280K->0K(917504K)
[24.757s][info][gc,heap        ] GC(109) ParOldGen: 19471666K->7812244K(19922944K)
[24.757s][info][gc             ] GC(109) Pause Full (Ergonomics) 19141M->7629M(20352M) (23.791s, 24.757s) 966.174ms
[24.757s][info][gc,cpu         ] GC(109) User=6.41s Sys=0.02s Real=0.97s

圧縮後のライブセットは7.6GB。並列処理により、6.4 秒相当の CPU 時間がかかります。これは、1 秒未満の一時停止時間に変換されます。

原則として、並列コレクターは、ヒープの大部分がライブ オブジェクトで構成されている場合でも、マルチコア システムで最大 2 分未満のフル GC 時間で 150 GB のヒープを処理できる必要があります。

もちろん、これは経験則にすぎません。悪影響を与える可能性のあるいくつかのこと：

  • ページング
  • サーマル CPU スロットリング
  • 非常に大規模で参照が多いオブジェクトで構成されるワークロード
  • NUMA 構成での非ローカル メモリ トラフィック
  • CPU 時間を奪い合う他のプロセス
  • 弱参照/ソフト参照の多用

場合によっては、このスループットを達成するためにチューニングが必要になることがあります。

それでも Parallel コレクターが機能しない場合は、CMS と G1 が実行可能な代替手段になる可能性がありますが、JVM で使用できる十分な予備のヒープ容量と CPU コアがある場合に限ります。フル GC の危険を冒さずに同時作業を行うには、十分な余裕が必要です。

インタラクティブではないと言ったのは正しいですが、それでも私は厳密なライセンス契約を結んでいます。1 時間以内にすべての処理を終了する必要があります。だから世界のイベントを30分止める余裕はない。

基本的に、CMS、G1、Shenandoah、または Zing が目指している意味での短い一時停止時間は実際には必要ありません (大きなヒープでも <100ms または <10ms を目指しています)。

必要なのは、STW の一時停止が、コンピューティング時間のかなりの部分を消費するほど壊滅的なほど悪くないことだけです。

これは、シリアル コレクターを無視して、利用可能なほとんどのコレクターで実現可能です。

実際には、失敗する可能性のある病的なエッジケースがいくつかありますが、そのポイントに到達するには、実際のワークロードでシステムをセットアップし、いくつかのテストを実行する必要があります. 実際の問題が発生した場合は、より詳細な質問をすることができます。

于 2016-07-10T11:19:50.500 に答える