本页目录
设备很忙，不等于设备就是根因
第 9 章先拦住一个最常见的直觉：指标一难看，就把问题压成磁盘根因。
磁盘相关问题，至少要分成四件事：
- 工作负载是什么样
- 队列是不是在堆
- 单次服务时间是不是变长
- 设备后面还有没有控制器、阵列、云盘这类抽象层
这四件事不拆开，await 和 %util 都很会骗人。
先把磁盘问题拆成四类
先按下面这个顺序判断：
1. 先看工作负载像什么
是顺序还是随机，是读多还是写多，是吃吞吐还是吃 IOPS。
2. 再看排队是不是开始堆
慢是因为每个请求本身都慢，还是因为请求先在队列里等了很久。
3. 再看服务时间是不是真的变长
如果单次服务时间确实变长，才更像设备或更下层存储本身出了问题。
4. 最后再看设备后面还有什么抽象
RAID、控制器、SAN、云盘、远端存储都会改写你看到的表象。
别拿高利用率和平均等待时间直接宣布设备根因
最常见的错法有四种：
await一高，就直接说磁盘不行%util一满，就直接说设备饱和- 只看单个设备数字，不看工作负载形状
- 把阵列、云盘、控制器当成裸设备看
这些错法都少了一步：先分清排队和服务时间。
如果后面挂的是 RAID、SAN、云盘或别的虚拟块设备，%util 的欺骗性会再放大一层。虚拟盘的 %util 到 100% 只说明它在这段时间没闲着，不等于底层所有物理盘都打满，更不等于阵列已经没有继续吞吐的空间。
什么时候更像排队，不像设备变慢
下面这些情况，更像请求在堆，而不是单次设备服务突然变坏：
- 并发一高，延迟立刻拉长
- 吞吐没明显掉，但等待快速变大
- 负载一波动，延迟跟着大起大落
- 上层写回、批量写或突发流量跟着一起出现
这时候先别急着判设备差，先看是不是队列被打满了。
一个最典型的错法：拿平均等待时间直接定案
现场里很常见：有人看到 await 很高，就说“磁盘就是瓶颈”。
但平均等待时间里，混着很多东西：
- 请求在队列里等了多久
- 设备真正服务了多久
- 不同负载形状被平均到一起
- 下游抽象层把表象重新包装了多久
所以第 9 章最值钱的地方，不是再给你一个更花的盘指标，而是逼你先把平均值拆开。
%iowait 也是同一类假象。它的意思只是“CPU 恰好闲着，同时有人在等 I/O”，不是“磁盘此刻有多慢”。随便再跑一个吃 CPU 的任务，%iowait 都可能立刻掉下去，但盘的真实状态一点没变。
吞吐、IOPS、排队和服务时间要拆开看
先把吞吐、IOPS、排队、服务时间分开
以后看磁盘问题，先别只盯一个数字。至少同时回答：
- 这更像吞吐受限，还是 IOPS 受限。
- 这更像队列积压，还是单次服务时间变长。
- 这是不是被阵列、控制器、云盘重新包装过的表象。
`await` 和 `%util` 只能当线索
看到这两个数字难看时，先把它们当“值得继续看”的信号，不要当最终结论。
抽象层一多，就优先保留对照证据
云盘、SAN、阵列环境里，优先保留这些证据：
- 前后变化
- 同类实例对照
- 不同卷或不同节点对照
- 工作负载变化和延迟变化的对应关系
这比死盯单一设备数字更有用。
本机设备分清以后，再看跨机器链路
第 9 章解决的是“本机块设备和存储抽象怎么看”。第 10 章接着进入最容易被单边证据带偏的领域：网络。