简介这份压缩包提供 Linux 下 perf 性能分析工具的完整可运行环境适合系统运维与后端开发人员用于定位 CPU 热点、缓存命中率低、调用链异常等性能瓶颈。包内共 8 个文件包含 perf 主程序、三个动态库、运行支撑的 0 字节占位文件及一个自动化测试脚本整体约 9.08MB便于直接部署或集成到测试流程中。资源已吸引 2531 人学习下载实用性得到较多关注。借助其中脚本可快速执行采样、事件统计与重复对比测试结合库文件支持可覆盖从内核态到用户态的调用链分析帮助使用者将性能数据映射到源码层级是开展系统级性能调优的一套轻量工具组合。1. perf 性能测试工具先搞清楚它是剖析器不是压测器先说个大部分人都会踩的坑以为 perf 是压测工具拿它去测并发接口结果一条命令下去程序还没启动它就退出了。perf 名字里虽然带 performance但它是 Linux 内核自带的性能剖析工具不是压测工具。它解决的是压测之后的问题——当接口延迟飙高、CPU 被打满top 只能告诉你哪个进程在烧 CPUperf 能告诉你这个进程里到底是哪个函数、哪一条指令在烧。它零安装、零侵入适合 C/C/Go/Rust 这类编译型服务也适合作为排查线上 CPU 异常的通用第一步。这篇笔记按我自己的使用习惯从事件模型讲到火焰图再讲翻车现场和验证方法目标是让你看完就能在现有工程里跑起来。2. perf stat 起步事件模型与第一份基线数据perf 的底层是内核的 perf_event 子系统用户态命令只是它的壳。想用好它先理解它提供的三种信息形态计数、采样、追踪。perf stat是计数模式负责回答「这段时间内发生了多少次某类事件」perf record是采样模式按固定频率打断 CPU记录当时的执行位置和调用栈perf trace和perf probe属于追踪模式用来观察系统调用和动态插桩。日常排查前两种占了我九成使用量后者在查锁竞争和系统调用时才拉出来。2.1 事件从哪来硬件 PMU、软件计数与内核 tracepointperf 能统计的事件大致分三类。硬件事件来自 CPU 里的性能计数器PMU比如 cycles、instructions、cache-misses、branches它们直接反映 CPU 微架构行为软件事件由内核计数比如 task-clock、context-switches、page-faultstracepoint 则是内核编译时埋好的静态跟踪点比如 sched:sched_switch 记录切走切进、kmem 相关记录内存分配。这就是为什么同一台机器换了 CPU 之后事件名可能对不上。perf list 才是你机器上事件名的唯一真相别照抄网上的命令就指望通用。我曾经在一台 ARM 服务器上跑 x86 教程里的事件名perf 直接报错换成 perf list 里实际的cache-misses名字才正常。2.2 抓第一份 perf stat 基线最小命令与输出解读假设你的程序已经能跑起来先给它套一层 perf stat 看看基线# 直接启动命令并统计-- 后面的参数都传给被测程序 perf stat -- ./myapp --configprod # 或者统计已经在跑的进程持续 5 秒 # perf stat -p 12345 -- sleep 5输出类似下面这样每一行代表一个事件计数和摘要Performance counter stats for ./myapp: 880.05 msec task-clock # 0.992 CPUs utilized 33 context-switches # 37.499 /sec 4 cpu-migrations # 4.545 /sec 312 page-faults # 354.543 /sec 3,524,876,430 cycles # 4.005 GHz 6,180,929,840 instructions # 1.75 insn per cycle 750,210,113 branches # 852.539 M/sec 12,220,940 branch-misses # 1.63% of all branches先看task-clock和CPUs utilized。task-clock 是进程真正占用 CPU 的时间如果用墙钟时间去除它得到 0.99说明这是一个单线程 CPU 密集任务几乎没有等待如果这个数字只有 0.2说明进程大部分时间在睡觉、等 I/O 或者等锁这时候单纯看 CPU 热点没有意义该去看 off-cpu 分析。再看insn per cycle也就是 IPCInstructions Per Cycle。它对 CPU 密集任务是个很好的健康指标IPC 在 0.5 到 1.5 之间是常见区间高于 2 说明流水线吃得非常满低于 0.5 配上高 cache-misses基本可以断定瓶颈在访存而不是计算这时加计算优化没有意义该考虑缓存友好度。branch-misses 的比例同理超过 5% 说明分支预测损失明显热点代码里如果有大 switch 或乱序 if值得重构。2.3 按需选事件perf list 与常用事件速查默认统计的事件适合看整体但定位具体问题要用-e指定事件# 查本机支持哪些事件 perf list | grep -i cache\|branch # 只看缓存失配和上下文切换 perf stat -e cache-misses,cache-references,context-switches -- ./myapp下面这几个事件是我最常组合的按使用频率排事件名类型用来判断什么cycles硬件CPU 周期总数程序到底烧了多少算力instructions硬件执行的指令条数结合 cycles 算 IPCcache-misses / cache-references硬件末级缓存失配率访存瓶颈的核心指标branches / branch-misses硬件分支预测失配率适合排查乱序分支代码task-clock软件进程实际占用 CPU 的时间判断是否在等待context-switches软件进程被切走的次数过高说明锁或调度有问题page-faults软件缺页次数内存充足但频繁缺页时值得看注意一点新内核里事件名可能显示成cpu_core/cycles/这种带 PMU 前缀的形式本质是同一件事性能数据也能对上。perf stat还支持-I 1000按秒打印快照适合观察周期波动-r 3可以重复执行 3 次取平均值后面讲对照实验时还会用到。拿到基线之后下一步才是定位热点把「烧了多少 CPU」细化到「烧在哪一行」。3. perf record 与 report把热点精确到函数和指令perf stat 给的是总量perf record 给的是分布。前者回答「多少」后者回答「在哪里」。这是排查线上性能问题时价值最大的一组命令。3.1 采样的数学与代价为什么 99Hz 就够用perf record 的原理是周期性打断 CPU记录当前正在执行的指令地址和调用栈。假设程序跑了 20 秒采样频率 99Hz你大约会得到 1980 个样本。统计学告诉我们用样本推断总体时误差大概在1/√N量级——1980 个样本意味着热点占比的误差在 2% 左右这对定位性能热点来说已经足够。那为什么不把频率调成 9999Hz因为每次采样都是一次中断、一次内核态切换、一次写 perf.data 的开销频率越高测量本身就在改变被测系统。99Hz 是实践里反复验证过的平衡点它避开和内核调度器 tick通常也是 100Hz共振又不会过分扰动程序。我见过有人为了「更精确」把频率拉到 9999结果程序本身变慢了 30%热点分布完全失真。记住一个原则采样是用来「找方向」的不是用来「算账」的。3.2 最小三步工作流record、report、annotate最常用的工作流是采正在跑的进程或者直接启动命令# 方式一采样正在运行的进程20 秒后自动停止 perf record -F 99 -g -p 12345 -- sleep 20 # 方式二直接启动被测命令并采样CtrlC 结束 perf record -F 99 -g -- ./myservice --listen:8080参数含义拆开解释-F 99是每秒采样 99 次-g记录调用栈-p指定目标 PID-- sleep 20的意思是「把 sleep 作为伴随进程20 秒后结束采样」。默认数据落在 ./perf.data一个 20 秒的采样大概几十到几百 MB取决于调用栈深度记得留足磁盘空间。采样完成后看结果# 静态文本输出先看头部热点 perf report --stdio | head -40 # 或者直接进交互界面方向键浏览回车展开调用栈 perf report如果第一个热点函数的占比就超过 50%事情很清楚了但更多时候热点是分散的需要往下钻。交互界面里选中某个热点函数按a直接进入 annotate 模式perf 会把采样对应到每条汇编指令逐行显示百分比。命令行模式也有等价写法perf annotate --stdio -s 你的热点函数annotate 输出里那一列数字就是采样落在这条指令上的比例。真正的热点通常集中在一两条循环体内的访存或分支指令上而不是函数开头那一堆栈操作。3.3 Overhead 与 Children热点报告的正确读法perf report 默认有两列新手最容易混淆Overhead 和 Children。Overhead 是「这个函数自身在采样中出现的比例」也就是自耗时Children 是「这个函数连同它调用的所有子函数加起来」的累计比例。举个例子函数 A 的 Overhead 只有 5%但 Children 高达 80%函数 B 的 Overhead 是 60%Children 也是 60%。这说明 A 是个「带节奏的调用者」真正烧时间的是它调用的子函数们B 则是个「自烧型」函数时间都花在自己身上。优化的时候优先动 B 这种自占比高的叶函数而不是去动 A——你改了 A大概率只是把时间从一个子函数挪到另一个子函数。线上遇到函数名带模板、命名空间特别长的 C 代码报告会被刷屏可以用--sortdso,symbol先按共享对象聚合再定位到具体库。3.4 把调用栈变成火焰图perf script 与折叠管线火焰图不是 perf 自带的但现在已经是性能剖析的事实标准可视化。Brendan Gregg 的 FlameGraph 项目提供了一套 Perl 脚本和 perf 配合的管线固定是三步# 1. 把 perf.data 转成文本 perf script out.perf # 2. 折叠成「调用栈路径 次数」的统计行 stackcollapse-perf.pl out.perf out.folded # 3. 渲染 SVG 火焰图 flamegraph.pl out.folded flame.svg浏览器打开 flame.svgX 轴是采样占比Y 轴是调用栈深度。读图时先找「平顶」——那些宽度大、顶部平坦的区块说明大量样本都停在这个函数里是真正的自耗热点深而窄的栈尖通常只是路径深占比不高不必急着处理。一个常见误区是盯着图上颜色判断热点火焰图默认配色只为了区分不同栈帧没有性能语义。火焰图还能直观对比两个版本分别导出两张图放在一起看哪一块「变宽了」。这张图通常比 perf report 的数字列表更容易说服同事也是我做性能优化交付时的默认附件。4. perf 避坑5 个让结果失真或直接翻车的现场perf 用起来不难难的是数据出来以后你敢不敢信。下面这几个坑我基本都踩过按出现频率排序。4.1 权限拒绝perf_event_paranoid 与容器限制现象perf stat报错You may not have permission to collect stats或者 perf record 采完所有样本都是 0。原因内核参数kernel.perf_event_paranoid默认值通常是 2非特权进程不允许访问内核态事件部分发行版更严格。容器场景还多一层容器里可能缺 CAP_PERFMON 权限即使宿主允许也采不了。解决先看当前值再决定怎么办。cat /proc/sys/kernel/perf_event_paranoid # 受控环境临时放宽到 1允许用户态采样 sudo sysctl -w kernel.perf_event_paranoid1生产环境不要随手改全局参数优先用 sudo 跑 perf容器里则换一个有权限的 base 镜像或者用特权容器跑采集端。改完记得恢复原值这个参数影响的是全系统安全边界。4.2 调用栈断在 [unknown]帧指针优化怎么破现象火焰图只有三四层大量[unknown]看不到业务函数名尤其 C/C 程序常见。原因编译器在 -O2 及以上默认开启-fomit-frame-pointer不再维护 rbp 帧指针。perf 默认用帧指针回溯调用栈帧指针被当作通用寄存器用掉后回溯到某一层就断了。解决两个方向。一是编译时保留帧指针性能压测版本单独加gcc -O2 -fno-omit-frame-pointer -o myapp myapp.c二是采样时改用 DWARF 调试信息展开调用栈代价是采样开销大几倍perf.data 体积也膨胀perf record -F 99 --call-graph dwarf -p 12345 -- sleep 20如果两种都不想做至少在火焰图里还能看到叶节点热点牺牲调用路径换采样精度是一种可接受的降级方案。JIT 类语言Java、Node.js 等还要额外配 jitdump 接口才能看到业务方法名否则只能看到解释器的 C 函数符号这类程序我更推荐直接用语言自带的 profiler。4.3 内核符号全是 [unknown]kptr_restrict 在作怪现象用户态函数名正常但内核态符号全是[unknown]或是一串0xffffffff...地址没法看。典型的场景是查 redis 或 nginx 高并发下的系统调用开销。原因另一个内核参数kernel.kptr_restrict1会限制非 root 用户读取 /proc/kallsymsperf 无法把内核地址翻译成符号名。解决采样时用 sudo或者在受控环境临时放行echo 0 | sudo tee /proc/sys/kernel/kptr_restrict # 用完恢复echo 1 | sudo tee /proc/sys/kernel/kptr_restrict系统调用密集的服务里用户态只能看到问题的表象内核态热点占比可能高达两三成这一条不处理火焰图永远缺一块。4.4 短程序样本太少固定频率采样的统计陷阱现象程序只跑两三秒-F 99采样完 perf report 里只有几十个样本热点排名每次都不一样甚至第一行是[unknown]。原因固定频率采样在短生命周期程序上样本数量天然不足启动和退出路径又被不成比例地放大。还有人会把频率调特别高试图「补样本」结果触发内核的采样保护机制perf_cpu_time_max_percent会限制 perf 自身 CPU 占用实际采样率被压缩数据更没法看。解决让被测程序多跑一会儿或者用事件间隔采样替代时间频率采样。事件间隔采样按每 N 个事件取一个样本适合事件密集的短程序perf record -c 100000 -g -- ./myapp这里的-c 100000表示每 10 万个 CPU 周期采一次。总样本数低于几百份的报告不要拿去下结论先解决样本量再讨论热点。4.5 结果漂移两次采样热点排名对不上现象同一份代码前后跑两次 perf record热点排名差异很大或者优化后测试提升明显过一会儿再测又没了。原因统计噪声、后台任务干扰、多核 NUMA 调度的不确定性还有被测程序自身输入数据的差异。性能剖析不是绝对测量它是一套带误差的推断。解决先稳定环境再谈性能。绑核、重复采样、固定输入这三件事缺一不可# 绑到 0 号核重复 3 次看标准差 taskset -c 2 perf stat -r 3 -e task-clock,instructions,cycles -- ./myapp对比两个版本时用同一份测试数据、同一台机器、同一批后台负载关闭 cron 和监控脚本。多个火焰图之间比对时看差集而不是单张图结论会更稳。先怀疑数据再怀疑代码是我踩过这个坑之后立下的规矩。5. 把优化验证坐实对照实验与采样可信度看到热点只是第一步难的是证明你的修改真的有效。我自己的标准做法是固定跑对照实验而不是靠「感觉快了」。# 优化前 perf stat -r 3 -e task-clock,cycles,instructions,cache-misses -- ./bench_old # 优化后 perf stat -r 3 -e task-clock,cycles,instructions,cache-misses -- ./bench_new对比时只看两个数字task-clock总 CPU 时间和热点函数的自占比。如果 task-clock 下降了但热点函数占比没变说明你优化的是非关键路径问题被挪到了别处如果 task-clock 没降但 IPC 明显提升说明优化方向对只是总工作量变大抵消了收益。两个数字同时改善才算是一次真正有效的优化。采样可信度也要一并检查。perf report 输出底部有一行类似Samples: 1K of event cpu-clock这里能看到总样本数。少于 500 个样本的结论我一般只当线索不当证据只有样本量足够、环境固定、重复结果稳定才能拿去说服别人改代码。我自己有个雷打不动的习惯优化前先存一份基线火焰图和 stat 输出优化后只对比上述两个核心数字其他指标一律当参考。新手最常犯的错就是拿一堆指标互相打架最后说不清自己到底优化成功没有。先让结论可复现再谈优化幅度。希望帮到你。本文还有配套的精品资源点击获取