本页目录

工具都会用，排障为什么还是慢

线上告警响了。CPU 不高，磁盘没满，网络没报错。服务就是慢。五个人盯了两小时，每人猜的方向不同——有人查 GC，有人查连接池，有人翻变更记录。最后发现是内核调度延迟。off-CPU 时间占了请求延迟的 70%。

排障效率低，原因很少是工具不够。mpstat、perf、tcpdump 都会敲。卡住的地方在上游：没有一条稳定的分析顺序。从哪里开始、什么时候排除、什么时候切工具、什么时候停下来——这些决策缺一个骨架。

Brendan Gregg 花了二十年做系统性能工程。他把排障顺序提炼成了可重复的方法。

USE：利用率、饱和度、错误

排障起手，Gregg 给了一个极简框架。对每种资源，依次检查三项：

顺序有讲究。利用率判断资源有没有被占用；饱和度判断请求有没有开始堆积；错误判断有没有直接丢。三项走完，至少能锁定问题落在哪一类资源上。

USE 最大的作用是防遗漏。它逼你对 CPU、内存、磁盘、网络逐项过一遍，而不只盯最顺手的指标。

CPU 利用率 80%——在干活还是在空转？

请求延迟 200ms——花在执行还是花在等锁？

Gregg 反复做的一个分析动作：延迟分解。把时间拆成 on-CPU（线程在处理器上执行）和 off-CPU（线程等待调度、I/O、锁、网络），然后分别追因。

大量看起来「CPU 很忙」的场景，延迟大头落在 off-CPU。反过来，CPU 不忙也不代表没有瓶颈。区分这两类时间，是后续所有分析的起点。

perf 做 CPU 采样。Ftrace 追内核函数调用链。BPF 做动态插桩，能在内核和用户态打自定义探针。火焰图把采样堆栈可视化。

选工具的依据是「当前缺什么视角」。profile 补 CPU 时间分布；trace 补事件级因果；计数器补趋势和统计。问题类型不同，需要的视角不同。

先跑工具再找问题，是排障效率最低的路径。

第二版最大的增量，是把分析方法扩展到了可见性残缺的环境。云实例、容器、托管服务，底层经常摸不到。

Gregg 的应对：切换证据类型。拿不到宿主机指标，用实例间对比；看不见内核细节，用 cgroup 配额和 steal time；缺全链路数据，用入口延迟分布和版本前后差异。

「看不全」在现代基础设施里是默认条件。方法如果只在完美可见性下成立，工程价值就打折扣。

后端工程师、SRE、平台工程师、DBA——日常包含排障和性能优化的人，Gregg 的方法骨架能直接嵌入工作流。

如果还在补操作系统基础，或工作不涉及系统层排障，八百页的密度可以排到后面。没有系统背景，读起来会吃力。