高 iowait 通常意味着磁盘子系统成为瓶颈，排查的核心是先找到占用 IO 最高的进程，再判断是硬件性能不足还是配置不当。
先说结论：不要盲目调整内核参数，优先确认是哪个进程在读写，以及磁盘本身是否健康。
- 先定位：用 iostat 确认是读还是写瓶颈，用 iotop 找到具体进程。
- 先做：如果是异常进程则限制或优化代码，如果是业务高峰则考虑升级硬件或架构。
- 再验证：观察 iowait 百分比和磁盘延迟是否回到基线水平。
命令速用版
# 查看整体 CPU 等待情况
top -bn1 | grep "Cpu(s)"
# 查看磁盘 IO 统计，重点关注%util 和 await
iostat -x 1 5
# 查看哪个进程在读写磁盘（需要 root）
iotop -oP为什么会这样
iowait 表示 CPU 空闲等待 I/O 操作完成的时间百分比。数值高并不一定代表 CPU 有问题，而是说明 CPU 在等磁盘干活。常见原因包括数据库频繁落盘、日志写入过大、内存不足导致频繁 Swap 交换，或者磁盘硬件本身老化、云硬盘达到带宽上限。
分步处理
1. 确认瓶颈类型
使用iostat -x 1观察。如果%util接近 100%，说明磁盘饱和；如果await很高但%util不高，可能是队列深度问题或后端存储响应慢。
2. 找出肇事进程
使用iotop -oP或pidstat -d 1。找到读写速率最高的 PID。如果是已知业务进程，检查其日志或查询语句；如果是未知进程，检查是否被入侵或配置错误。
3. 检查硬件健康
使用smartctl -a /dev/sdX查看磁盘 SMART 信息，关注重映射扇区计数。如果是云服务器，检查控制台监控看是否触发了 IO 限速。
4. 谨慎调整参数
仅在确认是写爆发导致时，可临时调整vm.dirty_ratio，但修改前需记录原值。命令示例：sysctl -w vm.dirty_ratio=10。不要随意更改 IO 调度算法，除非明确知道磁盘类型（如 SSD 适合 noop 或 none）。
怎么验证是否生效
再次运行iostat -x 1，观察await列数值是否下降，%util是否降低。同时观察top命令中的wa值是否回落。如果业务侧响应时间同步缩短，说明优化有效。
常见坑
1. Swap 干扰：内存不足时系统会使用 Swap，导致磁盘 IO 飙升。先用free -h确认内存状态，不要误判为磁盘故障。
2. NFS 网络存储：如果挂载了网络存储，网络延迟也会体现为 iowait，此时排查重点在网络而非本地磁盘。
3. RAID 重建：如果服务器做了硬件 RAID，磁盘重建期间 IO 性能会大幅下降，这是正常现象，等待完成即可。
4. 云盘限速：许多云厂商对基础型云盘有 IO 上限，持续高负载会触发限速，表现为 await 突增，需升级磁盘类型。
参考来源
- Brendan Gregg, Linux Performance Analysis, http://www.brendangregg.com/linuxperf.html
- Red Hat Customer Portal, High IOWAIT, https://access.redhat.com/solutions/567033
- Linux Man Pages, iostat(1), https://man7.org/linux/man-pages/man1/iostat.1.html