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

2011年3月25日(金)
東 浩二(A-pZ)(監修:山田祥寛)

JavaVMを監視するツール群

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

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

製品名 特徴
タブ表示できるGUIのログ追跡ツール。ログ・ファイルから、VMのヒープ状況の解析やスレッド解析を行える。
Eclipse Memory Analyzer IDE環境のEclipseで利用可能な、グラフィカル・メモリー解析プラグイン。単体テストから仮想サーバー上でのヒープ監視まで利用できる。ヒープ利用状況の円グラフ表示や、ガベージ・コレクション対象クラスの追跡など、多種多様なレポート機能を備える。
JProbe Java性能測定ツール。メソッドの実行時間、呼び出し回数をグラフィカルに表示、警告する。メモリー利用状況をグラフィカルに表示し、メモリー・リークの調査や、コード・カバレッジ*1調査も行う。
    [*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: jconsoleの概要画面

図1: jconsoleの概要画面(クリックで拡大)

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

【左上】: ヒープメモリの使用状況
  • 使用済み: 指定したJavaVMが実際に消費しているメモリーの量
  • 確定: ヒープで使用するように割り当てられた合計メモリー容量
  • 最大: 最大メモリー・サイズ
【右上】: 現在有効なスレッド数
【左下】: 現在までに読み込まれたクラスの数
  • 現在読み込まれているクラスの数、JavaVMの起動以降にメモリーにロードされたクラスの合計数(その後アンロードされたものを含む)、JavaVMの起動以降にメモリーからアンロードされたクラスの数
【右下】: JavaVMのCPU使用状況

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

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

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

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

著者
東 浩二(A-pZ)(監修:山田祥寛)
WINGSプロジェクト

有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表:山田祥寛)。おもな活動は、Web開発分野の書籍/雑誌/Web記事の執筆。ほかに海外記事の翻訳、講演なども幅広く手がける。2011年3月時点での登録メンバは36名で、現在もプロジェクトメンバーを募集中。執筆に興味のある方は、どしどしご応募頂きたい。著書多数。
http://www.wings.msn.to/

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています