linux存储性能瓶颈需分层下钻排查：先通过%wa和iostat -x判断是否真瓶颈，再从进程级（iotop/lsof）、页缓存层（/proc/pid/io）、块设备层（iostat/blktrace）到硬件层（dd with direct）逐层定位，同时警惕deleted文件、biovec合并失效及strace盲区，用perf或ebpf替代低效追踪。
Linux 存储性能瓶颈不能只看“磁盘慢”三个字。真正卡住的，往往不是硬盘本身，而是从应用发起请求开始，经过页缓存、文件系统、I/O调度器、块设备层，最终抵达物理设备这一整条链路上某个环节的阻塞或低效。排查必须分层下钻，否则容易误判——比如把 mmap 内存映射读写慢归咎于磁盘，实则问题出在 TLB 压力或大页未启用。
先确认是不是真瓶颈：看 %wa 和 iostat -x 的组合信号
top 中 %wa（I/O wait）持续高于 20%，且 %us/%sy 并不高，是磁盘 I/O 瓶颈的强提示。但要注意：
• %wa 高 ≠ 磁盘坏，可能是单个慢请求（如 NFS 延迟、存储阵列响应异常），此时 iostat -x 显示 %util 很低但 await > 10ms（HDD）或 > 1ms（SSD）；
• %util 持续 > 80% + await 同步升高，才说明设备确实饱和；
• 若 %util 低但 iotop 显示某进程 I/O 很高，要警惕它没走 read/write（比如用 mmap 或 io_uring），strace 可能完全看不到调用。
定位具体环节：从进程到内核栈的四层下钻
• 进程级：用 iotop -oP 查线程级实时 I/O，结合 lsof -p
• 页缓存层：用 cat /proc/
• 块设备层：用 iostat -x 1 观察 avgrq-sz（平均请求大小），若远小于 4K，属随机小 IO，需检查应用是否批量写不足；再用 blktrace 抓取 bio 请求流，确认是否在 elevator 层被合并失败；
• 硬件层：dd 测速必须加 oflag=direct conv=fdatasync，否则测的是 page cache；SSD 要关注 queue depth 和 NVMe namespace 是否启用多队列。
揪出“隐形”资源占用：deleted 文件与 biovec 合并失效
df -h 显示空间已满，但 du -sh /* 找不到大文件？运行 lsof +L1 —— 它会列出所有“已删除但仍被进程打开”的文件。常见于日志服务未 reload、容器内长期运行的 Java 进程持有旧日志句柄。
另外，biovec 是内核中描述 I/O 片段的结构。当应用发出大量非对齐、跨页的小写请求时，biovec 合并失败，导致本可合并的 IO 被拆成多个 request 下发，加剧调度器压力。可通过 /sys/block/
绕过用户态陷阱：别依赖 strace 看 I/O 行为
strace -p 无法捕获 mmap、io_submit、preadv2 等非标准路径的 I/O，且 ptrace 机制本身会拖慢目标进程数倍，生产环境禁用。
更可靠的方式：
• 对特定进程：用 perf record -e block:block_rq_issue,block:block_rq_complete -p
• 全局视角：用 bpftrace 或 eBPF 工具（如 biosnoop）跟踪 bio 提交链路，直接观测从 submit_bio 到 device driver 的延迟分布；
• 验证系统调用开销：若怀疑 syscall 本身耗时，可用 perf record -e syscalls:sys_enter_read,syscalls:sys_exit_read -p
