はじめに
J2EEサーバの健康診断をする上で、GC（ガーベッジ・コレクション）の発生状況の把握は非常に重要です。GCの発生状況を監視することによって、メモリリークを発見したり、サーバの負荷状況を調べたりすることができます。
そこで、商用J2EEサーバとしてはシェアの高いWebSphere Application Serverを想定し、GCの解析方法とチューニングポイントを説明します。
対象読者
WebSphere Application Serverを利用したシステム開発に携わる、開発者・アーキテクト。
必要な環境
- サーバ：WebSphere Application Server 6.0以上
- 解析用PC：IBM JDK 1.4.2以上がインストールされていること
IBM JDK 5.0は、developerWorksのWebページからダウンロードできます。Eclipseとセットになっています。
WebSphereの設定
GCを解析するためには、WebSphereに解析用ログ（native_stderr.log）を出力する設定を行います。
設定の手順
WebSphereの管理コンソールを開き、左側のメニューから
- ［サーバー］→［アプリケーション・サーバー］→［(サーバー名)］→［構成］→
- ［OK］ボタンを押下、上部に表示されるメッセージ枠内の「直接マスター構成に保管できます。」の［保管］をクリック
以上を行ったらサーバを再起動します。
「native_stderr.log」は以下のディレクトリに出力されます。
- native_stderr.logの出力ディレクトリ
<WAS導入ディレクトリ>\profiles\<サーバディレクトリ>\bin
C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\server1
native_stderr.logはシステムの健康診断書のようなものです。ログを出すこと自体は大きな負荷にはなりませんので、常に出力するようにしておくことをお勧めします。定期的に回収して健康診断を行いましょう。
verbosegcデータ
GCの解析に必要なデータは、JVMがnative_stderr.logに出力します。verbosegcデータとは、GCが発生する度にJVMが出力するXML形式のデータです。データに含まれる主な情報は次のとおりです。
- GC発生時刻
- GC発生の原因となったメモリ確保要求サイズ
- GCを実行した結果、確保されたメモリ量
- GCにかかった時間
<?xml version="1.0" ?> <verbosegc> <af type="tenured" id="9016" timestamp="Fri Jul 13 00:10:54 2007"
intervalms="953273.470"> <minimum requested_bytes="80" /> <time exclusiveaccessms="0.102" /> <tenured freebytes="1513888" totalbytes="805306368" percent="0" > <soa freebytes="0" totalbytes="803140608" percent="0" /> <loa freebytes="1513888" totalbytes="2165760" percent="69" /> </tenured> <gc type="global" id="9024" totalid="9024" intervalms="953273.995"> <refs_cleared soft="32" weak="454" phantom="1274" /> <finalization objectsqueued="1582" />
verbosegcはXML形式なので、必ずヘッダ（<?xml>タグと<verbosegc>タグ）とフッタ（</verbosegc>タグ）が付いていなければなりません。しかし、ログのローテート（日付が変わったりファイルサイズが設定された限界に達した時、ログの出力先を別のファイルに切り替えること）が行われ、ヘッダ、フッタがないファイルができる場合があります。
このようなファイルができてしまった場合は、そのままではツールが解析できません。不足したヘッダ、フッタを追加しておきましょう。
<?xml version="1.0" ?> <verbosegc> <af type="tenured" id="65" timestamp="Sun Jun 17 00:24:35 2007"
intervalms="4730690.326">
</af> </verbosegc>
