(この記事は 2015 年 4 月 30 日に Office Blogs に投稿された記事 Troubleshooting High CPU utilization issues in Exchange 2013の翻訳です。最新情報については、翻訳元の記事をご参照ください。)
はじめに
Exchange のサポートを行っていると、私たちはさまざまな問題にぶつかります。中でもとりわけ難しい問題はパフォーマンスの問題です。その背景には、「パフォーマンスの問題」という表現のあいまいさがあります。パフォーマンスの問題には、ランダムなクライアント接続の切断から、データベースのフェールオーバー、モバイル デバイスの同期速度の低下まで、あらゆる問題が含まれています。最も一般的なパフォーマンスの問題は、CPU 使用率の上昇です。「CPU 使用率の上昇」という表現も、ややあいまいです。CPU 使用率が上昇した状態とは、具体的にはどの程度の使用率を指すのでしょうか? その状態はいつ発生し、どのくらい続くのでしょうか? これらの点を明確にしてからでないと、問題の原因を本当に突き止めることはできません。たとえば、日中に CPU 使用率が 75% に達した場合に「CPU 使用率が高い」と判断するとしましょう。このとき、何か問題が発生しているでしょうか? データベースの負荷分散が不適切なのでしょうか? それとも、単にサーバーの容量が小さすぎるのでしょうか? では、CPU 使用率が 100% に達した場合はどうでしょう。その状態が続くのは 10 秒間、それとも 10 分間でしょうか? その状態は、クライアントが朝一番にログオンしたときに、はたまたフェールオーバーの後で発生するのでしょうか? この記事では、Exchange 2013 の CPU 使用率が高い場合の一般的な原因と、そのトラブルシューティングの方法について説明します。
最初に、この記事は Exchange 2013 のみを対象としており、それ以前のバージョンには当てはまらないことを述べておきます。バージョンが異なっていても、CPU 使用率が高い原因は共通していることもあります。しかし、この記事で紹介するデータの大部分は、Exchange 2013 固有のものです。Exchange 2010 と Exchange 2013 にはかなり大きな違いがあるため、ベスト プラクティスやトラブルシューティングの方法が異なります。さらに、処理能力 (メガサイクル) の要件、必要な .NET Framework のバージョン、.NET ガベージ コレクション (英語)の実装も異なります。このような理由から、この投稿では Exchange 2010 については扱いません。
設定に関する一般的な問題
パフォーマンスの問題に取り組む場合、私たちサポート担当は最初にチェック リストを確認します。最近公開された TechNet 記事「Exchange 2013 のサイズ変更と構成の推奨事項」は、このチェック リストを提供することを目的としています。この記事で、同じ解説をすべて繰り返すつもりはありません。このトピックにご関心のある方は、リンク先の記事をお読みください。ここでは、特に重要な点に的を絞って解説していきます。
.NET Framework のバージョン
Exchange 2013 は .NET Framework バージョン 4.5 で動作します。.NET チームは .NET 4.5 の更新をバージョン 4.5.1 および 4.5.2 としてリリースしました。Exchange 2013 では、このすべてのバージョンがサポートされます。しかし、使用しない理由が特にない限り、バージョン 4.5.2 を選択されることを強くお勧めします。バージョンを重ねるごとにパフォーマンス関連の修正が行われていますが、その中には Exchange 2013 に大きな影響を及ぼすものもあります。お客様のサポートを行ううえで目にすることも決して少なくありません。まだバージョン 4.5.2 を使用していない場合は、早急にアップグレードしていただければ、多くの問題を回避することができます。4.5.2 は、この投稿の公開時点における最新のバージョンです。.NET Framework の機能は、今後のリリースでさらに改善されますので、常に最新のバージョンがないかチェックしてください。.NET Framework の各バージョンの詳細については、こちらの記事をご覧ください。
電源管理
CPU 使用率が上昇する問題の原因として多いものは、電源管理の構成ミスです。電源管理は多くの場合、とても有用です。電源管理を行うと、特にハードウェアや OS では、CPU スロットリングを実施し、使用していないアイドル状態のネットワーク カードをオフにすることができます。ワークステーションや一部のサーバーでは電源管理を行うことで多くのメリットがあります。節電になるため電気料金を抑えることができ、二酸化炭素の排出力が減るため地球環境にも貢献できます。それではなぜ、電源管理が問題になるのでしょうか? たとえば、業務時間中、常に CPU 使用率 80% 前後で稼働するサーバーがあるとします。サイジングを繰り返した結果、CPU 使用率はほぼ 55% になりました。クライアントは問題なく動作しています。CPU の使用率以外に気になる点はありません。しかし、2.4GHz のコアのうち、ほぼ常に 1.2GHz のみが動作していると判明したらどうでしょう? CPU 使用率の内容が変わってくる可能性があります。Exchange の場合、推奨事項は単純です。ハードウェアの電源管理が必須でないなら、使わないことです。オペレーティング システムで電源管理を行い、Windows の電源プランで常に [高パフォーマンス] を選択してください。ハードウェアベースの電源管理を使わない場合でも、電源プランを既定の [バランス] に設定するだけで、CPU スロットリングが行われる可能性があります。
この問題が発生しているかどうかを確認するには、どうすればよいでしょうか? 物理サーバーの場合は簡単です。パフォーマンス モニターに "Processor Information(_Total)\% of Maximum Frequency" というカウンターがあります。この値は常に 100 になっている必要があります。値が 100 に満たない場合は、ハードウェアまたは OS レベルで、通常は何らかの電源管理によって、CPU スロットリングが行われています。仮想サーバーの場合はやや複雑です。Exchange サーバー (VM ゲスト) にとって、CPU のパフォーマンスの値は必ずしも信頼できません。VM ホスト レイヤーで電力のスロットリングが行われている場合、ゲスト OS 側では把握できない可能性もあるためです。この場合は、VM ホストのパフォーマンス モニタリング ツールを使って、プロセッサの電力のスロットリングが行われているかどうかをチェックします。
以下に、Perfmon のスクリーンショットを示します。CPU スロットリングが行われています。
正常性チェック
先日、TechNet ギャラリー (英語)に一般的な構成の問題を簡単に検出する PowerShell スクリプトが公開されました。このスクリプトは、ハードウェア/プロセッサ情報、NIC 設定、電源プラン、Pagefile の設定、.NET Framework のバージョンなどのレポートを作成します。クライアント アクセスの負荷分散チェック (サーバーあたりの現在の接続数) や、メールボックス レポート (サーバーあたりのアクティブ/パッシブなデータベースとメールボックスの合計数) も実行します。このスクリプトはリモート実行が可能で、組織内のすべてのサーバーに対して同時に実行できます。そのため、各サーバーについて、これらの設定を個別にチェックする手間が省けます。スクリプトの詳細と一般的な使用法 (構文) については、TechNet ギャラリーのページをご覧ください。
サイジング
前のセクションで取り上げた一般的な問題の原因を取り除いたら、今度はサイジングについて検討します。サーバーの処理能力が低く、負荷に対応しきれないため、CPU の使用率が高くなっている可能性があります。Exchange 2013 のサイジングについては、既に多くのブログ記事が投稿されています。サイジングについて詳しく知りたい場合は、Jeff Mealiffe のブログ記事「パフォーマンス チームに聞く: Exchange 2013 展開のサイジング (英語)」が参考になります。Ross Smith IV のサイジングの計算に関する記事 (英語)も一読されることをお勧めします。ほとんどの展開では、プランニングとサイジングに計算ツールを使用しています。私はサポート担当なので、既存の環境のトラブルシューティングという観点からこのトピックにアプローチしたいと思います。トラブルシューティングを行うには、展開のサイジングもプランニングも必要ありませんが、パフォーマンスの問題が単にサイズ不足によるものであるかどうかを判断するには、これらに関する十分な知識が必要です。サイジングの知識がまったくないと、CPU の使用率が高い問題のトラブルシューティングは非常に困難になります。CPU のサイジングを行うときは「負荷を処理するのに十分な処理能力があるのか」を考える必要があります。
簡単そうに思えますが、実はなかなか難しい問題です。現在の処理能力 (メガサイクル数) を確認するのは、多少の計算が必要ですが、それほど難しくありません。通常、次のような公式 (Jeff のサイジングに関するブログから引用) を使用します。
2 つの値は既にわかっています。ベースライン プラットフォームのコアあたりのクロック数 (メガヘルツ) は常に 2,000 です。また、コアあたりのベースラインのスコアは常に 33.75 です。なお、これは Exchange 2013 固有の値です。残ったのは、ターゲット プラットフォームのコアあたりのスコアの値です。この値を求めるには、サーバーの SPECInt 2006 (英語)ベンチマーク テストの結果を物理コアの合計数で除算します。SPECInt 2006 のサイトを使用しない場合は、Exchange Processor Query Tool (英語)でサーバーのスコアを参照することもできます。12 コアのサーバーの SPECInt 2006 の結果が 430 だとすると、コアあたりのスコアは 35.83 (430/12) になります。これを公式に当てはめると、次のようになります。
2,123.26 メガサイクルにコア数の 12 を乗算すると、合計 25,479 メガサイクルになります。次に、必要な処理能力 (メガサイクル数) を求める必要があります。この手順は少し複雑です。アクティブ/パッシブなメールボックスの数とメッセージ プロファイル (1 日あたりの送信/受信メッセージ数) のほか、サードパーティ製品の乗数を考慮する必要があるためです。しかし、これにも計算スクリプトを使用できます。
これらの値は、Exchange 2013 CPU Sizing Checker (英語)というスクリプトで計算できます。プロファイル情報をすべて入力することもできますが、サイジング計算ツールの結果から値を直接インポートする方が簡単です。構文の例はダウンロード ページに記載されています。
以下に、Sizing Checker のスクリーンショットを示します。
Sizing Calculator バージョン 7.2 でも、CPU 使用率を予測することができます。メールボックス サーバーから現在の CPU 使用率の合計を照会するのではなく、スプレッドシートの [Input] ページの値を使用して、計画されたアクティブ/パッシブなメールボックスの数から CPU 使用率を予測する点が特徴です。バージョン 7.2 の新機能を使うと、通常実行 (障害なし、すべてのデータベースに均等に負荷分散)、単一障害 (データセンター内の単一のサーバーで障害が発生し、データベース コピーがアクティブ化)、二重障害 (データセンター内の 2 台のサーバーで障害が発生し、データベース コピーがアクティブ化)、サイト障害 (データセンターで障害が発生し、別のデータセンターへのフェールオーバーが必要)、最悪の障害 (環境の設計要件に基づく、想定される最悪の障害) など、複数のシナリオにおける CPU 使用率から、実際の CPU 使用率を予測することができます。
メッセージ プロファイルと乗数
「CPU 使用率を予測できることはわかったけど、メッセージ プロファイルと乗数を把握はどうやって把握するのか」と疑問に思われる方もいるでしょう。良い質問です。運用環境におけるメッセージ プロファイルの値は、Dan Sheehan が作成したスクリプト、Generate-MessageProfiles.ps1 を使用して求めることができます。このスクリプトも、TechNet ギャラリー (英語)に公開されています。このスクリプトは、トランスポート ログを解析し、1 日あたりの実際の送信/受信メッセージ数を割り出します。このスクリプトの詳しい使用方法については、Dan Sheehan のブログ記事 (英語)をご覧ください。
メッセージ プロファイルの件は片付きました。では、乗数はどうやって求めるのでしょうか? これは難題です。サードパーティ ベンダーによっては、ソフトウェアの推奨乗数を提供している場合もあります。しかし、この情報は必ずしも提供されているとは限りません。この場合は、先ほどご紹介した Exchange 2013 CPU Sizing Checker (英語)スクリプトを使って、乗数を逆算して求めます。乗数 1.0 でスクリプトを実行した場合、CPU 使用率は 50% になります。これは、1 日で最も忙しい時間帯の Exchange 固有のプロセスの平均 CPU 使用率の予測値です。しかし、実際の CPU 使用率が 65% 近くである場合は、乗数を変更して、65% に近い結果が出るまで、スクリプトを繰り返し実行します。そうすることで、サイジング計画で使用する乗数を突き止めることができます。
先ほども説明したように、Sizing Calculator バージョン 7.2 では、計画した環境の値に基づいて CPU 使用率を予測することができます。具体的に説明すると、Sizing Calculator の [Input] タブで、プロファイル設定の [Megacycles Multiplication Factor] を変更すると、[Role Requirements] タブの [CPU Utilization/Dag] セクションに結果が表示されます。ここから、現在の環境に最適な乗数を割り出すことができます。通常は、スクリプトよりも Sizing Calculator を使う方法をお勧めします。Sizing Calculator の方が高速で、環境の計画に役立つような設計になっているからです (これに対し、スクリプトはどちらかというとトラブルシューティング向けです)。
過剰なサイジング
意外に思われるかもしれませんが、CPU を考慮して、サーバーを過剰にサイジングしている場合があります。実際の処理能力に影響はありません。コア数が多いサーバーを展開すると、場合によってはハードウェアを無駄に使用することになりますが、処理能力が高いこと自体は何ら問題ではありません。過剰なサイジングと言っているのは、処理能力ではなく、コア数の話です。Exchange 2013 はコモディティ タイプのサーバー上で動作することを想定して開発されました。テストは通常、2 ソケット、16 ～ 20 コア程度のプロセッサのサーバーで実施されます。したがって、コア数がこれよりはるかに多いサーバーに展開する場合、スケーラビリティの問題が起こる可能性があります。コア数に基づいて、パフォーマンスに影響を及ぼす可能性があるアプリケーション レベルの設定を決定します。たとえば、サーバー モードのガベージ コレクションを使用するプロセスでは、コアあたり 1 つのマネージ ヒープを作成します (.NET 4.5 のガベージ コレクションの詳細については、こちらの記事 (英語)をご覧ください)。この場合、プロセスはメモリを大量に占有し、コア数が多いほど増加します。コア数から、多くのプロセスのスレッドプール (英語)内の最小スレッド数も特定できます。既定値はコアあたり 9 スレッドです。32 コアのサーバーを使用している場合、288 スレッドになります。アクティビティのバーストが突然発生した場合、これらの多数のスレッドが同時に処理を実行しようとします。Exchange 2013 には、スレッドの安全性を確保するためのロック機構があります。しかし、一部のロック機構は、コア数が非常に多いと、推奨コア数の範囲内で動作しているときのように効率的に機能しません。つまり、特定の条件下では、コア数が多いと CPU 使用率が高くなります。ハイパースレッディングも CPU 使用率に影響します。Exchange では、16 コアのハイパースレッド サーバーは 32 コアと認識されるからです。この点からも、ハイパースレッディングを無効にすることをお勧めしています。これらはほんの一例ですが、サーバーをサイジングする際は、製品グループの推奨事項に従うことが非常に重要だとおわかりいただけるかと思います。コスト、高可用性、製品の設計のどの観点から考えても、スケールアップよりスケールアウトの方が効果的です。
単一のプロセスによる CPU 使用率の上昇
一般的に、CPU スロットリングの問題が発生している場合やサーバーのサイズが小さすぎる場合、CPU 使用率が高くなりますが、単一のプロセスが問題の原因となっているようには見えません。単に、サーバーがビジー状態のように見えるだけです。つまり、CPU 使用率が高いのに、単一のプロセスが原因だとは考えられない状況です。しかし実際には、単一のプロセスが CPU 使用率の上昇の原因になっている可能性があります。このセクションでは、パフォーマンス モニターを使って、問題を引き起こしているプロセスを特定し、その原因を探る方法についてご説明します。
Perfmon ログ
パフォーマンス モニター (Perfmon) は優れたツールです。しかし、問題が発生しているにもかかわらず、Perfmon データが記録されていなければ意味がありません。Exchange 2013 では、毎日のパフォーマンス データを記録する機能を使用できます。この機能は既定でオンになっています。通常、ログは、Exchange Server のインストール フォルダーの "V15\Logging\Diagnostics\DailyPerformanceLogs" に保存されます。これらは perfmon.exe で読み取り可能なバイナリ ログ (*.blg) ファイルです。内容を確認するには、Perfmon を起動し、Monitoring Tools\Performance Monitor に移動して、[View Log Data] ボタンをクリックします。続いて、[Data Source] で [Log Files] を選択し、[Add] をクリックして、表示したいファイルを選択します。この組み込みのログ記録機能では、有用なデータを収集しつつ、ディスク領域を消費しすぎないようにするため、すべてのカウンターを記録するのではなく、1 分間隔で記録します。ほとんどの場合、このペースで十分有用なデータが得られます。より堅牢なカウンター セットが必要な場合や、間隔を 1 分より短くする必要がある場合は、ExPerfWiz (英語)を使ってカスタム設定を行うことができます。なお、この情報を定期的に複数のサーバーから収集する方法については、こちらのブログ記事が参考になります。
Perfmon 分析
Perfmon ログで CPU 使用率が高い問題の原因を分析するとき、最初に "Process(_Total)\% Processor Time" というカウンターをロードします。このカウンターから、サーバーの合計 CPU 使用率を把握することができます。これはきわめて重要です。なぜなら、ログに CPU 使用率を引き上げる条件が含まれていることを真っ先に確認する必要があるからです。このカウンターを使うと、CPU 使用率の上昇を簡単に特定できます。短時間のバーストが見つかった場合は、発生したタイミングに着目して、同じ時間に何が起こっていたのかを詳しく調べます。ここで、Process(_Total) と Processor(_Total) の違いを説明しておきましょう。Processor(_Total) は 0 ～ 100 の範囲になります (CPU 使用率のパーセンテージ)。一方、Process(_Total) はサーバーのコア数によって決定されます。たとえば、16 コアのサーバーの場合、CPU 使用率 100% のスパイクの値は 1600 になります。Process(_Total) と Processor(_Total) の違いを把握しているなら、どちらを使ってもかまいません。Perfmon ログを見ていて合計コア数がわからない場合は、Processor カウンターの下のインスタンス ウィンドウ内の一番大きな数字を見てください。これはゼロを最小値とするコレクションで、それぞれの数字がコアを表しています。たとえば、一番大きな数字が 23 ならコア数は 24 になります。トラブルシューティングのこのフェーズでは、Perfmon ウィンドウの縦軸の目盛を変更すると見やすくなります。ウィンドウ内を右クリックし、[Properties]、[Graph] タブの順に選択して、最大値をコア数 × 100 に変更します。たとえば、16 コアなら 1,600 に変更します。
CPU 使用率を引き上げる条件と、その発生のタイミングがわかったら、今度はその原因を絞り込んでいきます。まず、"Process\% Processor Time" の下のすべてのインスタンスをロードします。CPU 使用率の測定で既に使用しているので、"_Total" は無視してかまいません。"_Total" の裏返しとなる "Idle" も同様です。CPU 使用率と並行して上昇しているプロセスがないかを確認します。見つからない場合、問題の原因になっているのは単一のプロセスではないということになります。この場合、ここまでのセクションで取り上げてきたサイジング、負荷、CPU スロットリングなどのトピックが原因である可能性が高くなります。
w3wp インスタンスとアプリケーション プールの対応
CPU 使用率の上昇の原因になっている単一のプロセスが見つかったとします。このプロセスの名前が "w3wp#1" だとしましょう。このプロセスをどう処理したらよいでしょうか? Exchange はサポート対象のさまざまなプロトコル用に IIS 内で複数のアプリケーション プールを実行しています。そこで、"w3wp#1" が対応しているアプリケーション プールを突き止める必要があります。必要な情報は Perfmon が収集しているので、それを見つける方法さえわかれば良いのです。
まず、"Process(w3wp#1)\ID Process" というカウンターをロードします。これにより、w3wp インスタンスのプロセス ID (PID) がわかります。PID が 22480 だとしましょう。この情報を使って、カウンターのロード画面に戻り、"W3SVC_W3WP" を確認します。任意のカウンターをクリックすると、その下のウィンドウに PID_AppPool という形式のエントリが表示されます。この例では、"22480_MSExchangeSyncAppPool" と表示されています。このエントリから、w3wp#1 が Exchange ActiveSync アプリケーション プールに属していることがわかります。これで、CPU 使用率の上昇の原因になっているのは ActiveSync だということがわかりました。この時点で、"Process(w3wp#1)\% Processor Time" 以外のカウンターはすべて削除できます。これらは不要な情報です。また、縦軸を 100 に戻し、カウンターを右クリックして、[Scale Selected Counters] を選択します。
管理可用性の正常性チェックにより、アプリケーション プールが再起動される場合があります。この場合、PID と w3wp インスタンスは変更されます。対象のワーカー プロセスの "Process(w3wp*)\ID Process" カウンターに注目してください。この値が変更された場合、プロセスがリサイクルされたか、PID が変更されたか、w3wp インスタンスが変更された可能性があります。正しい情報を利用するためには、プロセスのリサイクル後にインスタンスが変更されたかどうかを確認する必要があります。
プロセスの動作
w3wp#1 に絞り込み、問題の原因が ActiveSync であることがわかったので、ActiveSync のトラブルシューティングを開始します。以下のトラブルシューティングの手順はその他のアプリケーション プールにも適用できますが、ここで紹介するのは ActiveSync 固有の例です。確認するべき原因として最も一般的なのは、アクティビティのバーストです。"MSExchangeActiveSync\Requests /sec" カウンターをロードして、問題が発生したタイミングの前後に要求の増加がないかどうかを確認します。要求の増加があった場合もない場合も、要求トラフィックの増加が CPU 使用率の上昇の原因であったのかどうかがわかります。トラフィックの増加が原因だった場合は、トラフィックの原因を探る必要があります。そのためには、"MSExchange IS Mailbox(_Total)\Messages Delivered /sec" カウンターをチェックします。CPU 使用率が上昇する直前にこのカウンターの値が上昇していた場合、着信メッセージのバーストがあり、おそらくそのバーストが原因であることがわかります。その場合、トランスポート ログを確認して、手がかりを探ります。メッセージ配信が原因でないとしたら、モバイル デバイスのアクティビティが原因である可能性があります。その場合は、Log Parser Studio (英語)を使って IIS ログを分析し、ActiveSync トラフィックのトレンドを確認します。
ガベージ コレクション (GC)
要求トラフィックにもメッセージ配信にも顕著な増加が見られない場合、プロセス内に原因がある可能性があります。多くの場合、原因はガベージ コレクションです。".NET CLR Memory(w3wp#1)\% Time in Garbage Collection" を確認してみましょう。問題の発生時、この値が 10% 以上になっていれば、CPU 使用率の上昇の原因である可能性があります。その場合は、".NET CLR Memory(w3wp#1)\Allocated Bytes /sec" も確認します。CPU 使用率が高い間、このカウンターの値が 50,000,000 前後であり、"% Time in Garbage Collection" の値の上昇と連動している場合、ガベージ コレクターが負荷を処理しきれていない可能性があります。この場合、ガベージ コレクションのスループットは、通常、問題の根本原因ではありません。それは別の問題です。この種の上昇は通常、システムに異常な負荷がかかっていることを示します。ガベージ コレクターの設定を変更するよりも、根本的な原因を探り、その原因を排除する方がはるかに効果的です。
RPC Operations/sec
これは、クライアントのアクティビティと CPU 使用率の関係を突き止める上で、おそらく最も有効なカウンターです。"MSExchangeIS Client Type(*)\RPC Operations /sec" をロードすると、インフォメーション ストアに対して発行されている RPC 要求の数をクライアントのタイプ別に把握できます。通常、特に大きな影響を及ぼしているのは、momt (RPC Client Access サービス (通常は Outlook MAPI クライアント) からの要求)、コンテンツのインデックス作成、Web サービス (EWS)、トランスポート (メール配信) です。本来、何が「通常」の状態であるかを把握するには、現在の環境のベースラインを設定しておく必要があります。しかし、このカウンターと CPU 使用率を比較すると、クライアント要求が CPU 使用率の上昇の原因になっているかどうかを確認できます。
Log Parser Studio (LPS)
無人島に取り残されたとします。食べ物を手に入れるためには、Exchange のパフォーマンスの問題のトラブルシューティングを行わなければなりません。このとき、2 つしか道具を持って行けないとしたら、私が選ぶのは Perfmon と Log Parser Studio です。LPS には、Exchange で使用するさまざまなプロトコルのトラフィックを簡単に分析できる組み込みクエリが用意されています。これらを使うと、1 日あたりの ActiveSync のヒット数をデバイスごとに表示したり、EWS 要求をクライアントの種類別に表示したり、RPC Client Access MAPI クライアントのバージョンの割合を表示したりできます。組み込みクエリは、必要な情報を見つけるのにきわめて有効です。TSQL の知識が少しあれば、自分でクエリを作成することもできます。LPS の詳細については、Kary Wall のブログ記事 (英語)をご覧ください。クライアントの種類が問題の原因になっているところまで突き止められたら、通常、その次に使用するのが LPS です。
まとめ
パフォーマンスは非常に広いテーマなので、この記事だけですべてを網羅することはできません。しかし、Exchange 2013 の使用中に CPU 使用率が上昇した場合、その原因を突き止めるヒントとテクニックは十分にお伝えしたつもりです。Exchange のパフォーマンスについて他に取り上げてほしいトピックがあれば、ぜひ下記のコメント欄にフィードバックをお寄せください。最後までお読みいただき、ありがとうございました。
Marc Nivens