完全なGCの前に事前警告を得る

Question

200ms以上休止しないようなソフトリアルタイムシステムのコンテキストについては、Full GCが差し迫る前に事前警告を行う方法を探しています。私たちはそれを避けることができないかもしれないが、システムが停止する前に別のノードにフェールオーバーしたいと考えています。

私たちは、システムが数秒間ストールする可能性がある差し迫った完全なGCに先立って、事前の警告を私たちに提供する計画を考え出すことができました。

私たちが思い付くことができたのは、CMSフリーリスト統計に基づいています：-XX:PrintFLSStatistics=1。これは若いGCを含むすべてのGCサイクルの後に空きリスト統計をGCログに出力するので、情報は短い間隔で利用でき、高いメモリ割り当て率の間隔でさらに頻繁に表示されます。おそらくパフォーマンス面では少しコストがかかるかもしれませんが、私たちの実際の前提は、私​​たちがそれを買う余裕があるということです。

ログへの出力はそうのようになります。特に

Statistics for BinaryTreeDictionary: 
------------------------------------ 
Total Free Space: 382153298 
Max Chunk Size: 382064598 
Number of Blocks: 28 
Av. Block Size: 13648332 
Tree  Height: 8 

、最大空きチャンクサイズは382064598の言葉です。 64ビットワードの場合、これは2915MBをわずかに下回るはずです。この数値は、1時間あたり約1MBの割合で非常にゆっくりと減少しています。

フリーチャンクの最大サイズが若い世代より大きい限り（気楽なオブジェクト割り当てがないと仮定して）、すべてのオブジェクトプロモーションが成功するはずです。

最近では、数日間のストレステストを実行し、CMSが古い領域の総容量の94％を超える最大チャンクサイズを維持できることが確認されています。フリーチャンクの最大サイズは、1MB /時未満の割合で減少しているように見えます。これにより、すぐに完全なGCになることはなく、メンテナンスのためにサーバーがダウンする可能性が高くなります。フルGCよりも頻繁に発生する可能性があります。

以前のテストでは、システムのメモリ効率が低下した時点で、システムを10時間稼働させることができました。最初の1時間で、フリーチャンクの最大サイズは100MBに減少し、8時間以上滞在しました。最後の40分間は、完全なGCが発生したとき、フリーチャンクの最大サイズは0に向かって一定の割合で減少しました。これは非常に勇気づけました。そのワークロードでは、40分の前進を得ることができたようです警告（チャンクサイズが0に向かって着実に減少し始めたとき）。あなたへ

私の質問：これはすべてが長期のピーク負荷を反映仮定（生産の任意の時点でのワークロードだけ低くなります）、有効なアプローチのようなこのサウンドしていますか？どの程度の信頼性があると思いますか？GCログからチャンクサイズの最大値を計算できるはずです。

私たちは間違いなく提案はしていますが、HotSpot（No Azul、少なくとも今のところは利用できません）で利用可能なソリューションに限定するようリクエストしています。また、Full GC、またはSLAを大幅に上回るGC（および時々発生する可能性のあるGC）の前に警告を発する似たような指標を考え出すことができない限り、G1自体は解決策ではありません。

Answer 1

私はHotSpot GCメーリングリスト（hotspot-gc-use@openjdk.java.net）から入手したOracleのJon Masamitsuによる非常に啓発的で励みになる答えの抜粋を掲載しています。彼はHotSpot 、これは本当に良いニュースです。

いずれにしても、問題はまだ開いています（私は電子メールを引用することはできません:-)）ので、あなたの提案を追加してください！

書式設定：元の投稿の引用符は、Jonの応答よりもインデントされています。

最大の空きチャンクサイズは若い世代（何humungousオブジェクト 割り当てを想定していない）より 大きい限り、すべてのオブジェクトのプロモーションが成功する必要があることを我々の理解です。

非常に大きい程度にこれは正しいです。若い世代からCMS世代に昇格されたオブジェクトは、 の下に若い世代よりも多くのスペースがCMS世代で必要となります（ ）。私は これはかなりの程度発生するとは思わない。

これは非常に奨励しています。なぜなら、私たちは間違いなくスペアメモリを捧げることができます。

< --snip -

あなたへの私の質問> ：と仮定し、これはすべての生産の任意の時点での長時間のピーク 作業負荷（ワークロードを反映します のみ）、これは有効なアプローチのように聞こえますか？ の信頼度はどれくらいですか？GCログから最大 無料チャンクサイズ統計をカウントできるはずですか？

最大無料のチャンクサイズは、それは時間のGCプリントで正確であるが、それは はあなたがそれを読んで、あなたの意思決定を行う時点で陳腐することができます。私たちのワークロードの場合

、このメトリックは非常に遅い下方スパイラルにあるので、少し古さは私たちを傷つけることはありません。

< --snip - >

我々は提案のため間違いなく開いているが、彼らは は、少なくとも、私たちのためのHotSpot（ノーアズールで利用可能なソリューションに限定されることを要求します現在は ）。また、フルGCよりも前に警告を出すような尺度 や、 私たちのSLAを大幅に上回るGC（が発生することがあります）を思い付かない限り、G1自体は解決策ではありません。

私はあなたのメトリックとして最大無料のチャンクサイズの使用は良い 選択であると思います。これは非常に保守的です（あなたの望みのように聞こえる）。 はオブジェクトサイズの奇妙な混合を受けません。

G1については、完全に空いている領域の数を使用できると思います。 現在のところ、どのログにも印刷されているかどうかわかりませんが、それはおそらく です。完全にフリーの数が時間の経過と共に減少すると、完全なGCが来ていることを示す可能性があります。

ジョン

あなたのジョンをありがとう！

Answer 2

分裂と征服！

ご使用のシステムでは多くのメモリが使用されており、応答性が高い必要があります。ブースを実現するために、システムのアーキテクチャを再設計します。

重要なリアルタイムタスクとそのビジネスルールを特定して、そのためのJavaプロセスを作成します。そして、従来のプログラミングの習慣を使用しないで、GCがメモリをきれいに保つようにするという考えはありません。それについて考えると、創造的である。

他のレイヤーとプロセスを作成し、残りの部分を処理し、すべてを接続するパイプコードを作成します。

リアルタイムプロセスの寿命をスケジューリングしたり、応答時間を確認したりして、新しいプロセスを作成して新しいプロセスを作成することもできます。しかし、私はあなたが高いレスポンスを保つために、それを殺す必要はないと期待できます。

幸運を祈る！