Linux磁盘IO异常怎么排查_日志与工具分析方法【指导】

磁盘 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 分析来源进程和路径。