問題タブ [concurrent-mark-sweep]

Linux 上にある本番サーバーにデプロイするときに、Web アプリケーションのデフォルトの Parallel GC とは異なるガベージ コレクターを使用したいと考えています。

たとえば、アプリケーションに Concurrent Mark Sweep GC を使用したいとします。

-XX:+UseConcMarkSweepGCこれで、他のさまざまな JVM パラメータを追加して微調整することで、これを使用できることを読みました。

そのため、maven を使用して戦争をパッケージ化するときに、この追加の JVM パラメーターを含めます。例：

戦争はパッケージ化されており、Linux 環境で実行されている Tomcat サーバーに展開します。

この戦争をWindowsマシンにパッケージ化してから、パテとwinscpを使用してLinuxマシンに戦争を展開することに注意してください

私が理解していないのは、CMS GC が実行されていることをどのように保証するのでしょうか? アプリケーションが実行されている場所にこれらの変更を含めるべきではないということですか?

または、パッケージ化中にこれらの JVM パラメータを含めるだけで十分です。

戦争をパッケージ化している間など、他のさまざまなJVMパラメーターを含めたい場合も同様です。または、これらを他の場所にも含める必要がありますか?

説明してください。

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

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

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

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

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

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

代替案

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

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

CMSIncrementalMode を除いて、同じ GC 構成を持つ 2 つのアプリ ノードがあります。以下は、CMSIncrementalMode を使用する場合と使用しない場合の両方のアプリの GC ビューアーのスクリーン ショットです。

CMSIncrementalMode を使用していないアプリのスループットは大幅に低下し、「CMS: 時間が経過したためプレクリーンを中止します」というメッセージが表示されてプレクリーンが中止されました。また、古い世代に空きスペースがたくさんある場合でも、オブジェクトは古い世代に昇格されませんでした。

漸進的なより小さな並行ステップにより、事前クリーニングの中止が停止した可能性があることを理解しています。しかし、私は次のことを理解しようとしています。

1. 事前クリーンアップを中止すると、アプリにこれほど大きな悪影響が及ぶのはなぜですか? それとも、悪影響を引き起こしている何か他のものですか？

2. CMSIncrementalMode は、若い世代のマイナー GC にどのように役立ちましたか。インクリメンタル モードは古い世代のコレクションだけにあるのではないですか?

3. ParNew カウントが initial-mark および remark と異なるのはなぜですか。CMSIncrementalMode がないと、より多くのマークとコメントが表示されます。CMSIncrementalMode を使用すると、より多くの ParNews が表示されます。

GC 構成:

GC ビューアー統計:
CMSIncrementalMode を使用する
アプリ CMSIncrementalMode を使用しないアプリ

前もって感謝します

古い世代が半分も満たされていなくても、平均して約700ミリ秒のCMSマークとコメント（他のフェーズも）の数が多い原因を理解しようとしています.GCViewerからのGC構成と統計は次のとおりです。

GC Viewer を使用したまとめ: http://i.imgur.com/0IIbNUr.png

GC ログ

Tomcat7 と JRE 1.8 を使用して Java WebApp を実行しています。アプリケーションは大量のデータ (~15GB) をキャッシュし、高いスループット (~4K/秒) をサポートします。要求率が高いため、若い世代に多数のオブジェクトが生成されます。一部のオブジェクトは、若い世代の ParNew コレクションを生き残り、サバイバーに移動され、最終的にはヒープ メモリ内の古い世代の空間に移動されます。

これらのオブジェクトは古い世代に蓄積され続けます。旧世代がほぼ満杯になると CMS が起動し、その結果、stop-the-world GC が発生します。これは、アプリケーションのレイテンシーに影響します。

これを避けるために、 とCMSInitiatingOccupancyFraction=85一緒に使い始めました+UseCMSInitiatingOccupancyOnly。ただし、これら 2 つのオプションがあるにもかかわらず、古い世代が 85% いっぱいになると、CMS は起動しません。古い世代がほぼいっぱいになり、stop-the-world GC を実行するときにも発生します。の制限を検索しましCMSInitiatingOccupancyFractionたが、動作を説明する関連リンクが見つかりませんでした。私のTomcatプロセスの正確なコマンドラインを以下に見つけてください：

古い世代が 85% いっぱいになったときに CMS が実行を開始しない理由を誰かが理解するのを手伝ってくれませんか?

現在、CMS と ParNewGC を組み合わせて使用​​しています。

私の理解では、CMSはOld Gen GCに使用され、UserPareNewGCはgenガベージコレクションに使用されます。

単一のパラメーターとして CMS のみを渡すと -XX:+UseConcMarkSweepGC、CMS は若い世代と古い世代の両方のガベージ コレクションに使用されますか?

UseParNewGCCMS と一緒に構成されていませんが、まだ若い世代に使用されていると思います。しかし、私は仮定を確認したい。

私は正しいですか？

編集: JDK 1.7 バージョンを使用しています。1.7 と 1.8で動作が異なる場合は、説明してください。

プロダクション マシンの 1 つに奇妙な問題があります。CMS (コンカレント マーク アンド スイープ) を行う Java アプリケーションをホストしますが、古い世代のほんの一部をクリーンアップします。メモリ リークを疑い、ヒープ ダンプを試みました。ただし、ヒープ ダンプに先行するフル GC では、古い世代のほとんどすべてがクリーンアップされます。何が起こっていますか？Java ガベージ コレクションのこの動作は見たことがありません。通常、CMS とフル GC はほぼ同じ量のガベージを収集する必要がありますが、現在は CMS が約 10GB 以上を保持しています。

• Java 1.7.0_75
• Linux セント OS 7

GC ログ:

同じアプリケーションが、Cent OS 5、Java 7 を使用する別のマシンで正常に実行されています。

更新:問題はまだ解決されていません。OS パッケージとカーネルを更新し、Java を最新バージョンの Java 1.7.0_80 に更新し、アプリケーション バージョンをロールバックしましたが、成功しませんでした。

また、以前の GC ログを確認したところ、この問題が永遠に続くわけではないことがわかりました。展開後、約1か月前に開始しました。