调试 .NET Core 中的高 CPU 使用率

项目
05/10/2023

本文适用于： ✔️ .NET Core 3.1 SDK 及更高版本

本教程将介绍如何调试 CPU 使用率过高的情况。使用提供的示例 ASP.NET Core Web 应用源代码存储库，可以故意造成死锁。终结点将停止响应并遇到线程累积问题。你将了解如何使用各种工具，通过几条关键的诊断数据诊断此情况。

在本教程中，你将：

调查 CPU 使用率是否过高
使用 dotnet-counters 确定 CPU 使用率
使用 dotnet-trace 进行跟踪生成
PerfView 中的配置文件性能
诊断并解决 CPU 使用率过高的问题

先决条件

本教程使用：

.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 使用率

当分析具有高 CPU 使用率的应用时，需要一个诊断工具来提供代码正在执行的操作的见解。常见的选择是探查器，并且有不同的探查器选项可供选择。 dotnet-trace 可以在所有操作系统上使用，但是，与 Linux 或适用于 Windows 的 ETW 的“perf”等内核感知探查器相比，其安全点偏差和仅限托管的调用堆栈的限制产生的信息更加笼统。如果性能调查仅涉及托管代码，通常 dotnet-trace 就足够了。

Linux
Windows

perf 工具可用于生成 .NET Core 应用配置文件。我们将演示此工具，尽管也可以使用 dotnet-trace。退出示例调试目标的上一个实例。

设置 DOTNET_PerfMapEnabled 环境变量，使 .NET 应用在 /tmp 目录中创建 map 文件。 perf 使用此 map 文件按名称将 CPU 地址映射到 JIT 生成的函数。有关详细信息，请参阅导出 perf 映射和 jit 转储。

注意

.NET 6 为用于配置 .NET 运行时行为的环境变量标准化前缀 DOTNET_ 而不是 COMPlus_。但是，COMPlus_ 前缀仍将继续正常工作。如果使用的是早期版本的 .NET 运行时，则环境变量仍应该使用 COMPlus_ 前缀。

在同一终端会话中运行示例调试目标。

export DOTNET_PerfMapEnabled=1
dotnet run

再次使用高 CPU API (https://localhost:5001/api/diagscenario/highcpu/60000) 终结点。当它在 1 分钟请求内运行时，对进程 ID 运行 perf 命令：

sudo perf record -p 2266 -g

perf 命令将启动性能收集过程。让它运行大约 20-30 秒，然后按 Ctrl+C 退出收集过程。可以使用相同的 perf 命令来查看跟踪的输出。

sudo perf report -f

还可以使用以下命令生成 flame-graph：

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

此命令生成 flamegraph.svg，你可以在浏览器中查看 flamegraph.svg 以调查性能问题：

在 Windows 上，可以使用 dotnet-trace 工具作为探查器。使用之前的示例调试目标，再次使用高 CPU (https://localhost:5001/api/diagscenario/highcpu/60000) 终结点。当它在 1 分钟请求内运行时，使用 collect 命令，并包含 providers 选项来指定所需的提供程序：Microsoft-DotNetCore-SampleProfiler，以便收集应用的跟踪，如下所示：

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

让 dotnet-trace 运行大约 20-30 秒，然后按 Enter 退出收集。结果是位于同一文件夹中的 nettrace 文件。 nettrace 文件是在 Windows 上使用现有分析工具的好方法。

使用 PerfView 打开 nettrace：导航到 samples/core/diagnostics/DiagnosticScenarios/，单击 nettrace 文件旁边的箭头。打开“线程时间(使用 StartStop 活动)堆栈”，然后选择顶部附近的“CallTree”选项卡。选中其中一个线程左侧的框后，文件应该与下图类似。

使用 Visual Studio 分析高 CPU 数据

可以在 Visual Studio 中分析所有 *.nettrace 文件。若要在 Visual Studio 中分析 Linux *.nettrace 文件，除了其他必要的文档外，还要将 *.nettrace 文件传输到 Windows 计算机，然后在 Visual Studio 中打开 *.nettrace 文件。有关详细信息，请参阅分析 CPU 使用量数据。

请参阅

用于列出进程的 dotnet-trace
用于检查托管内存使用情况的 dotnet-counters
用于收集和分析转储文件的 dotnet-dump
dotnet/diagnostics

后续步骤

调试 .NET Core 中的死锁

通过