磁盘I/O延迟过高核心是请求在内核块层积压，需分四步排查：先用iostat -x 1看await与avgqu-sz是否同步异常；再用ioping测裸设备确认硬件响应；接着用iotop/pidstat定位真实填队列进程；最后检查IO调度器、队列深度及挂载参数等底层配置。
磁盘 I/O 延迟过高，系统卡顿但 CPU 不高，核心问题不是“谁在占 CPU”，而是“谁在让磁盘等不及、排长队”。排查要从延迟本身出发，分层定位：先确认是否真存在高延迟，再锁定是哪块盘、哪个路径（读/写）、哪个进程在推高延迟，最后看是不是底层配置或硬件拖了后腿。
看 await 和 r_await/w_await 是否真实偏高
iostat -x 1 是第一道筛子。重点关注：
- await：整体平均等待时间（毫秒）。HDD 超过 20ms 就需警惕，持续 >50ms 基本确认存在排队瓶颈；SSD 应
- r_await / w_await：分开看读和写。若 w_await 远高于 r_await，重点查日志刷盘、数据库事务提交、sync 写入或文件系统 journal 模式
- avgqu-sz：平均队列长度。HDD >2、SATA SSD >8、NVMe >32 且 %util 未满，说明上层并发远超设备处理能力，不是盘慢，是请求塞满了
用 ioping 测裸设备延迟，排除缓存干扰
iostat 的 await 包含排队+服务时间，无法区分是“等太久”还是“处理太慢”。ioping 直打块设备，测的是真实物理延迟：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 装好后运行 ioping -C -c 10 /dev/sda（-C 强制同步落盘，绕过缓存）
- 看 avg 值：HDD 正常 5–15ms，NVMe 应 ≤0.2ms。若 avg 正常但 iostat 的 await 很高，说明问题在排队或调度，不在硬件响应
- 若 ioping avg 也高（比如 NVMe 达到 5ms），就要怀疑硬件故障、驱动异常或存储后端（如 SAN/NAS）链路问题
揪出真正“填队列”的进程，别只盯 D 状态
D 状态进程是受害者，不是源头。要用能反映实时 I/O 提交行为的工具：
- iotop -oP -d 1：只显示有实际读写动作的进程，按 IO_RATE 排序，快速识别吞吐大户
- pidstat -d 1：更稳定，输出 kB_rd/s、kB_wr/s，还带 pgpgin/pgpgout——若换页量大，说明内存不足引发 swap I/O
- 容器环境别漏关联：对 PID 执行 cat /proc/
/cgroup | grep docker | awk -F'/' '{print $NF}' | cut -c1-12 ，快速定位所属服务名
检查三道底层关卡：调度器、队列深度、挂载参数
即使进程合理、硬件正常，错误的内核配置也会人为制造延迟：
- IO 调度器：cat /sys/block/sda/queue/scheduler。HDD 用 deadline；SSD/NVMe 推荐 noop 或 mq-deadline；CFQ 已淘汰，易堆积
- 设备队列大小：cat /sys/block/sda/queue/nr_requests。NVMe 默认可能仅 128，而硬件支持 1024，可适当调高
- 挂载参数：mount | grep sda。警惕 data=journal（ext4 双倍 I/O）、barrier=1、commit=5（加重同步负担），高负载下可考虑 data=ordered + barrier=0（需断电保护）
