共通のカウンタの監視
適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1
トピックの最終更新日: 2008-11-03
ここでは、すべての Microsoft Exchange Server 2007 サーバーの役割に共通するパフォーマンス カウンタを監視するのに最も役立つガイダンスを示します。Exchange 2007 サーバーを監視する場合、どのパフォーマンスの要素が最も重要なのかを把握しておく必要があります。ここで詳細を示す共通のカウンタとしきい値を使用することにより、可能性のある問題を予防的に識別し、トラブルシューティングの際に問題の根本原因を特定することができます。
一般的に、サーバーがプロセッサ限度に達していることを識別するのは簡単です。次の表に一覧で示すカウンタを使用して、プロセッサに競合が存在するかどうかを判断します。
| カウンタ | 予期される値 |
|---|---|
Processor(_Total)\% Processor Time プロセッサがアプリケーションまたはオペレーティング システム プロセスを実行している時間の割合を示します。これはプロセッサがアイドル状態ではない時間です。 |
平均 75% 未満である必要があります。 |
Processor(_Total)\% User Time ユーザー モードで経過したプロセッサ時間の割合を示します。 ユーザー モードは、アプリケーション、環境サブシステム、および統合サブシステム向けに設計された制限付きの処理モードです。 |
75% 未満を保つ必要があります。 |
Processor(_Total)\% Privileged Time 特権モードで経過したプロセッサ時間の割合を示します。特権モードは、オペレーティング システム コンポーネントとハードウェアを操作するドライバ向けに設計された処理モードです。このモードでは、ハードウェアとすべてのメモリへの直接アクセスが可能です。 |
75% 未満を保つ必要があります。 |
Process(*)\% Processor Time すべてのプロセスのスレッドが命令を実行するために費やしたプロセッサ時間の割合を示します。命令はコンピュータ内の基本の実行単位、スレッドは命令を実行するオブジェクト、そしてプロセスはプログラム実行時に作成されるオブジェクトです。一部のハードウェア割り込みやトラップ条件を処理するために実行されるコードもこのカウントに含まれます。 プロセッサ時間の合計値が高い場合は、このカウンタを使用して、高い CPU 使用率の原因となっているプロセスを判断します。 |
該当なし。 |
System\Processor Queue Length (all instances) 各プロセッサが処理しているスレッドの数を示します。 Processor Queue Length は、プロセッサの処理能力が不十分であるために割り当てられた負荷を処理できないことが原因で、プロセッサの競合または高い CPU 使用率が生じていないかどうかを判断するのに使用できます。また、Processor Queue Length は、Processor Ready Queue で遅延が生じ、実行対象としてスケジュールされるのを待っているスレッド数を示します。一覧表示される値は、測定が行われた時点での最新の観測値です。 単一プロセッサのコンピュータで、キューの長さが 5 より大きくなっている場合、プロセッサが直ちに処理できる量よりも多くの処理が頻繁に利用可能な状態になっているという警告になります。この数が 10 より大きい場合 (特に、高い CPU 使用率を伴っている場合)、プロセッサが処理能力いっぱいになっているという強力な指標となります。 マルチプロセッサのシステムでは、キューの長さを物理プロセッサ数で割ります。ハード プロセッサの類似性を使用して構成されたマルチプロセッサ システム (プロセッサは特定の CPU コアに割り当てられます) で、キューの長さの値が大きくなっている場合、構成が不均衡であることを示している可能性があります。 通常、Processor Queue Length は容量計画のために使用されることはありませんが、環境内のシステムで負荷を実行できるかどうか、または今後のサーバー用に追加のプロセッサまたはより高速なプロセッサを購入する必要があるかどうかを判断するために使用できます。 |
プロセッサごとに 5 を超えない必要があります。 |
Exchange 2007 は、動作方法にさまざまな変更が加えられているため、Exchange Server 2003 よりも多くのメモリを使用します。Exchange 2003 は、4 GB の物理メモリにしか対応できません。また、ページ プールおよび非ページ プール メモリなど、オペレーティング システムにはその他の制限があります。これは、オペレーティング システム カーネルに多くの点で影響を及ぼします。ストア プロセスが消費するメモリ量を制限するのに役立つ、インフォメーション ストアのデータベース キャッシュ サイズ全体に関する制限もあります。
64 ビット プラットフォームで実行される Exchange 2007 の場合、これらの制限のほとんどが除外されます。Exchange 2007 は、特定のサーバーにインストールされている RAM の最大容量まで処理することができます。サーバー上のメモリの量が多くなると、インフォメーション ストア プロセスが全体的に消費したり、キャッシュしたりする量も多くなります。主な利点は、特定のデータを読み取ったり書き込んだりするためにディスクを操作するのではなく、ストア キャッシュ内のデータを再利用して、メモリ内でより多くの操作が実行されることです。Extensible Storage Engine (ESE) データベース キャッシュ、および Exchange 2007 と Exchange 2003 の違いの詳細については、「Exchange 2007 の ESE データベース キャッシュ サイズ」を参照してください。Exchange 2007 用のメモリ構成の計画に関する詳細なガイドラインについては、「メモリの構成の計画」を参照してください。
次の表に一覧で示すカウンタを使用して、メモリに関する問題が存在するかどうかを判断します。
| カウンタ | 予期される値 |
|---|---|
Memory\Available Mbytes プロセスに割り当てるかシステムで使用するのに直ちに利用可能な、物理メモリの量を MB 単位で示します。これは、スタンバイ (キャッシュ済み)、空き、ゼロ ページの一覧に割り当てられているメモリの合計と等しくなります。メモリ マネージャに関する詳細な説明については、MSDN または『Windows Server 2003 リソース キット』の「システム パフォーマンスとトラブルシューティング ガイド」を参照してください。 |
常に 100 MB を上回っている必要があります。 |
Memory\Pool Nonpaged Bytes 常に物理メモリ内に存在することを保証されているシステム仮想アドレスで構成されるため、ページング入出力 (I/O) を発生させることなく、任意のアドレス スペースからアクセスできます。ページ プールと同様に、非ページ プールはシステムの初期化中に作成され、システム メモリを割り当てるためにカーネル モード コンポーネントによって使用されます。 通常、各 TCP 接続は非ページ メモリを消費するため、接続数が非常に高い値にならない限り参照されません。 |
該当なし。 |
Memory\Pool Paged Bytes ディスク ページング ファイルにページングできる、共有システム メモリの部分を示します。ページ プールは、システムの初期化中に作成され、システム メモリを割り当てるためにカーネル モード コンポーネントによって使用されます。 メモリ リークの可能性を示す、プール ページ バイトの増加を監視します。 |
該当なし。 |
Memory\Cache Bytes ファイル システム キャッシュの現在のサイズをバイト単位で示します。既定では、キャッシュは最大で利用可能な物理メモリの 50% を使用します。カウンタ値は、Memory\System Cache Resident Bytes、Memory\System Driver Resident Bytes、Memory\System Code Resident Bytes、および Memory\Pool Paged Resident Bytes の合計です。 アプリケーションがメモリ使用量をキャッシュした後は安定した状態になる必要があります。ワーキング セット トリミングや過度なページングを原因とする、このカウンタの大幅な低下を確認します。 コンテンツ インデックス カタログと連続レプリケーション ログのコピーによって使用されます。 |
該当なし。 |
Memory\Committed Bytes コミットされた仮想メモリの量をバイト単位で示します。コミットされたメモリは、領域がディスク ページング ファイルで予約されている物理メモリです。各物理ドライブにはページング ファイルを 1 つ以上置くことができます。このカウンタは、平均値ではなく最新の観測値のみを表示します。 使用中のコミットされたバイトの量を判断します。 |
該当なし。 |
Memory\%Committed Bytes in Use Memory\Committed Bytes の Memory\Commit Limit に対する割合を示します。コミットされたメモリは、ディスクに書き込む必要のあるページング ファイルで領域が予約されている、使用中の物理メモリです。Commit Limit はページング ファイルのサイズにより決定されます。ページング ファイルが拡張されると、Commit Limit も増え、割合は低くなります。このカウンタは、平均値ではなく現在の値のみを割合で表示します。 この値が非常に高い (90% を上回る) 場合、コミット エラーが発生する可能性があります。これは、システムでメモリの圧迫が生じていることを明らかに示しています。 |
該当なし。 |
サーバーが高い負荷の下にあるか、メモリの制限がある場合、オペレーティング システムはメモリ ブロックのページ アウトを開始するか、現在要求しているプロセスが、要求中のタスクを完了するのに十分なメモリを確保できるようにページング ファイルに対してページングできます。ある処理がメモリ内のページを要求し、要求された場所でこのページが見つからない場合、ページ フォールトが発生します。これは、ハード ページ フォールトと呼ばれます。ページがメモリの別の場所で見つかった場合、これはソフト ページ フォールトと呼ばれます。ほとんどのプロセッサは、ソフト ページ フォールトを処理可能で、パフォーマンス上の問題にはなりません。以前にページ アウトしたメモリ ブロックがアプリケーションまたはプロセスによって要求された場合、このメモリはメモリ キャッシュに移行し直す必要があります。このプロセスは、全体的なプロセッサ時間を消費する、ページング ファイルとの間でより多くのデータが読み取られたり書き込まれたりするため、サーバーの全体的なパフォーマンスに悪影響を及ぼす可能性があります。
次の表に一覧で示すカウンタを使用して、ページング ファイルの問題が存在するかどうかを判断します。
| カウンタ | 予期される値 |
|---|---|
Memory->Transition Pages Repurposed/sec システム キャッシュの圧迫を示します。 |
平均 100 未満である必要があります。 スパイクは 1,000 未満である必要があります。 |
Memory\Page Reads/sec メモリではなく、ディスクからデータを読み取る必要があることを示します。メモリ不足であり、ページングが開始されていることを示します。1 秒あたりの値が 30 を上回っている場合、サーバーが負荷に対応できなくなっていることを示します。 |
平均 100 未満である必要があります。 |
Memory\Pages/Sec ハード ページ フォールトを解決するためにディスクからページを読み取るか、ディスクにページを書き込む速度を示します。このカウンタは、システム全体の遅延を引き起こす種類のフォールトの主な指標です。これは Memory\Pages Input/sec と Memory\Pages Output/sec の合計です。ページの数がカウントされるので、変換せずに Memory\Page Faults/sec などの他のページ カウントと比較できます。(通常、アプリケーションが要求する) ファイル システム キャッシュ内および非キャッシュのマップされたメモリ ファイル内のフォールトを解決するために取得されたページが含まれます。 Pages/sec カウンタによって返される値は、予想した値を上回っている場合があります。これらの値は、ページング ファイル処理ともキャッシュ処理とも関連がない可能性があります。代わりに、これらの値は、メモリにマップされたファイルを順次読み取るアプリケーションによって生じる可能性があります。 Memory\Pages Input/sec と Memory\Pages Output/sec を使用してページ ファイル I/O を判断します。 |
平均で 1,000 未満である必要があります。 |
Memory\Pages Input/sec ハード ページ フォールトを解決するためにディスクからページを読み取る速度を示します。ワーキング セット内にないか、物理メモリのどこかにある仮想メモリ内のページをプロセスが参照すると、ハード ページ フォールトが発生し、ディスクから取得しなければならなくなります。ページ フォールトが発生すると、システムは読み取り操作の利点を最大限に高めるために、複数の連続したページをメモリに読み取ろうとします。Memory\Pages Input/sec の値と Memory\Page Reads/sec の値を比較して、それぞれの読み取り操作時にメモリに読み取られた平均ページ数を確認します。 |
平均で 1,000 未満である必要があります。 |
Memory\Pages Output/sec 物理メモリ内の領域を解放するためにページがディスクに書き込まれた速度を示します。ページは、物理メモリ内で変更された場合にのみディスクに書き戻されるので、コードではなくデータを保持します。高いページ出力率は、メモリ不足を示している場合があります。物理メモリが不足している場合、Microsoft Windows はメモリ領域を解放するためにさらにページをディスクに書き戻します。このカウンタはページ数を示すので、変換せずに他のページ カウントと比較できます。 |
平均で 1,000 未満である必要があります。 |
すべてのアプリケーションとサービスはシステム上でプロセスとして実行されるため、異常なメモリやプロセッサ消費についてこれらのプロセスを監視することは非常に重要です。次の表 (および後の 2 つのセクション) に一覧で示すカウンタを使用すると、システム リソースを独占する可能性のあるプロセスを切り離すのに役立ちます。
| カウンタ | 予期される値 |
|---|---|
Process(*)\Private Bytes 他のプロセスと共有できない、このプロセスに割り当てられている現在のバイト数を示します。 このカウンタを使用して、プロセスに対するメモリ リークがないかどうかを判断できます。 インフォメーション ストア プロセスについて、このカウンタ値をデータベース キャッシュ サイズと比較して、インフォメーション ストア プロセスでメモリ リークが発生していないかどうかを判断します。インフォメーション ストア プライベート バイトが増加し、データベース キャッシュでも同様の増加が見られる場合、正しく動作しています (メモリ リークではありません)。 |
該当なし。 |
Process(*)\Virtual Bytes プロセスが現在消費している仮想アドレス領域の量をバイト単位で表します。 プロセスが大量の仮想メモリを消費していないかどうかを判断するために使用します。 |
該当なし。 |
このカウンタは、追加のメモリを消費し、通常のパフォーマンスの低下を引き起こすワーキング セットがプロセスで増加していないかどうかを判断するのに役立ちます。
| カウンタ | 予期される値 |
|---|---|
Process(_Total)\Working Set このプロセスのワーキング セットの現在のサイズをバイト単位で示します。ワーキング セットは、プロセスのスレッドが最後に参照したメモリ ページのセットです。コンピュータの空きメモリ領域がしきい値よりも大きい場合、ページが使用中でなくてもプロセスのワーキング セットに残されます。空きメモリ領域がしきい値を下回ると、ページはワーキング セットから削除されます。削除されたページが必要な場合、このページはメイン メモリから出される前にワーキング セットに戻されます。 ワーキング セットの大幅な増加や減少により、ページングが発生します。 ページング ファイルが推奨値である RAM + 10 に設定されていることを確認します。ワーキング セットが削除されている場合、Process(*)\Working set を追加して、どのプロセスが影響を受けているのかを確認します。このカウンタは、システム全体の問題またはプロセス全体の問題のいずれかを示している場合があります。このカウンタを Memory\System Cache Resident Bytes と相互参照して、システム全体のワーキング セット トリミングが発生しているかどうかを判断します。 |
該当なし。 |
このカウンタは、追加のメモリを消費し、通常のパフォーマンスの低下を引き起こすハンドルの数がプロセスで増加していないかどうかを判断するのに役立ちます。
| カウンタ | 予期される値 |
|---|---|
Process(*)\Handle Count このプロセスによって現在開かれているハンドルの総数を示します。この数は、このプロセスの各スレッドによって現在開かれているハンドルの合計です。 特定のプロセスのハンドルの数が増加している場合、サーバー上でパフォーマンスの問題を引き起こす、ハンドル リークによるプロセスの問題の兆候がある可能性があります。これは必ずしも問題とは限りませんが、長期にわたって監視し、ハンドル リークが発生していないかどうかを判断する必要があります。 |
該当なし。 |
Microsoft .NET Framework は、Exchange 2007 の不可欠な要素です。ほとんどの Exchange 2007 コンポーネントは、マネージ コード内でこのフレームワークに基づいて完全に書き換えられます。マネージ コードは、リアルタイムでアプリケーションをコンパイルする機能など、アンマネージ コードよりも大きな利点があります。このため、異なるアーキテクチャまたはプラットフォーム上でアプリケーションを実行することを心配する必要はありません。マネージ コードは、メモリを効率的に管理する機能も提供します。Microsoft .NET 接続ソフトウェアでは、共通言語ランタイム (CLR) を使用して、同じランタイムを共有しているために、さまざまな言語で簡単にコーディングを行うことができます。ランタイムを対象とする言語コンパイラを使用して開発したコードは、マネージ コードと呼ばれます。これについては、「Common Language Runtime Overview」 (英語) で説明されています。
リアルタイムでのアプリケーションの構築またはコンパイルには、このコンパイルの実行時における高いパフォーマンスなどの利点があります。Exchange のインストール処理中に、Exchange コンポーネントがプリコンパイルされるため、インストール時間が大幅に長くなります。ただし、その結果、初回の読み込み時間がはるかに短くなるため、サーバー上のパフォーマンスは向上します。これらのバイナリは、コンパイル後に、ローカル コンピュータ上のグローバル アセンブリ キャッシュ (GAC) に格納されます。このプリコンパイル処理は NGEN と呼ばれます。NGEN の詳細については、「Native Image Generator (Ngen.exe)」 (英語) を参照してください。
Exchange 2007 には、Windows カーネルと .NET CLR メモリ管理など、その他の依存関係があります。これは、監視する必要のある Exchange のより重要な側面の 1 つです。メモリが正しく管理されていないか、過度に断片化されている場合、過度なページングが発生する可能性があります。これにより、処理能力の望ましくない増大が引き起こされ、全体的なクライアントの遅延に多大な影響が及ぶ場合があります。
次の表に示すカウンタを監視することは、管理されているアプリケーションが過度なガーベジ コレクションを生じさせていないかどうかを判断するのに役立ちます。ガーベジ コレクションは、基本的に、CLR 内で使用されなくなったオブジェクトのメモリを解放する方法です。長期間にわたって大量のメモリを解放する必要がある場合、メモリの制限が生じる可能性があります。これは、サーバー上で十分なメモリが利用できないか、メモリ リークが原因で割り当て分以上のメモリをアプリケーションが消費するためです。CLR のメモリの自動管理の詳細については、「Automatic Memory Management」 (英語) を参照してください。
次の表に一覧で示すカウンタを使用すると, .NET Framework の基本的な問題を特定するのに役立ちます。
| カウンタ | 予期される値 |
|---|---|
.NET CLR Memory(*)\% Time in GC ガーベジ コレクションが発生した時間を示します。カウンタがしきい値を超えた場合、CPU がクリーンアップされ、負荷に対して効率的に使用されていないことを示します。サーバーにメモリを追加すると、この状況が改善される可能性があります。 このカウンタが高い値になっている場合、一部のオブジェクトが Gen 1 ガベージ コレクションの後に残り、Gen 2 に昇格される可能性があります。Gen 2 のコレクションには、クリーンアップのために完全なグローバル カタログが必要です。この場合には、他の .NET メモリ カウンタを追加して判断します。 |
平均で 10% 未満である必要があります。 |
.NET CLR Exceptions(*)\# of Excepts Thrown / sec 1 秒間にスローされた例外の数を表示します。これらには, .NET 例外と, .NET 例外に変換されるアンマネージ例外の両方が含まれます。たとえば、アンマネージ コード内の NULL ポインタ参照の例外は、マネージ コード内で .NET System.NullReferenceException として再度スローされる可能性があります。このカウンタには、処理された例外と処理不能な例外の両方が含まれます。例外は、プログラムの通常の制御フローではなく、まれな状況でしか発生しません。このカウンタは、大量の例外が (>100 秒) スローされたために発生する可能性のあるパフォーマンスの問題の指標として設計されました。このカウンタは、長期にわたる平均ではなく、最新の 2 つのサンプルで監視された値の差をサンプリング間隔の時間で割った値を表示します。 |
RPS (Web Server(_Total)\Connection Attempts/sec * .05) の合計の 5% 未満である必要があります。 |
.NET CLR Memory(*)\# Bytes in all Heaps Gen 0 Heap Size、Gen 1 Heap Size、Gen 2 Heap Size、および Large Object Heap Size という他の 4 つのカウンタの合計を示します。このカウンタは、GC ヒープに割り当てられている現在のメモリをバイト単位で示します。 メモリのこれらの領域は、MEM_COMMIT という種類です (詳細については、プラットフォーム SDK ドキュメントの「VirtualAlloc」を参照してください)。このカウンタの値は常に、プロセスのすべての MEM_COMMIT 領域をカウントする、Process\Private Bytes の値未満になります。プライベート バイトからすべてのヒープ内のバイト数を引いた値が、アンマネージ オブジェクトによりコミットされたバイト数となります。 メモリ リークの可能性や、管理されているオブジェクトまたはアンマネージ オブジェクトの過度なメモリ使用を監視するために使用されます。 |
該当なし。 |
ネットワーク、およびその展開方法は、Exchange サーバーの適切なパフォーマンスを実現するために非常に重要です。100 Mbps のネットワークは通常、ほとんどの組織にとって十分な帯域幅であるため、ネットワークのパフォーマンスが問題になることは多くありません。ただし、メッセージ サイズやサーバーあたりのユーザー数が増えることによって、ネットワークがボトルネックとならないようにすることが重要です。
次の表に記載されているカウンタを使用して、ネットワーク パフォーマンスの低下が発生していないかどうかを判断します。
| カウンタ | 予期される値 |
|---|---|
Network Interface(*)\Bytes Total/sec ネットワーク アダプタがデータ バイトを処理する速度を示します。 このカウンタには、すべてのアプリケーションやファイルのデータ、およびパケット ヘッダーなどのプロトコル情報が含まれます。 |
100 Mbps のネットワーク アダプタの場合、6 ～ 7 Mbps 未満である必要があります。 1,000 Mbps のネットワーク アダプタの場合、60 ～ 70 Mbps 未満である必要があります。 |
Network Interface(*)\Packets Outbound Errors エラーのために送信できなかった送信パケットの数を示します。 |
常に 0 である必要があります。 |
IPV4\Datagrams/sec IPV6\Datagrams/sec インターフェイス間で 1 秒間に送受信された IP データグラムの速度で、エラーのあるデータグラムも含まれます。転送されたデータグラムはこのカウンタには含まれません。 現在のユーザー負荷で判断されます。 |
該当なし。 |
TCPv4\Connections Established TCPv6\Connections Established 現在の状態が ESTABLISHED または CLOSE-WAIT のいずれかである TCP 接続の数を示します。 確立できる TCP 接続の数は、非ページ プールのサイズに制約されます。非ページ プールが使い果たされた場合は、新しい接続を確立することはできません。 現在のユーザー負荷で判断されます。 |
該当なし。 |
TCPv4\Segments Received/sec TCPv6\Segments Received/sec エラーで受信されるセグメントを含む、セグメントが受信される速度を示します。このカウントには、現在確立されている接続で受信されるセグメントが含まれます。 現在のユーザー負荷で判断されます。 |
該当なし。 |
TCPv4\Connection Failures TCPv6\Connection Failures TCP 接続が、SYN-SENT 状態または SYN-RCVD 状態から CLOSED 状態に直接移行した回数、および SYN-RCVD 状態から LISTEN 状態に直接移行した回数です。 |
エラー数の増加や、一貫して増加するエラー率は、帯域幅の不足を示している場合があります。 |
TCPv4\Connections Reset TCPv6\Connections Reset TCP 接続が ESTABLISHED 状態または CLOSE-WAIT 状態のいずれかから CLOSED 状態に直接移行した回数を示します。 一部のブラウザは TCP リセット (RST) パケットを送信するため、このカウンタを使用してリセット率を判断するときは注意してください。 |
リセット数の増加や、一貫して増加するリセット率は、帯域幅の不足を示している場合があります。 |
Exchange 2007 は、グローバル カタログ ドメイン コントローラのパフォーマンスに依存します。次の表に記載されているカウンタを使用して、トポロジ内の各 Exchange サーバーについて、グローバル カタログとの通信速度が低下していないかどうかを判断します。
次の表に記載されているカウンタを使用して、ネットワーク パフォーマンスの低下が発生していないかどうかを判断します。
| カウンタ | 予期される値 |
|---|---|
MSExchange ADAccess Caches(*)\LDAP Searches/Sec 1 秒間に発行される LDAP (ライトウェイト ディレクトリ アクセス プロトコル) 検索要求の数を示します。 現在の LDAP 検索の数を判断するために使用します。 |
該当なし。 |
MSExchange ADAccess Domain Controllers(*)\LDAP Read Time 指定されたドメイン コントローラに LDAP 読み取り要求を送信し、応答を受信するためにかかる時間をミリ秒単位 (ms) で示します。 |
平均 50 ミリ秒未満である必要があります。 スパイク (最大値) は 100 ミリ秒以下の値である必要があります。 |
MSExchange ADAccess Domain Controllers(*)\LDAP Search Time LDAP 検索要求を送信し、応答を受信するためにかかる時間 (ミリ秒) を示します。 |
平均 50 ミリ秒未満である必要があります。 スパイク (最大値) は 100 ミリ秒以下の値である必要があります。 |
MSExchange ADAccess Processes(*)\LDAP Read Time 指定されたドメイン コントローラに LDAP 読み取り要求を送信し、応答を受信するためにかかる時間をミリ秒単位で示します。 |
平均 50 ミリ秒未満である必要があります。 スパイク (最大値) は 100 ミリ秒以下の値である必要があります。 |
MSExchange ADAccess Processes(*)\LDAP Search Time LDAP 検索要求を送信し、応答を受信するためにかかる時間 (ミリ秒) を示します。 |
平均 50 ミリ秒未満である必要があります。 スパイク (最大値) は 100 ミリ秒以下の値である必要があります。 |
MSExchange ADAccess Domain Controllers(*)\LDAP Searches timed out per minute 最後の 1 分間に LDAP_Timeout を返した LDAP 検索の数を示します。 |
すべての役割で常に 10 未満である必要があります。 これより高い値は Active Directory リソースの問題を示している可能性があります。 |
MSExchange ADAccess Domain Controllers(*)\Long running LDAP operations/Min 1 分間にこのドメイン コントローラで実行された LDAP 操作のうち、指定されたしきい値を超えた LDAP 操作の数を示します (既定のしきい値は 15 秒です)。 |
常に 50 未満である必要があります。 これより高い値は Active Directory リソースの問題を示している可能性があります。 |
ここでは、Windows Server 2008 または Windows Server 2003 オペレーティング システム上で実行されるドメイン コントローラに関する特定の情報など、Active Directory ドメイン コントローラのパフォーマンスに関する情報を示します。
.gif "note") 注 : |
|---|
| 次のセクションの内容は、エッジ トランスポート サーバーの役割がインストールされた Exchange 2007 サーバーには当てはまりません。 |
Active Directory の応答時間は、すべての Exchange サーバーのパフォーマンスに直接影響を及ぼす可能性があります。これは、すべての LDAP 要求と認証要求はドメイン コントローラまたは一連のドメイン コントローラによって処理されるためです。トラブルシューティングでは、LDAP の待機時間は、Exchange サーバーのパフォーマンスに関する問題の原因であると判断されます。ドメイン コントローラに焦点を合わせるのは、次の論理的な段階になります。
Windows Server 2008 ドメイン コントローラのパフォーマンスに関連する問題のトラブルシューティングのために、データ コレクタ セットを使用して、信頼性とパフォーマンス モニタによって Active Directory パフォーマンスを監視できます。
Windows Server 2008 ドメイン コントローラでは、コレクタ テンプレートは Reliability and Performance\Data Collector Sets\System\Active Directory Diagnostics の下の [Reliability and Performance Monitor] にあります。このツールは、5 分間でデータを収集し、Reliability and Performance\Reports\System\Active Directory Diagnostics の下にレポートを生成します。このレポートは、サーバー上でボトルネックが生じる可能性がないかどうかを判断するのに役立ちます。たとえば、信頼性とパフォーマンス モニタを使用することにより、全体的なパフォーマンスと LDAP 応答時間を低下させる、長期間実行されている LDAP 検索があるかどうかを確認するのに役立ちます。CPU またはディスク ボトルネックの可能性があるかどうかも判断できます。
Windows Server 2008 の信頼性とパフォーマンス モニタを使用する方法の詳細については、「Performance and Reliability」 (英語) を参照してください。
Windows Server 2003 ドメイン コントローラのパフォーマンスに関する問題のトラブルシューティングのために、Server Performance Advisor を使用してデータ収集を自動化できます。
Server Performance Advisor のダウンロードの詳細については、「Microsoft Windows Server 2003 Performance Advisor」 (英語) を参照してください。
参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。