perf 可监控文件系统层面的磁盘调用行为，聚焦调用主体、方式及开销，通过 perf stat 统计系统调用频次与耗时，perf trace 追踪 I/O 生命周期延迟，perf record -g 分析内核路径热点，并需结合 iostat、/proc/diskstats 等工具交叉验证真实瓶颈。
perf 能直接监控文件系统层面的磁盘调用行为，但需明确：它不替代 iostat 或 sar 这类 I/O 吞吐量工具，而是聚焦于“谁在调用、怎么调用、开销在哪”——比如某个进程频繁触发小 write、某个路径反复 open 失败、或 vfs 层函数成为瓶颈。
抓取关键系统调用事件
文件系统 I/O 的起点是系统调用。perf 可精准统计 read/write/open/fstat 等调用频次与耗时：
- 运行 perf stat -e syscalls:sys_enter_read,syscalls:sys_enter_write,syscalls:sys_enter_openat -p
，观察单位时间内各调用次数。若 write 次数远高于数据量（如每秒 2000 次 write，但总写入仅 1MB），说明存在大量小写或日志刷盘行为。 - 加 -I 1000 参数实现每秒采样一次，便于观察波动趋势；配合 timeout 10 限制总时长，避免干扰业务。
- 注意：syscalls:xxx 事件需内核支持 tracepoint，4.14+ 主流发行版默认启用；若提示 event not found，可先运行 perf list | grep syscalls 确认可用项。
定位阻塞型 I/O 延迟
单纯看调用次数不够，还要知道“卡在哪”。perf trace 可追踪请求从发出到完成的完整生命周期：
- 执行 perf trace -e block:block_rq_issue,block:block_rq_complete -p
，会输出类似：
write(2) ... → block_rq_issue → block_rq_complete → return
从中可计算每个 I/O 的 issue→complete 时间差，即实际设备处理延迟。 - 若发现大量请求 delay > 5ms，且伴随高 block:block_rq_requeue 事件，说明队列拥塞或设备响应慢；若 delay 正常但整体 write 延迟高，则问题可能出在 page cache 回写或 fsync 阻塞。
- 该命令对磁盘压力极小，适合短时在线诊断，无需停服。
关联内核路径分析热点
当发现某类调用异常高频，需深入内核函数栈看“为什么调用”：
- 用 perf record -e syscalls:sys_enter_write -g -p
-- sleep 5 录制带调用图的数据。 - 再运行 perf report --no-children，重点关注 Symbol 列中 vfs_write、__generic_file_write_iter、ext4_file_write_iter 等路径占比——若 ext4_commit_super 占比突增，可能因元数据更新频繁；若 __x64_sys_openat 耗时高，需检查路径解析或权限检查开销。
- 确保已安装对应内核调试符号（如 linux-image-$(uname -r)-dbgsym），否则函数名显示为 [unknown] 或地址，无法定位。
结合上下文判断真实瓶颈
perf 给出的是“现象”，结论需交叉验证：
- 如果 sys_enter_write 高频但 perf stat 显示 cache-misses 也同步飙升，可能是 buffer 不足导致反复缺页；此时应查 /proc/meminfo 中 PageTables 和 SReclaimable。
- 若 block_rq_issue 频次低但单次延迟长，而 iostat 显示 %util 接近 100%，说明磁盘确实饱和；若 %util 很低却延迟高，则可能是存储栈上层（如 LVM、md、NVMe queue depth）限制。
- 不要孤立看 perf 数据——它反映“软件视角的 I/O 行为”，必须和 iostat（硬件队列）、/proc/diskstats（底层扇区计数）、dmesg（error 日志）一起读。
