問題タブ [concurrent-mark-sweep]

CentOS 64 ビット Linux マシンで jdk 1.7.0_09 を使用しています。

GC 関連の vm 引数は

-Xmx4g -Xmn2g -XX:SurvivorRatio=4 -XX:PermSize=128m -XX:MaxPermSize=128m -XX:InitialTenuringThreshold=15 -XX:CMSWaitDuration=50 -XX:MaxTenuringThreshold=15 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=128m

しかし、それは継続的にフルGCを行っています

Linux と Mac、または異なるバージョンの Java での Java Concurrent Mark Sweep GC の使用に関する Web 上の情報を探していました。特に、Oracle Java 1.6 および 1.7 の最新バージョンに関心があります。

逆に何も見つからなかったので動作すると思いますが、OpenJDK を含め、Windows と比較してパフォーマンスに顕著な違いはありますか?

私の知る限り、次のオプションで JVM を実行できます。

この場合、若い世代にはSerial (DefNew)ガベージ コレクタを、古い世代にはConcurrent Mark Sweepガベージ コレクタを使用します。

では、JVM を-XX:+UseConcMarkSweepGCオプションのみで実行できますか? 若い世代のガベージ コレクターを説明するオプションがないことを意味します。それができるとしたら、古い世代にはどのガベージ コレクタが使用されるでしょうか。

私が知る限り、CMS コレクターは古い世代を収集し、ParNew コレクター (若い世代の収集に適用されます) と連携して動作します。CMSがどのように機能するかを明確に理解するのは簡単ではありませんが、私が見た方法は次のとおりです。

1) イニシャルマーク。ルート参照を探しています。コレクターは oldgen コレクターであるため、古い世代のみをスキャンする必要があります。

2) コンカレント マーク すべてのルート参照が見つかったら、コンカレント マーキングを開始します。最初のフェーズでマークされたオブジェクトから推移的に到達可能なすべてのオブジェクトは、このフェーズでマークされます。

3) コンカレント プレクリーン GC は、前のコンカレント マーキング フェーズでコンカレント マーキングを行っている間に、若い世代または新しい割り当てからの昇格によって更新された、またはミューテータによって更新された CMS ヒープ内のオブジェクトを調べます。[ 1 このフェーズの唯一の目的は、次のフェーズで実行する必要があるジョブの一部を作成することであることを確認してください(コメント) ? 2) Concurrent-Mark フェーズでどの参照が変更されたかを調べるプロセスがいくつかあります。この2つの項目について、私が正しいかどうか教えてください]

4) GC は世界を停止し、CMS ヒープ内のオブジェクトを調べます。これらのオブジェクトは、若い世代または新しい割り当てからの昇格によって更新されたか、同時プリクリーンの実行中にミューテーターによって更新されました。

でも今日、こんな記事を見た

初期マーク 初期マーク中、CMS はすべてのルート参照を収集して、古いスペースのマークを開始する必要があります。これには、スレッド スタックからの参照、若い空間からの参照が含まれます。通常、スタックからの参照は非常に迅速に (1 ミリ秒未満) 収集されますが、若いスペースから参照を収集する時間は、若いスペース内のオブジェクトのサイズによって異なります。通常、初期マークは若いスペース コレクションの直後に開始されるため、Eden スペースは空で、生存オブジェクトのみが生存スペースの 1 つになります。通常、サバイバー領域は小さく、若い領域の収集後の初期マークはミリ秒未満であることがよくあります。しかし、Eden がいっぱいになったときに初期マークが開始されると、かなり時間がかかる場合があります (通常、若いスペース コレクション自体よりも長くなります)。CMS コレクションがトリガーされると、JVM は初期のマーキングを開始する前に、若いコレクションが発生するまでしばらく待機する場合があります。JVM 構成オプション –XX:CMSWaitDuration= を使用して、CMS が初期マーキングの開始前に若い領域の収集を待機する時間を設定できます。初期マーキングの長い一時停止を回避したい場合は、この時間をアプリケーションの若いコレクションの一般的な期間よりも長く構成する必要があります。

備考ほとんどのマーキングはアプリケーションと並行して行われますが、アプリケーションはマーキング中にオブジェクト グラフを変更する可能性があるため、正確ではない可能性があります。同時採点が終了したら、ガベージ コレクターは、アプリケーションを停止し、到達可能なすべてのオブジェクトが生きているとマークされていることを確認するために、マークを繰り返す必要があります。ただし、コレクターはオブジェクト グラフ全体をトラバースする必要はありません。マーキングの開始以降に変更された参照のみをトラバースする必要があります（実際には、プレクリーンフェーズの開始以降）。カード テーブル (カード マーキング ライト バリアを参照) は、古い領域のメモリの変更された部分を識別するために使用されますが、スレッド スタックと若い領域はもう一度スキャンする必要があります。 通常、発言フェーズのほとんどの時間は、若いスペースのスキャンに費やされます。発言開始前に若いスペースにゴミを集めておけば、この時間はかなり短くなります。CMS リマークの前に常に若いスペースのコレクションを強制するように JVM に指示できます。このオプションを有効にするには、JVM パラメータ –XX:+CMSScavengeBeforeRemark を使用します。若いスペースが空であっても、リマーク フェーズは古いスペースの変更された参照をスキャンする必要があります。これには通常、通常の若いコレクションの一時停止に近い時間がかかります (若いコレクション中に行われる古いスペースのスキャンは、リマークに必要なスキャンに似ているため)。

http://blog.griddynamics.com/2011/06/understanding-gc-pauses-in-jvm-hotspots_02.html

CMS が若い世代をスキャンする必要がある理由がわかりません。なぜ古い世代のガベージコレクションに必要なのですか?

CMS GC で jdk 1.6 を使用していましたが、JDK 1.7 に移行しようとすると、ヒープ使用量が増加し、プロセスが遅くなります。

これらのバージョンで GC の動作に大きな違いはありますか? JDK 1.7 で遅くなった場合の回避策は何ですか?

多くのクラスのアンロードが見られ、その期間中にシステム全体がハングします..

同時に、パーマスペースにスパイクが見られないため、GC イベントではないようです。

次のことを知りたい

コンカレント マーク スイープ コレクションは、世界を止めるイベントですか?

パーマスペースがいっぱいでなくても起こりますか?

Tomcat 7、JDK 7、Amazon Linux に Web アプリケーションがあります。これは、GC 構成用に用意されているものです。

「PrintGCDetails」が有効になっていません。

これは、数秒ごとに gc.log ファイルに出力されるものです (この時点でアプリケーションの負荷が 0 の場合、48 時間連続で - まったくアクティビティがなく、それでも以下が出力され、これらのスレッドによって使用される CPU は15%) (コンテキストについては以下を参照してください):

また、次の GC スレッドが CPU を占有していることがわかります (全体で約 15%)。

• システムにアクティビティがなく、
• これら以外の他のスレッドはアクティブではなく、これは 48 時間続き、この時点でシステムの負荷は 0でした。
• システムは過去 24 時間も負荷がゼロであり、その後これらのスレッドがアクティブになりました
• これらのスレッドがアクティブで CPU を占有しているときに、前の行が gc.log に出力されました。
• これは 2 日間続き、最終的にこの JVM で Web アプリケーションを 5 分間呼び出して負荷をかけた後、すべて停止しました。現在、これらのスレッドが CPU を使用していない (1% 未満) ことに気付きました。FULL GC が発生すると、問題は解決したようです。FULL GC は、システムに負荷がかかった後に発生しました。
• つまり、GC スレッドは、システムの負荷が 48 時間ゼロの状態でも 15% の CPU を使用し続けました。

これらはスレッドです：

質問 1: これらのスレッドが 15% の CPU を使用しているときに、gc ログが次のように記録されるのはなぜですか?

質問 2: 上記のログは CMS の障害 (マーク、スイープなど) を示していますか?

質問 3: Web アプリケーションに中程度の負荷をかけ、FULL GC が発生したときに問題が解決したのはなぜですか?

はい、printGCDetails を有効にして別の環境で問題を再現し、情報または解決策を返信します。以前に誰かがこれを見た場合は、会話に追加してください。

編集 1: これは、「PrintGCDetails」が有効になっているときのログです。

また、「CMSMaxAbortablePrecleanTime」は 35 秒に設定されています。ありがとう。

私の Java アプリケーションの GC ログは、継続的な CMS GC に続いて、ヒープのほぼ全体を再利用する並行モード障害の停止世界コレクションを示しています。

CMS コレクションが古い世代をクリアできないのはなぜですか? コンカレント モードの障害による stop-the-world コレクションが必要なのはなぜですか?

以下のような CMS コレクションが数日間連続して発生した後、コンカレント モードの障害により、最終的に領域をクリアする stop-the-world コレクションが強制的に実行されました。CMS コレクションがほとんどスペースを回復しないことに注意してください。一方、昇格の失敗に続くコレクションは古い世代を 1.92 GB から 50.7 MB に減らします。

古い世代のオブジェクトは、STW の収集中に破棄される、永続的な世代の収集されていない死んだオブジェクトによって生き続けられますか? これに対処するために ‑XX:+CMSClassUnloadingEnabled の使用を検討する必要がありますか?

GC ログでの完全な CMS 収集:

同時モード障害 GC ログ:

Java バージョン:

JVM オプション: