低速な RPC 要求処理の問題のトラブルシューティング
トピックの最終更新日: 2008-11-12
Microsoft Office Outlook を MAPI モードで使用するとき、Outlook はクライアント操作をクライアントとサーバー間のリモート プロシージャ コール (RPC) として実行します。ユーザーがオンライン モードで実行している場合、これらの RPC 呼び出しは同期的に発生します。これらの同期要求の実行におけるサーバーによる遅延は、ユーザーの操作環境および Outlook の応答性に直接影響します。一方、キャッシュ モードで実行しているときに行われるほとんどの操作は、ユーザーのメールボックスのローカル コピーに対して行われるか、非同期 (バックグラウンド) RPC の形式でサーバーに発行されます。一般に、非同期 RPC は、Outlook クライアント自体の応答性または全体的な操作環境に影響を及ぼすことはありません。
Microsoft Exchange Information Store サービスは、サーバー上で最初に開始されるときに、RPC サービスに登録し、500 の RPC スレッドの割り当てを受け取ります。クライアントは、日常的な操作を行うときに各スレッドとの接続および切断を行います。このような操作には、電子メールの読み取りと送信、予定と仕事の作成、および予定表の参照があります。MSExchangeIS\RPC Requests パフォーマンス カウンタは、現在使用されている (クライアントが "所有" している) スレッドの数を示します。MSExchangeIS\RPC Operations/sec パフォーマンス カウンタは、過去 1 秒間にサーバーが受信した操作の数を反映します。RPC 要求の数が時間の経過と共に増加し続ける場合、サーバーがクライアント操作を十分迅速に処理できないことは明らかです。MSExchangeIS\RPC Requests パフォーマンス カウンタが 500 に達すると、すべての RPC スレッドが使い果たされ、既存のスレッド上のすべての操作が完了してスレッドが解放されるまで、クライアントは新しい要求をサーバーに送信できなくなります。
MSExchangeIS\RPC Operations/sec パフォーマンス カウンタは、サーバーの現在の負荷を反映するため、管理者がピーク時および通常運用時のサーバーの予期される値を把握している場合は特に、Exchange の処理におけるボトルネックの特定に非常に役に立ちます。1 秒間に 300 の RPC 操作を受信する場合は許容範囲内のパフォーマンスを発揮するサーバーが、1 秒間に 1,500 の RPC 操作への対応に苦労する場合があります。管理者は、常に MSExchangeIS\RPC Operations/sec カウンタを確認し、この値の変化と RPC 要求の数の変化を相互に関連付ける必要があります。
クライアントから Exchange のパフォーマンスが低下しているいう苦情があり、MSExchangeIS\RPC Requests と MSExchangeIS\RPC Operations/sec がいずれも低いか 0 の場合は、明らかにボトルネックがサーバー自体にはないことを示しています。ここで問題なのは、サーバーの外部の何かが情報がサーバーに到達するのを妨げているということです。管理者は、Active Directory のパフォーマンス、ネットワーク パフォーマンス、クライアント構成、および Exchange サーバーにデータが到達しない原因となっている可能性があるその他の領域を確認する必要があります。
MSExchangeIS\RPC Requests が着実に増加している一方で、MSExchangeIS\RPC Operations/sec がほぼ安定している場合は、サーバーが既存の負荷を処理できないことを示しています。管理者は、物理メモリ、格納域、およびプロセッサの性能を含め、ハードウェア コンポーネントを確認するか、サーバー上のユーザーの数を減らす必要があります。
MSExchangeIS\RPC Requests は着実に増加しているが、MSExchangeIS\RPC Operations/sec が着実に減少している場合は、Exchange サーバーがボトルネックの原因であることを示しています。この状況では、何かがインフォメーション ストアが RPC 操作を完了するのを妨げており、関連付けられている RPC スレッドが割り当てられたままになっています。割り当てられるスレッドの数が多くなるほど、サーバーが新しい操作に使用できるスレッドが少なくなるため、新しい操作の数は減少します。サーバーの未処理の RPC 要求の数が最終的に 500 に達すると、新しい RPC 操作は拒否されます。これは一般に、深刻な物理リソースの不足 (メモリまたはディスク) や、インフォメーション ストアまたは統合コンポーネント (ウイルス対策、ジャーナリングなど) 内の処理の問題によって引き起こされます。
次の表に、RPC 処理の問題のトラブルシューティングおよび特定を行う際に最も重要なカウンタを示します。
RPC 処理のパフォーマンス カウンタ
カウンタ | 予期される値 |
---|---|
MSExchangeIS\RPC Requests Microsoft Exchange Information Store サービスが現在処理している MAPI RPC 要求の数を示します。 Microsoft Exchange Information Store サービスは、新しいクライアント要求を拒否する前に、最大 500 の RPC 要求を同時にサポートできます。 |
|
MSExchangeIS\RPC Averaged Latency 待機時間 (ミリ秒単位) を示します。過去 1024 の RPC パケットの RPC 操作全体の平均です。 サーバーの RPC の全体的な平均待機時間が増加したときにクライアントがどのような影響を受けるかについては、後の「クライアント調整」を参照してください。 |
|
MSExchangeIS\RPC Operations/sec 1 秒間にインフォメーション ストアに送信される RPC 操作の現在の数を示します。 |
|
MSExchangeIS\RPC Num. of Slow Packets 待機時間が 2 秒を超える過去 1,024 パケット内の RPC パケットの数を示します。 |
|
クライアント側の監視
Microsoft Office Outlook 2003 および Office Outlook 2007 には、クライアント側の監視機能が追加されています。クライアント側の監視は、クライアント エラーおよび待機時間の問題を見つけるために使用されます。Exchange サーバーでサーバーのレジストリを変更することによって、クライアント側の監視を有効にすることができます。有効にすると、Outlook 2007 および Outlook 2003 クライアントは接続の状態に基づいて、失敗した RPC 要求やエラー状況などのデータをサーバーに送信します。この情報はサーバーで集約され、サーバー上のイベント ログ エントリに記録されます。Outlook でクライアント側の監視を有効にする方法の詳細については、「クライアント側の監視を有効にする方法」を参照してください。
クライアント調整
Exchange 2007 には、RPC クライアント調整と呼ばれる新しい機能があります。管理者はこの機能を使用して、エンド ユーザーのパフォーマンスを管理することができます。クライアント アプリケーションが Exchange サーバーに 1 秒間に送信する RPC 操作の数が多すぎると、サーバー全体のパフォーマンスが低下する可能性があります。RPC クライアント調整は、クライアント アプリケーションがこのように多数の RPC 操作を送信できないようにするために導入されました。これらのクライアント アプリケーションには、ユーザーのメールボックス内のすべてのオブジェクトを検索するデスクトップ検索エンジン、Exchange メールボックス内のデータを操作するために記述されたカスタム アプリケーション、エンタープライズ規模の電子メール アーカイブ製品、電子メールの自動タグ付けが有効になっている CRM 対応のメールボックスなどがあります。クライアント調整により、Exchange では数人のユーザーによるサーバーの独占を検出し、防止することができます。クライアントがサーバーに過度の影響を与えていると Exchange サーバーによって確認されると、サーバーはサーバーのパフォーマンスに対する影響を低減するために、クライアントに "バックオフ" 要求を送信します。Exchange 2007 で使用可能なクライアント調整機能の詳細については、「クライアント調整について」を参照してください。
参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。