收到 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%，否则写放大加剧延迟。
