操作系统内功 · 第 10 篇｜性能观测方法论：USE 方法、火焰图与 P99 尾延迟

「系统变慢了」是运维与后端接到的最难的工单：没有报错、没有变更、监控里全是绿色的，就是慢。这种时刻拼的不是谁工具装得多，而是谁有系统的排查方法论——先问对问题，再让工具回答。系列收官篇把三套底层功法讲透：Brendan Gregg 的 USE 方法、同样出自他手的火焰图，以及 Google 的尾延迟理论；最后加上压测圈最大的陷阱「协调遗漏」。这四件事合起来，就是「系统变慢」这个谜题的标准解法。

一、USE 方法：给每个资源问三个问题

USE 方法由性能工程大师 Brendan Gregg 提出，规则简单到可以背下来：对系统里的每一种资源，依次检查 Utilization（利用率）、Saturation（饱和度）、Errors（错误）。资源既包括 CPU、内存、磁盘、网络这些物理件，也包括连接池、锁队列、线程池这些软件件。它的力量在于把「系统变慢」这个开放问题压缩成一张有限矩阵——

排查就是逐行扫表：先扫 Errors（最便宜且指向明确），再扫 Saturation（排队是万恶之源），最后看 Utilization（高利用率未必是问题——瞬时突发同样制造饱和，平均利用率低也可能一直在打满核）。USE 是「减法」方法论：它不能直接告诉你答案，但能在十分钟内把怀疑范围从两千个指标砍到两三个。顺带一提，应用层监控的 RED 方法（速率、错误、耗时）是它在服务维度的对偶——两层方法论拼起来，从集群到内核就都有「必查清单」了。前九篇讲的每个机制——运行队列（第 1 篇调度器）、缺页与回收（第 2、3 篇）、脏页闸门（第 4 篇）、TIME_WAIT 队列（第 7 篇）、cgroup 压力信号（第 8 篇）——都是这张矩阵里某一格的底层原理。

二、工具分层与六十秒巡检

Gregg 的 Linux 性能观测图把工具按层次排好，巡检的最短路径大致是：uptime 看负载 → vmstat 1 看 CPU 与运行队列、si/so 换页 → pidstat 1 找出谁在吃 CPU/内存 → iostat -xz 1 看磁盘饱和 → sar -n DEV 1 看网络流量 → free -m 复核 available。这套六十秒巡检的价值不在深入，而在定向：它是 USE 矩阵的执行器，扫完就知道该把火力集中到 CPU、内存、磁盘还是网络。巡检之后的深入分析才轮到重武器——perf、eBPF 工具链，而重武器里的第一件叫火焰图。两个工具细节容易踩：iostat/pidstat/sar 来自 sysstat 包、vmstat/free 来自 procps，新机器别忘了装；mpstat -P ALL 1 看每核分布，个别核 si（软中断）畸高往往直指网络收包路径——第 5 篇的 epoll 与第 6 篇的零拷贝优化的收益，就是从这里量出来的。

三、火焰图：让热点自己浮出来

2011 年 12 月，Brendan Gregg 为了排查 MySQL 的 CPU 问题发明了火焰图，2013 年在 USENIX LISA 大会上做全体会议演讲公开，工具链开源在 FlameGraph 仓库，2016 年登上 CACM。它的设计天才之处只有一条：把成千上万个调用栈聚合成一张矩形图，横轴是 CPU 时间占比，纵轴是调用深度——宽度就是热度，哪个函数吃 CPU，一眼看出。读图的技巧只有一句：先找最宽的「平顶」——又宽又平的块意味着大量时间花在同一个叶子函数上，那就是优化的靶心。工具链生成的是可交互 SVG，点击可下钻展开调用子树；做优化前后对比还有差分火焰图（differential flame graphs），新增的热点直接标红。相比逐行翻 perf 输出，这是从「读日志」到「看图像」的降维。

但火焰图有个必须记住的边界：它默认只画 on-CPU 的时间——线程真正在 CPU 上烧的那部分。如果系统慢是因为「大家都在等」，CPU 利用率很低，火焰图却平平无奇。等，藏在另一半真相里。

四、off-CPU 分析：另一半真相

线程不在线程调度器「运行中」的时间——阻塞在 IO、锁、换页、定时器上——是 off-CPU 分析的对象，同样由 Gregg 倡导多年。把 on-CPU 与 off-CPU 两张图并排看齐，才能解释一个线程的 100% 时间去向。工程上 Linux 的 off-CPU 分析是 eBPF 成熟后才真正可用的：内核 4.8 起支持可靠的栈回溯，bcc 的 offcputime 在内核态聚合阻塞栈，开销低到可以常驻；perf 也能做（perf sched timehist），但开销大得多。两个已知的坑值得点名：编译器省略帧指针会让栈断链（编译时补 -fno-omit-frame-pointer，或改用 DWARF 栈回溯），解释型语言的 JIT 栈需要符号注入才能连起来。分析时还有个精度技巧： involuntary context switch（被调度器强制换下的时间）与主动等待要分开看——offcputime 支持 --state 2 只统计不可中断等待（TASK_UNINTERRUPTIBLE），那是最像「系统有问题」的一类。当火焰图与 off-CPU 图合起来还解释不了慢，才需要分布式追踪出场——那是应用层的功课，本系列的系统层结论是：先分层问对问题，再谈工具。

五、尾延迟：P99 为什么比均值重要

Google 的 Dean 与 Barroso 在 2013 年的 CACM 论文《The Tail at Scale》给出了大服务体系里最重要的一组观察：大规模服务的响应延迟由尾部决定，而不是均值。一次用户请求在服务端被拆成成百上千个并行子调用，只要其中一个落在 P99 那批慢样本里，整次响应就被拖长——个体的小概率尾部，在规模化之后成为整体的确定性代价——论文里最有冲击力的一条算术：请求拆成 1000 个并行子调用、每个子调用 99.9% 成功率，整体成功率只剩约 37%。更糟的是方差来源无处不在：共享资源的排队、后台任务抢核、垃圾回收、机械盘的寻道抖动，每个组件的微小方差在乘法下放大。更糟的是方差来源无处不在：共享资源的排队、后台任务抢核、垃圾回收、机械盘的寻道抖动，每个组件的微小方差在乘法下放大。

应对思路叫「尾容忍（tail tolerance）」，论文给了几个传世方案：hedged requests（对冲请求——主请求超时阈值未到就发第二份，谁先回用谁）、tied requests、把大请求切小的 micro-partitioning。对冲请求不是免费的：多发的副本要付出额外的算力与写入幂等成本，所以它有明确的适用边界——读多写少的扇出型请求收益最大，非幂等操作要先补幂等再谈对冲。SRE 侧的落地共识：SLA 按 P99/P999 定义而不是均值；容量评估盯住「慢样本的成因」而不是「快样本的平均」。均值会骗人，P99 会说实话——这句朴素的工程格言背后是整整一篇 CACM。

六、协调遗漏：你的压测可能在撒谎

最后一课是压测方法论的最大陷阱。协调遗漏（coordinated omission）由 Gil Tene 在 2015 年提出：闭环压测器（发一个请求、等响应回来、再发下一个）在被测系统卡顿时会「体贴地」暂停发送——系统最慢的时刻恰恰没有采样，坏样本被系统性漏掉。经典对照：压测报告 P99 约 47ms，生产真实 P99 逼近 1.8 秒——差的不是运气，是采样偏差。修正方法同样明确：压测器改为开环定速（按固定节拍发压，不管上一发回没回来），并把「应发未发」的样本按应发时刻记账；主流压测工具近年都补了此类模式，压测报告里值得专门标注用的是哪种。顺手澄清一对中文术语：「协调遗漏」是压测偏差，「协调开销」是分布式系统的另一回事，别混用。

七、工程落地清单

1. 把 USE 矩阵贴在事故文档第一页。逐格扫过再深入，避免「上来就猜」。
2. CPU 慢看火焰图，不烧 CPU 的慢看 off-CPU。两张图并排，时间账才完整。
3. 压测器必须是开环定速。闭环压测的 P99 默认按「偏乐观一个数量级」对待。
4. SLA 与告警一律按百分位。P99 上探先查：排队？锁？GC？后台任务抢核？
5. 常驻低开销观测。eBPF 系（offcputime、cachestat）与 PSI 适合常驻，perf 系留给专项深挖。
6. 每次排障产出一张新火焰图。热点会漂移，基线要常更新。

结语：系列的终点，排查的起点

十篇走过一圈：进程与调度给了你「谁在跑」，虚拟内存与分配器给了你「内存去哪了」，文件系统与 Page Cache 给了「数据在哪」，epoll 与零拷贝给了「数据怎么流」，TCP 给了「网络怎么走」，容器给了「边界怎么划」，eBPF 给了「怎么看」。收官这篇是把这些全部串起来的绳子：USE 方法提供问题的清单，火焰图与 off-CPU 提供显微镜，尾延迟与协调遗漏校准你的度量衡。操作系统内功的真正用处，从来不是背参数——而是在「没人改代码、系统却变慢」的那个凌晨，你手里有一条从现象直达机制的完整推理链。系列完结，排查从今天开始。

参考资料

• The USE Method — Brendan Gregg——USE 方法的原始定义与资源清单。
• Blazing Performance with Flame Graphs — Brendan Gregg——火焰图 2011 年发布与工具链的一手说明。
• The Flame Graph — Communications of the ACM——火焰图的正式论文（2016-06）。
• Off-CPU Analysis — Brendan Gregg——off-CPU 分析的定义、历史与工具坑。
• Linux Performance — Brendan Gregg——Linux 观测工具分层地图。
• The Tail at Scale — Dean & Barroso, CACM 2013——尾延迟理论的原始论文。
• Your Load Generator is Probably Lying to You — High Scalability——协调遗漏的引入性综述。
• On Coordinated Omission — ScyllaDB——开环修正的工程实践。