3. 性能分析方法论
本章目标
- 掌握 USE 方法：对任何资源做 Utilization / Saturation / Errors 三连问
- 掌握工作负载特征化：先问"是什么负载"，再问"为什么慢"
- 能把一句"存储慢了"的口头投诉转化为可执行的排查流程
工具是武器，方法论是作战地图。没有方法论的排查叫"碰运气"：跑 20 个命令，总有一个看起来不对。
3.1 USE 方法
对每一种资源依次问三个问题 —— This is your "不知道从哪开始"时的万能起手式：
text
for 资源 in [CPU, 内存, 网卡, 磁盘, ...]:
Utilization 使用率：资源忙的时间比例
Saturation 饱和度：排队/挤压程度
Errors 错误： 计数器是否非零以存储运维最相关的两类资源为例：
| 资源 | Utilization | Saturation | Errors |
|---|---|---|---|
| 磁盘设备 | iostat 的 %util（注意并行失真） | aqu-sz、await 超基线 | dmesg 介质错误、smartctl |
| 网络接口 | 带宽占用率（sar -n DEV） | 重传率上升、ss -ti 的 retrans | ip -s link 的 errs/dropped |
USE 的价值在于完备性：遍历资源 × 三问，你不会漏掉某个没检查的角落。它定位"系统资源问题"很有效，但它不回答"该不该做这么多工作"—— 那是工作负载特征化的任务。
3.2 工作负载特征化
一半的"性能问题"其实是"容量问题"。 特征化五问：
- 谁：哪个进程/哪个客户端/哪个租户在产生负载？（
pidstat -d、ss -ti、网关日志） - 什么操作：读还是写？随机还是顺序？4K 还是 1M？
- 多少：IOPS 多少？带宽多少？
- 何时：持续还是突发？和业务高峰重合吗？（sar 历史回放）
- 预期：业务方认为应该是多少？实际差多少倍？
问完这五个问题，方向自然清楚：负载比预期高 10 倍 → 找业务方（可能是某个定时任务配错了）；负载正常但延迟高 → 回到 USE 方法查资源。
3.3 假设驱动的排查循环
text
现象 ──▶ 列出候选假设 ──▶ 选"最便宜可验证"的假设 ──▶ 验证
│
更新/排除假设 ◀── 证据 ◀───────────────┘关键纪律：
- 一次只验证一个假设，别同时动三个变量
- 每个结论附一条工具输出（呼应第 2 章"证据链"）
- 假设被推翻是进展，不是失败 —— 排除法在收窄范围
实战案例：虚拟机磁盘慢
现象：某虚拟机用户反馈写文件慢。
| 假设 | 验证手段 | 结果 |
|---|---|---|
| H1: 虚拟机内文件系统满 | df -i / df -h | 排除（空间、inode 充足） |
| H2: 虚拟机内 CPU 饱和 | vmstat 1 的 r 列 | 排除 |
| H3: 后端存储慢 | 宿主机 iostat -x | 待定：await 略高但未爆表 |
| H4: 网络链路劣化 | ss -ti retrans | 命中：重传率 8%，正常 <0.1% |
| H5: 虚拟机内存压力换页 | vmstat 的 si/so | 排除 |
根因：交换机端口故障导致重传。修复后延迟恢复。注意 H3"略高但未爆表"如果先被当成根因，就会走弯路 —— 略异常的指标是线索，不是结论。
3.4 排查流程图
把 USE + 特征化 + 假设循环拼成一张实用的图：
text
"存储慢了"
│
├─ Q1 范围：所有客户端慢 or 个别？ ──▶ 集群问题 / 单节点问题 / 单卷问题
├─ Q2 负载：IOPS/带宽比基线高吗？ ──▶ 高 → 特征化五问（找业务）
│ 低 → 继续
├─ Q3 USE：遍历资源三问（盘/网/内存/CPU） ──▶ 饱和/错误 → 定位到资源
└─ Q4 追踪：长尾在哪一层？ ──▶ biosnoop/fileslower/offcputime3.5 基线与容量规划
- 基线（baseline）：系统正常时的关键指标采样（IOPS、延迟分布、带宽、重传率）。没有基线就没有"异常" —— 0.8ms 的 await 是好是坏，取决于这块盘平时是 0.3ms 还是 0.9ms
- 怎么建：部署完成后立刻用 第 2 章体检 Lab 采集存档；开启 sysstat 让 sar 持续记录
- 容量水位：为第二篇的容量规划埋伏笔 —— 性能也要看水位（如 peak IOPS 的 60%），不只是容量百分比
本章小结
- USE 方法保证不漏查；工作负载特征化保证不误诊（负载问题 ≠ 资源问题）
- 假设驱动 + 单变量验证 + 证据链，是生产排障的职业习惯
- 基线是"异常"的定义来源，第一天就要建
自测
QuizUSE 方法中，iostat 的 aqu-sz（队列深度）属于哪个维度？
Quiz业务方投诉「存储慢」，你采集后发现 IOPS 是平时的 10 倍，来自一个新上的备份任务，延迟等指标都在正常范围。最合理的处置是？
Lab · 综合演练：诊断一次 IO 慢挑战
1. 同伴从以下任选一种注入，不告诉你选了哪种：高负载（fio 压测）、网络延迟（tc netem delay）、丢包重传（tc netem loss）、IO 限速（cgroup io.max 或 device-mapper throttle）。 2. 你只知道现象："写文件变慢了"。按本章流程图走：先定性（Q1/Q2），再 USE 遍历，最后追踪定位。 3. **验收标准**：给出证据链 —— 每一步结论附一条工具输出，最终指出注入的故障类型；全程不超过 5 条"假设→验证"记录。