.NET Core で高い CPU 使用率をデバッグする

この記事の対象: ✔️ .NET Core 3.1 SDK 以降のバージョン

このチュートリアルでは、過剰な CPU 使用率のシナリオをデバッグする方法について説明します。 示されている例の ASP.NET Core Web アプリ ソース コード リポジトリを使用して、デッドロックを意図的に発生させることができます。 エンドポイントは応答を停止し、スレッドが累積されます。 さまざまなツールを使用して、診断データのいくつかの重要な部分でこのシナリオを診断する方法について説明します。

このチュートリアルでは、次の作業を行います。

必須コンポーネント

このチュートリアルでは次のものを使用します。

• .NET Core 3.1 SDK 以降のバージョン。
• シナリオをトリガーするサンプル デバッグ ターゲット
• dotnet-trace を使ってプロセスを一覧表示し、プロファイルを生成する
• dotnet-counters を使って CPU 使用率を監視する

CPU カウンター

診断データの収集を試行する前に、高い CPU 状態を確認する必要があります。 プロジェクトのルート ディレクトリから次のコマンドを使用して、サンプル アプリケーションを実行します。

dotnet run

このプロセス ID を検索するには、次のコマンドを使用します。

dotnet-trace ps

ご自分のコマンド出力からプロセス ID をメモしておきます。 プロセス ID は 22884 でしたが、この ID は異なります。 現在の CPU 使用率を確認するには、dotnet-counters ツール コマンドを使用します。

dotnet-counters monitor --refresh-interval 1 -p 22884

refresh-interval は、CPU 値をポーリングするカウンターの間隔を秒数で示します。 出力は次のようになります。

Press p to pause, r to resume, q to quit.
    Status: Running

[System.Runtime]
    % Time in GC since last GC (%)                         0
    Allocation Rate / 1 sec (B)                            0
    CPU Usage (%)                                          0
    Exception Count / 1 sec                                0
    GC Heap Size (MB)                                      4
    Gen 0 GC Count / 60 sec                                0
    Gen 0 Size (B)                                         0
    Gen 1 GC Count / 60 sec                                0
    Gen 1 Size (B)                                         0
    Gen 2 GC Count / 60 sec                                0
    Gen 2 Size (B)                                         0
    LOH Size (B)                                           0
    Monitor Lock Contention Count / 1 sec                  0
    Number of Active Timers                                1
    Number of Assemblies Loaded                          140
    ThreadPool Completed Work Item Count / 1 sec           3
    ThreadPool Queue Length                                0
    ThreadPool Thread Count                                7
    Working Set (MB)                                      63

Web アプリを実行している状態で、スタートアップ直後に CPU が使用されておらず、0% で報告されます。 ルート パラメーターとして 60000 を使用して api/diagscenario/highcpu ルートに移動します。

https://localhost:5001/api/diagscenario/highcpu/60000

次に、dotnet-counters コマンドを再実行します。 cpu-usage カウンターのみを監視する場合は、前のコマンドに '--counters System.Runtime[cpu-usage]' を追加します。 CPU が使用されているかどうかは不明であるため、上記と同じカウンターの一覧を監視して、カウンター値がアプリケーションに予期される範囲内であることを確認します。

dotnet-counters monitor -p 22884 --refresh-interval 1

次に示すように、CPU 使用率の増加が表示されます (ホスト マシンにより、さまざまな CPU 使用率が想定されます)。

Press p to pause, r to resume, q to quit.
    Status: Running

[System.Runtime]
    % Time in GC since last GC (%)                         0
    Allocation Rate / 1 sec (B)                            0
    CPU Usage (%)                                         25
    Exception Count / 1 sec                                0
    GC Heap Size (MB)                                      4
    Gen 0 GC Count / 60 sec                                0
    Gen 0 Size (B)                                         0
    Gen 1 GC Count / 60 sec                                0
    Gen 1 Size (B)                                         0
    Gen 2 GC Count / 60 sec                                0
    Gen 2 Size (B)                                         0
    LOH Size (B)                                           0
    Monitor Lock Contention Count / 1 sec                  0
    Number of Active Timers                                1
    Number of Assemblies Loaded                          140
    ThreadPool Completed Work Item Count / 1 sec           3
    ThreadPool Queue Length                                0
    ThreadPool Thread Count                                7
    Working Set (MB)                                      63

要求の期間中、CPU 使用率は上昇したパーセンテージで推移します。

この時点で、CPU が予想以上に高くなっていることを確認できます。 問題の影響を特定することは、原因を見つけるための鍵となります。 診断ツールに加えて、高い CPU 使用率の影響を使って、問題の原因を見つけます。

プロファイラーで高い CPU 使用率を分析する

高い CPU 使用率のアプリを分析する場合は、コードの実行内容に関する分析情報を提供できる診断ツールが必要です。 通常はプロファイラーが適しており、さまざまなプロファイラー オプションを選択できます。 dotnet-trace はすべてのオペレーティング システムで使用できますが、セーフポイント バイアスとマネージドのみの呼び出し履歴の制限により、Linux の 'perf' や Windows の ETW などのカーネルを認識するプロファイラーと比較すると、より一般的な情報になります。 パフォーマンス調査がマネージド コードのみであれば、通常、dotnet-trace で十分です。

export DOTNET_PerfMapEnabled=1
dotnet run

sudo perf record -p 2266 -g

sudo perf report -f

git clone --depth=1 https://github.com/BrendanGregg/FlameGraph
sudo perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > flamegraph.svg

dotnet-trace collect -p 22884 --providers Microsoft-DotNETCore-SampleProfiler

Visual Studio で高い CPU 使用率データを分析する

すべての *.nettrace ファイルは、Visual Studio で分析することができます。 Linux の *.nettrace ファイルを Visual Studio で分析するには、*.nettrace ファイルとその他の必要なドキュメントを Windows マシンに転送し、*.nettrace ファイルを Visual Studio で開いてください。 詳細については、「CPU 使用率データを分析する」を参照してください。

関連項目

• dotnet-trace を使ってプロセスを一覧表示する
• dotnet-counters を使ってマネージド メモリ使用量を確認する
• dotnet-dump を使ってダンプ ファイルを収集して分析する
• dotnet/診断

次の手順