服务器CPU iowait高，磁盘IO瓶颈定位iostat
当你发现服务器CPU iowait飙高，系统响应变慢，最直接的原因是CPU在等待磁盘IO完成。
本文用一台Linux服务器作为例子，带你从零开始使用iostat和iotop定位磁盘IO瓶颈，找到是哪个磁盘、哪个进程拖慢了整台机器。
先确认iowait真的高
登录服务器后，先执行top，看第三行%Cpu(s)里的wa值。
如果持续超过20%，说明磁盘IO确实在拖后腿。
也可以用vmstat 1 5观察wa列，多个采样都偏高时再进入下一步。
确认iowait高之后，需要提前安装两个工具：sysstat（提供iostat）和iotop。
CentOS/RHEL系统执行：
yum install -y sysstat iotopUbuntu/Debian系统执行：
apt install -y sysstat iotop安装完成后，先用iostat -x 1 3启动持续3次采样，每1秒一次，重点看%util、r/s、w/s和await这几列。
用iostat缩小到具体磁盘
iostat的输出按磁盘设备分行，%util表示设备处理IO请求的繁忙程度。
很多人以为%util到100%就是磁盘满了，其实不完全正确。
在机械硬盘上，%util高通常代表饱和；
但SSD和云硬盘可能%util不高却已经出现延迟，所以要结合await判断。await是IO请求平均等待时间，机械盘如果持续超过50毫秒，SSD超过20毫秒，就需要警惕。
建议重点看这三列：
%util：设备繁忙比例，长期高于80%说明负载很重await：IO平均等待时间，数值越大代表排队越严重r/s和w/s：每秒读写次数，帮助你判断是读多还是写多
执行iostat -x 1 3后，如果看到某一个盘例如vdb1的%util接近100%且await很高，基本可以断定瓶颈在该磁盘。
用iotop揪出占IO的进程
iostat告诉你哪个磁盘忙，但没告诉你谁在读写它。
这时用iotop找到具体进程。
执行：
iotop -oP-o表示只显示有IO操作的进程，-P表示只显示进程而不是线程。
这个命令会持续刷新，建议按Shift+P按CPU占用排序，按Shift+O按IO排序。
你会在输出里看到类似这样的进程行：1234 mysql，后面的DISK READ和DISK WRITE就是它的实时读写速度。
如果iotop启动报错requires root privileges，说明当前用户权限不够，用sudo iotop -oP重新执行即可。
避坑指南：iowait高不一定是磁盘坏
排查时最容易踩的两个坑：
内存不足导致的swap交换。
当物理内存不够，系统把内存页换到磁盘上，也会造成iowait飙升。
遇到iowait高，先看free -h确认可用内存，再决定是否优化应用内存占用，而不是一上来就换磁盘。
云服务器和本地盘的表现差异。
大多数云主机的系统盘是网络存储，IO指标和本地SSD有区别。
如果你看到%util不高但await异常偏大，要考虑是否被其他租户影响或达到云盘本身的性能上限。
这种情况建议用dmesg检查是否出现IO错误，并参考云厂商控制台的监控曲线。
还有一个常见疑问：iowait多少算高？
其实没有绝对阈值，比较稳妥的方法是先观察正常业务时段的基线，再在故障时段对比。
临时高不一定是问题，持续超过20%且伴随请求延迟增加，才需要优化。
验证瓶颈是否解决
定位到问题进程后，不要急着杀进程，先判断它是正常业务还是异常程序。
如果是业务要求的大量读写，可以考虑调整IO调度器、增加缓存或升级云盘规格。
如果是异常程序（比如日志刷屏、死循环写入临时文件），再针对性处理。
处理完成后，重新执行vmstat 1 5观察wa值回落情况，同时用iostat -x 1 3确认对应磁盘的%util和await是否恢复正常。
记录处理前后的数据，作为后续容量规划的参考。
如果你正在处理服务器CPU iowait高的问题，建议先按本文的步骤完整执行一遍，再结合自己的业务场景判断。
遇到拿不准的指标，优先回看避坑部分，别急着下结论。
