LinuxIO性能怎么分析_iotat与iotop使用技巧【技巧】

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（每秒刷新一次扩展指标），重点关注以下字段：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• %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 回溯分析。