iostat -x 1 是识别磁盘真实瓶颈的关键，需重点关注 await、r_await/w_await、avgqu-sz：await > 10ms 且波动表明响应慢或串行请求；avgqu-sz > 1 但 %util 低说明队列配置不当；高 iops 低吞吐率反映小块随机 io 问题。
怎么用 iostat 看出磁盘是不是真瓶颈
光看 %util 接近 100% 不代表磁盘忙，可能是队列积压或响应延迟高。iostat -x 1 才是关键，重点盯 await（平均 I/O 等待毫秒）、r_await/w_await、avgqu-sz（平均队列长度）。
-
await > 10且持续波动 → 应用层可能在串行发请求，或磁盘本身响应慢 -
avgqu-sz > 1但%util很低 → 设备支持并行但驱动/队列没调好（比如 NVMe 的nr_requests默认太小） -
r/s和w/s很高，但rkB/s和wkB/s很低 → 小块随机 IO，不是带宽问题，是寻道/延迟问题
为什么 dd 测出来的磁盘速度和实际应用差很远
dd 默认顺序大块写，绕过了文件系统缓存策略、日志开销、锁竞争，也测不出随机读写的延迟毛刺。它只反映“理想裸盘吞吐”，对数据库、日志服务这类场景几乎没参考价值。
- 用
fio --name=randread --ioengine=libaio --rw=randread --bs=4k --direct=1 --runtime=60模拟真实负载 -
dd加oflag=direct能跳过 page cache，但依然不触发文件系统元数据操作 - SSD 上
dd可能测出虚高值（TRIM 未触发、写放大未体现），NVMe 盘还要注意queue_depth是否匹配硬件能力
vmstat 里 bi/bo 高但 iowait 很低，说明什么
这表示内核确实在做大量块设备 I/O（bi=block in, bo=block out），但 CPU 并没卡在等待磁盘上——常见于异步 IO 场景，比如应用用 libaio 或 io_uring 提交请求后立刻干别的事。
- 别只盯着
iowait判断磁盘压力，它只统计“当前线程因等磁盘被调度器挂起”的时间 - 结合
/proc/diskstats看ms字段（I/O 总耗时毫秒），比iowait更准 - 如果
bi/bo高 +si/so（swap in/out）也高，可能是内存不足导致频繁换页，表面是磁盘忙，根因是内存配置不合理
调整 /sys/block/*/queue/scheduler 有实际效果吗
对传统 HDD 有用（cfq 或 bfq 能控制 IO 优先级），但对 SSD/NVMe 基本无效甚至有害。现代固态盘内部控制器自己调度，内核 IO 调度器反而增加延迟。
- NVMe 盘建议设为
none：echo none > /sys/block/nvme0n1/queue/scheduler - SATA SSD 可试
mq-deadline或none，但必须配合nr_requests调大（默认 128，可设到 512） - 改完要验证：用
iostat -x 1对比await和svctm（服务时间），若await ≫ svctm，说明调度器引入了排队延迟
真正影响性能的往往是文件系统挂载参数（比如 noatime、commit=60）和应用层 IO 模式，而不是调度器名字。
