iowait高≠硬盘故障，而是CPU空闲等待I/O完成；需定位频繁发起I/O的进程、分析请求排队原因及底层资源真实承载能力，结合top%wa、mpstat和ps等工具综合诊断。
看整体：确认是不是真有IO问题
先别急着敲命令，打开top或htop，盯住%wa（iowait）这一列：
- 持续高于20%，基本可以判定存在IO等待问题
- 同时观察
load average——如果负载高但CPU使用率低（比如us/sy加起来才30%，wa却占60%），那几乎100%是IO卡住了 - 再跑一次
mpstat -P ALL 1 3，确认是否集中在某几个CPU上，排除单核调度异常干扰
看磁盘：用iostat定位哪块盘拖后腿
执行iostat -x 1 5，重点关注三组数字：
- await：平均每次IO耗时（毫秒）。云盘一般
- svctm：实际服务时间。它和await差距越大，说明排队越严重（await − svctm就是纯等待时间）
- %util：设备忙碌占比。别只看它接近100%就喊“磁盘满了”——如果await仍很低，可能是高并发合理利用；真出问题时，往往是%util刚到70%~80%，await已明显拉高
特别注意avgqu-sz（平均队列长度）：SSD盘长期>64、HDD盘>4，基本说明请求积压严重。
看进程：用iotop揪出“IO大户”
运行sudo iotop -ao（-a显示累计IO，-o只显示活跃进程）：
- 重点关注
READ和WRITE列数值大的进程，尤其是IO>持续不为0的 - 留意
COMMAND列——常见“嫌疑人”包括：mysqld（刷redo log或刷脏页）、rsync/tar（备份）、journalctl（日志轮转）、dockerd（镜像加载）、还有没配异步写的应用日志进程 - 配合
ps -p PID -o pid,ppid,comm,args查清进程完整路径和启动参数，判断是否属于预期行为
看深层原因：不止是盘慢，还可能是配置或设计问题
很多高IO不是硬件不行，而是用法不当：
-
文件系统层：ext4默认
data=ordered模式会强制日志同步，小文件频繁写极易放大IO次数；检查df -i看inode是否快耗尽，用e4defrag查碎片 - 云盘规格错配：腾讯云高效云盘IOPS随容量线性增长，1TB盘和2TB盘性能差一倍；增强型SSD虽强，但若挂在低带宽CVM实例上（如共享型），实际吞吐被实例网络带宽卡死
-
应用写模式激进：比如数据库
sync_binlog=1+innodb_flush_log_at_trx_commit=1组合，每笔事务都强制落盘；日志框架用FileAppender且未设缓冲，每条日志单独write+fsync
不复杂但容易忽略。
