先分清主机与后端
主机侧排查要回答的核心问题是：慢在主机内部（调度、队列、内存回写、协议栈、多路径），还是慢在后端。主机侧可见的 await 包含排队与设备服务两部分，光看绝对值无法区分责任，必须结合队列长度与并发请求数一起读。把「主机发出的请求量」与「后端能完成的请求量」对照起来，责任边界就清楚了。
基本信息
| 常用工具 | iostat、vmstat、sar、iotop、blktrace、multipath |
|---|---|
| 关键文件 | /proc/diskstats、/sys/block 下的队列参数 |
| 核心指标 | IOPS、吞吐、平均与分位时延、队列长度、利用率 |
| 易忽略项 | 内存回写、IO 调度器、中断绑核、多路径健康 |
| 适用系统 | Linux 主机；工具参数以对应发行版手册为准 |
典型使用场景
- 业务反馈某台主机慢：先确认是主机自身还是共享后端
- 数据库抖动排查：区分日志写入与数据文件读取的差异
- 挂载点接入后性能不达标：检查多路径、协议与队列参数
- 批量任务并发下性能劣化：确认是否内存回写引发周期性阻塞
- 扩容验证：确认新增路径被正确使用且负载均衡
主机侧排查命令
主机侧排查命令
iostat -x 1 # 逐设备看时延、队列与利用率
iostat -x 1 /dev/sdb # 只看指定设备，减少噪声
vmstat 1 # 关注 wa 列：IO 等待占 CPU 时间的比例
sar -d -p 1 # 历史与实时对比设备级负载
iotop # 按进程看谁在发起 IO
cat /proc/diskstats # 原始计数，适合脚本采基线
multipath -ll # 多路径状态与负载分布
cat /sys/block/sdb/queue/scheduler # 当前 IO 调度器
cat /sys/block/sdb/queue/nr_requests # 队列深度上限关键列读法
| 列 | 含义 | 判读要点 |
|---|---|---|
| r/s、w/s | 每秒读、写请求数 | 与后端能力对照，不看绝对值 |
| rkB/s、wkB/s | 每秒读写字节数 | 配合平均请求大小判断顺序还是随机 |
| r_await、w_await | 单请求平均时延 | 读写分开看，写入常常更高 |
| aqu-sz / avgqu-sz | 平均队列长度（新老版本列名不同） | 持续大于 1 说明经常排队 |
| %util | 设备繁忙比例 | 接近满且时延上升才是真瓶颈，单看它易误判 |
| wa（vmstat） | CPU 等待 IO 的时间占比 | 持续偏高说明 IO 已成主要等待来源 |
固态盘下 %util 接近满不一定代表瓶颈，它描述的是有请求在处理的忙碌比例；判断瓶颈要回到时延与队列是否同步恶化。
写入侧要注意内存回写：脏页累积到阈值后集中刷盘，会周期性把写时延推高。排查此类抖动应同时看内存脏页与写入时延的时间对应关系，而不是只看磁盘。