10

短い形式：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を実行しています。

-server -Xms3072m -Xmx3072m -XX:NewSize=512m -XX:MaxNewSize=512m 
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled 
-XX:CMSInitiatingOccupancyFraction=70 
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 
-XX:+DisableExplicitGC

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出力ブロックは次のようになります。

36301.827: [GC [1 CMS-initial-mark: 1856321K(2621330K)] 1879456K(3093312K), 1.7634200 secs] [Times: user=0.17 sys=0.00, real=0.18 secs]
36303.638: [CMS-concurrent-mark-start]
36314.903: [CMS-concurrent-mark: 7.804/11.264 secs] [Times: user=2.13 sys=0.06, real=1.13 secs]
36314.903: [CMS-concurrent-preclean-start]
36314.963: [CMS-concurrent-preclean: 0.037/0.060 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
36314.963: [CMS-concurrent-abortable-preclean-start]
36315.195: [GC 36315.195: [ParNew: 428092K->40832K(471872K), 1.1705760 secs] 2284414K->1897153K(3093312K), 1.1710560 secs] [Times: user=0.13 sys=0.02, real=0.12 secs]
CMS: abort preclean due to time 36320.059: [CMS-concurrent-abortable-preclean: 0.844/5.095 secs] [Times: user=0.74 sys=0.05, real=0.51 secs]
36320.062: [GC[YG occupancy: 146166 K (471872 K)]36320.062: [Rescan (parallel), 1.54078550 secs]36321.603: [weak refs processing, 0.0042640 secs] [1 CMS-remark: 1856321K(2621440K)] 2002488K(3093312K), 1.5456150 secs] [Times: user=0.18 sys=0.03, real=0.15 secs]
36321.608: [CMS-concurrent-sweep-start]
36324.650: [CMS-concurrent-sweep: 2.686/3.042 secs] [Times: uesr=0.66 sys=0.02, real=0.30 secs]
36324.651: [CMS-concurrent-reset-start]
36324.700: [CMS-concurrent-reset: 0.050/0.050 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

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

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

48004.088: [CMS-concurrent-mark: 8.012/8.647 secs] [Times: user=1.15 sys=0.02, real=0.87 secs]
(concurrent mode interrupted)

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

[Unloading class sun.reflect.GeneratedMethodAccessor3]

に続く：

: 1911295K->562232K(2621440K), 15.6886180 secs] 2366440K->562232K(3093312K), [CMS Perm: 52729K->51864K(65536K)], 15.6892270 secs] [Times: user=1.55 sys=0.01, real=1.57 secs]

前もって感謝します！

4

4 に答える 4

7

com.sun.jmx.remote.util.OrderClassLoader は、JMX のリモート レイヤーで使用されます。コードを簡単に確認すると、JVM 内のリモート リクエストのアンマーシャリング プロセスの一部として作成されていることがわかります。これらのクラスローダーの有効期間は、アンマーシャリングされたものの有効期間に直接関係するため、そのものへの参照がなくなると、クラスローダーを解放できます。

この場合、これらのインスタンスの存在が、JConsole を使用して JVM で行われていることを調べた直接の結果であったとしても、私は驚かないでしょう。そして、それらは通常の操作の一環として GC によってクリーンアップされるようです。

JMX 実装にバグがある可能性があり (比較的最新の JVM ではありそうにないようです)、カスタム MBean を使用しているか、問題の原因となっているカスタム JMX ツールを使用している可能性があります。しかし、最終的には、OrderClassLoader はおそらく厄介者であり、問​​題は別の場所にあるのではないかと疑っています (GC の破損またはその他のリーク)。

于 2010-10-06T18:01:41.493 に答える
5

テクニカル ノート: Linux 2.6.9 ボックスで Sun JDK 1.6.0_07、32 ビットを実行しています。JDK バージョンのアップグレードは、やむを得ない大きな理由がない限り、実際にはオプションではありません。

いくつかの新しい Java バージョンでは、CMS ガベージ コレクターが更新されています。特に 6u12、6u14、および 6u18。

私は GC の専門家ではありませんが、6u14 の preclean 修正により、発生している問題が修正される可能性があると推測しています。もちろん、6u18 のクラス アンロード バグについても同じことが言えます。私が言ったように、私は GC の専門家ではありません。

以下の修正があります。

  • 6u10: (6u4+ に影響) -XX:+ParallelRefProcEnabled の場合、CMS はリファレントをクリアしません
  • 6u12: CMS: 同時事前クリーニング中のオーバーフローしたオブジェクト配列のエンコードが正しくありません
  • 6u12: CMS: 並列同時マーキングを使用する場合のオーバーフロー処理が正しくない
  • 6u14: CMS: アサーション エラー「is_cms_thread == Thread::current()->is_ConcurrentGC_thread()」
  • 6u14: CMS: perm には CMSInitiatingPermOccupancyFraction が必要で、CMSInitiatingOccupancyFraction から分離されています
  • 6u14: CMS アサート: _concurrent_iteration_safe_limit の更新に失敗しました
  • 6u14: CMS: 参照リストのプレクリーニング中のオーバーフロー処理が正しくありません
  • 6u14: CMS および COOP で実行する場合の SIGSEGV または (!is_null(v),"oop value can never be zero") アサーション
  • 6u14: CMS: CompactibleFreeListSpace::block_size() でのライブロック。
  • 6u14: CMS を圧縮 oops で動作させる
  • 6u18: CMS: -XX:+UseCompressedOops を使用したコア ダンプ
  • 6u18: CMS: クラスのアンロードに関連するバグ
  • 6u18: CMS: CMS プレクリーニングが存在する場合、ReduceInitialCardMarks は安全ではありません
  • 6u18: [リグレッション] -XX:NewRatio に -XX:+UseConcMarkSweepGC を指定すると致命的なエラーが発生する
  • 6u20: カード マークの延期が長すぎる

上記のすべてに加えて、6u14 ではG1ガベージ コレクタも導入されましたが、まだテスト中です。G1 は、Java 7 の CMS を置き換えることを目的としています。

G1 は、次のコマンドライン スイッチを使用して Java 6u14 以降で使用できます。

-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

于 2010-10-06T15:17:41.843 に答える
-1

私は、次のようなはるかに単純なものから始めます。

-server -Xms3072m -Xmx3072m -XX:+UseParallelOldGC -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

そして、これがあなたのニーズを満たしているかどうかを確認してください。

于 2010-10-07T03:44:07.863 に答える
-2

所有者を指すオブジェクトを構築しているようです ( A は B を指し、 A を指します)。これにより、参照カウントがゼロより大きいままになるため、ガベージ コレクターは参照カウントをクリーンアップできません。それらを解放するときは、サイクルを壊す必要があります。A または B の参照を無効にすると、問題が解決します。これは、( A -> B -> C -> D -> A) のような大きな参照でも機能します。ベクトルとオブジェクト配列は、HashMap で使用できます。

リモート ローダーの存在は、JNDI またはその他のリモート アクセス メソッドを介してロードされたオブジェクトへの参照のクリーンアップとクローズに失敗したことを示している可能性があります。

編集：最後の行をもう一度見ました。パーマの割り当てを増やしたい場合があります。

于 2010-10-06T14:52:05.487 に答える