perf实战：从CPU热点定位到指令级优化

上个月排查一个上报服务的CPU瓶颈时，我用perf在线上抓了一把热点，眼睁睁看着一个十六进制解码函数占了将近三分之一的CPU。这种“热点很明确、问题很扎手”的场景，恰恰是perf最擅长的：不需要打日志猜，直接用采样告诉你下一步该看哪。这篇文章记录我从perf定位热点、到perf annotate盯着汇编看、最后一步步把解码函数从一堆条件分支优化到底层指令的全过程。适合正在处理性能问题但还没系统用过perf的人，也适合已经会用perf top，却不知道如何把优化落到指令级别的同学。

1. perf不神秘：先弄懂它如何“看穿”CPU

1.1 采样而不是插桩，这是关键

很多人在刚接触perf时有个困惑：它既不往代码里塞探针，也不需要重新编译就能知道热点在哪，到底做了什么？

核心答案就四个字：硬件采样。perf利用CPU自带的性能监控单元，按固定频率触发中断，在每个中断点记录当前正在执行的指令地址和调用栈。你跑10秒，它可能采样几千次，最终统计出来的分布就是CPU时间花在哪里的近似图。

这和我们平时用printf打印时间戳截然不同。插桩会改变程序行为，还要求源码可改；采样对程序几乎透明，能直接用在线上生产环境。缺点也明显：它看到的是“大概率”，不是“精确值”。采样频率越高越接近真相，但开销也会变大。实际用的时候，-F 999这个档位基本够用，意思是每秒采样999次，大概控制在千分之一级别的开销。

1.2 四个子命令解决绝大多数问题

perf家族命令很多，但日常实战最常用的就是这四个：

一套标准打法就是：先用perf top定性，再用record+report定量，最后用annotate到指令级。整个过程不需要改代码，也不依赖调试符号有多少，只要二进制里保留了-g级别的符号信息就行。

1.3 两个容易踩的环境坑

第一，内核采样权限。很多发行版默认kernel.perf_event_paranoid=2，这时普通用户只能采用户态事件，采不到内核态调用栈。线上抓问题可以直接提权执行，或者临时调低这个值：

bash复制sudo sysctl kernel.perf_event_paranoid=1

第二，调用栈的展开方式。老版本里-g默认用帧指针回溯，但现代编译器默认-O2可能省略帧指针，导致调用栈是空的。我一般直接写：

bash复制perf record -F 999 --call-graph dwarf -p PID -- sleep 30

dwarf模式慢一些，但栈信息完整。等后续需要精确分析时，再用fp模式对比一下。

2. 一次真实热点排查：从perf top到perf annotate

2.1 先还原一下现场

我优化的服务是一个数据上报网关，客户端发来的报文里有大段的十六进制字符串，我们需要实时解码成二进制再做转发。接口的吞吐一直卡在每秒几万条上不去，CPU跑满了，但谁都不知道热点在哪。因为代码早就经历过好几轮C++/优化改造，靠肉眼扫循环已经不现实。

先写一个最小复现benchmark，把线上收到的典型报文灌进去，保证后面每次优化都在同一份输入下对比。这一步非常重要：没有稳定输入，后面所有perf数据都无从对齐。

2.2 perf top一眼锁定目标

在服务运行状态下执行：

bash复制sudo perf top -g -p $(pgrep -f gateway)

几秒钟后，列表里有一个叫hex_decode的函数占了31.8%。这个比例相当显眼，排第二的只有百分之七左右。这说明问题不是全局分散的，而是高度集中在一个函数里。到了这一步，方向基本明确：不是去看底层的锁竞争，也不是去调网络参数，先把hex_decode干掉再说。

2.3 record加report拿到调用链和精确占比

perf top适合快速看，但要拿稳定可复现的数据，还是得record：

bash复制sudo perf record -F 999 --call-graph dwarf -p $(pgrep -f gateway) -- sleep 30
sudo perf report

30秒采集在最终report里大概生成了上万条样本。能看到两层信息：一是hex_decode自身CPU占比约28%到33%浮动；二是调用它的是parse_report_line，这排除了“热点是A函数但其实是B