問題タブ [concurrent-mark-sweep]

ConcurrentMark-Sweepコレクターを使用したアプリケーションのGCログファイルに次の症状が見られます。

プレクリーンプロセスは継続的に中断し続けます。CMSMaxAbortablePrecleanTimeをデフォルトの5から15秒に調整しようとしましたが、それは役に立ちませんでした。現在のJVMオプションは次のとおりです...

並行-abortable-precleanが実行される機会がないようです。CMSScavengeBeforeRemarkを有効にすることを提案したhttps://blogs.oracle.com/jonthecollector/entry/did_you_knowを読みましたが、一時停止の副作用は理想的ではなかったようです。誰かが何か提案をすることができますか？

また、CMS GCログ、特に次の行を取得するための優れたリファレンスがあるかどうか疑問に思いました。

それらの番号が参照しているメモリ領域が明確ではありません。 編集このhttp://www.sun.com/bigadmin/content/submitted/cms_gc_logs.jsp へのリンクが見つかりました

短い形式：CMSガベージコレクターは、増え続けるガベージの収集に失敗しているようです。最終的に、JVMがいっぱいになり、アプリケーションが応答しなくなります。外部ツール（JConsoleまたはjmap -histo:live）を介してGCを強制すると、GCが1回クリーンアップされます。

更新：この問題は、JConsoleのJTopプラグインに関連しているようです。JConsoleを実行しない場合、またはJTopプラグインなしで実行すると、動作はなくなります。

（テクニカルノート：Linux2.6.9ボックスでSunJDK 1.6.0_07、32ビットを実行しています。避けられない大きな理由がない限り、JDKバージョンのアップグレードは実際にはオプションではありません。また、システムはそうではありません。インターネットにアクセス可能なマシンに接続されているため、JConsoleなどのスクリーンショットはオプションではありません。）

現在、次のフラグを使用してJVMを実行しています。

JConsoleのメモリグラフを観察すると、アプリケーションのライフスパンの最初の数時間は約15分ごとに実行される完全なGCがあります。完全なGCが実行されるたびに、使用中のメモリはますます増えていきます。数時間後、システムは定常状態になり、CMSの旧世代で約2GBの使用済みメモリがあります。

これは古典的なメモリリークのように聞こえますが、完全なGCを強制するツールを使用すると（JConsoleの[ガベージコレクション]ボタンを押す、または実行jmap -histo:liveするなど）、古い世代が突然約500MBに低下し、アプリケーションが使用されます次の数時間は再び応答するようになります（その間、同じパターンが続きます-各完全なGCの後、ますます多くの古い世代がいっぱいになります）。

注意点の1つ：JConsoleでは、jconsole / jmap / etcを使用してGCを強制するまで、報告されるConcurrentMarkSweepGCカウントは0のままになります。

を使用jmap -histoしjmap -histo:liveて順番に、明らかに収集されていないオブジェクトが次のもので構成されていることを確認できます。

• 数百万HashMapの配列HashMap$Entry（1：1の比率）
• 数百万Vectorのオブジェクト配列（1：1の比率、HashMapの数とほぼ同じ）
• 数百万HashSet、、、Hashtableおよびcom.sun.jmx.remote.util.OrderClassLoaders、およびHashtable$Entry（それぞれのほぼ同じ数、HashMapsおよびVectorsの約半分の数）の配列

以下のGC出力からの抜粋がいくつかあります。それらの私の解釈は、CMSGCがstop-the-worldGCにフェイルオーバーすることなく中止されているように見えます。この出力をどういうわけか誤解していますか？それを引き起こす何かがありますか？

通常の実行時、CMSGC出力ブロックは次のようになります。

以上です; 次の行は次のParNewGCになります。

jmap -histo：liveを使用してGCを強制すると、代わりに次のようになります。

以下の形式の〜125行が続きます:(一部のGeneratedMethodAccessor、一部のGeneratedSerializationConstructorAccessor、一部のGeneratedConstructorAccessorなど）

に続く：

前もって感謝します！

そこで私は、JVM が OOM の状況に向かう可能性がある時期を監視するための良い方法を突き止めようと試みてきました。私たちのアプリで機能すると思われる最善の方法は、CMS を介してバックツーバックの同時モード障害を追跡することです。これは、Tenured プールが実際にクリーンアップできるよりも早くいっぱいになっているか、ほとんど再生されていないことを示しています。

GC を追跡するための JMX Bean には、前後のメモリ使用量などの非常に一般的な情報があります。この情報は、せいぜい比較的一貫性がありません。この死にかけている JVM の潜在的な警告サインを監視するためのより良い方法はありますか?

Java アプリケーションのメモリ生成プール サイズを調整したいと考えています。これを行うには、まずヒープがどのように使用されるかを理解する必要があります。本質的に、JVM ヒープ内のすべてのオブジェクトの数、サイズ、および有効期間を知る必要があります。このデータを収集した後、若い世代と在職期間中の世代のプールにより適したサイズを見つけることができるはずです。

Sun/Oracle のホワイトペーパー「Tuning Garbage Collection with the 5.0 JVM」に記載されている情報に基づいてチューニングを行っています。セクション 3 ( http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html#1.1.%20Generations%7Coutline ) では、世代のサイジングについて説明し、オブジェクトの有効期間グラフの例を示します。アプリケーションで達成しようとしているものとほぼ同じです。

これまでのところ、特定のクラスのインスタンス数とそれぞれのサイズをメモリに記録できました。ただし、インスタンスの平均寿命を抽出する方法が見つかりません。現在、jProfiler を検討していますが、これまでのところ成功していません。

Java アプリケーションのオブジェクトの平均寿命のグラフ化に成功した人はいますか?

環境の詳細：OS：Linux RedHat Java：JRE 6 Update 21

アプリに次のGC設定を使用しています。

そこに設定すると、アプリケーションの開始時に単一のフルGCがあります

その後、4〜5回成功したCMSコレクションが続きますが、この後、ログにCMSの痕跡はなく、マイナーコレクションのみにエントリがあります。

ヒープは継続的に成長しており、7GBに達しています。OOMや本番システムの故障は許されないため、アプリケーションを再起動する必要があります。

CMSコレクターがクリーニングを停止した理由がわかりません。手がかり/提案は大歓迎です。前もって感謝します。

================================================== ====================================1月23日更新。

これまでのご回答ありがとうございました。テスト環境でアプリケーションをセットアップし、次の一連のJVMオプションを使用してアプリをテストしました。

オプション1

オプション＃2

両方の設定で2日間並行してテストを実行しました。これらは私の観察です：

オプション＃1ヒープメモリは安定していますが、90個のConcurrentMarkSweepコレクションがあり、JVMは24分を費やしました。それは高すぎます。そして、GCログに次の行が表示され、パターンは1時間ごとに続きます...

マークアンドスイープログが同時に表示されません。これは、CMSがスループットコレクターに切り替えられたことを意味しますか？もしそうなら、なぜですか？

オプション＃2：

フルGC（システム）ログが表示されるので、-XX \：+DisableExplicitGCを追加することを考えました。ただし、そのオプションを使用すると、収集は行われず、現在のヒープサイズは7.5Gです。私が疑問に思っているのは、CMSが同時収集ではなくフルGCを実行している理由です。

現在、ガベージ コレクション時間が非常に長いという問題があります。以下をご覧ください。私の現在の設定では、-Xms1g と -Xmx3g を使用しています。私のアプリケーションは Java 1.4.2 を使用しています。ガベージ コレクション フラグを設定していません。見た目では、3GB では十分ではなく、ガベージ コレクションするオブジェクトが本当にたくさんあります。

質問：

ガベージ コレクション アルゴリズムを変更する必要がありますか? 何を使えばいいですか？使ったほうがいいですか-XX:+UseParallelGC or -XX:+UseConcMarkSweepGC

または、この組み合わせを使用する必要があります

メモリを占有しているのは主にレポート データであり、キャッシュ データではありません。また、マシンには 16 GB のメモリがあり、ヒープを 8 GB に増やす予定です。

まだ理解するのが難しいと思うので、2つのオプションの違いは何ですか。マシンには複数のプロセッサがあります。5秒くらいまでは打てますが、30秒から70秒はかなりきついです。

助けてくれてありがとう。

CMS コレクターが起動するタイミングを制御する可能性のある 2 つのパラメーターについて、私は混乱しています。

MaxHeapFreeRatio(デフォルトでは 70%)

CMSInitiatingOccupancyFraction(デフォルトで 90% 以上)

これらの各パラメーターは、正確には何を意味するのでしょうか? コレクターはいつ開始 (マーキング フェーズ) し、いつ収集しますか (スイープ フェーズ)?

アプリケーションのガベージ コレクション ログを有効にしました。一部の CMS ステップの時間を出力する行がいくつかあります。誰でも説明したり、CMSログを説明するリンクを教えてもらえますか

9657.238: [CMS-concurrent-mark: 17.199/17.396 秒] [時間: user=80.61 sys=10.00, real=17.40 秒]

120GB 以上の RAM を搭載した Hotspot で Concurrent Mark Sweep ガベージ コレクター (UseConcMarkSweepGC) を使用できた人はいますか?

-ms と -mx を 120G に設定すると、JVM は問題なく起動しますが、130G に設定すると、起動時に JVM がクラッシュします。JVM は、並列コレクターと G1 コレクターを使用して正常に起動します (ただし、独自の問題があります)。

120GB を超えるヒープで Concurrent Mark Sweep コレクターを使用できた人はいますか? もしそうなら、何か特別なことをしなければならなかったのですか、それとも私が運が悪かっただけですか?

JVM エラー ダンプのスタックは次のとおりです。

私は Oracle ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175901 ) でこれについてバグを報告しましたが、他の誰かがそれを見たのではないかと思っていました。

私のアプリケーションは、16 個のプロセッサと 64 GB の RAM を搭載したサーバーで正しく動作します。複数のプロセスがあり、プロセスの最大ヒープを 8 GB に制限しようとしています。

私の問題は、何らかの形の生産者と消費者のパターンがあり、生産速度を制限する必要があることです。そうしないと、古い世代のガベージ コレクションがほとんど発生しないため、メモリが不足します。

• アプリケーションを監視すると、4 時間実行した後、ParNEW で 7 分、ConcurrentMarkSweep で 0.775 秒を費やしたことがわかります。
• 私のヒープ占有率は最大で約 6GB になり、その後 1GB まで低下し、ゆっくりと 6GB まで上昇してから再び低下します。サイクルは約10分です

JVisualVM を介して、メモリ占有の 90% が CMS Old Gen によって与えられていることがわかります。どうすれば、並行マーク スイープをもう少し頻繁に実行するように強制できますか?

@PeterLawrey のコメントは非常に関連性があります。私のアプリケーションは、Terracotta や Coherence などのイベント駆動型処理とデータ パーティション分割用に設計されたアプリケーション サーバー上で実行されるからです。基礎となる実装には、イベント処理用のキューイング システムが含まれている可能性があります。

私の問題は、ヒープ サイズを制限することは解決策ではないということです。私が経験したように、より頻繁にガベージ コレクションを行う代わりに、アプリケーションがメモリ不足になるからです。