当存储延迟突增但 %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 -
重点关注两段差值：
-
Q → G延迟大 → 应用或文件系统层阻塞（如 XFS 日志锁、ext4 journal wait） -
G → D延迟大 → 块层调度器或队列深度不足（/sys/block/nvme0n1/device/queue_depth太小） -
D → C延迟大 → 真实设备响应慢（坏块、固件 hang、PCIe link 降速）
如果发现大量 Q 到 G 耗时 >100ms，别急着查磁盘，先用 perf record -e 'block:*' -a sleep 10 看内核栈，常会暴露在 xfs_log_force 或 __ext4_journal_start 卡住。
警惕 vm.dirty_ratio 和 vm.dirty_background_ratio 引发的 writeback 风暴
当脏页积累到 vm.dirty_background_ratio（默认 10%）时，内核后台线程开始刷盘；一旦冲到 vm.dirty_ratio（默认 20%），所有写进程会同步阻塞直到脏页回落。此时 iostat 可能显示 await 暴涨、w_await 远高于 r_await，且 biotop 里 kswapd0 或 flush-* 进程占高 I/O。
检查当前值：
sysctl vm.dirty_ratio vm.dirty_background_ratio vm.dirty_expire_centisecs
典型调优方向：
- 降低
vm.dirty_expire_centisecs（默认 3000 = 30 秒），让脏页更早被回收 - 提高
vm.dirty_background_ratio至 15，避免 flush 线程太激进干扰前台 I/O - 对数据库类负载，建议关掉
vm.swappiness（设为 0），防止 page reclaim 误杀 buffer cache
这些参数改动后，必须观察 /proc/vmstat 中的 pgpgout、pgmajfault 和 pgpgin 是否异常跳变——调得太激进反而引发 swap thrashing。
真正难排查的是混合场景：比如 NFS 客户端 + 本地 ext4 + dirty_ratio 偏高 + scheduler 错配，多个延迟源叠加，await 看似统一升高，但根因分散在四层。这时候不能只盯一个指标，得把 blktrace、/proc/diskstats、perf script -F comm,pid,tid,usyms 和 dmesg -T | grep -i "nvme\|ata\|timeout" 四路日志对齐时间轴。
