次の方法で共有

IIS アプリケーション プールでの高 CPU のトラブルシューティング

  • [アーティクル]

適用対象: インターネット インフォメーション サービス

このトラブルシューティング ツールは、インターネット インフォメーション サービス (IIS) アプリケーション プールで CPU が高く維持される原因を特定するのに役立ちます。 Web アプリケーションが要求を処理するときに CPU の使用率が増加するのは正常であるということを覚えておくことが重要です。 ただし、長期間にわたって高いレベル (80% 以上の領域) で一貫して CPU が維持されると、アプリケーションのパフォーマンスが低下します。 そのため、可能であれば対処して修正できるように、CPU が持続的に高くなる原因を理解することが重要です。

シナリオ

IIS のアプリケーション プールで、長期にわたり CPU 使用率が 90% を超えています。 アプリケーションをテストしても、問題は発生しません。 ただし、アプリケーションで実際のユーザー負荷が発生すると、CPU の使用率が上昇し、そのまま維持されます。 復旧するには、アプリケーション プールを再起動する必要がありますが、再起動後も CPU の使用率が再び高いレベルに上昇します。

ツール

データ収集

CPU 使用率の高い問題が発生した場合に最初に行う必要があるのは、CPU を消費しているプロセスを特定することです。 タスク マネージャーの Processes タブを使用してこれを行うことができます。 [すべてのユーザーからプロセスを表示するチェック ボックスをオンにします。 次の図は、このチェック ボックスをオンにし、高レベルの CPU を消費する w3wp.exe プロセス (IIS アプリケーション プールをホストするプロセス) を示しています。

スクリーンショットは、Windows タスク マネージャーを示しています。C P U 列の下の w 3 w p 実行可能行で 85 が強調表示されています。すべてのユーザーのプロセスが選択されていることを示します。

パフォーマンス モニターを使用して、CPU を使用しているプロセスを特定することもできます。 パフォーマンス モニターの使用方法の詳細については、「パフォーマンス データの分析」を参照してください。

ヒント

特定のw3wp.exe プロセスに関連付けられているアプリケーション プールを特定する必要がある場合は、管理コマンド プロンプトを開き、 %windir%\System32\inetsrv フォルダー cd %windir%\System32\inetsrv に切り替えて、 appcmd list wpを実行します。 これにより、w3wp.exe プロセスのプロセス識別子 (PID) が引用符で囲まれた形式で表示されます。 その PID を、タスク マネージャーで使用可能な PID と照合することができます。

w3wp.exe プロセスで CPU 使用率が高くなっていることを確認したら、問題の原因を特定するために次の情報を収集する必要があります。

  • パフォーマンス モニターのデータ コレクター セット。
  • w3wp.exe プロセスのユーザー モード メモリ ダンプ。

どちらの情報も、CPU イベントが高い間に収集する必要があります。

パフォーマンス モニター データ コレクター セットの収集

パフォーマンス モニターデータは、多くの場合、CPU の高い問題の原因を特定する上で重要です。 また、アプリケーションの実行方法の "全体像" を取得する場合にも非常に役立ちます。

Perfmon データは、リアルタイムで表示することも、後で確認できるデータ コレクター セットで収集することもできます。 CPU が高くなる問題をトラブルシューティングするには、データ コレクター セットを収集する必要があります。 CPU が高くなる問題をトラブルシューティングするためにデータ コレクター セットを作成するには、次の手順に従います。

  1. Windows コントロール パネルの [管理ツール] を開きます。
  2. パフォーマンス モニターをダブルクリックします。
  3. Data コレクター セットノードを展開します。
  4. ユーザー定義を右クリックし、 New ->Data コレクター セットを選択します。
  5. データ コレクター セットの名前として「 High CPU 」と入力します。
  6. 手動で作成 (詳細設定)を選択します。
  7. [次へ] を選択します。
  8. [データ ログ 作成を選択します。
  9. パフォーマンス カウンターチェック ボックスをオンにします。
  10. [次へ] を選択します。
  11. [追加] を選択します。 アプリケーションが ASP.NET アプリケーションでない場合は、手順 19 に進みます。
  12. カウンターの一覧の一番上までスクロールし、 .NET CLR メモリを選択します。
  13. インスタンスの一覧から <[すべてのインスタンス]> を選択します。
  14. 追加を選択して、追加したカウンターの一覧にカウンターを追加します。
  15. カウンターの一覧から ASP.NET を選択し、 追加を選択します。
  16. カウンターの一覧から ASP.NET アプリケーション を選択します。
  17. インスタンス <一覧からすべてのインスタンス> を選択します。
  18. [追加] を選択します。
  19. カウンターの一覧から Process を展開します。 (必ず 展開してくださいProcess Processor ではありません。)
  20. Process オブジェクトから % Processor Time を選択します。
  21. インスタンス <一覧からすべてのインスタンス> を選択します。
  22. [追加] を選択します。
  23. カウンターの一覧から Thread を展開します。
  24. Thread オブジェクトから % Processor Time を選択します。
  25. インスタンス <一覧からすべてのインスタンス> を選択します。
  26. [追加] を選択します。
  27. インスタンスの一覧から ID Thread を選択します。
  28. [追加] を選択します。

ダイアログは次の図のようになります。

[データ コレクション 0 1 のプロパティ] ダイアログ ボックスを示すスクリーンショット。[パフォーマンス カウンター] タブで [I D スレッド] が選択されています。

OK ->Next を選択します。 データ コレクター セットが保存されている場所をメモしておきます (必要に応じて、この場所を変更できます)。次に、 Finish を選択します。

データ コレクター セットはまだ実行されていません。 起動するには、User Defined ノードの下にある High CPU を右クリックし、メニューから Start を選択します。

デバッグ診断ルールの作成

CPU の状態が高い場合にユーザー モード プロセス ダンプを収集する最も簡単な方法は、デバッグ診断を使用することです。

DebugDiag をダウンロードし、サーバーにインストールして実行します。 ( に表示されます)インストール後の [スタート ] メニュー)。DebugDiag を実行すると、 規則の種類の選択 ダイアログが表示されます。 アプリケーション プールのクラッシュ ルールを作成するには、次の手順に従います。

  1. Performance ->Next を選択します。
  2. パフォーマンス カウンター ->Next を選択します。
  3. [パフォーマンス トリガー 追加を選択します。
  4. Processor (Process ではなく) オブジェクトを展開し、プロセッサ時間% を選択。 Windows Server 2008 R2 を使用していて、プロセッサが 64 個を超える場合は、Processor オブジェクトの代わりに Processor Information オブジェクトを選択します。
  5. インスタンスの一覧で、 _Totalを選択します。
  6. [追加 ->OK を選択します。
  7. 新しく追加したトリガーを選択し、 Edit Thresholds を選択します。 [パフォーマンス カウンターの選択] ダイアログ ボックスを示すスクリーンショット。
  8. ドロップダウンで Above を選択します。
  9. しきい値を 80 に変更します。
  10. 秒数として「 20 」と入力します。 (必要に応じてこの値を調整できますが、誤ったトリガーを防ぐために、秒数を少なく指定しないように注意してください)。
  11. [OK] を選択します。
  12. [次へ] を選択します。
  13. [ダンプ ターゲット 追加を選択します。
  14. ドロップダウンから Web アプリケーション プール を選択します。
  15. アプリケーション プールの一覧から、お使いのアプリケーション プールを選択します。
  16. [OK] を選択します。
  17. [次へ] を選択します。
  18. 次へを再度選択します。
  19. 必要に応じてルールの名前を入力し、ダンプを保存する場所をメモします。 この場所は必要に応じて変更できます。
  20. [次へ] を選択します。
  21. [今すぐルールを有効にする]<を選択し、Finish を選択します。

ヒント

手順 13 から 15 と同じ方法を使用して複数のダンプ ターゲットを追加することで、複数のアプリケーション プールのダンプを作成できます。

この規則では、11 個のダンプ ファイルが作成されます。 最初の 10 個は、サイズが非常に小さい "ミニ ダンプ" になります。 最後のダンプは完全なメモリ ダンプで、サイズがはるかに大きくなります。

CPU 使用率が高くなる問題が発生したら、Perfmon データ コレクター セットによるデータの収集を停止する必要があります。 これを行うには、User Defined ノードの下にリストされている High CPU データ コレクター セットを右クリックし、Stop を選択します。

データ分析

高 CPU イベントが発生したら、Perfmon データ コレクター セットとメモリ ダンプの 2 つを確認します。 まず、Perfmon データを確認します。

パフォーマンス データの分析

問題の Perfmon データを確認するには、User Defined ノードの下に一覧表示されている High CPU データ コレクター セットを右クリックし、[Latest Report] を選択します。 次のスクリーンショットのようなレポートが表示されます。

パフォーマンス モニター ウィンドウを示すスクリーンショット。

最初に、確認する明示的なカウンターを追加できるように、現在のすべてのカウンターを削除します。 一覧で最初のカウンターを選択します。 次に、リストの一番下までスクロールし、Shift キーを押しながら最後のカウンターを選択します。 すべてのカウンターを選択したら、Delete キーを押して削除します。

次の手順で、 Process / % プロセッサ時間カウンター を追加します。

  1. Perfmon の右ペインの任意の場所を右クリックし、[カウンターの追加 選択。
  2. Process オブジェクトを展開します。
  3. 一覧から % プロセッサ時間 を選択します。
  4. インスタンス <一覧からすべてのインスタンス> を選択します。
  5. [追加] を選択します。
  6. [OK] を選択します。

これで、データ コレクター セットの実行中にコンピューター上の各プロセスによって使用されたプロセッサ時間のグラフが表示されます。 最も高いレベルの CPU を使用していたプロセスを特定する最も簡単な方法は、Perfmon の強調表示機能を有効にすることです。

これを行うには、一覧で最初のカウンターを選択し、Ctrl + H キーを押します。これを行うと、選択したプロセスがグラフ上に太字の黒い線として表示されます。

CPU 使用率が最も高いプロセスが見つかるまで、キーボードの下矢印を使用してプロセスの一覧を下に移動します。 次のスクリーンショットでは、w3wp.exe プロセスがマシンで大量の CPU を使用していたことがわかります。 これにより、コンピューターの CPU 使用率が高くなっていたのは IIS アプリケーション プールが原因であったことが確認されます。

パフォーマンス モニター ウィンドウを示すスクリーンショット。Perfmon は、w 3 w p 実行可能ファイルの C P U 使用法を示しています。

ヒント

Perfmon は、アプリケーションのパフォーマンス上の問題を特定するのに非常に役立ちます。 Perfmon ログで収集されたデータは、ASP.NET オブジェクトと ASP.NET アプリケーション オブジェクトを使用して実行されている要求の数を示すことができます。また、アプリケーションのパフォーマンスに関するその他の重要なパフォーマンス データを表示することもできます。

CPU 使用率の高い問題の根本原因を調べるには、DebugDiag を使用して作成されたダンプを確認します。

DebugDiag を使用したダンプ分析

DebugDiag には、自動化されたダンプ分析を実行して多くの問題を認識する機能があります。 この特定の問題に対して、DebugDiag のパフォーマンス アナライザーは、CPU 使用率の高い問題の根本原因を特定するのに適しています。 アナライザーを使用するには、次の手順に従います。

  1. DebugDiag の [ Advanced Analysis タブを選択します。
  2. パフォーマンス アナライザーを選択。
  3. [データ ファイル 追加を選択します。
  4. ダンプが作成された場所にブラウザーでアクセスします。 既定では、これは C:\Program Files\DebugDiag\Logs フォルダーのサブフォルダーになります。
  5. ダンプの 1 つを選択し、Ctrl キーを押しながら A キーを押して、そのフォルダー内のすべてのダンプを選択します。
  6. [Open] を選択します。
  7. 分析の開始を選択します。

DebugDiag では、ダンプを解析して分析を行うのに数分かかります。 分析が完了すると、次の図のようなページが表示されます。

Internet Explorer を示すスクリーンショット。デバッグ診断分析レポート ページが表示されます。

レポートの上部に、高い CPU が検出されたことが示されていることに注意してください。 右側の列には、平均 CPU 時間別に上位 7 つのスレッドへのリンクを含む推奨事項が表示されます。 そのリンクを選択すると、上位の CPU コンシューマーが何を行っていたかについての情報が表示されます。 たとえば、次のスクリーンショットは、アプリケーションでこれらのスレッドが実行している内容を示しています。

ブラウザーの [Functions Stats] ページを示すスクリーンショット。

このサンプルでは、FastApp アプリケーションの default.aspx ページが実行されています。 (ページの下部にある) 呼び出し履歴をさらに下に見ると、このスレッドが文字列連結を行っていることがわかります。 (呼び出し履歴で System.String.Concat への呼び出しに注意してください)。他の上位 CPU スレッドを分析すると、同じパターンが表示されます。

次の手順では、FastApp アプリケーションのdefault.aspx ページでPage_Load イベントを確認します。 これにより、次のコードが見つかります。

htmlTable += "<table>";
for (int x = 0; x < 5000; x++)
{
htmlTable += "<tr>" + "<td>" + "Cell A" + x.ToString() + "</td>";
    htmlTable += "<td>" + "Cell B" + x.ToString() + "</td>" + "</tr>";
}
htmlTable += "</table>";

この種のコードは間違いなく高い CPU の原因となります。

まとめ

Perfmon と DebugDiag を使用すると、アプリケーション プールで CPU が高くなっている原因を特定するのに役立つデータを簡単に収集できます。 これらの手法を使用して根本原因が見つからない場合は、Microsoft サポートにお問い合わせください。 Microsoft サポート エンジニアは、問題の原因の特定に役立ちます。 ケースを開くときに Perfmon データとダンプを準備することで、エンジニアが支援するために必要な時間を大幅に短縮できます。

その他のリソース