問題タブ [g1gc]

JDK バージョン:

GC/メモリ パラメータ:

時折、長い若い GC が 1 分以上一時停止することがあります。GC ログを確認したところ、それらはすべて、混合 GC イベントの同時マーキング サイクルの初期化と共に表示されることがわかりました。若い GC の見積もりの​​一時停止は非常に速いため、同時マーキング サイクルが通常の若い GC のパフォーマンスに影響を与えていると思います。どうすれば影響を軽減できますか? gc ログを確認します。同時マーキング サイクルのほとんどは、若い gc に影響を与えません。大きな影響を与えるものはごくわずかです。gc ログは次のようになります。

以下は私のgcログです：

そして私のJavaオプションは次のとおりです。

さらに、私の CPU には 16 個のコアがあるため、ParallelGCThreads を 15 に減らした後、若い GC 時間を半分に短縮しました。しかし、それでもこの問題は発生しました。以下は新しい gc ログです。

私は実行Spark 2していて、約 5 テラバイトの json をシャッフルしようとしています。のシャッフル中に非常に長いガベージ コレクションの一時停止が発生していDatasetます。

この問題に対処するための明らかな構成の微調整はありますか? 私の構成は次のとおりです。

最新の G1 ガベージ コレクタを使用したいのですが、使用中にメモリ割り当てエラーが発生する状況に遭遇しています。これは、メモリを OS に解放しているためだと思います。OS は、要求されたときに JVM がメモリを取り戻すことを許可していないためです。これは、CMS コレクターでは発生しないためです。私が実行している特定のサーバーは、CMS コレクターで正常に機能しており (理想的とは言えない GC の一時停止を除いて)、G1 に移動するとすぐに、約 6 時間の実行後にこれらの割り当てエラーが発生し、JVM が存在します。

G1コレクターでこれが起こらないようにすることが可能かどうかは明らかではありませんが、コミュニティの誰かが答えてくれることを望んでいました.

ありがとう！

G1 の一時停止時間は短いがスループットが低い理由 (スループットが低いということは、GC が実行される合計時間 (秒) が長くなることを意味します)

メモリが小さな部分に分割されているため、私の理解では、完全なヒープよりも小さな部分でフルを実行する必要があります。実際、完全なヒープで実行されていないため、現在完全な GC はないと言えますが、代わりに複数のバックグラウンド スレッドが同時に実行されており、最大数のデッド オブジェクトを含むメモリ ブロックを最初にクリアしています。そのため、休憩時間は短いです。

大きなメモリが小さなブロックに分割されているため、スループットが低くなります。これは、複数の GC スレッドを単一のブロックではなく小さなブロックで実行する必要があるためです。そのため、ほとんどの場合、多少忙しいでしょう。

あれは正しいですか ？

また、G1 が 4GB より大きいヒープに適しているのはなぜですか? より小さなブロッカーに分割され、一時停止時間が遅くなるため、すべてのヒープ サイズでより適切に機能するはずです。では、なぜ G1 が 4 GB より大きいヒープに推奨されるのでしょうか?

現在、高スループット フローで動作するように Apache NiFi を調整しようとしていますが、フル GC を避けることはできません。

フローが開始されると、非常に迅速な若い GC が発生しますが、最終的にフル GC がトリガーされるまで、割り当て要求に対応できません。この状況は、さまざまなヒープ サイズ (8 GB から 50 GB) と基本的な構成 (オラクルのドキュメントに従って領域サイズと指定されたスレッドのみが構成されている) で発生します。

以下は、GCViewer を使用して実行された GC ダンプ分析です。

ログを見ると、混合 GC 用に選択された古いリージョンの数が常にゼロであることがわかりました。この非常に役立つ記事によると、 InitiatingHeapOccupancyPercentをドロップして、マーキングフェーズをより早く開始できるようにすることができます。選択された古い領域の数がゼロのままであることを考えると、これは何の効果もないようです。

オラクルのドキュメントによると、G1MixedGCLiveThresholdPercent=65など、使用できる実験的なフラグがありますが、他のすべての前にUnlockExperimentalVMOptionsフラグを追加しても、次のエラーが発生します。

基本的に、フラグは無視されます。

最初の例では、完全な GC をトリガーするのは、古いリージョンの非コレクションでしょうか? もしそうなら、どうすれば古いリージョンを収集し、アプリケーションのニーズに十分なメモリを解放できますか?

ご協力ありがとうございました。

G1GCを使用しています。

jvmに渡すことができるjvm引数はありますか?巨大な割り当てが発生するたびにgcログを取得しますか?

私のサーバーは CentOS 6.7 で 1.8.0_92 を使用しています。GC パラメータは「-Xms16g -Xmx16g -XX:+UseG1GC」です。したがって、デフォルトの InitiatingHeapOccupancyPercent は 45、G1HeapWastePercent は 5、G1MixedGCLiveThresholdPercent は 85 です。私のサーバーの混合 GC は 7.2GB から開始されますが、クリーニングはますます少なくなり、最終的に古い世代は 7.2GB よりも大きく維持されるため、常に並行マークを実行しようとします。最後に、すべてのヒープが使い果たされ、完全な GC が発生しました。完全な GC の後、使用される古い世代は 500MB 未満です。

混合 GC がこれ以上収集できない理由が気になります。ライブ データがそれほど多くないように見えます...

g1 関連の情報を印刷してみましたが、以下のようなメッセージがたくさん見つかりました。私の古い世代には多くのライブ データが含まれているようですが、フル GC でこれほど多くのデータを収集できるのはなぜですか...

以下のログは、高速化のために InitiatingHeapOccupancyPercent を 15 (2.4GB で同時実行マークを開始) に変更した結果です。

編集：

混合GCの後にフルGCをトリガーしようとしましたが、それでも4xx MBに減少する可能性があるため、古い世代ではより多くのデータを収集できるようです。

フル GC の前に、混合 GC ログは

編集： 2016/12/11

で別のマシンからヒープをダンプしました-Xmx4G。

レタスを redis クライアントとして使用しましたが、LatencyUtils を使用した追跡機能があります。これにより、LatencyStats ( long[]3000 近くの要素を持つものを含む) インスタンスが 10 分ごとに弱く参照されます (公開後のレイテンシーのリセットはデフォルトで true、https://github.com/mp911de/lettuce/wiki/Command-Latency-Metrics )。そのため、久しぶりに LatencyStats の弱い参照をたくさん作成します。

フル GC の前。

フル GC 後。

現在、レタスからの追跡は必要ないので、無効にするだけで完全な GC がなくなります。しかし、混合 gc がそれらをクリアしない理由がわかりません。