要看磁盘是否真忙，需同时关注%util和await：%util＞80%表示设备繁忙，await＞200ms则反映高延迟；iostat -x 1持续观察5–10秒，结合物理盘、分区、LVM及NVMe命名差异综合判断。
怎么看磁盘是不是真忙——盯住 %util 和 await 两个数
单看 kB_read/s 或 kB_wrtn/s 容易误判：大块顺序写可能吞吐高但延迟低，小文件随机读可能流量不大却卡死应用。%util 表示设备忙于处理 I/O 的时间占比，持续 >80% 就得警惕；但更关键的是 await（单位毫秒），它反映请求从发出到完成的平均耗时。如果 %util 才 40% 但 await 动辄 200ms 以上，说明不是磁盘带宽瓶颈，而是响应慢或队列堆积——可能是 RAID 卡缓存关闭、SSD 垃圾回收卡顿，或上层应用频繁小 IO。
-
iostat -x 1是最基础的实时观察命令，每秒刷新一次扩展指标 - 别只跑一次：至少看 5–10 秒，避免被瞬时抖动误导
- 注意单位：加
-m用 MB/s 更直观，-k是 KB/s，不加默认是 block/s（512 字节）
怎么定位哪个磁盘在拖后腿——区分物理盘、分区和 LVM 设备
iostat 默认显示所有块设备，但你看到的 sda、nvme0n1 是物理盘，sda1、nvme0n1p1 是分区，而 dm-0 这类通常是 LVM 逻辑卷。真实瓶颈常藏在底层：比如 dm-0 利用率 95%，但它的物理盘 sdb 才 30%，那问题就在 LVM 层或上层映射逻辑；反过来，如果 sdb 满载而所有分区都闲着，就得查是不是有裸设备直写或内核模块异常。
- 用
iostat -d -p ALL 1同时看物理盘 + 所有分区，快速比对负载归属 - LVM 场景加
-N参数：iostat -x -N 1可显示 device mapper 名称（如centos-root），比dm-0好认得多 - NVMe 盘注意命名差异：
nvme0n1是盘，nvme0n1p1是分区，别把 p1 当成主设备去优化
为什么 %iowait 高不一定代表磁盘有问题
%iowait 是 CPU 等待 I/O 完成的时间比例，但它只是“症状”，不是“病因”。CPU 空闲时等磁盘，%iowait 就涨；但如果 CPU 本身在满负荷跑计算任务，哪怕磁盘飞快，%iowait 也可能很低——因为 CPU 根本没空等。所以单独看 %iowait 没意义，必须结合 %idle 和磁盘自身指标一起判断。
- 若
%iowait>20% 且%idle很高（比如 >70%），基本可锁定是磁盘响应慢或队列深 - 若
%iowait高但%idle很低（比如 -
iostat -c单独看 CPU 报告，iostat -d单独看磁盘报告，混在一起容易看串行
怎么确认是哪个进程在狂刷磁盘——iotop 比 iostat 更直接
iostat 告诉你“谁在用磁盘”，但不告诉你“哪个进程”。这时候得切到 iotop：它像 top 一样实时排序，按 I/O 带宽或 IOPS 降序列出活跃进程，还能区分读/写、是否缓冲、是否脏页回写。
- 安装后直接运行
iotop -o，只显示有实际 I/O 的进程，避免干扰 - 按
P键按磁盘读速率排序，W键按写速率排序，R切换正/逆序 - 注意看
IO>列：值为 0 表示该进程当前无 I/O，别被名字误导（比如rsyslog平时不刷盘，但日志爆发时会突增） - 如果
iotop里看不到明显大户，但iostat显示磁盘持续忙碌，可能是内核线程（如kswapd、kauditd）或直接 I/O（O_DIRECT）绕过了 page cache
真正难搞的不是数字看不懂，而是同一组指标在不同硬件（HDD/SSD/NVMe）、不同负载模式（随机小 IO / 大块顺序 IO）、不同栈深度（ext4 → LVM → RAID → NVMe controller）下含义完全不同。盯着 await 和 avgqu-sz 的变化趋势，比记绝对值有用得多。
