收到io告警后应先验证真实性，用iostat -x 1 3检查%util>90%、await>50ms、avgqu-sz显著大于1等指标；再用iotop -opa定位高io进程，pidstat -d -p pid 1分析其读写量；接着用lsof和strace识别文件访问模式与系统调用行为；最后检查diskstats、smartctl、lvm/raid状态及ssd剩余空间。
确认IO告警是否真实存在
收到IO告警后，先别急着查进程，先验证指标是否异常。常见误报来自监控采样抖动、短时峰值或阈值设置过低。用 iostat -x 1 3 查看近几秒的详细IO统计，重点关注 %util（设备忙时百分比）、await（IO平均等待毫秒）、r/s 和 w/s（每秒读写次数）、avgqu-sz（平均队列长度）。若 %util 持续 >90%、await >50ms、avgqu-sz 显著大于1，基本可判定为真实IO压力。
定位高IO的进程和线程
用 iotop -oPa 实时查看实际产生IO的进程（-o 只显示有IO的，-P 显示进程而非线程，-a 累计IO量）。重点关注 IO> 列（当前IO速率）和 IO+ 列（累计读写总量）。若发现某个Java或MySQL进程IO很高，进一步用 pidstat -d -p PID 1 观察其每秒读写字节数。对多线程应用，可加 -t 参数看具体线程级IO分布。
分析IO行为类型与来源文件
确定高IO进程后，查它正在访问哪些文件：lsof -p PID | grep -E "(REG|DIR)" | head -20。重点关注大文件读写、频繁小文件追加（如日志轮转）、或临时文件目录（/tmp、/var/tmp）。再结合 strace -p PID -e trace=read,write,open,fsync -s 128 2>&1 | head -30 抓实时系统调用，能快速识别是读配置、刷日志、还是大量磁盘排序。若看到密集 fsync() 或 fdatasync()，说明应用在强刷盘，可能需调整同步策略。
检查底层存储与配置瓶颈
排除应用层问题后，看设备本身：用 cat /proc/diskstats 对比各磁盘的 io_ticks（设备忙时jiffies）和 aveq（加权IO队列长度），判断是否单盘过载；用 smartctl -a /dev/sdX 检查硬盘健康（尤其关注 Reallocated_Sector_Ct、Pending_Sector 和 UDMA_CRC_Error_Count）；对LVM或RAID，运行 pvs / vgs / lvs 或 mdadm --detail /dev/mdX 确认无降级或重建中。SSD还需注意 df -h 剩余空间是否低于15%，否则写放大加剧延迟。
