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