📚 课程目录第4章剖析工具基础与数据采集

4. 剖析工具基础与数据采集

性能剖析的成败，往往在“采集”这一步就已经决定。工具选得不对、采样频率设得不合理、插桩范围过大，都会让后续分析建立在失真甚至错误的数据之上。本节围绕五类常用工具——perf、VTune、gprof、TAU、Score-P——讲清它们各自的采集机制、典型配置方式，以及数据采集中最容易踩的坑。

两类采集机制：采样与插桩

所有剖析工具归根结底只有两种获取信息的方式。采样（sampling）依靠定时中断或硬件计数器，周期性记录当前指令指针与调用栈，属于“统计推断”：频率越高越接近真实分布，但永远存在遗漏，且对短小函数不敏感。插桩（instrumentation）则在函数入口/出口或指定代码段插入计时代码，能精确统计每次调用的耗时与次数，代价是额外开销，且需要重新编译或依赖编译器/链接器支持。理解这一点，才能判断某份数据“能不能信”。

perf：零侵入的系统级采样

perf 是 Linux 上最易上手的入口。它不需要重新编译，直接利用内核的 perf_event 子系统。典型流程是先采集再报告：

# 以 997Hz 采样，记录调用栈，采集 30 秒
perf record -F 997 -g -- sleep 30
# 查看热点函数及占比
perf report --stdio --sort comm,dso,symbol
# 统计某进程的缓存未命中
perf stat -e cache-misses,cache-references,instructions ./app

这里有两个关键参数值得说明。-F 997 而非 1000，是为了避开与系统定时器（如 1000Hz 的 tick）同频导致的采样偏差——同频采样会系统性地总是命中同一批指令，形成“采样混叠”。-g 开启调用栈展开，但若程序编译时省略了帧指针（-fomit-frame-pointer），栈回溯会失败，perf 只能给出扁平的热点而无法还原调用关系。此时应改用 --call-graph dwarf，代价是更大的采样开销与更长的处理时间。

另一个常见障碍是权限。默认 perf_event_paranoid 值较高时，普通用户无法采集内核事件。可临时调整：

cat /proc/sys/kernel/perf_event_paranoid   # 常见为 2 或 3
sudo sysctl -w kernel.perf_event_paranoid=1

VTune：微架构级归因

当 perf 只能告诉你“哪个函数热”，而你需要知道“为什么热”时，VTune 的硬件事件分析更有价值。以热点分析为例：

vtune -collect hotspots -result-dir ./r1 -- ./app
vtune -report summary -result-dir ./r1
vtune -collect memory-access -knob sampling-interval=10 -- ./app

VTune 能给出 CPI（每指令周期数）、前端/后端绑定、缓存层级命中率等指标，帮助区分“计算密集”与“访存受限”。但要注意：在虚拟机或容器中，PMU（性能监控单元）常被禁用或虚拟化，采集会退化为基于时间的采样，微架构指标不可用。采集前应先用 lscpu 确认 CPU 型号，并检查 /proc/sys/kernel/perf_event_paranoid 与容器权限。

gprof：轻量但边界清晰

gprof 采用“编译期插桩 + 运行期 PC 采样”的混合模式。使用只需两步：编译时加 -pg，运行后生成 gmon.out：

gcc -O2 -pg -o app app.c
./app
gprof ./app gmon.out | head -40

gprof 的局限必须提前知道：它不统计库函数（如 memcpy、BLAS 调用）的时间，因为那些代码没有插桩；内联函数在优化后消失，也无法单独统计；多线程程序的时间归属会混乱。因此 gprof 适合快速定位“自己代码里哪个函数最耗时”，不适合分析依赖库或并行程序。

TAU 与 Score-P：并行程序的插桩体系

TAU 和 Score-P 面向 HPC 与并行程序，核心思路是用编译器包装器自动插入测量点。TAU 的典型用法是替换编译器：

tau_cc.sh -O2 -o app app.c        # C 程序
tau_exec ./app                     # 或对已有二进制做动态插桩
pprof                           # 查看 profile 结果

Score-P 类似，通过 scorep 前缀包装编译命令，运行后产出 OTF2 格式的 trace，再用 Vampir 可视化时间线，观察 MPI 通信与计算的重叠情况：

scorep --mpp=mpi mpicc -O2 -o app app.c
scorep --mpp=mpi mpirun -np 8 ./app
# 生成 trace 后可用 vampir 打开分析

这类工具的采集陷阱集中在“开销”与“缓冲”。插桩每个函数调用都写事件，若函数被调用上亿次，trace 文件会急剧膨胀，程序行为也被严重扭曲。应通过过滤配置只插桩关键区域（如 Score-P 的 --instrument-filter 文件），或改用采样模式。同时，事件缓冲区若设置过小，运行中会丢事件，导致时间线出现空洞——这在使用 PAPI 计数器或高并发 MPI 时尤其常见。

数据采集的共性陷阱

观测者效应：插桩开销使程序变慢，热点排序可能改变。应对比插桩前后总运行时间，若膨胀超过 20%，结论需谨慎。
采样频率与混叠：固定频率采样可能周期性错过某些代码段，建议使用质数频率或随机抖动。
优化级别不一致：用 -O0 采集的数据不能代表 -O2 发布版的性能，函数可能被内联或消除。
短时程序：运行不足一秒的程序，采样点太少，统计无意义，应循环放大负载或改用插桩。
环境噪声：后台进程、频率调节（turbo/节能）会污染数据，采集前应固定 CPU 频率、关闭无关服务。

采集前先问三个问题：我要回答的是“哪里慢”还是“为什么慢”？程序是单机还是并行？能否接受重编译？答案会直接决定选采样还是插桩、选 perf 还是 Score-P。

把工具选型与陷阱对照起来看，采集就不再是“跑个命令看结果”，而是一次有明确假设、可验证、可复现的测量实验。只有数据本身可信，后续的瓶颈定位才有意义。