GC ログ解釈の分析

目次

GC分類

GC ログ分類

GC ログ構造の分析

ログを通してガベージコレクターを見る

ログから GC の原因を確認する

GCログ解析ツール


GC分類

HotSpot VM の実装では、その中の GC はリカバリ領域に応じて 2 つのタイプに分けられます。1 つは部分コレクション (Partial GC) で、もう 1 つは完全ヒープ コレクション (Full GC) です。

  • 部分コレクション (部分 GC): Java ヒープ全体を完全には収集しないガベージ コレクション。次のように分類されます。
  1. Young GC (Minor GC / Young GC): 新世代のガベージ コレクション (Eden / S0、S1)
  2. 古い世代のコレクション (Major GC / Old GC): 古い世代のガベージ コレクションです。現在、古い世代を個別に収集する動作を持つのは CMS GC だけです。メジャー GC はフル GC と混同されることが多く、オールド エイジ コレクションかフル ヒープ コレクションかを明確に区別する必要があることに注意してください。
  • 混合コレクション (Mixed GC): 新しい世代全体と古い世代のガベージ コレクションの一部を収集します。現在、G1 GC のみがこの動作をしています。
  • 全ヒープ コレクション (Full GC): Java ヒープおよびメソッド領域全体を収集するガベージ コレクション。

GC ログ分類

マイナーGC

MinorGC (または若い GC または YGC) ログ:

 

フルGC 

GC ログ構造の分析


ログを通してガベージコレクターを見る



● シリアル コレクタ: 新しい世代は「[DefNew」と表示されます。つまり、Default New Generation
● ParNew コレクタ: 新しい世代は「[ParNew」と表示されます。つまり、Parallel New Generation
● Parallel Scavenge コレクタ: 新しい世代は「[PSYoungGen」と表示されます。 JDK1.7 は PSYoungGen を使用
● Parallel Old コレクタ:古い時代の「[ParoldGen]」を表示
●G1 コレクタ:「garbage-first heap」を表示


ログから GC の原因を確認する


Allocation Failure: 今回の GC の理由は、割り当てる必要のあるデータを格納するための十分な領域が新しい世代にないためであることを示します
Metadata GCThreshold: メタスペース領域が不足しています
FErgonomics: JVM 適応調整
システムによる GC : システムは .gc() メソッドと呼ばれます

GC 前後の状況をログで見てみましょう
図から、GC ログ形式のパターンは一般的に GC 前のメモリ使用量 -> GC 後のメモリ使用量 (合計) であることがわかりますこの領域のメモリサイズ)

[PSYoungGen: 5986K->696K (8704K) ] 5986K->704K (9216K)
  • 角括弧内: GC 回復前の若い世代のヒープのサイズ、回復後のサイズ (若い世代のヒープの合計サイズ)
  • 括弧外:GC回復前の若い世代と古い世代のサイズ、回復後のサイズ(若い世代と古い世代の合計サイズ)

注: 合計マイナー GC ヒープ メモリ容量 = 9/10 若い世代 + 古い世代。その理由は、Survivor 領域は from 部分のみを計算し、JVM はデフォルトで、若い世代の Eden 領域と Survivor 領域の比率、Eden:S0:S1=8:1:1 になるためです。

ログで GC 時間を表示する

GC ログには、user、sys、real の 3 回があります。

  • user: ユーザー モード コードを実行するプロセス (コアの外部) に費やされた時間。これは、このプロセスの実行に費やされた実際の CPU 時間であり、他のプロセスとこのプロセスがブロックされた時間はカウントされません。ガベージ コレクションの場合、GC スレッドの実行に使用された合計 CPU 時間。
  • sys: カーネル モードでプロセスが消費した CPU 時間、つまり、カーネルがシステム コールの実行またはシステム イベントの待機に使用した CPU 時間
  • real: プログラムが開始から終了までにかかったクロック時間。この時間には、他のプロセスによって使用されるタイム スライスと、プロセスがブロックされている時間 (I/O の完了の待機など) が含まれます。並列 GC の場合、この数値は (ユーザー時間 + システム時間) をガベージ コレクターが使用するスレッド数で割った値に近くなるはずです。

マルチコアの理由により、一般的な GC イベントでは、リアルタイムは sys 時間 + ユーザー時間よりも短くなります。これは、一般に複数のスレッドが GC を同時に実行するためです。したがって、リアルタイムは sys + ユーザー時間よりも短くなります。real>sys+user の場合、アプリケーションに次の問題がある可能性があります: IO 負荷が非常に高いか、CPU が十分ではありません。

GCログ解析ツール

GCEasy

GCEasy はオンライン GC ログ アナライザーであり、GC ログ分析によるメモリ リーク検出、GC 一時停止原因分析、JVM 構成提案最適化などの機能を実行できます.ほとんどの機能は無料です.

公式 Web サイトアドレス: Universal JVM GC アナライザー - Java ガベージ コレクションのログ分析が簡単に

GCビューア

GCViewer は、Java VM オプション -verbose:gc および .NET -Xloggc:<file> によって生成されたデータを視覚化するためのオフライン GC ログ アナライザーです。ガベージ コレクションに関連するパフォーマンス メトリックも計算できます (スループット、累積一時停止、最長一時停止など)。この機能は、生成サイズを変更したり、初期ヒープ サイズを設定したりして、特定のアプリケーションのガベージ コレクションを調整する場合に役立ちます。

ソース码下载:GitHub - cheiebug/GCViewer: tagtraum industry's GCViewer のフォーク。Tagtraum は 2008 年に開発を停止しました。Sun の / Oracle の Java 1.6+ ガベージ コレクター ログ (G1 コレクターを含む) のサポートを改善することを目指しています。

実行中のバージョンのダウンロード:変更ログ chwebug/GCViewer Wiki GitHub

おすすめ

転載: blog.csdn.net/m0_62436868/article/details/130399672