当存储延迟突增但 %util 很低（比如
看 iostat -x 1 的 %util 和 await 是否背离
当存储延迟突增但 %util 很低（比如 await（平均每次 I/O 耗时）和 r_await/w_await：如果它们飙升到几十甚至上百毫秒，但 svctm（实际服务时间）仍很低（
常见诱因包括：
- 上层应用突发大量随机小 I/O，触发内核 elevator 队列积压
- 使用了
cfq或bfq调度器且权重配置不当，导致某进程饿死或抢占过度 - 块设备启用了
rotational=0但底层其实是慢速 SATA SSD，调度器误判为 NVMe 导致激进合并
查 /sys/block/*/queue/scheduler 和 iosched 参数是否匹配硬件类型
SSD 和 NVMe 应该用 none（即 mq-deadline 或直接绕过调度器），而传统 HDD 才适合 cfq 或 bfq。运行 cat /sys/block/nvme0n1/queue/scheduler，若输出是 [bfq] mq-deadline none，但设备是 NVMe，括号里不该是 bfq —— 这会引入不必要的排序与延迟。
临时切换（以 nvme0n1 为例）：
echo none > /sys/block/nvme0n1/queue/scheduler
注意：none 在较新内核中等价于禁用多队列调度，对 NVMe 更友好；但若用的是老内核（mq-deadline。永久生效需改 /etc/default/grub 中的 GRUB_CMDLINE_LINUX，加 scsi_mod.use_blk_mq=1 nvme_core.default_ps_max_latency_us=0 等参数。
用 blktrace 抓原始 I/O 时间线，定位卡点在哪一层
iostat 只给平均值，掩盖毛刺；blktrace 能记录每个 I/O 从提交（Q）、排队（G）、派发（D）、完成（C）的精确时间戳。运行：
blktrace -d /dev/nvme0n1 -o - | blkparse -i -
重点关注两段差值：
