チューニングを実施する前にやるべきこととは？：WebSphereサーバ・チューニング入門（1）（3/3 ページ）
「PMI」および「TPV」で詳細な情報を入手
WASが提供する2つ目のツールとして、さらに詳細なパフォーマンス情報を取得するための基盤であるPMI（Performance Monitoring Infrastructure）が挙げられます。PMIデータを使用して、WASのパフォーマンス・ボトルネックを識別し、修正できます。WASは、J2EE仕様のパフォーマンス・データ・フレームワークであるJSR-077をサポートしており、さまざまなJ2EEコンポーネントのために使用できるパフォーマンス・データを提供します。
PMIは、J2EE 1.4パフォーマンス・データ・フレームワークに加え、サーブレットやEJBなどのJ2EEコンポーネントおよび、スレッド・プールやワークロード管理などのWAS固有のコンポーネントに関する追加の統計を提供します。PMIは、WASのコンポーネントごとに設定可能であり、データベース接続プール・サイズ、サーブレット応答時間、EJBメソッド応答時間、JVMガーベッジ・コレクション時間、CPU 使用量、スレッドの使用状況、キャッシュの状況など非常に多くの情報を取得できます。このデータを使用して、スレッド・プール、接続プールなどのランタイム・リソース使用率パターンと、サーブレット、JSP、およびEJBのようなアプリケーション・コンポーネントのパフォーマンス特性を理解できます。
例えば、PMIで取得した統計データを利用し、JDBC接続プールのPrepared Statement Cacheから廃棄されたステートメント数を把握できます。この統計を使用してPrepared Statement Cacheのサイズを調整し、廃棄されるステートメント数を最小化でき、それによりデータベースアクセスのパフォーマンスを向上させることができます。また、PMIのインターフェイスを利用して、ユーザーアプリケーションの情報を取得することも可能です。
PMIの設定の仕方
PMIの設定は、WAS管理コンソールから実施します。管理コンソールで、「モニターおよびチューニング」→「Performance Monitoring Infrastructure（PMI）」をクリックし、該当のサーバを選択・クリックします。「構成」タブの一般プロパティーで、「Performance Monitoring Infrastructure（PMI）を使用可能にする」のチェックボックスをチェックし、「現在モニターされている統計セット」でモニターする必要がある統計セットを選択します。WASは、PMIを使用したシナリオに基づいた、定義済みの固定のサーバ・サイドの統計セットを提供しています。
PMI仕様レベルには、「なし」「基本」「拡張」「すべて」「カスタム」があります。以下、選択時の効果です。
- 「なし」を選択すると、すべてのPMIモジュールが無効になる
- 「基本」を選択すると、基本レベルのモニターを行えるように、J2EEおよび基本セットの統計が提供される
- 「拡張」を選択すると、基本レベルのモニターとワークロード・モニター、パフォーマンス・アドバイザー、およびTivoliリソース・モデルなどのより多くのモニター・セットが提供される
- 「すべて」を選択すると、すべての統計が使用可能になる
- 「カスタム」を選択すると、統計を個々に使用可能または使用不可にできる
「構成」タブでの設定は、サーバが再始動された時点で適用されます。「ランタイム」タブでの設定は、即時に適用されます。 PMIは、「構成」タブでのみ使用可能にできるという点に注意してください。
TPVとは何か？
PMIはそれらの情報を取得するための基盤ですので、取得した情報を表示するためのツールが必要になります。
WASは、「TPV（Tivoli Performance Viewer）」と呼ばれるツールを提供しています。TPVは、WAS管理コンソールに統合されたシン・クライアントで、PMIによって提供されるパフォーマンス・データの簡単なビューアを提供し、システム管理者はカウンターのデータを見たり、操作できたりします。
TPVを使ってみよう！
WAS管理コンソールで、「モニターおよびチューニング」→「Performance Viewer」→「現行アクティビティー」をクリックし、「Tivoli Performance Viewer」画面で、該当のサーバの「コレクション状況」が「使用可能」になっていることを確認します。該当のサーバを選択し、「モニターの開始」をクリックします。
なお、「コレクション状況」が「使用可能」になっていない場合には、先ほど説明したPMIの設定画面で、「PMIを使用可能にする」を選択しているかどうかを確認してください。
モニターが正常に開始されたことを示すメッセージが管理コンソール上に表示されます。
図5 モニターの開始次に、該当のサーバをクリックし、TPV画面を表示します。
上記画面で、選択されたサーバのパフォーマンス・データの表示と最新表示、ユーザー設定およびログ設定の変更、サマリー・レポートの表示、および特定のパフォーマンス・モジュールに関する情報の表示を行えます。
「ユーザー設定」では、データ収集のリフレッシュ速度やバッファー・サイズを調整できます。「ログ設定」では、ロギング期間、ファイルサイズ、ファイル名、ログ出力フォーマットなどを設定できます。「サマリー・レポート」では、「サーブレット」「EJB」「EJBメソッド」「接続プール」「スレッド・プール」に関する統計情報を表示します。「パフォーマンス・モジュール」では、表示したいモジュールを選択します。
図7 パフォーマンス・モジュールの表示PMIのデータをTPVで表示するには？
PMIのデータをTPVで表示する場合に、「現行アクティビティー」を表示する以外に、「ログの表示」という方法があります。リアルタイム・データを、ログ・ファイル内に保管する容易な方法を提供します。サーバの現行アクティビティーを表示中にロギングを開始および停止し、後からこのデータを再生できます。パフォーマンス・データのロギングは、適時にパフォーマンス・データを取り込むため、このデータを後で分析できます。
そのためには、まず始めに、WASで生成されるPMIパフォーマンス・データが特定の場所のログ・ファイルに保管されるように、TPVロギングを使用可能にします。サマリー・レポートまたはパフォーマンス・モジュールを表示した画面上で、「ロギング開始」をクリックします。以下のようなロギングが開始されたことを示すメッセージがコンソール上に表示されます。
図8 TPVログの開始「ロギング停止」をクリックして、ロギングを停止します。
図9 TPVログの停止その後、TPV の再生フィーチャーを使用して、リアルタイムで生成された順序とまったく同じ発生順で生成・取得されたパフォーマンス・データを表示できます。
WAS管理コンソールで、「モニターおよびチューニング」→「Performance Viewer」→「ログの表示」をクリックし、「Tivoli Performance Viewer」画面上の「ログ・データの表示」で、「ログ・ファイルの明示的パス」あるいは、「サーバー・ファイル」を選択し、保存されているログ・ファイルの場所を指定します。デフォルトでTPVログが保管されるローカルの場所は、「＜profile_root＞/logs/tpv」ディレクトリです。該当するログ・ファイル（デフォルトは、「tpv_＜server_name＞_xxxxxxxxxxxxx_y.zip」）を選択し、「ログの表示」をクリックします。
その後、サマリー・レポートやパフォーマンス・モジュールで表示したいモジュールを選択することにより、記録されたデータを再生できます。
「SIB Explorer」でメッセージ・キューをモニタリング
最後に、フリーにダウンロードして使用できるツ−ルを少しだけ紹介します。SIB（Service Integration Bus） Explorerと呼ばれるツールがあります。IBMのサイトから入手可能です。
このツールを使うことにより、JMSで使用するメッセージ・キューの使用状況を動的にモニターすることが可能です。それにより、キューにメッセージが逐次たまっていく様子などを発見できます。SIB Explorerを起動し、接続先のWASを指定します。接続が完了すると以下のような画面が表示されます。
「View」→「View System Objects」を選択することにより（左にチェックマークが付きます）、WASが自動生成するQueue Pointを表示します。
上記例の場合は、「TradeBrokerJSD」というQueue Pointが、管理者が設定したユーザーアプリケーション用のQueueで、それ以外の「_」（アンダースコア）で始まる名前のQueueはWASが内部で使用するSystem Objectです。また、定期的に最新情報を取得・表示するための設定が、「View」→「Auto Refresh」で指定できます。
モニタリングしていて、Current Depthの値が常に増加している場合には、Queueにメッセージが滞留していることを意味します（つまり、Message ProducerがQueueにメッセージを送信するレートが、Message ConsumerがQueueからメッセージを取り出すレートを、上回っているということになります）ので、Queueの設定調整を見直す必要があります。
また、「_SYSTEM.Exception.Destination.xxx」というQueue PointのCurrent Depthの値は、Exceptionが発生していることを意味しますので、パフォーマンス調整以外にも、エラー発生の原因解明・解決を行う必要があります。
実際にツールに触れて、使い方を体得しよう
このように、今回は、パフォーマンス・チューニングの必要性やパフォーマンス・チューニングを実施する前にやっておくべきこと、ツールの使い方といった内容に触れました。
誌面の都合上、残念ながら、TPVやSIB Explorerの使用方法について十分な情報を記載できませんでした。ビジュアルなツールですので、読者の皆さんご自身がTPVやSIB Explorerを試用して体験していただくことが多量のスクリーンキャプチャによる解説よりも効率よくご理解していただけると思います。ぜひ、試してみてください。ただし、PMIや要求メトリックを利用される際には、多少ですがパフォーマンス性能に影響を及ぼしますので、その点にご注意ください。
次回からは、WASの各種コンポーネントのチューニングについて解説をしていきます。その際にも、必要に応じて今回ご紹介したツールを用いて、具体的なチューニングを行う予定です。
関連URL
＠IT関連記事
WebSphereのインストールと動作確認
[連載]初めてのWebアプリケーション・サーバ（2）
だれでも1からWebアプリケーション・サーバを学べる基礎講座。今回はいよいよWASをインストールします
「Java Solution」フォーラム 2001/4/18
Linuxで動くJavaアプリケーションサーバ・カタログ
アプリケーションサーバは、いま最も開発競争が激しいジャンルの1つだ。その中から、Linuxに対応する5つの商用製品を紹介する。製品導入の際の参考にしてほしい
「Linux Square」フォーラム 2003/5/13
オープン化とミッションクリティカルの実現
[製品紹介] WebSphere V5.0 一層のオープン化が進められたWebSphereは、エンタープライズやWebサービスの本格的プラットフォームとして工夫も凝らされている
「Java Solution」フォーラム 2003/2/21
Javaパフォーマンスチューニング
JVMレベルにとどまらず、OSのカーネル・パラメータやネットワーク・パラメータのレベルでのチューニングを6回の連載で紹介する
第1回 Javaパフォーマンスチューニングのルール（2005/1/29）
第2回 Javaのガベージ・コレクションを知る（2005/2/25）
第3回 Javaのヒープ・メモリ管理の仕組み（2005/4/2）
第4回 Javaのマルチスレッドによるリソース競合から守る（2005/5/14）
第5回 Javaアプリのメモリ・リークを発見する（2005/5/24）
第6回 HotSpot VMの特性を知る（2005/8/31）
連載各回の解説はこちら
J2EEパフォーマンスチューニング
Webシステムをようやくカットオーバーしたものの、顧客からパフォーマンスが出ないというクレームを受けてしまった。そんなとき、システムを改善するために行うべき分析と、解決について連載します
第1回「システムが遅い！」その時どう取り組むか（2001/12/13）
第2回 パフォーマンスチューニングの定石を知る（2002/2/15）
第3回 APサーバのチューニングで性能を上げる（2002/3/30）
第4回 Webアプリケーションの高速化実験（2002/8/6）
連載各回の解説はこちら
プロフィール
日本アイ・ビー・エム 東京基礎研究所 アドバイザリー・リサーチャー
上野 憲一郎（うえの けんいちろう）
kenueno@jp.ibm.com
日本アイ・ビー・エムに入社後、システム・エンジニアとして10年ほど活動した後、米国IBMへ赴任。米国IBM Raleighソフトウェア開発研究所にて、WebSphere Application Server開発部門のパフォーマンス専門グループのメンバーとして活動。2003年に帰国後、IBM東京基礎研究所にて、XML、Web サービス、SOA関連技術の研究開発に従事。WebSphere Application Serverパフォーマンス専門家として、セミナーなどで講演も実施。
主な著書
「WebSphere V3.5 Handbook」（Prentice Hall）
主な訳書
「Webサービスプラットフォームアーキテクチャ」（エスアイビーアクセス）
Copyright © ITmedia, Inc. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。