定位磁盘io瓶颈需分层验证：先用top看%wa确认io等待，再用iostat -x 2查%util、await和iops锁定饱和设备，最后用sudo iotop -op找出高io进程，辅以lsof -p pid和df -h分析文件与空间。
磁盘 IO 瓶颈的定位不是靠猜，而是分层验证：先确认是不是 IO 问题，再看是哪块设备忙，最后锁定是哪个进程在拖慢它。整个过程用三个核心命令就能完成，不需要复杂配置。
第一步：确认系统是否真的被 IO 卡住
运行 top，直接看右上角的 %wa（iowait）值：
- %wa
- %wa 在 30%–50% → IO 已开始影响响应，需进一步查
- %wa > 50% → CPU 大量时间在等磁盘，IO 是主因
注意：这个值高，只说明“CPU 在等”，不代表一定是硬盘慢——也可能是 NFS 挂载卡住、或本地 SSD 队列堆积。但它是最快速的入口判断。
第二步：找出哪块磁盘正在饱和
用 iostat -x 2（每 2 秒刷新一次），重点关注三列：
- %util：传统 HDD/SSD 上接近 100% 表示设备已满负荷；NVMe 设备可忽略此值，转看 await
- await：平均每次 IO 的等待时间（ms）。> 50ms 就值得警惕，> 100ms 通常已严重排队
- r/s + w/s：总 IOPS。对比设备标称值（如 SATA SSD 约 10K，NVMe 可达 500K+），超了就是过载
例如看到 sda %util=98.3, await=124.6ms，基本可以断定 sda 是瓶颈点。
第三步：定位具体是哪个进程在大量读写
用 sudo iotop -oP（只显示有 IO 活动的进程，不显示线程）：
- 按 WRITE 列排序，找写速最高者（单位通常是 KB/s 或 MB/s）
- 观察 IO% 是否长期 > 80%，说明该进程几乎独占磁盘带宽
- 如果看到
mysqld或rsync或java占比异常高，就基本锁定目标
若容器环境没装 iotop，可用 pidstat -d 2 3 替代，输出更简洁，适合脚本化检查。
补充验证：确认它在写什么文件
拿到高 IO 进程的 PID 后，用 lsof -p PID 查它打开的文件：
- 重点过滤
REG（普通文件）和DIR（目录），按文件大小或访问频率排序 - 常见线索：
/var/log/*.log、/data/mysql/ibdata1、/tmp/*.tmp - 配合
df -h看对应挂载点是否快满（>90%），空间不足也会引发 IO 恶性循环
这时再结合业务日志，就能明确是日志轮转失控、数据库刷盘激增，还是临时文件未清理。
