解读

面试官把“util 100%”与“await 正常”放在一起，是在考察候选人能否区分“设备繁忙”与“请求排队”两个不同维度，并据此判断磁盘是否已成为系统瓶颈。国内一线互联网与金融公司普遍使用 Linux 自带的 iostat 做现场排障，因此必须给出基于 iostat 指标体系的判断逻辑，而不是照搬书本定义。

知识点

1. iostat 字段含义（Linux 3.19+ 内核之后稳定）

   • %util：设备处于“有 I/O 请求正在处理”状态的时间占比，与并发度无关，100% 仅表示“一直不空闲”，不直接等价于“跑满”。
   • await：平均每次 I/O 请求从进入队列到完成的耗时（毫秒），包含排队 + 服务时间。
   • svctm：内核移除该指标，官方文档已声明“无物理意义”，面试中应主动指出不再使用。
   • aqu-sz（旧版 avgqu-sz）：平均队列长度，可辅助判断排队程度。
   • r/s + w/s：实际 IOPS，与磁盘规格对比可判断是否真到硬件上限。

2. 瓶颈定义（国内 SLAs 通用） 磁盘成为瓶颈需同时满足： a) 业务视角：该资源导致上游响应时间或吞吐量无法再提升； b) 资源视角：资源利用率或队列已饱和，且增加压力不再增加产出。

3. 固态盘 vs 机械盘 NVMe SSD 并发队列深 64K，util 100% 但 await 仍 <1 ms 是常见现象；SATA SSD 与 SAS 机械盘队列深 32/128，需结合规格判断。

4. 工具链 现场排查顺序：iostat → pt-ioprofile/percona-toolkit → bcc/bpftrace → fio 复现。

答案

不能仅凭“util 100% 且 await 正常”就断定磁盘是瓶颈，需要三步验证：

1. 看队列深度：iostat -x 1 中 aqu-sz 是否持续 >1。若 aqu-sz 接近 1 且 await≈svctime（或 <5 ms），说明请求几乎无排队，设备虽“忙”但处理及时，尚未饱和。
2. 看 IOPS/带宽是否到顶：将当前 r/s+w/s 与磁盘规格（SATA SSD 约 7-10 k IOPS，NVMe 可达 100 k+）对比；若距离规格上限还有 30% 以上余量，则 util 100% 只是“高频小 IO”导致，并非瓶颈。
3. 看业务指标：用 fio 或业务压测脚本把压力再抬 20%，观察 RT 和吞吐量。若 RT 几乎不变、吞吐量线性增加，则磁盘未成为系统瓶颈；若 RT 陡升或吞吐量不再增长，则此时才是真正的磁盘瓶颈。

结论：util 100% 仅表示设备不空闲，await 正常且队列浅说明暂无排队；只有 aqu-sz 持续高企、IOPS/带宽触顶且业务 RT 随压不再下降，才能判定磁盘是瓶颈。

拓展思考

1. 云环境注意“ steal ”：公有云磁盘 util 100% 可能是宿主机限流，await 正常但云监控显示“打满”，需要结合云厂商的 Burst Balance 或 IOPS 积分判断。
2. 多路径与 RAID：RAID 卡缓存、write-back 模式会把 util 折算到后端盘，需看 /sys/block/*/device/ioerr_cnt 及 MegaCLI 工具，避免误判。
3. 文件系统层排队：ext4 的 jbd2 线程或 xfs log 并发度不足时，await 正常但业务线程卡在 fsync，需用 bcc 工具观察 vfs 延迟分布，再决定是调大 logbsize 还是换 NVMe。
4. 面试加分话术：主动提到“我会用 bpftrace 脚本跟踪 block:block_rq_issue 与 block:block_rq_complete，计算实际 svctime 分布，把排队时间与服务时间拆开，给开发量化证据”，可体现源码级定位能力。