调试 .NET Core 中的高 CPU 使用率
本文适用于： ✔️ .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 就足够了。
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 以调查性能问题：
使用 Visual Studio 分析高 CPU 数据
可以在 Visual Studio 中分析所有 *.nettrace 文件。 若要在 Visual Studio 中分析 Linux *.nettrace 文件，除了其他必要的文档外，还要将 *.nettrace 文件传输到 Windows 计算机，然后在 Visual Studio 中打开 *.nettrace 文件。 有关详细信息，请参阅分析 CPU 使用量数据。
请参阅
- 用于列出进程的 dotnet-trace
- 用于检查托管内存使用情况的 dotnet-counters
- 用于收集和分析转储文件的 dotnet-dump
- dotnet/diagnostics
后续步骤
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈