场景:生产服务器上一堆 dotnet QH.xxx.dll 进程,ps 里发现某个进程 CPU
常年很高(比如 ****AutoTask.dll 占 32.5%),想知道它到底在跑什么代码。
本文记录从零开始,用微软官方 dotnet-trace / dotnet-counters 工具,把
CPU 热点定位到具体 C# 方法的完整过程,以及踩过的坑。
一、先搞清楚:三个层次的排查手段
ps / top -H
能看到:哪个进程/线程在烧 CPU
需装工具:否 影响:无
strace -c
能看到:在做哪些系统调用(read/futex/write)
需装工具:否 影响:采样期间轻微
dotnet-counters
能看到:CPU%、GC、线程池、锁竞争等运行时指标
需装工具:是 影响:几乎无(只读)
dotnet-trace
能看到:精确到 C# 方法的 CPU 火焰图
需装工具:是 影响:采样期 CPU 略升 5~15%
dotnet-dump
能看到:每个线程当前的托管调用栈
需装工具:是 影响:抓转储瞬间短暂冻结几秒
排查顺序:top -H 定位线程 -> dotnet-counters 定性 -> dotnet-trace 定位方法
二、安装诊断工具(.NET 3.1 有大坑)
2.1 先确认运行时版本
which dotnet
dotnet --version # 例如 3.1.412
2.2 坑:新版工具跑不起来
dotnet tool install --global dotnet-trace
# error NU1202: 包 dotnet-trace 9.0.x 与 netcoreapp3.1 不兼容,只支持 net8.0
原因:新版工具本身是用 .NET 8 编译的,而机器只有 .NET 3.1 运行时,
工具装上也跑不起来。--framework netcoreapp3.1 也没用,因为新版包里根本没有 3.1 的。
2.3 解法:钉住支持 3.1 的最后版本(5.0.x)
dotnet tool install --global dotnet-trace --version 5.0.251802
dotnet tool install --global dotnet-counters --version 5.0.251802
# 关键:把工具目录加进 PATH(否则 command not found)
export PATH="$PATH:$HOME/.dotnet/tools"
# 验证
dotnet-trace --version
版本对照记忆:
.NET 3.1 -> 用工具 5.0.x
.NET 6 -> 用工具 6.0.x
.NET 8+ -> 用最新版
工具版本要能被目标机器的运行时跑起来。
2.4 安装对现有服务有影响吗?
几乎零影响。dotnet tool install --global 只往 ~/.dotnet/tools/ 下载
几个可执行文件:
- 不碰系统、不改配置、不重启任何服务
- 现有的所有 dotnet 服务继续正常跑
- 不要了 dotnet tool uninstall --global dotnet-trace 删干净,无残留
- export PATH 只对当前终端有效,关了就没了
运行诊断时才有轻微影响,且只影响你指定的那一个 PID:
- dotnet-counters : 只读,随便用
- dotnet-trace : 采样期 CPU 略升,不暂停服务,可接受
- dotnet-dump collect : 抓转储瞬间短暂冻结进程几秒,别在业务高峰做
三、第一步:用 counters 定性
dotnet-counters monitor -p <PID> # 看完按 q 退出
重点看这几行:
CPU Usage (%) 确认是否真的高
GC Heap Size / Gen 2 GC Count 频繁涨 = 在狂建对象
Monitor Lock Contention Count 高 = 锁竞争严重
ThreadPool Thread Count / Queue 暴涨 = 任务堆积
Allocation Rate 分配速率,高 = 内存压力大
四、第二步:用 trace 采样火焰图
# 采 30 秒;注意工具会自动加后缀,最终文件是 trace.speedscope.json
dotnet-trace collect -p <PID> --duration 00:00:30 --format speedscope -o /tmp/trace.json
把生成的 /tmp/trace.speedscope.json 下载到本地电脑:
scp root@<服务器IP>:/tmp/trace.speedscope.json .
浏览器打开 https://www.speedscope.app (纯前端,不上传数据),
把 json 拖进去。
五、【核心】怎么读懂火焰图
speedscope 顶部有三个视图,主要用前两个。
5.1 Left Heavy 视图(最常用)
点顶部 "Left Heavy",它把相同调用栈合并,按耗时从大到小、从左往右排。
- 最左边、最宽的柱子 = 最耗 CPU 的代码路径
- 横轴 = 占 CPU 时间比例(越宽越费)
- 纵轴 = 调用深度(从下往上 = 谁调用谁)
- 从最宽那根底部往上点,直到看见自己的业务代码 QH.xxx.xxx(),
那就是热点
5.2 Time Order 视图(看死循环/周期性)
- 某方法铺满整条时间轴、连续不断 -> 大概率死循环 / 无间隔轮询
- 一段一段规律出现 -> 定时任务周期性跑,正常
5.3 【关键技巧】看 Self 判断"真忙 vs 假忙"
左下角面板:
Total = 这根栈总耗时
Self = 真正在这个方法自身消耗的 CPU
Self 接近 0 = 假忙(在等待/睡觉)
Self 很大 = 真忙(在烧 CPU)
5.4 读图对照表
栈顶 ManualResetEventSlim.Wait / Thread.Sleep,Self≈0
-> 空闲,睡觉等活。不是问题,换时机采
栈顶 QH.xxx.业务方法,Self 很宽
-> 真忙,元凶。看那方法的循环/算法
栈顶 System.Data.SqlClient / Npgsql 很宽
-> 卡数据库查询。抓慢 SQL、加索引
栈顶 Newtonsoft.Json / 序列化 很宽
-> 狂转 JSON。大对象序列化,分页/缓存
栈顶 System.Threading / Monitor.Wait
-> 等锁/空转。看锁竞争
栈顶 System.GC / GCHeap 很宽
-> 疯狂 new 对象触发频繁 GC。找循环里建对象的地方
全是 [native] 看不到方法名
-> 符号缺失。改用 dotnet-dump + clrstack
六、【踩坑实录】抓到一张"空闲"的火焰图
实测时对一个进程采样,speedscope 里只有一根柱子:
************.Program.Main()
-> HostExtensions.Run() 启动后挂起,等关闭信号
-> TaskAwaiter.GetResult()
-> Task.InternalWaitCore()
-> Task.SpinThenBlockingWait()
-> ManualResetEventSlim.Wait() 在这里"睡着"等着
-> UNMANAGED_CODE_TIME
左下角:Total 29.79s,但 Self <0.01%(202 纳秒)。
解读:这是每个 .NET 后台服务空闲时的标准姿势——主线程停在
Host.Run() 的 ManualResetEventSlim.Wait() 上等待关闭信号。
Self≈0 就是铁证:这 30 秒里进程根本没干活。
为什么?——采样时机不对!
ps 里看到的 6.5% 是进程开机以来 76 小时的平均值,不代表此刻在忙。
采样的这 30 秒它刚好空闲,所以只拍到"睡觉"的样子。
>>> 性能采样第一铁律:必须在它"正在飙 CPU 的那一刻"采样,采到的才有用。
七、【关键】怎么抓到"正在飙高"的现场
方法 A:手动踩点
# 终端1:盯着线程级 CPU
top -H -p <PID>
# 终端2:一看到飙高,立刻采(趁它还在忙)
dotnet-trace collect -p <PID> --duration 00:00:30 --format speedscope -o /tmp/hot.json
方法 B:自动蹲守脚本(推荐,尤其偶发飙高)
------------------------------------------------------------------------
#!/bin/bash
# watch_and_trace.sh 用法: ./watch_and_trace.sh <PID> [阈值]
# 例: ./watch_and_trace.sh 15515 30
PID=$1
THRESHOLD=${2:-30} # CPU 超过 30% 就采样
export PATH="$PATH:$HOME/.dotnet/tools"
echo "盯着 PID=$PID,CPU 超过 ${THRESHOLD}% 就自动采样..."
while true; do
CPU=$(ps -p $PID -o %cpu= | tr -d ' ' | cut -d. -f1)
if [ -n "$CPU" ] && [ "$CPU" -ge "$THRESHOLD" ]; then
TS=$(date +%H%M%S)
echo "$(date) 命中!CPU=${CPU}%,开始采样..."
# 顺手存一份线程级 CPU 快照,知道是哪个线程在烧
top -H -b -n 1 -p $PID | head -30 > /tmp/threads_$TS.txt
# 采 30 秒火焰图
dotnet-trace collect -p $PID --duration 00:00:30 --format speedscope \
-o /tmp/hot_$TS.json
echo "完成:/tmp/hot_$TS.speedscope.json + /tmp/threads_$TS.txt,继续蹲守..."
fi
sleep 3
done
抓到真正忙的现场后,火焰图里就会出现又宽、Self 又大的柱子,
栈顶是 QH.xxx 的业务方法——那就是元凶。
八、备选:火焰图符号不全时,用 dump 看线程栈
如果火焰图里全是 [native] 看不到方法名:
# 注意:抓转储瞬间会冻结进程几秒,别在高峰做
dotnet-dump collect -p <PID> -o /tmp/dump.dmp
dotnet-dump analyze /tmp/dump.dmp
进入 > 提示符后:
threads 列出所有线程
clrstack -all 打印所有线程的托管调用栈 <- 核心
exit 退出
在输出里搜业务命名空间(如 QH.JQAutoTask),看高 CPU 线程停在哪个方法。
九、完整排查清单(TL;DR)
1. ps -aux | grep <关键字> 找到当前 PID(进程可能重启换号,别用旧 PID)
2. dotnet tool install --global dotnet-trace --version 5.0.251802(.NET 3.1)
+ export PATH="$PATH:$HOME/.dotnet/tools"
3. dotnet-counters monitor -p PID 定性:CPU 高不高?GC/锁多不多?
4. 等 CPU 真飙起来时(手动 top 盯 / 蹲守脚本)采样:
dotnet-trace collect -p PID --duration 00:00:30 --format speedscope -o /tmp/hot.json
5. speedscope -> Left Heavy -> 找最宽 + Self 大的柱子 -> 一路点到 **.xxx 业务方法
6. 对照读图表下结论(死循环 / 慢 SQL / 疯狂 GC / 锁等待)
十、核心经验(最容易忽略的三点)
1. 工具版本要匹配运行时:.NET 3.1 只能用 5.0.x 的 dotnet-trace,
新版跑不起来。
2. Self 才是关键:Total 大不代表在烧 CPU,Self 大才是真忙。
栈顶是 Wait/Sleep 且 Self≈0 = 空闲。
3. 采样时机决定成败:必须在 CPU 峰值那一刻采样。空闲时采到的全是
Host.Run -> Wait,毫无价值。用蹲守脚本自动踩点最省心。
10个月宝宝每天需要喝多少奶粉？
