Linux中%iowait过高表示CPU空闲时等待IO，需分三层定位：先确认是否真为IO瓶颈（看%iowait+%idle≈100%、%util≈100%、await异常等），再用iotop/pidstat/lsof定位高IO进程及文件，最后分析IO模式与存储栈（iostat、lsblk、fio）并针对性优化。
Linux系统中IO等待（%iowait）过高，通常意味着CPU在等待IO操作完成，但不等于IO本身一定慢——它反映的是“有进程想干活却因IO被卡住”。定位需分三层：确认是否真瓶颈、找到谁在拖慢IO、再针对性优化。
一、确认iowait是否真实反映IO瓶颈
%iowait是CPU空闲且在等IO时的占比，但它有前提：CPU必须处于idle状态。如果系统CPU已满载（%us/%sy高），即使IO很慢，iowait也可能很低。因此先交叉验证：
- 用 top 或 htop 看 %iowait + %idle 总和是否接近100%（说明CPU确实空闲但等IO）
- 用 iostat -x 1 检查关键指标：%util ≈ 100% 表示设备饱和；avgqu-sz > 1 表示队列积压；r_await/w_await > 10ms（机械盘）或 > 1ms（SSD） 表示响应延迟异常
- 对比 vmstat 1 中 b（blocked进程数）是否持续大于0，且与iowait趋势同步
二、定位发起IO的进程和文件
iowait高，但未必是磁盘慢，可能是某进程频繁小IO、随机读写、或锁竞争导致。重点排查活跃IO进程：
- 用 iotop -o -P（-o仅显示有IO的进程，-P按进程而非线程聚合），关注 IO> 列（实际IO带宽）和 SWAPIN 列（可能因内存不足触发交换）
- 对可疑进程，用 lsof -p PID 查看打开的文件/设备；结合 cat /proc/PID/io 看rchar/wchar、read_bytes/write_bytes、cancelled_write_bytes（刷脏页失败次数）
- 用 pidstat -d 1 持续观察各进程IO吞吐与请求频率（-d显示IO，-r可加看缺页）
- 若怀疑是内核路径（如日志刷盘、ext4 journal、swap），可用 perf record -e block:block_rq_issue -g sleep 10 && perf script 追踪块层请求来源
三、分析IO模式与存储栈瓶颈
同一磁盘，顺序大写和随机小读表现天差地别。需判断IO特征及所经路径：
- 用 iostat -x 1 的 rrqm/s, wrqm/s（合并请求数）和 r/s, w/s（IOPS）比值粗判：若 r/s 很高但 rkB/s 很低 → 高频小IO（如数据库索引扫描、日志轮转）
- 检查存储栈层级：本地盘？LVM？mdraid？NVMe多队列？用 lsblk -t 看ra（readahead）、rotational（是否机械盘）、rq_size（队列深度）；cat /sys/block/*/queue/scheduler 看IO调度器（SSD建议noop/mq-deadline，机械盘cfq已弃用，用bfq或none）
- 若使用云盘（如AWS EBS、阿里云ESSD），注意基线性能与突发能力，用 fio --name=randread --ioengine=libaio --rw=randread --bs=4k --iodepth=64 --runtime=60 --time_based 做基准测试，对比厂商SLA
四、常见优化方向与验证方法
优化需匹配根因，避免盲目调参：
- 应用层：批量写替代频繁fsync（如MySQL的innodb_flush_log_at_trx_commit=2）、关闭不必要的日志（auditd、journalctl --vacuum-size=100M）、用O_DIRECT绕过page cache（需应用支持）
- 文件系统：ext4挂载加 noatime,nodiratime,commit=60；XFS用 logbsize=256k 减少日志刷写；禁用uuid挂载（改用LABEL或UUID=xxx，避免每次scan）
- 内核与IO栈：提高脏页参数（vm.dirty_ratio=80, vm.dirty_background_ratio=5, vm.dirty_expire_centisecs=30000）缓解突发写压力；NVMe盘启用多队列：echo 'nvme_core.default_ps_max_latency_us=0' > /etc/modprobe.d/nvme.conf
- 验证效果：优化后持续运行 iostat -x 1 和 pidstat -d 1 5分钟，确认 %util 下降、await缩短、阻塞进程减少，且业务延迟/吞吐符合预期
IO问题不是单点故障，而是路径上任一环节（应用逻辑、文件系统、驱动、固件、物理介质）失配的结果。从现象出发，逐层向下收窄，比直接调优更可靠。
