iostat不监控进程级i/o等待，仅反映设备总体负载；需用iotop、pidstat等定位具体进程，并结合%util、await、avgqu-sz等指标分析磁盘瓶颈及优化措施。
iostat 本身不直接监控进程级 I/O 等待，它反映的是设备（如磁盘）的总体 I/O 负载和平均等待情况；要定位具体哪个进程导致 I/O 等待高，需结合其他工具协同分析。
理解 iostat 中与 I/O 等待相关的关键指标
iostat -x 1（每秒刷新一次扩展统计）输出中，重点关注以下几列：
- %util：设备忙于处理 I/O 请求的时间百分比。接近 100% 表示磁盘可能成为瓶颈，但要注意 SSD 和高并发场景下该值参考性会下降；
- await：I/O 请求在队列中等待 + 设备处理的平均时间（毫秒）。持续高于 10–20ms（机械盘）或 1–5ms（SSD）需警惕；
- svctm（已弃用）：旧版内核中表示设备平均服务时间，新内核中恒为 0，不再使用；
- avgqu-sz：平均队列长度。若该值持续大于 1，且 await 同步升高，说明请求积压明显。
定位高 I/O 等待的具体进程
iostat 只告诉你“磁盘忙”，不告诉你“谁在忙”。需配合以下命令排查：
- 用 iotop -o 查看当前正在执行 I/O 的进程（-o 仅显示有 I/O 活动的进程），支持按 IO_RATE 或 SWAPIN 排序；
- 用 pidstat -d 1 每秒输出各进程的读写速率（kB_read/s、kB_wrtn/s）和 I/O 等待时间（%iowait）；
- 检查 /proc/[pid]/io 获取某进程累计 I/O 统计（如 rchar、wchar、read_bytes、write_bytes）；
- 对可疑进程，可用 lsof -p [pid] 查看其打开的文件及对应设备，确认是否在频繁读写慢速存储（如 NFS、USB 盘）。
I/O 等待高不等于 CPU 瓶颈，但会影响响应延迟
系统负载（load average）中的“1 分钟负载”若显著高于 CPU 核心数，且 %iowait 在 top 或 pidstat 中占比高，说明大量进程处于不可中断睡眠状态（D 状态），等待 I/O 完成。此时：
- CPU 使用率可能很低，但用户感觉系统卡顿——因为任务被阻塞在 I/O 层；
- 数据库、日志服务、备份脚本、容器镜像加载等是常见诱因；
- 注意区分“真实 I/O 等待”和“伪等待”：某些 NFS 或 FUSE 文件系统在超时重试时也会表现为 D 状态，实际未必是本地磁盘问题。
优化建议从源头入手
发现高 I/O 等待后，优先检查可操作项：
- 确认磁盘健康：smartctl -a /dev/sdX 查坏道或重映射计数；
- 检查 I/O 调度器：cat /sys/block/sdX/queue/scheduler，SSD 建议用 none 或 kyber，机械盘可尝试 deadline；
- 减少随机小 I/O：调整应用日志级别、合并写操作、启用 buffer/write-back（需权衡数据安全性）；
- 隔离 I/O 负载：将数据库数据目录、日志目录、临时文件分别挂载到不同物理盘；
- 容器环境注意：docker stats 或 cgroup v2 io.weight 可限制单个容器 I/O 份额。
