test

Sun Java System Application Server Enterprise Edition 8.2 パフォーマンスチューニングガイド

ガベージコレクションの追跡

ガベージコレクションのパフォーマンスは、主にスループットとポーズによって測定されます。スループットは、GC 以外のアクティビティーに費やされた合計時間の割合です。ポーズは、GC が原因でアプリケーションが応答していないように見える時間です。

そのほかにも、フットプリントと即応性の 2 つの考慮事項があります。フットプリントは JVM プロセスの作業サイズで、ページとキャッシュ行で測定されます。即応性は、オブジェクトがデッド状態になってからメモリーが利用可能になるまでの時間です。分散システムでは、これは重要な考慮事項です。

各世代のサイズを決定するときは、これら 4 つのメトリック間のトレードオフを考慮します。たとえば、若い世代を大きくすれば、スループットを最大にできるかもしれませんが、フットプリントと即応性は犠牲にされます。逆に、若い世代を小さくして 増分 GC を使用すれば、ポーズを最小にできるので即応性は増しますが、スループットは低下します。

JVM 診断の出力に、ガベージコレクションによるポーズに関する情報が表示されます。サーバーを冗長モード (asadmin start-domain --verbose domain コマンドを使用) で起動する場合は、コマンド行引数の -verbose:gc により、コレクションのたびに情報が出力されます。この JVM フラグで生成される情報の出力例を次に示します。

[GC 50650K->21808K(76868K), 0.0478645 secs]
 [GC 51197K->22305K(76868K), 0.0478645 secs]
 [GC 52293K->23867K(76868K), 0.0478645 secs]
 [Full GC 52970K->1690K(76868K), 0.54789968 secs]

各行の最初の数字は、GC 前のライブオブジェクトの合計サイズ、2 番目の数字は GC 後のライブオブジェクトのサイズ、括弧内の数字は合計空き容量 (ヒープの合計容量から一方の Survivor 領域を差し引いたもの) を示します。最後の数字は、GC に要した時間です。この例は、3 回のマイナーコレクションと 1 回のメジャーコレクションが行われたことを示しています。最初の GC では、コレクションの前は 50650K バイトのオブジェクトが存在していましたが、コレクションのあとは 21808K バイトになりました。つまり、28842K バイトのオブジェクトがデッド状態で収集されたことになります。ヒープの合計サイズは 76868K バイトです。コレクションプロセスには 0.0478645 秒を要しました。

その他の有用な監視オプションを次に示します。