問題タブ [verbosegc]

CMS (Concurrent-Mark-Sweep) GC が有効になっている Java ランタイムを調べると、以下のログのスペースの定義は何ですか? CMS 在職中のスペースだと思いますか？マイナー-メジャー-マイナー GC イベントの次の行が表示されます

特にイベント[CMS: 10899K->9379K(12448K), 0.2675281 secs]時23.492。これは、CMS とラベル付けされたばかりの在職期間を示していますか? CMS は在職期間中のみに実行されますか?

CMS GC が有効になっている Java ランタイムで、次の verbosegc 行について洞察を提供してもらえますか? 具体的には：

1. でのイベントは29.490、マーキングのための高水準のヒープ位置を示していますか?
2. フェーズとは何precleanですか?マーキングとは何が違うのですか?
3. resetフェーズとは何ですか？それがスイープの終わりではないのに、なぜそれが完了するのに時間がかかるのでしょうか?
4. 最後に、 でのイベントのRescan、greyおよびroot再スキャンとremarkエリアとメトリックとは29.653何ですか? これらは、後続のスイープで報告されたヒープ メトリックであると仮定しますか? もしそうなら、なぜ彼らは時間を消費するのですか？

verbosegc ログの抜粋:

ありがとう、

いくつかのパフォーマンスの問題がある Java アプリケーションがあり、誰かが verbose:gc モードで実行することを勧めています。これは完了しましたが、ログの解釈方法がわかりません。それが何を意味するのかを説明したり、パフォーマンスを向上させるために何ができるかをアドバイスしたりできますか?

出力ログはhttp://pastebin.com/uDNPEGcdにあります。

前もって感謝します, 敬具, マールテン

Linux サーバー上に verbose:gc がオンの Glassfish サーバーがあり、gc.log ファイルに出力されます。

フラグを使用します-XX:+PrintGCDetails。生成されたファイルには、次のような行が含まれています。

ご覧のとおり、最後の行にはその[Times: ...]部分が含まれていません。次の GC イベントが発生すると[Times: ...]、前の行の一部が書き込まれ、次に別の部分的な行が書き込まれるため、GC イベント行はログ ファイルに完全には書き込まれません。

行が終了していないため、改行が存在しないため、行は次のようなツールに表示されませんmultitail

フラグを使用すると、-XX:+PrintGCこの問題はなくなります。しかし、完全な詳細が必要なため、これは良い解決策ではありません。

Linux で動作する JVM バージョン:

問題は、JVM に強制的にログ行を書き込むこと (一種のフラッシュ トリック) は可能かということです。または、最後の部分なしで GC の詳細を取得することは可能ですか?

-XX:+PrintGCApplicationStoppedTimeオプションとオプションを使用-XX:+PrintGCApplicationConcurrentTimeして、gc ロギングをオンにしています。

しかし、コマンドPrintGCApplicationStoppedTimeを介して印刷された gc ログの実際の詳細を4 0r 5 印刷した後であることがわかりました。-XX:+PrintGCDetails

定義によりPrintGCApplicationStoppedTime、すべての gc のアプリケーション停止時間を出力します。

しかし、以下に示す例のように印刷される理由は明確ではありません。

そのせいか

PrintGCApplicationStoppedTime安全なポイントに到達するたびに印刷するだけです

（また）

ログ ファイルは、さまざまな gc スレッドによって記録されます。フルGCには同時スイープを使用し、若い世代にはParNewを使用しています

私のアプリケーションは Web アプリケーションです。

O/p パターン - 私はこのようになっています:

これらは私のJavaアプリケーション/ jvmの場合、世界のイベントを停止しますか?もしそうなら、どれを停止しますか? ユーザー sys real、

[PSYoungGen: 347808K->672K(348160K)] 415832K->68744K(1047552K), 0.0019772 秒] [時間: user=0.03 sys=0.00, real=0.00 秒]

[PSYoungGen: 347808K->640K(348160K)] 415880K->68792K(1 047552K), 0.0018775 秒] [時間: user=0.01 sys=0.01, real=0.00 秒]

[PSYoungGen: 347776K->704K(348160K)] 415928K->68912K(1047552K), 0.0020238 秒] [時間: user=0.02 sys=0.00, real=0.00 秒]

ありがとう

次のコマンドを使用して、JBoss システムでラージ ページを使用できるようにしました。

また、OS レベルでページを割り当て、JBoss がページを使用するためのアクセス許可を提供しました。4k ページ サイズを示す Verbose GC ログ ヘッダーを除いて、すべて問題ないように見えます。

この行は、JAVA_OPTS および OS レベルで定義されているラージ ページ サイズに一致するように「2m ページ」と表示されると予想されますが、Java ヒープがラージ ページを「認識」していないか、GC ログ ヘッダーが認識されていない可能性があります。これらの変更に敏感です (たとえば、この出力はシステムのページ サイズをチェックしますが、必ずしも Java によって使用されているページではありません。この場合は 2m の大きなページです (うまくいけば))。

大きなページを使用してこのヘッダーが変更されることを期待すべきかどうかは誰にもわかりませんか?