製品版 Javaデバッグツール
DevPartner Java Edition メモ

最終更新日:2004/06/28
ogwa567@oki.com

製品版 Javaデバッグツール DevPartner Java Edition

DevPartner はパフォーマンス分析、メモリ分析、カバレッジ分析の3つを行うことができる製品です。「簡単なオペレーション」,「サーブレット・コンテナとの連携が容易」といった特徴があります。

詳細はhttp://www.compuware.co.jp/products/devpartnerJE/dpj2.htmlを参照して下さい。

目次

インストール

インストール媒体は、WindowsだけでなくLlinux向けのものもあります。今回はWindowsプラットフォーム向けの媒体をインストールします。

Windowsプラットフォーム向けに、インストール媒体(EXE)を実行し、画面の指示に従ってインストールします。尚、測定対象のアプリケーションが動作するマシンにインストールをして下さい(リモートからの分析が可能かどうかは不明)。

パフォーマンス分析

ここでは、DevPartnerを使ってパフォーマンス分析を行う方法を紹介します。尚、今回はTomcat上で動作するWebアプリケーションを測定対象とします。スタンドアロンアプリケーションでも分析の方法は基本的に同じです。

Tomcatの設定

スタートメニューから、「Compware ...」→「Utilities」→「Administration」を選択します。すると以下の画面が表示されます。

画面左上のドロップボックスで"Apache Tomcat"を選択し、「New Configuration..」ボタンをクリックすると以下の画面が表示されます。

TomcatとJDKのロケーションを入力し、OKボタン押下で設定完了です。

起動

スタートメニューから、「Compware ...」→「DevPartner Java Edition」を選択します。すると以下の画面が表示されます。

DevPartnerの管理コンソースはWebベースです。基本的にすべての操作はWebブラウザがから行います。

コンフィグレーションの新規作成

上の画面で「Configurations」タブを選択します。以下のような画面が表示されます。

画面右の「New」ボタンをクリックし、新しいコンフィグレーションを作成します。名前を入力すると以下の画面が表示されます。

この画面で様々な設定を行います。

分析対象パッケージの選択

画面左の「Data Collection」下の「Packages And Classes」を選択し、分析対象とするパッケージを選択します。上の画面はデフォルトの設定です。上側のテキストボックスへ分析対象から除外するパッケージを入力し、下側は分析対象にしたいパッケージを入力します(どちらか一方を選択する)。デフォルト設定でTomcatのパッケージは除外されているので、デフォルト設定のままにしておきます。必要に応じてここを変更して下さい。

分析対象ソースファイルの設定

画面左の「Source File Paths」を選択し、右側の「Add...」ボタンで分析対象ソースファイルの格納場所を設定します。ここで分析対象ソースファイルの格納場所を設定しておけば、パフォーマンス分析において、実行時間の多いメソッドの特定だけでなく、更にメソッド内の一つ一つのコードが何%占めているかまで測定できます。

Tomcatの起動

分析のためには、TomcatもDevPartnerから起動する必要があります。管理コンソース(上記ブラウザ)で「Application Server Testing」タブを選択します。

「Configuration」ドロップボックスで先ほど作成したコンフィグレーションの名前を設定し、「Analysis Type」には"Performance"を選択します。DevPartnerでは以下の分析が可能です。

このAyalysis Typeでその中の一つを選択します。今回はパフォーマンス分析を行います。

画面内の「Start」ボタンを押下してTomcatを起動します。起動に成功すると、以下の画面が表示されます。

Webブラウザを立ち上げ、測定対象操作を実行します。その後、上の画面の「View Results」を表示すると、新しいウィンドウが生成され、分析結果が表示されます。

エントリポイント

Webアプリケーションのエントリポイント(典型的にはサーブレットのdoGet or doPost)の中で実行時間の占める割合が大きいものから順に表示されます。今回の測定では一つのサーブレットを一度実行しただけなので、一つしかエントリポイントがありません。そのため画面でもその一つのみ表示されています。

メソッドコールグラフ

上の画面のグラフ右のメソッド名をクリックすると、以下のウィンドウが表示されます。

このメソッドの実行時間に関する情報が表示されます。更に「View Call Graph」リンクをクリックすると、メソッドコールグラフが表示されます。

グラフからdoPost()からtask1(), task3()を呼び出していることがわかります。task1()への矢印に付けられた"100.00%"は、doPost()から呼び出しているメソッドにおける、実行時間の割合を示しています。task3()は0.5%以下です。つまり、doPost()から呼び出しているメソッドの中では、task1()がそのほとんどの実行時間を占めていることがわかります。task2()についても同様です。

実行時間という観点でのボトルネック

エントリポイントの下には更に以下のグラフが表示されます。

グラフは横軸がメソッドの平均実行時間を,縦軸がメソッドの実行回数を表しています。この図には「平均実行時間」*「実行回数」が大きい上位5つのメソッドが表示されます。グラフに表示されている色つきの円は、この「平均実行時間」*「実行回数」の大きさをグラフィカルに表しています。つまり、最も大きな円が実行時間という観点で最も大きいボトルネックということです。一番大きなボトルネックは赤色で表されます。グラフの右に円に対応するメソッドが対応する色のアイコンで表示されています。この例ではHeavyTask1#task1()が最も大きいボトルネックになります。

待機時間という観点でのボトルネック

実行時間の更に下には以下のグラフが表示されます。

実行時間のグラフと比べて、横軸がメソッドの待機時間になっています。この待機時間は他の何らかのイベントによってメソッド実行が待たされた時間です。メソッドの実行に費やされた時間は含まれません。この例でもHeavyTask1#task1()が待機時間という観点で最も大きいボトルネックと言えます。

このようにDevPartnerは二つの観点でボトルネックを表示します。ボトルネックを発見するためには、この二つのグラフに基づいて調査していくと良いでしょう。

ソースファイルとの連携

実行時間という観点でのボトルネックで示したグラフの右側にある、HeavyTask1.task1()リンクをクリックします。すると以下のウィンドウが表示されます。

「View Source Code」リンクをクリックすると以下の画面が表示されます。

メソッド内のどの処理が何%占めているかが表示されます。この例ではforループの繰り返し処理とcount変数のインクリメントが、それぞれ45.88%, 45.41%を占めていることがわかります。

メモリリーク分析

メモリリーク分析の準備

次はメモリリークの調査方法を紹介します。まずはパフォーマンス分析の場合と同じように、「Configuration」タブから新しくコンフィグレーションを作成しましょう。作成したら、「Application Server Testing」タグをクリックします。そこでAnalysis Typeを"Momory Analysis"とします(下図)。

「Start」ボタンをクリックすると、次のようにメモリ使用量を表すグラフが表示されます。

メモリリークの分析方法

ここで画面左上のドロップボックスで「Memory Leaks」を選択し、「Start Tracking」ボタンをクリックし、メモリリークの監視を開始します。

その後メモリリークが発生していると思われる操作をWebブラウザから行います。下図は実際メモリリークが発生する処理をWebブラウザ経由で実行した後のグラフです。

操作が終わったら、「Stop Tracking」ボタンをクリックして監視を終了します。すると、監視中に生成され、GCでも回収されなかったオブジェクトが下図の「Tracked Objects」列に表示されます。

リーク箇所の特定

上の画面で「View Memory Leaks...」ボタンをクリックすると、以下のように様々な分析結果が表示されます。

分析結果として表示されるのは、以下の項目です。

これらの上位5つが表示されます。ここではまず、リーク箇所を特定するために「リークしたオブジェクトを割り当てたメソッド」を見ていきます。上のグラフがそれを表しています。LeakTask#task()がその第1位ですので、このメソッド名のリンクをクリックします。すると以下のウィンドウが表示されます。

パフォーマンス分析の場合と同じように、「View Source Code」リンクをクリックします。

ソースコードが表示され、どの行でどれだけリークが発生したかが表示されます。この例では、 list.add(new Object[100]) というコードが大量のリークが発生させていることがわかります。

資料室へ戻る