直接用bcc-tools查磁盘瓶颈，关键不是看“用了多少io”，而是看“谁在用、怎么用、为什么慢”：biotop定位高io进程，opensnoop/execsnoop追踪文件操作与刷盘行为，xfsslower/ext4slower捕获慢路径操作，biosnoop下探块层排队与响应延迟。
直接用 bcc-tools 查磁盘瓶颈，关键不是看“用了多少IO”，而是看“谁在用、怎么用、为什么慢”。传统工具如 iostat 或 iotop 只能告诉你某进程 IO 量大，但无法回答：是小文件随机写拖慢了？是某个系统调用卡在 fsync 上？还是 XFS 日志刷盘延迟突增？bcc-tools 的优势正在于穿透内核路径，定位到具体操作级别。
用 biotop 定位高 IO 活跃进程
这是第一步，快速锁定嫌疑对象：
- 运行
/usr/share/bcc/tools/biotop 5（监控 5 秒），它会按 I/O 字节数和延时排序显示实时读写进程 - 重点关注 D 列（R/W） 和 AVGms 列：即使字节数不大，但 AVGms 超过 10ms 的进程，很可能是小文件或元数据操作导致的延迟型瓶颈
- 注意
kswapd0或jbd2出现在前列——这往往指向内存压力引发的交换刷盘，或 ext4 日志提交阻塞
用 opensnoop + execsnoop 追踪文件操作源头
biotop 告诉你“谁在 IO”，opensnoop 和 execsnoop 告诉你“它在碰什么文件、怎么启动的”：
- 先开
/usr/share/bcc/tools/opensnoop -n your_app_name（比如-n nginx），观察其打开的配置文件、日志路径、临时目录是否异常（如反复 open/close 同一锁文件） - 同时运行
/usr/share/bcc/tools/execsnoop | grep -E "(fsync|sync|fdatasync)"，抓取主动刷盘行为——若看到大量短生命周期进程频繁调用fsync，说明应用层存在不合理的持久化策略 - 特别留意
ERR != 0的行：如open返回 -2（ENOENT）却反复重试，可能因路径配置错误导致空转消耗 IO
用 xfsslower 或 ext4slower 捕获慢路径操作
这才是查深层瓶颈的核心。它不看总量，而记录单次操作耗时超过阈值的实例：
-
/usr/share/bcc/tools/xfsslower 10（XFS 文件系统）或/usr/share/bcc/tools/ext4slower 10（ext4），数字表示毫秒阈值 - 输出包含 T (ms)、COMM、PID、TYPE（如
write、create、unlink）、OFFSET、BYTES 和 PATH - 典型线索：
create耗时 >50ms → 可能是目录项查找慢（inode 分布碎片化）；write耗时突增且BYTES=4096→ 高概率是小块同步写卡在日志提交或磁盘寻道
用 biosnoop 看到底层块设备响应
如果上层工具都指向某进程，但怀疑是硬件或驱动问题，就下探到块层：
-
/usr/share/bcc/tools/biosnoop显示每个 I/O 请求从发出到完成的完整生命周期，含 QUEUED（排队时间）、ISSUE（下发时间）、COMPLETION（完成时间） - 若
QUEUED时间长 → 队列深度不足或 IO 调度器拥堵（检查cat /sys/block/vda/queue/nr_requests） - 若
ISSUE到COMPLETION时间长，且集中在某 LUN → 硬件响应慢，需结合smartctl和存储侧日志交叉验证
