ガベージコレクション情報をログにダンプするようにJavaを構成しました( verbose GC )。ログのガベージコレクションエントリの意味がわかりません。これらのエントリのサンプルを以下に掲載します。 Google で検索したところ、確固たる説明は見つかりませんでした。
合理的な推測はいくつかありますが、信頼できる情報源によって裏付けられた、エントリ内の数字の意味を厳密に定義する回答を探しています。 Sunのドキュメントを引用するすべての回答に対する自動+1。私の質問は:
8109.128:[GC [PSYoungGen:109884K-> 14201K(139904K)] 691015K-> 595332K(1119040K)、0.0454530秒]
8112.111:[GC [PSYoungGen:126649K-> 15528K(142336K)] 707780K-> 605892K(1121472K)、0.0934560秒]
8112.802:[GC [PSYoungGen:130344K-> 3732K(118592K)] 720708K-> 607895K(1097728K)、0.0682690秒]
そのほとんどは GC Tuning Guide (とにかく読むのがいいでしょう)で説明されています。
コマンドラインオプション
-verbose:gc
を使用すると、ヒープおよびガベージコレクションに関する情報が各コレクションで出力されます。たとえば、大規模なサーバーアプリケーションからの出力は次のとおりです。[GC 325407K->83000K(776768K), 0.2300771 secs] [GC 325816K->83372K(776768K), 0.2454258 secs] [Full GC 267628K->83769K(776768K), 1.8479984 secs]
ここでは、2つのマイナーコレクションの後に1つのメジャーコレクションが表示されます。矢印の前後の数字(たとえば、最初の行の
325407K->83000K
)は、ガベージコレクションの前後のライブオブジェクトの合計サイズをそれぞれ示しています。マイナーコレクションの後、サイズには、ガベージ(もはや生きていない)が回収できないオブジェクトが含まれます。これらのオブジェクトは、終身世代に含まれるか、終身世代または永続世代から参照されます。括弧で囲まれた次の数値(たとえば、最初の行の
(776768K)
)は、ヒープのコミットサイズです。オペレーティングシステムに追加のメモリを要求せずにJavaオブジェクトに使用できるスペースの量です。常に1つしか使用できないため、この数にはサバイバースペースのいずれも含まれず、仮想マシンで使用されるメタデータを保持する永続的な世代も含まれないことに注意してください。行の最後の項目(例:
0.2300771 secs
)は、コレクションの実行にかかった時間を示します。この場合、約1/4秒です。3行目のメジャーコレクションの形式は似ています。
-verbose:gc
によって生成される出力の形式は、将来のリリースで変更される可能性があります。
PSYoungGenがあなたのものにある理由はわかりません。ガベージコレクターを変更しましたか?
関連するフルGCの例は、古い世代と永続的な世代に使用されるコレクターも示しています。
3.757: [Full GC [PSYoungGen: 2672K->0K(35584K)]
[ParOldGen: 3225K->5735K(43712K)] 5898K->5735K(79296K)
[PSPermGen: 13533K->13516K(27584K)], 0.0860402 secs]
最後に、ログ出力例の1行を分解します。
8109.128: [GC [PSYoungGen: 109884K->14201K(139904K)] 691015K->595332K(1119040K), 0.0454530 secs]
詳細なGCログを取得するには、
-XX:+PrintGCDetails
パラメータ。次に、回答のようにPSYoungGenまたはPSPermGenの出力が表示されます。
-Xloggc:gc.log
も-verbose:gc
と同じ出力を生成するようですが、最初に出力ファイルを指定できます。
使用例:
Java -Xloggc:./memory.log -XX:+PrintGCDetails Memory
データをよりよく視覚化するには、 gcviewer (より新しいバージョンは github にあります)を試すことができます。
パラメータを正しく記述するよう注意してください。「+」を忘れると、JBossはエラーメッセージなしで起動しません。