系统性能观测工作流：USE 方法与工具矩阵

一句话定义

性能观测是有纪律的诊断流程而非工具堆砌：先定义症状与指标，用 USE 方法（对每个资源检查利用率 Utilization、饱和度 Saturation、错误 Errors）系统扫描，再按"从粗到细、从计数器到追踪"逐层下钻，全程警惕观测者效应。

为什么重要

操作系统知识 80% 的价值在诊断现场兑现。面对"服务变慢"，无纪律者的动作是胡乱重启与盲调参数；有纪律者的动作是一条可复现的证据链。本节把前 30 个知识点的机制全部翻译成"看哪个指标、用什么命令、怀疑什么根因"的行动手册，是全库的实践收束点。

前置知识

kp-003（strace 的原理）；kp-006（切换与 CPU 指标语义）；本库其余知识点按需回查。

核心概念

• 症状与指标：延迟（latency）、吞吐（throughput）、利用率（utilization）——先问"慢在哪一层"（应用/内核/硬件）。
• USE 方法：遍历资源清单（CPU/内存/存储/网络/设备），逐项查利用率、饱和度、错误。
• RED/负载特征化：谁在负载（who）、调用什么（what）、为何慢（why）。
• 工具金字塔：计数器（vmstat/iostat）→ 剖析（perf）→ 追踪（strace/eBPF）→ 实验（对照变更）。
• 观测者效应：strace 让 syscall 翻倍慢、perf 改变缓存行为——工具本身是干扰源。
• 长尾意识：平均值掩盖 99 分位，p99 才是用户体验（The Tail at Scale）。

原理与机制

一次"服务 CPU 100%、延迟升高"的标准下钻链：

uptime && vmstat 1        # 1. load 与 runqueue 饱和度; us高=应用, sy高=内核路径
mpstat -P ALL 1           # 2. 是否单核热点(单线程瓶颈)还是全核均匀
pidstat -u 1              # 3. 定位到进程; -t 再定位到线程
pidstat -w -p <pid> 1     # 4. 自愿/非自愿切换: 非自愿高=CPU 被抢, 自愿高=等锁等IO
strace -c -p <tid>        # 5. 系统调用分布(生产慎用, 10-100x 降速)  -> kp-003
perf top -p <pid>         # 6. 热点函数定位(采样剖析, 开销<5%)
perf trace -p <tid>       # 7. 低开销版 strace

每一步都有明确的分支逻辑：us 高走应用剖析（perf flamegraph）；sy 高查 syscall 分布与锁（kp-012 争用）；wa 高转 I/O 链（iostat await → kp-022）；非自愿切换高可能是超售或优先级问题（kp-010）。eBPF（bcc/bpftrace）是现代终点：内核内安全插桩，可用一行脚本统计"哪个进程在为哪个文件的哪个偏移做读"，开销与粒度兼得。

图示

诊断漏斗:  症状(用户投诉)
            -> 指标分层(网络? 应用? 内核? 磁盘?)     vmstat/ss/应用埋点
            -> 资源扫描(USE: CPU/内存/IO/网络)      mpstat/free/iostat
            -> 进程定位(pidstat) -> 线程 -> 栈(perf)
            -> 机制归因(切换? 锁? 缺页? syscall?)   本库各章知识回查
            -> 验证(对照实验/压测复现)

直观类比

性能诊断像医生问诊：vmstat 是量体温血压（全身指标），pidstat 是分诊到科室（进程），perf 是影像检查（热点函数），strace/eBPF 是内窥镜（逐调用直视）——没有医生跳过问诊直接开刀，也没有性能诊断跳过 USE 直接改内核参数。

实例或案例

复现一次完整诊断（Linux + sysstat + perf）：

stress-ng --cpu 2 --timeout 60 &     # 制造 CPU 症状
vmstat 1                             # us 飙升, id 归零
pidstat -u 1 | sort -k8 -r | head    # 锁定 stress-ng
perf top -U                          # 热点在其计算循环 -> 归因完成

对内存症状的分支：free -h 看 available → vmstat 看 si/so（kp-018 抖动）→ ps rss 找大户 → pmap -x 看其分布 → 疑泄漏则用 bpftrace 追踪 malloc 路径（kp-019）。

常见误区

• 盯平均值做容量决策：p99/p999 决定体验，多租户与队列系统尤其如此（Tail at Scale）。
• 在生产高频使用 strace：它使目标进程每次 syscall 停顿两次，10 倍以上减速，应改用 perf trace 或 eBPF。
• 无基线调优：没有变更前的对照数据，"优化"与"过拟合某次抖动"无法区分。

与其他知识点的关系

本节是 kp-003/006/010/018/019/022/027 的行动化出口；eBPF 的安全插桩机制连接 kp-030 的可编程内核与最小权限设计。

延伸阅读

Brendan Gregg《Systems Performance》第 2 章（方法论）；USE 方法官方清单；The Tail at Scale（CACM 2013）。

自测题

1. USE 方法的三个字母分别检查什么？

答：Utilization 利用率（资源忙的时间占比）、Saturation 饱和度（排队/等待的额外工作量）、Errors 错误（失败与重试）——对每个资源逐项扫描。

1. 为什么生产环境慎用 strace？

答：每次系统调用引入两次进程停顿（ ptrace 机制），syscall 密集进程可被拖慢 10~100 倍；应改用采样式的 perf trace 或内核内插桩的 eBPF。

1. vmstat 显示 sy（系统态 CPU）持续 60%，下钻的第一步是什么？

答：怀疑内核路径繁忙——用 strace -c 或 perf trace 看 syscall 分布（哪个调用最多），再用 perf 找内核热点函数，对应锁争用或某驱动路径。