判断磁盘i/o瓶颈需聚焦%iowait、r_await/w_await、avgqu-sz及rkb/s+wkb/s组合：%iowait>5%需警惕，>20%表明i/o成明显瓶颈；机械盘await>20ms、ssd>1–2ms、nvme>0.5ms即异常；avgqu-sz超理论队列深度两倍说明严重积压；%util在nvme/ssd上已弃用，应以吞吐是否逼近理论带宽为准。

监控 Linux 文件系统读写性能，iostat 是最直接、最常用的工具之一，但它输出的几十个字段容易让人困惑。关键不在于看全，而在于盯住真正反映瓶颈的几个核心指标——尤其要区分机械盘、SSD 和 NVMe 的判断逻辑完全不同。

重点关注 CPU 等待时间：%iowait

这是第一个需要扫一眼的信号。它表示 CPU 空闲时却在等 I/O 完成的时间占比：

• 持续高于 5% 就值得警惕，说明 I/O 已开始拖慢整体响应
• 超过 20% 往往意味着存储已成为明显瓶颈，应用延迟会显著上升
• 注意：%iowait 高但 %util 很低，可能是进程频繁同步等待（如 fsync），而非磁盘真忙

设备层看延迟和队列：r_await、w_await 和 avgqu-sz

这才是定位文件系统卡在哪的关键。不要只盯着 %util —— 它对 SSD/NVMe 参考价值很低：

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

• r_await / w_await（单位 ms）：一次读/写请求从发出到完成的平均耗时
   • 机械盘 > 20ms、SSD > 1–2ms、NVMe > 0.5ms 就需关注
• avgqu-sz：I/O 请求在队列中平均堆积数量
   • 值大于设备理论队列深度（如 NVMe 默认 64）的两倍，说明请求严重积压
• 如果 await 高但 r/s 或 w/s 不高，大概率是随机小 IO（如数据库索引查找），不是吞吐问题

结合吞吐与 IOPS 判断访问模式

rkB/s 和 wkB/s 告诉你“写了多少”，r/s 和 w/s 告诉你“写了几次”，两者比值揭示实际 IO 特性：

• 高 r/s + 低 rkB/s → 大量小读（例如日志轮转、元数据操作）
• 低 w/s + 高 wkB/s → 大块顺序写（例如备份、归档、日志刷盘）
• 用公式算平均 IO 大小：rareq-sz ≈ (rkB/s × 1024) ÷ r/s（单位 KB）
• 若 rareq-sz 在 4–8KB 波动，基本是典型数据库随机读；若 >64KB，偏向顺序流式访问

别被 %util 带偏：现代设备的特殊性

%util 接近 100% 并不等于“磁盘卡死”。它的定义是“设备有 I/O 的时间占比”，而 NVMe 能并行处理数百请求：

• Linux 5.0+ 内核已将 %util 标记为 deprecated（弃用），尤其在多队列设备上数值失真
• SSD/NVMe 更应关注：rkB/s 和 wkB/s 是否逼近理论带宽（如 PCIe 4.0 x4 NVMe 理论约 7GB/s）
• rrqm/s 和 wrqm/s 为 0 是常态——现代调度器（none/mq-deadline）或硬件已在底层合并，无需干预