必须加 -xk 1 才能看清真实负载，因默认 iostat 缺失关键指标：-x 提供 %util、await、avgqu-sz 等设备级延迟与队列深度数据；-k 统一单位为 KB 避免混淆；1 实现每秒刷新捕获瞬时峰值。
直接看 iostat -xk 1，别用默认参数——它不显示关键指标，等于白跑。
为什么必须加 -xk 1 才能看清真实负载
默认 iostat 只输出基础吞吐量（rkB/s、wkB/s），但高吞吐 ≠ 高性能，更不等于没瓶颈。真正决定磁盘是否扛不住的是延迟和队列深度：
-
%util持续 >80%：磁盘几乎无空闲窗口，新请求进来就得排队 -
avgqu-sz>2（HDD）或 >1（SSD）：I/O 请求已在内核队列里堵车 -
await>50ms（HDD）或 >10ms（SSD）：用户侧感知到明显卡顿的起点
这些字段全靠 -x（扩展统计）才出来；-k 把单位统一成 KB，避免 MB/GB 混乱；1 是每秒刷新，方便盯住瞬时峰值。
iostat 输出里最该盯死的三列
执行 iostat -xk 1 后，跳过第一行（那是启动前的平均值，不准），从第二行开始看：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
%util：不是“使用率”，是“设备忙于处理 I/O 的时间占比”。100% 不代表写不动，而是响应时间会指数级上升 -
await和svctm对比：如果await远大于svctm，说明瓶颈在队列等待，不是磁盘本身慢；如果两者接近，问题真在物理介质或控制器 -
r/s和w/s：IOPS 数值。突然飙升但%util没涨？可能是缓存层（如 page cache）在扛，还没落到盘上
wa% 高但 iostat 没异常？先确认是不是真在等磁盘
top 或 vmstat 里看到 wa（CPU 等待 I/O 时间）超过 30%，不代表一定是磁盘问题：
- 某些 NVMe 设备或虚拟化环境（如 KVM + virtio-blk）中，
wa可能被内核计入，但实际 I/O 已卸载到硬件队列，iostat显示%util却很低 - 进程处于 D 状态（不可中断睡眠）但并非等磁盘——比如等 NFS server 响应、等 kernel lock、甚至等 cgroup throttle，也会推高
wa - 此时要配合
iotop -o看真实读写进程，或用pidstat -d 1确认具体 PID 的 I/O 行为
别忘了检查设备名是否对应真实物理盘
iostat 列出的 Device 名（如 sda、nvme0n1、dm-0）容易误判：
-
dm-*是 LVM 或加密设备（LUKS），它的%util高，不等于底层物理盘饱和，得顺着lsblk往下查 -
loop*或zram出现在列表里？说明有容器镜像加载、快照挂载或内存压缩在偷偷吃 I/O - 云主机常见陷阱：
vda是虚拟块设备，%util高可能只是宿主机存储池争用，你改不了——这时候看await更实在
真正难缠的 IO 问题，往往卡在设备名和实际路径的映射关系上，而不是数值本身。
