Use PerfMon to Diagnose Common Server Performance Problems

[アーティクル]
08/24/2016

Windows の管理

サーバーのパフォーマンスを測定する

Steven Choy

概要 :

パフォーマンスモニタをカスタマイズする
測定する内容と頻度に関するガイダンス
重要なカウンタと予期される値の概要

パフォーマンスモニタにアクセスするには、コマンドプロンプトで「perfmon」と入力するか、[管理ツール] メニューの [パフォーマンス] (Windows Vista® または Windows Server® 2008 の場合は [信頼性とパフォーマンスモニタ]) を選択します。監視するパフォーマンスカウンタとオブジェクトを追加するには、単純にプラス記号をクリックし、多数の選択肢から選択します。

では、どのようにしてサーバーのパフォーマンスを測定すればよいでしょうか。60 個を超える基本的なパフォーマンスオブジェクトが提供されており、各オブジェクトには複数のカウンタが含まれています。この記事では、サーバーのパフォーマンスを示すカウンタについて、およびマイクロソフトのサービスサポート部門に所属するエンジニアがパフォーマンスに関する問題のトラブルシューティングに最もよく使用する標準的なサンプリング間隔について説明します。

トラブルシューティングを行うときには、ベースラインによって重要な基準点が提供されることは言うまでもありません。サーバーの負荷はビジネス要件によって異なり、ビジネスサイクルによって変化することもあるので、特定期間の標準的なワークロードに基づいてベースラインを確立することが重要です。このベースラインを使用することによって、変更を監視し、傾向を特定できます。

結果を見やすくする

サーバーのパフォーマンスを表すカウンタの分析について詳しく説明する前に、パフォーマンスモニタを使用してサーバーのパフォーマンスを測定する作業を容易にする 2 つのテクニックについて説明します。これら 2 つのテクニックは Windows Vista と Windows Server 2008 では不要ですが、以前のバージョンの Windows でパフォーマンスモニタを実行する場合は非常に役立ちます。

まず、グラフィカルなビューの傾向線を見えにくくする、紛らわしい不要なサンプル表示を無効にします。Windows Vista と Windows Server 2008 のパフォーマンスモニタでは、最大 1,000 個のデータポイントをグラフィカルなビューに表示できます。以前のバージョンの Windows では、表示できるデータポイントが 100 個に制限されています。データポイントの数が 100 個を超えると、表示上データポイント間で値が急激に変化します。このような場合、サンプルポイントの最小値、平均値、および最大値が同じように垂直線で表されます。

図 1 のグラフからわかるように、同時に表示されるデータの量が多すぎると、傾向線を見分けるのは困難です。図 2 のグラフは、余分な情報を非表示にすることによって、データをどれだけ確認しやすくなるかを示しています。急激な変化を示す垂直線を非表示にする方法の詳細については、サポート技術情報の資料 (support.microsoft.com/kb/283110) を参照してください。

図 1 コンマ区切りを使用せずに紛らわしい垂直線で表されたパフォーマンスデータ (画像をクリックすると拡大表示されます)

図 2 コンマ区切りを使用したわかりやすいデータ表示 (画像をクリックすると拡大表示されます)

もう 1 つのテクニックは、数値にコンマ区切りを追加して、カウンタに表示される値を見やすくすることです。Windows Vista と Windows Server 2008 では、既定でコンマ区切りが有効になっています。一方、以前のバージョンの Windows のパフォーマンスモニタでは、コンマ区切りが既定で有効になっていません。

これは、あまり大きな違いを生まないと思うかもしれませんが、図 1 を見てください。この図は、コンマ区切りを使用していないパフォーマンスカウンタを示しています。これに対して、図 2 はコンマ区切りを使用したパフォーマンスカウンタを示しています。後者の方が見やすいことは明らかです。Windows XP でパフォーマンスカウンタにコンマ区切りを追加する簡単な手順については、サポート技術情報の記事 (support.microsoft.com/kb/300884) を参照してください。

測定する内容とタイミング

ボトルネックは、リソースが処理能力の限度近くまで使用された場合に発生し、システム全体のパフォーマンスを低下させます。一般的に、ボトルネックは、リソースの不足や誤った構成、正常に機能しないコンポーネント、およびプログラムによる適切でないリソース要求が原因で発生します。

ボトルネックを引き起こし、サーバーのパフォーマンスに影響を与える可能性のある主なリソース領域は 5 つあります。これらは、物理ディスク、メモリ、プロセス、CPU、およびネットワークです。いずれかのリソースが過剰に使用されると、サーバーやアプリケーションの処理速度が著しく低下したり、これらがクラッシュしたりする可能性があります。ここでは、これら 5 つの領域について説明すると共に、使用した方がよいカウンタに関するガイダンス、およびサーバーのパフォーマンスを測定するときに使用するしきい値の候補を提供します。

サンプリング間隔はログファイルのサイズやサーバーの負荷に大きな影響を与えるため、問題が発生するまでの平均経過時間に基づいてサンプリング間隔を設定し、問題が再度発生する前にベースラインを確立できるようにする必要があります。これにより、問題の原因となる傾向を突き止めることができます。

通常の運用時、ベースラインを確立するための適切なサンプリング間隔は 15 分です。問題が発生するまでの平均経過時間が約 4 時間の場合は、サンプリング間隔を 15 秒に設定します。問題が発生するまでの時間が 8 時間以上の場合は、サンプリング間隔を 5 分以上に設定します。そうしなかった場合、最終的にログファイルのサイズが非常に大きくなり、データの分析が困難になります。

ハードディスクのボトルネック

ディスクシステムではサーバー上のプログラムとデータが保存および処理されるため、ディスクの使用量と処理速度に影響するボトルネックは、サーバーの全体的なパフォーマンスに大きな影響を与えます。

ディスクオブジェクトがサーバー上で有効になっていない場合は、Diskperf コマンドラインツールを使用してディスクオブジェクトを有効にする必要があります。また、% Disk Time は 100% を超える可能性があるため、ハードディスクの使用率がより正確にわかるように、% Idle Time、Avg. Disk sec/Read、および Avg. Disk sec/write を使用します。% Disk Time の詳細については、サポート技術情報の資料 (support.microsoft.com/kb/310067) を参照してください。

マイクロソフトのサービスサポート部門のエンジニアがディスクの監視に使用するカウンタを次に示します。

LogicalDisk\% Free Space 選択した論理ディスクドライブ上の空き領域の割合を測定します。この値が 15% を下回る場合は、OS が重要なファイルを格納するための空き領域が不足している可能性があります。当然この場合の解決策は、ディスク領域を追加することです。

PhysicalDisk\% Idle Time サンプリング間隔中にディスクがアイドル状態であった時間の割合を測定します。このカウンタの値が 20% を下回る場合、ディスクシステムの使用率は非常に高いと言えます。現在のディスクシステムを処理速度の速いディスクシステムに交換することを検討してください。

PhysicalDisk\Avg.Disk Sec/Read ディスクからのデータの読み取りにかかる平均時間 (秒単位) を測定します。この値が 25 ミリ秒を超える場合、ディスクシステムがディスクからデータを読み取るときに待ち時間が発生しています。SQL Server® や Exchange Server をホストするミッションクリティカルなサーバーでは、許容可能なしきい値が約 10 ミリ秒と非常に小さくなります。この場合、論理上最も適切な解決策は、現在のディスクシステムを処理速度の速いディスクシステムに交換することです。

PhysicalDisk\Avg.Disk Sec/Write ディスクへのデータの書き込みにかかる平均時間 (秒単位) を測定します。この値が 25 ミリ秒を超える場合、ディスクシステムがディスクにデータを書き込むときに待ち時間が発生しています。SQL Server や Exchange Server をホストするミッションクリティカルなサーバーでは、許容可能なしきい値が約 10 ミリ秒と非常に小さくなります。この場合、考えられる解決策は、現在のディスクシステムを処理速度の速いディスクシステムに交換することです。

PhysicalDisk\Avg.Disk Queue Length ハードドライブが使用可能になるのを待機している I/O 操作の数を示します。この値がスピンドルの 2 倍より大きい場合は、ディスク自体がボトルネックになっている可能性があります。

Memory\Cache Bytes ファイルシステムキャッシュに使用されているメモリの量を示します。この値が 200 MB を超える場合は、ディスクがボトルネックになっている可能性があります。

メモリのボトルネック

一般的に、メモリ不足の原因は、不十分な RAM、メモリリーク、および boot.ini 内に配置されたメモリスイッチです。メモリに関するカウンタの説明を始める前に、/3GB スイッチについて説明します。

メモリが増加すると、ディスク I/O 操作の回数が減少し、さらにアプリケーションのパフォーマンスが向上します。/3GB スイッチは、より多くのメモリをユーザーモードのプログラムに提供する方法として、Windows NT® で導入されました。

Windows では、(システムに搭載された物理 RAM の量に関係なく) 4 GB の仮想アドレス空間が使用されます。既定では、下位の 2 GB はユーザーモードのプログラム用に予約され、上位の 2 GB はカーネルモードのプログラム用に予約されます。/3GB スイッチを使用すると、ユーザーモードのプロセスに 3 GB が提供されます。当然ながら、この結果カーネルメモリが犠牲となり、その仮想アドレス空間は 1 GB のみになります。つまり、Pool NonPaged Bytes、Pool Paged Bytes、Free System Page Tables Entries、およびデスクトップヒープがすべてこの 1 GB の空間に詰め込まれるため、問題が発生する可能性があります。このため、/3GB スイッチを使用する前に、各自の環境で徹底的にテストを行うようにしてください。

上記はメモリに関連するボトルネックが発生している疑いがある場合の検討事項です。/3GB スイッチが問題の原因でない場合は、次のカウンタを使用して、メモリの潜在的なボトルネックを診断します。

Memory\% Committed Bytes in Use Commit Limit に対する Committed Bytes の割合 (つまり、使用されている仮想メモリの量) を測定します。この値が 80% を超える場合は、メモリが不足しています。この場合の解決策は、当然メモリを追加することです。

Memory\% Available Mbytes 実行中のプロセスに使用できる物理メモリのサイズ (MB 単位) を測定します。この値が物理 RAM 全体の 5% を下回る場合は、メモリが不足しているため、ページング操作の回数が増加する可能性があります。この問題を解決するには、単純にメモリを追加します。

Memory\Free System Page Table Entries システムによって現在使用されていないページテーブルエントリの数を示します。この値が 5,000 を下回る場合は、メモリリークが発生している可能性があります。

Memory\Pool NonPaged Bytes 非ページプールのサイズ (バイト単位) を測定します。これは、ディスクに書き込むことはできないが、割り当てられている間は物理メモリ内に存在するオブジェクト用のシステムメモリ領域です。この値が 175 MB (/3GB スイッチの使用時は 100 MB) を超える場合は、メモリリークが発生している可能性があります。システムイベントログには、一般的なイベント ID 2019 が記録されます。

Memory\Pool Paged Bytes ページプールのサイズ (バイト単位) を測定します。これは、使用されていないときにディスクに書き込むことができるオブジェクト用のシステムメモリ領域です。この値が 250 MB (/3GB スイッチの使用時は 170 MB) を超える場合は、メモリリークが発生している可能性があります。システムイベントログには、一般的なイベント ID 2020 が記録されます。

Memory\Pages per Second ハードページフォールトを解決するためにディスクから読み取られた、またはディスクに書き込まれたページの数を測定します。この値が 1,000 を超える場合は、ページングが過剰に発生し、それによってメモリリークが発生している可能性があります。

プロセッサのボトルネック

プロセッサに負荷がかかる原因としては、プロセッサ自体の処理能力が不十分であることや、アプリケーションの処理が効率的でないことが考えられます。物理メモリの不足が原因でプロセッサのページング操作が大量に発生していないかどうかを再確認する必要があります。マイクロソフトのサービスサポート部門のエンジニアは、次のカウンタを使用して、プロセッサの潜在的なボトルネックを調査します。

Processor\% Processor Time プロセッサがアイドル状態でないスレッドを実行した時間の割合を測定します。この割合が 85% を超える場合は、プロセッサに負荷がかかっており、より処理速度の速いプロセッサをサーバーで使用することが必要になる場合があります。

Processor\% User Time プロセッサがユーザーモードのプログラムを実行した時間の割合を測定します。この値が大きい場合、サーバーのリソースはアプリケーションに占有されています。この場合に考えられる解決策の 1 つは、プロセッサリソースを占有しているアプリケーションを最適化することです。

Processor\% Interrupt Time 特定のサンプリング間隔中にプロセッサがハードウェア割り込みを受け取って処理した時間の割合を測定します。このカウンタの値が 15% を超える場合、ハードウェアに関する問題が発生している可能性があります。

System\Processor Queue Length プロセッサキューに格納されているスレッドの数を示します。この値が長時間にわたって CPU 数の 2 倍を超える場合は、サーバーで使用されているプロセッサの処理能力が十分ではありません。

ネットワークのボトルネック

当然ながら、ネットワークのボトルネックは、サーバーがネットワーク経由でデータを送受信する機能に影響を与えます。この場合、サーバーで使用されているネットワークカードに問題があるか、おそらくネットワークが飽和状態になっており、ネットワークのセグメント化が必要です。ネットワークの潜在的なボトルネックを診断するには、次のカウンタを使用します。

Network Interface\Bytes Total/Sec 各ネットワークアダプタ経由で送受信されるバイト (フレーム文字を含む) の割合を測定します。インターフェイスの 70% を超える部分が使用されている場合、ネットワークは飽和状態になっています。100 Mbps の NIC の場合、使用されるインターフェイスは 8.7 MB/sec (100 Mbps = 100000 kbps = 12.5 MB/sec x 70%) です。このような場合は、処理速度の速いネットワークカードを追加するか、ネットワークをセグメント化してください。

Network Interface\Output Queue Length 送信パケットが格納されるキューの長さをパケット単位で測定します。この値が 2 を超える場合、ネットワークは飽和状態になっています。この問題を解決するには、処理速度の速いネットワークカードを追加するか、ネットワークをセグメント化します。

プロセスのボトルネック

プロセスの動作が適切でない場合やプロセスが最適化されていない場合、サーバーのパフォーマンスは大幅に低下します。スレッドリークやハンドルリークが発生すると、最終的にサーバーがダウンすることになります。また、プロセッサの使用率が大幅に上昇した場合、サーバーのパフォーマンスが低下します。プロセス関連のボトルネックを診断する場合は、次のカウンタが必要不可欠です。

Process\Handle Count プロセスによって現在開かれているハンドルの合計数を測定します。このカウンタの値が 10,000 を超える場合、ハンドルリークが発生している可能性があります。

Process\Thread Count プロセス内で現在アクティブなスレッドの数を測定します。この値がスレッドの最小数と最大数の間で 500 を超える場合、スレッドリークが発生している可能性があります。

Process\Private Bytes このプロセスに割り当てられており、他のプロセスと共有できないメモリの量を示します。この値がスレッドの最小数と最大数の間で 250 を超える場合、メモリリークが発生している可能性があります。

まとめ

この記事では、マイクロソフトのサービスサポート部門のエンジニアがさまざまなボトルネックを診断する際に使用するカウンタについて説明しました。当然ながら、ほとんどの場合は、使用する一連のカウンタを特定の要件に合わせて選択することになるでしょう。サーバーを監視するたびに一連のカウンタをすべて手動で追加する必要がなければ、時間を節約できると思います。さいわい、パフォーマンスモニタでは、選択した一連のカウンタを後で使用するために、テンプレートに保存できるオプションが用意されています。

パフォーマンスモニタをローカルとリモートのどちらで実行すればよいか、まだ疑問に思っているのではないでしょうか。パフォーマンスモニタをローカルで実行した場合のパフォーマンスへの影響は、環境によって異なります。サーバー上でパフォーマンスモニタを実行する場合でも、間隔を 5 分以上に設定すれば、パフォーマンスへの影響はほとんどありません。

サーバー上でパフォーマンスモニタを実行するとパフォーマンスが低下することを把握している場合は、パフォーマンスモニタをローカルで実行した方がよいでしょう。サーバー上のリソースが不足していると、パフォーマンスモニタはリモートコンピュータからデータをキャプチャできない可能性があります。複数のサーバーを監視したり、それらのサーバーをベースラインとして使用する場合は、パフォーマンスモニタを集中管理用のコンピュータからリモートで実行する方法が適しています。

Steven Choy は、マイクロソフトのプレミアフィールドエンジニアリング部門でシニアプレミアフィールドエンジニアを務めています。彼は、政府機関や民間の顧客を対象に、デスクトップの展開と移行、修正プログラムの管理、およびグループポリシーに関するプロジェクトをサポートしてきました。現在は、サーバーの仮想化とサーバーの正常性に関する業務に携わっています。

目次

その他のリソース