チューニングに使えるJava性能監視ツール

JavaVMを監視するツール群

今回は、Java EEアプリケーションをチューニングする際に便利なツールを紹介します。JavaVMの状態を監視／レポートするツールは、フリー・ソフトウエアや製品を含め、いくつか提供されています。米Oracle（米Sun Microsystems）のJava環境にも、標準で便利なツール群が付いています。本記事では、標準ツールであるjconsoleとjstatの2つを紹介します。

表1: 主なJavaVM監視／レポーティング・ツール

[*1] コード・カバレッジ: アプリケーション内にあるメソッドの実行率のこと。コードは存在するが実行されていないクラスやメソッドを追跡するために利用する。

これらのほか、Oracle WebLogic Application Serverや、IBM WebSphereなどの統合アプリケーション・サーバー製品には、管理ツールの1つとして性能監視ツールが整備されています。

JavaVMをグラフィカルに監視するjconsole

JavaVMのメモリー使用状況などを参照／監視できるツールとして、Sun Java 5以降では、標準でいくつかの便利なツールが用意されています。その1つに、JavaVMの利用状況を監視した結果をリアルタイムで図示するjconsoleがあります。使い方は非常に簡単で、コマンド・プロンプトからコマンドを入力するだけで起動します。

C:\>jconsole [監視するJavaVMのプロセス番号]

起動時にプロセス番号を省略した場合は、現在起動しているJavaプロセスの一覧から選択できます。JavaVMのプロセス番号を調べるツールも用意されています。こちらは、コマンド・プロンプトで、以下のように入力すると起動します。

C:\>jps

例えば、Windows環境でEclipseを起動した状態で、EclipseからTomcat 6.0を起動させたケースを想定します。この状態でjpsを実行した結果は、以下のようになります。

C:\>jps
6284 Bootstrap
7512
6564 Jps

この状態にて、jconsoleでTomcat 6.0（=Bootstrap）プロセスを指定します。

C:\>jconsole 6284

プロセス番号を正しく指定すると、jconsoleが監視した結果のグラフが、図1のように表示されます。

図中のグラフの意味は、以下の通りです。

ヒープ・メモリーの推移は、図1の左上にあるヒープ・メモリーの使用状況のように、ノコギリ状の波形が全体的にゆるやかに右肩上がりになり、一定時間後に大幅に下がるのが通常です。これは、ガベージ・コレクション（GC）と呼ばれる、JavaVMのメモリー開放機能が自動的に実行されたことによります。もしヒープ・メモリーを開放せずに蓄積したままであれば、長期的に利用されているオブジェクトが存在し続けることになります。それが想定外のことであれば、メモリー・リークを疑います。

ただし、監視（モニタリング）しながらアプリケーションを開発／実装することは、非常に稀です。開発時には何度もアプリケーション・サーバーを再起動することになるため、再起動するたびに毎回監視プロセスを変更しなければなりません。さらに、実装段階ではコードに不具合が含まれるため、運用段階とはメモリーの使用状況やクラスの数が明らかに異なるでしょう。

可能であれば、アプリケーションが完成してから単体テストの段階で何度も動かしてみて監視します。しかし、高い負荷を持つ機能でもない限り、プロセスの測定や監視をしても、あまり効果がありません。監視する対象の例には、プロトタイプ作成後の動作テストやライブラリ導入後の動作テストが挙げられます。

明らかに複数の機能や画面で共有するオブジェクトを利用する場合や、外部リソースを取得する処理、何らかの業務処理で非同期通信をする場合など、ほかの機能に比べて特殊な操作を行うもの、特に外部システムとのI/Oが発生するものは、監視の必要があります。オブジェクトが保持されるタイミングや開放されるタイミングが、共通機能や外部機能に依存するからです。何度も動かして監視する必要があります。