性能分析的第一课：USE 方法

从一句"系统很慢"说起

值班群里最常见的报障是这样的：

我们的训练任务读数据特别慢，是不是存储有问题？

这句话里没有任何可以直接动手的信息。慢到什么程度？和什么时候比慢？读的是大文件还是小文件？只有这一个任务慢还是所有人都慢？新人最容易犯的错误，是听到"存储慢"就直接登上存储节点开始翻日志——翻半小时也翻不出东西，因为你根本不知道要找什么。

性能分析需要的是套路，一套不管遇到什么系统都能照着跑的固定动作。Brendan Gregg 在 Systems Performance 里给了一个非常朴素但极其好用的套路：USE 方法。

先说清四个指标

在用套路之前，得先把词说准。这四个词在存储领域天天出现，混着用会让沟通完全失效。

指标	英文	回答什么问题	典型单位
延迟	Latency	一次操作要等多久	ms、µs
吞吐	Throughput	每秒搬运多少数据	MB/s、GB/s
IOPS	IOPS	每秒完成多少次操作	次/秒
饱和度	Saturation	有多少请求在排队等不到服务	队列长度

它们之间有一个关系式，存储工程师应该形成肌肉记忆：

吞吐 ≈ IOPS × 平均请求大小

4KB 随机读跑到 50000 IOPS，吞吐是 200 MB/s；1MB 顺序读只要 200 IOPS 就能跑到同样的 200 MB/s。所以脱离块大小谈 IOPS，或者脱离块大小谈吞吐，都是没有意义的。

USE 方法：三个指标 × 一张资源清单

USE 的做法是：列出系统里所有的资源，对每个资源检查三件事。

• U — Utilization 使用率：这个资源有多少时间在干活
• S — Saturation 饱和度：有多少工作排不上队，只能等
• E — Errors 错误：有没有报错

关键在于第二项。使用率 100% 不一定是问题（比如一块盘一直在满速顺序读，那是好事），但饱和度大于 0 一定意味着有人在等。很多新人只看使用率，于是看到 %util 100% 就下结论说盘坏了，其实那可能只是队列深度为 1 的正常顺序读。

对一台存储节点，资源清单大致是这样：

资源	使用率	饱和度	错误
CPU	mpstat -P ALL 1 的 %usr + %sys	vmstat 1 的 r 列（运行队列）	dmesg 中的 MCE
内存	free -g 已用容量	vmstat 1 的 si/so（换页）	OOM killer 日志
磁盘	iostat -x 1 的 %util	iostat -x 1 的 aqu-sz	dmesg、SMART
网络	sar -n DEV 1 的收发速率	netstat -s 重传、ifconfig drop	ip -s link 的 errors

60 秒体检清单

拿到一台没见过的机器，先花一分钟跑完这几条，心里就有底了：

uptime                  # 负载趋势：1/5/15 分钟三个数，看是在恶化还是在恢复
dmesg -T | tail -30     # 有没有 OOM、磁盘 I/O 错误、网卡 down
vmstat 1 5              # r 运行队列、si/so 换页、us/sy/wa 时间分布
mpstat -P ALL 1 3       # 是所有核都忙，还是某一个核被打满（常见于单队列中断）
pidstat 1 3             # 哪个进程在吃 CPU
iostat -xz 1 3          # 每块盘的 IOPS、吞吐、延迟、队列深度
free -g                 # 可用内存与 buff/cache
sar -n DEV 1 3          # 每张网卡的收发速率，对比线速
sar -n TCP,ETCP 1 3     # TCP 重传，网络质量的直接指标
top                     # 兜底看一眼全局

这份清单的顺序是有讲究的：从全局趋势（uptime）到硬错误（dmesg），再到四大资源，最后才是进程级细节。反过来做——一上来就 top 盯着看——很容易被某个瞬时高 CPU 的进程带偏。

套到存储场景上

回到开头那个"训练读数据慢"的报障。用 USE 的思路，处理顺序应该是：

1. 先量化：慢到什么程度？让对方给出具体数字或复现命令。没有数字就没有下一步。
2. 划边界：只有一个节点慢，还是所有客户端都慢？只有一个目录慢，还是整个文件系统都慢？这一步能砍掉一半的排查范围。
3. 客户端侧跑 USE：很多时候瓶颈根本不在存储，而在客户端单线程读取、或者客户端网卡被别的任务占满。
4. 网络侧看重传：分布式存储把网络放进了 I/O 路径，重传率上升会直接表现为延迟毛刺。
5. 存储侧跑 USE：这时候再登存储节点，你已经知道要看哪块盘、哪个时间段了。

检查点单选

某块 NVMe 盘的 iostat 显示 %util 接近 100%，但平均队列深度 aqu-sz 只有 0.9，延迟 0.1ms。下面哪个判断最合理？

• A磁盘已经饱和，必须立刻扩容
• B磁盘一直有请求在处理，但没有排队，说明还没饱和
• C%util 100% 说明磁盘故障，应该更换
• D延迟 0.1ms 说明数据没有真正落盘

提交

检查点多选

按 USE 方法排查时，下面哪些属于「饱和度」指标？（多选）

• Avmstat 中的 r 列（运行队列长度）
• Biostat 中的 aqu-sz（平均队列长度）
• Cfree 显示的已用内存百分比
• Dvmstat 中的 si/so（换入换出）

提交

这节课的落点

• 报障先量化，没有数字就不要动手
• 四个指标各司其职，谈 IOPS 必须带块大小，谈延迟必须带分位数
• USE 强制你横向扫一遍所有资源，避免一头扎进错误的方向
• 60 秒清单要背下来，它是后面所有课程的公共前置动作

下一节我们把 iostat -x 的每一列拆开讲透——那是存储工程师每天都要读的东西。