磁盘I/O异常表现为系统响应迟缓、进程卡顿、CPU长时间处于wa状态或应用写入超时;需分层排查:先用iostat确认是否真为I/O问题并锁定设备,再用iotop定位高IO进程,结合dmesg、smartctl验证硬件健康,最后通过lsof、pidstat、perf追溯具体文件与系统调用。

磁盘I/O异常通常表现为系统响应迟缓、进程卡顿、CPU长时间处于 wa(I/O wait)状态,或应用写入超时。排查关键在于分层定位:先确认是否真为I/O问题,再锁定设备,最后找到具体进程和行为根源。
看整体负载:用 iostat 判断磁盘是否过载
iostat 是最直接的入口工具,能快速反映磁盘真实压力:
- 运行 iostat -dx 2(每2秒刷新),重点关注以下字段:
• %util:持续高于 80% 表示设备已接近饱和;
• await:平均等待时间 > 50ms 常见于队列堆积或硬件响应慢;
• avgqu-sz:大于 2 说明请求排队明显;
• r/s 和 w/s:结合业务预期判断 IOPS 是否异常飙升。
- 若多块盘中仅某一块(如 sdb)%util 长期 95%+,而其他盘平稳,说明瓶颈集中在此设备,无需全局优化。
找罪魁进程:用 iotop 定位高IO消耗者
iotop 可实时显示每个进程的读写速率,是“谁在狂刷磁盘”的第一答案:
- 执行 sudo iotop -o,只显示正在做 I/O 的活跃进程;
- 按 P 键按 I/O 速率排序,重点关注 DISK WRITE 或 DISK READ 数值高的进程;
- 观察 IO> 列(I/O 等待时间占比):超过 90% 的进程大概率是 I/O 阻塞源;
- 若看到 java、mysqld、rsyslogd 等长期高写,需进一步查其行为(如日志轮转策略、SQL 执行计划、JVM 缓存配置)。
查底层线索:日志与硬件健康双验证
系统日志和磁盘SMART信息能揭示隐性风险,避免把故障当性能问题处理:
- 用 dmesg -T | grep -i "ata\|nvme\|error\|fail" 查内核报错,如 "end_request: I/O error" 或 "link is slow" 直接指向硬件或链路问题;
- 检查 /var/log/messages 或 /var/log/syslog 中近期是否有 "buffer I/O error"、"ext4 journal failed" 类警告;
- 运行 smartctl -a /dev/sda(替换为实际设备),重点看:
• Reallocated_Sector_Ct(重映射扇区数)非零且增长;
• Current_Pending_Sector(待重映射扇区)> 0;
• UDMA_CRC_Error_Count(接口校验错误)突增——可能线缆或控制器异常。
挖行为细节:从文件到系统调用追根溯源
知道哪个进程吃IO后,要弄清它在操作什么:
- 查该进程打开的写入文件:lsof -p PID | grep -E "(REG|DEL)" | grep -E "w|W";
- 识别是否在写大日志(如 /var/log/app.log)、临时文件(/tmp/xxx.tmp)或数据库文件(/var/lib/mysql/ibdata1);
- 用 pidstat -d -p PID 1 观察该进程每秒读写字节数变化趋势;
- 对短时进程或可疑调用,可用 perf record -e block:block_rq_issue -a sleep 10 捕获块层请求,再用 perf script 分析来源进程和路径。
以上就是Linux磁盘IO异常怎么排查_日志与工具分析方法【指导】的详细内容,更多请关注php中文网其它相关文章!