Linux IO性能分析需先用iostat -dx 1定位设备瓶颈（关注%util>80%、await异常、r/s/w/s超限、avgqu-sz>1、rkB/wkB/s达带宽上限），再用iotop -o -P -d1揪出高IO进程，联动lsof/pidstat深入排查，云环境需结合平台监控验证。
Linux IO性能分析，核心是快速定位“谁在读写”和“设备是否扛得住”。iostat看设备级负载，iotop看进程级行为，两者配合使用最有效。
iostat：看清磁盘整体压力
运行 iostat -dx 1（每秒刷新一次扩展指标），重点关注以下字段：
- %util：设备利用率。持续 >80% 表示磁盘已接近饱和，可能是瓶颈源头；达100%说明I/O请求排队严重。
- await：平均每次I/O耗时（毫秒）。若明显高于 svctm（服务时间），说明队列堆积，等待时间长——常见于高并发小IO或机械盘随机写。
- r/s 和 w/s：每秒读/写请求数。对比设备能力（HDD约100–200 IOPS，SATA SSD可达数万），超限即过载。
- avgqu-sz：平均队列长度。值 >1 且持续上升，表明I/O请求来不及处理，系统在“堵车”。
- rkB/s 和 wkB/s：实际吞吐量。结合设备标称带宽（如SATA III约550MB/s），判断是否已达物理上限。
iotop：揪出吃IO的“真凶进程”
直接运行 iotop -o -P -d1（只显示活跃进程、不显示线程、每秒刷新）：
- -o 很关键：过滤掉静默进程，专注正在真实发起读写的进程。
- 默认按IO速率排序，首列 IO 显示实时读写带宽（如 12.45 M/s），第二列 SWAPIN 高说明进程频繁换页，可能内存不足引发IO放大。
- 按 P 键可切换显示PID（而非TID），更易关联到业务进程；按 O 键可只显示当前有IO活动的行。
- 注意区分 DISK READ 和 DISK WRITE 列，数据库、日志服务、备份任务常分别主导其中一项。
iostat + iotop 联动排查流程
当发现系统响应慢、wa%（top中CPU等待IO占比）偏高时，按顺序操作：
- 先跑
iostat -dx 1 3，确认哪个设备 %util 或 await 异常，比如vdb的 await 达到 85ms 且 %util=98%。 - 立刻执行
iotop -o -P -d1，观察哪些进程在向vdb大量读写；若看到mysqld占用 90% write，再结合lsof -p PID查它正在操作的具体文件（如 ibdata1 或 binlog）。 - 进一步验证：用
pidstat -d -p PID 1看该进程的IO速率变化趋势，排除瞬时毛刺。 - 若 iotop 没看到明显大IO进程，但 iostat 显示高util，需检查是否内核行为（如ext4 journal、swap活动）或底层存储（LVM、RAID、云盘网络延迟）问题。
几个实用小技巧
- 加
-k参数让 iostat 输出单位为 KB/s（iostat -dxk 1），比默认的块/秒更直观。 - iotop 启动后按 R 可反转排序，方便看最低IO的进程（辅助排除干扰项）。
- 对云服务器，%util 接近100%不一定代表物理磁盘满，可能是云厂商IO配额限制，需结合云平台监控交叉验证。
- 长期监控建议用
sar -d 1 3600（记录1小时），事后用sar -d -f /var/log/sa/saXX回溯分析。
