ボトルネックが特定できる! 〜 パフォーマンスモニタの見極めポイント
パフォーマンスモニタ徹底攻略マニュアル[Part 2]Part 1でパフォーマンスモニタとデータコレクタの利用方法が確認できたら、実際にパフォーマンスを測定してみよう。Part 2では、主にハードウェア・コンポーネントを対象としたパフォーマンスの解析ポイントを紹介する。ポイントごとに確認すれば、原因を特定できなかったパフォーマンスの問題も解決できるだろう。
ベースライン測定のススメ
パフォーマンスの計測には、問題があるときに測定して、問題の原因を探る方法もある。しかし、正常な状態のときにも測定しておけば比較することができ、問題の原因を特定しやすくなる。このようなサーバのパフォーマンスの基本となる状態を「ベースライン」と呼ぶ。パフォーマンス測定によるトラブルシューティングを行うときにはぜひとも持っておきたい情報だ。
ベースラインの測定ポイント
ベースラインは、システムが正常な状態にあるときのパフォーマンスデータである。そのため、パフォーマンス上のトラブルが発生する前に測定しておかなければならない。具体的には、次のようなタイミングである。あらかじめベースラインを取得しておけば、パフォーマンスの問題が発生したときに、原因を特定しやすくなる。
■実装直後
OSやアプリケーション、サービスなどをインストールした直後にパフォーマンスを測定することで、初期状態のパフォーマンスが保存できる。パフォーマンス上のトラブルが発生したときには、初期状態と比べてどのようなパフォーマンスの変化があったのかを確認することで、問題の早期解決に役立つだろう。
■一般的な利用時
サービスのアクティビティに沿って、パフォーマンスを測定する。例えば、サーバのサービスの1日の利用状況は、アクセスが集中するときや平均的なとき、閑散時などに分けられる。これらの時間帯ごとにパフォーマンスを測定すれば、トラブルの発生時に、発生した時間帯によって比較するデータを変えることができる。
■テスト環境
アプリケーションやサービスの実装前に、テスト用のシステム環境を構築し、パフォーマンステストを行う。例えば、想定されるクライアント数でのパフォーマンスをテストして、その結果をベースラインとして保存する。テスト結果のデータがあれば、実環境で負担がかかるパフォーマンス測定をわざわざ行わずに済む。
例えば、「以前と比べると、サーバの処理が遅いようだ」という報告を受けたとしよう。管理者はパフォーマンスコンソールを使って現在の状態を計測し、あらかじめ測定したベースラインのデータと比較する(画面7-1、7-2)。利用可能なメモリ領域(「Memory」オブジェクトの「Available Mbytes」カウンタ)について、ベースライン(画面7-1)ではほとんど一定の線を描いているのに対し、処理が遅いときはグラフが右下がりである(利用可能なメモリ領域が徐々に減っている)ことがわかる(画面7-2)。
この結果から判断して、メモリリークが発生していることが想定できる。もちろん、右のグラフだけで判断することもできるが、ベースラインと比較してみることにより、問題の原因を、より鮮明に把握できる。





.gif)






























