1. Perf到底是个什么工具
我最早接触Perf是在排查一次线上服务CPU异常飙升的时候。那会儿服务器负载已经报警，top一看某个进程占了接近百分之三百的CPU，代码上翻来覆去看了好几遍都没看出问题在哪。后来用Perf采样了几分钟，一眼就定位到是某个字符串匹配函数内部的一个热点循环，优化完之后负载直接降下来。那次之后我就把这个工具当成性能排查的常备武器了。
Perf是Linux内核自带的性能分析工具，全称是Performance counters for Linux，早在2.6.31版本的内核里就合入了主线。它的基本原理是借助内核的Performance Events子系统，通过硬件性能计数器、软件事件、tracepoint等维度采集系统运行时的数据，再汇总成报告供开发者分析。它和gprof这类编译期插桩工具最大的区别在于——Perf几乎不会侵入程序本身，不需要重新编译代码，也不需要在代码里埋点，直接对正在运行的程序做采样，特别适合排查线上问题。
这几年我用Perf做过的事情大致包括：定位“某个进程CPU爆高但不知道在干什么”、分析系统调用频繁导致的性能损耗、统计缓存命中率验证优化效果、甚至排查过NUMA架构下内存访问延迟异常的问题。它并不只是用来“看出来”问题，很多时候还是用来“验证”优化之后到底有没有效果。一个工具能同时承担“定位”和“验收”两种职能，这也是Perf在设计上相当务实的地方。
如果你刚接触这个工具，也不用有压力。Perf虽然参数很多，但绝大多数场景下常用的命令就那么几条。这篇文章我会从最基础的计数器概念讲起，把整个使用链条串起来：看懂事件、跑出报告、定位函数、结合代码确认问题、最后再验证优化效果。这个过程带下来了，基本就够应付日常大部分性能问题了。
适合看这篇文章的朋友有两类：一类是后端开发或运维，服务出问题时需要快速找到性能瓶颈；另一类是做底层优化、要验证编译器选项或内核参数效果的人。如果你只是写简单脚本、没有高性能诉求，Perf可能暂时用不上，但理解这套分析思路对你后续排查复杂问题依然有帮助。
2. 从计数器到采样：Perf是怎么看到程序内部的
2.1 硬件计数器和软件事件的区别
Perf的数据来源主要分两层。第一层是硬件性能计数器，这是CPU内部真实存在的寄存器，能够记录诸如CPU周期数、执行的指令数、分支预测失败次数、缓存未命中次数等事件。这些计数器是芯片厂商在设计CPU时就实现的，精度非常高，而且开销极小，因为硬件自己就在数，不需要额外干涉。
第二层是软件事件和内核tracepoint。软件事件比如上下文切换次数、CPU迁移次数、页面错误次数，这些由内核在相应逻辑路径上统计。tracepoint则是内核里的一个静态埋点机制，像函数调用、系统调用、网络收发包这些行为都能通过tracepoint被记录。Perf把这两类事件统一抽象成事件源，用一套语法来指定。
实际使用中，最常用的事件大概包括指令周期数、CPU周期数、分支预测相关的、缓存未命中的。有些芯片厂商还提供自定义的PMU事件，比如Intel的offcore事件可以用来分析访问远端内存的行为。普通开发者其实不需要记太多编号，Perf提供了常见事件的别名，比如cycles、instructions、cache-misses，直接用这些可读性高的名字就行。
有个容易混淆的点是“指令数”和“周期数”的关系。指令数是在程序运行期间CPU执行了多少条指令，周期数则是耗费了多少个时钟周期。两者相除相当于平均每周期执行的指令数，这个值也叫IPC（Instructions Per Cycle），通常用来衡量CPU执行效率。IPC太低往往说明流水线经常停摆，可能是在等内存、等分支预测、或者是多核之间共享数据产生争用。Perf跑一次程序就能直接给出这些数，省了自己去估算的功夫。
2.2 采样的原理：不打断程序也能看清热点
Perf分析用户态程序主要用采样模式。所谓采样，就是按照一定的频率周期性触发中断，记录当前正在执行指令的地址，以及当前的调用链。这里的背景是：如果一个函数花了大量时间，那在随机采样时它被命中的概率就高；反过来，采样点分布基本反映了程序的时间开销分布。统计足够多的样本之后，就能得到一个“地毯式”的热点分布。
这种做法很像电视台做收视率调查，不需要每家每户都装监控，只要抽样的样本足够多、足够随机，统计结果就接近真实分布。Perf默认的采样频率大约在几千赫兹，跑几秒钟就能攒下几十万甚至上百万个样本，对热点判断已经足够准确。
不过采样也有一个天然限制：它只能看到“CPU正在执行”的时候。如果程序大部分时间在阻塞等锁、等IO，采样点就会集中在可运行状态那个线程上，看不出锁等待是谁在占用。遇到这类问题，需要用off-CPU分析、或者配合tracepoint去分析阻塞原因。Perf本身也能做这些事，只是普通采样看不出来而已。
2.3 Perf工作在内核和用户态之间的协作方式
从权限角度讲，Perf在2.6.32以下的内核版本里一般要求root权限运行。从某个版本开始，内核引入了perf_event_paranoid等级控制，默认等级为2时，用户态程序只能采样自己的事件，不能读取CPU级的全局统计。如果是在容器或者共享机器上分析别人的进程，就必须先确认权限是否够用，否则采样的数据会不完整。
内核还有个细节是perf_event_open这个系统调用，它是所有Perf操作的基础。Perf命令行的其余部分，包括打开事件、建立映射、读取样本数据等，都是围绕这个系统调用展开的。Perf的设计是“事件驱动”的：先打开一个事件描述符，然后以某种方式启用它，再等待反馈。用命令行跑的时候，你并不会感受到这个流程，但理解这一点有助于解释某些异常现象——比如为什么perf top看不到某个函数，很可能是因为当前进程打开了进程级perf事件但没继承到子进程，导致子进程的热点没有被统计到。
上述机制合在一起，构成了Perf的基本工作框架。硬件计数器负责提供精确计数，内核事件负责暴露系统行为，采样负责把时间开销转化为统计分布。理解了这个框架，后面各种子命令就不会觉得是孤立的了。
3. 常用命令选择：报告、统计、动态追踪怎么分工
Perf的命令行工具集很长，但日常真正高频使用的没有几个。我习惯把它们分成三类：第一类是现场观察类，代表命令perf top，像top命令一样实时刷新，适合快速确认“现在哪个函数最热”；第二类是统计汇总类，代表命令perf stat，整体跑一次程序，给出事件计数和比例，适合做宏观对比；第三类是深入定位类，代表命令perf record和perf report，把采样到的调用链写进文件，然后离线看函数栈和热点，适合精确定位到某一行代码。
除了这三类，还有几个经常被低估的命令值得提一下。perf script可以把采样的原始数据转换成类似trace的文本流，方便和分析脚本对接。perf annotate可以查看某条指令级别的热点注释，把热点精确到具体的汇编指令，这对那些需要做指令级优化的场景非常有用。另外，perf trace类似strace的简化版，但它走的是tracepoint，输出更贴合内核事件的语义，还带时长统计，分析系统调用相关的性能问题很好用。
选命令其实有个经验法则：如果你想快速看某个进程现在在忙什么，直接perf top -p 进程号，几秒内就能看出个大概；如果你想对比两个版本的性能、或者确认某个参数调整是否起作用，优先用perf stat跑对应的基准测试；如果已经知道大概方向、但不知道怎么定位到具体函数，再用perf record记录加perf report报告。这三步走完，绝大多数性能问题都能有一个结论。
下面我按这三个层次分别拆解使用方法和注意事项。
4. 现场看热点：perf top的实战方法与局限
perf top的用法相当简单，就是直接跑，它会像一个动态报表，定时刷新当前系统上的热点函数。常用的参数包括-p指定进程、-e指定事件、-k指定内核符号表、-g开启调用链采样。一般我上手第一件事就是看默认事件cycles下，哪些函数百分比更高。
它的输出列一般包含采样占比、符号名、函数所属模块或二进制。占比越高的说明CPU时间占比越大。如果热点集中在某个C库函数内部，比如memcpy、strlen这些，往往说明程序在做大量内存复制；如果热点集中在自研模块的函数内部，那就值得打开相应的源码看代码。还有一个常见现象是热点出现在一个未知的模块，比如长时间的[jitted]或者[vdso]，这通常表示采样到的地址没有对应的符号信息，要么是JIT编译出来的代码，要么是动态生成的可执行内存。
用perf top有几个需要注意的地方。第一，默认按cycles事件统计，看不到IO等待和阻塞；第二，如果系统负载本身很高，perf top自己也消耗一点CPU，在极端场景下可能看到perf本身出现在列表里，这个不用慌；第三，对于容器内部进程，默认可能看不到宿主机上其他进程的热点，除非容器共享了宿主机的内核视角。这种情况下建议用--pid或者--tid精确指定进程，或者直接用nsenter进入容器的PID命名空间再运行。
另外，perf top有一个很实用的小功能是交互式操作，输入p可以开关调用链展示切换，输入d可以切换采样显示维度。不过实际排查时我很少长时间开着perf top，它更适合做快速定向。因为默认展示维度过于宏观，时间长了信息噪音也多。一旦确认了可疑模块，我会立刻转入perf record去抓调用链，那才是定位问题的关键。
5. 宏观量化窗口：perf stat怎么用量化数据判断性能
说到perf stat，它是我做优化前后对比时最依赖的命令。用起来也非常直接：在程序运行命令前面加上perf stat，结束后会输出一组计数器数值。
perf stat ./myapp跑完一次基准测试，你会看到类似下面的输出：
Performance counter stats for './myapp': 3,684.89 msec task-clock # 0.998 CPUs utilized 420 context-switches # 0.114 K/sec 0 cpu-migrations # 0.000 K/sec 66 page-faults # 0.018 K/sec 12,845,900,102 cycles # 3.485 GHz 18,547,331,211 instructions # 1.44 insn per cycle 2,903,990,112 branches # 788.068 M/sec 87,456,210 branch-misses # 3.01% of all branches这些数字里的门道不少。task-clock表示任务实际占用的CPU时间，如果数值远小于真实运行时间，说明程序有很大一部分时间不在CPU上，可能在等IO或者等锁。context-switches数字很大，可能说明存在频繁的线程调度或者锁竞争。instructions和cycles的比值如果远低于1，就要小心：执行效率偏低，大概率在等待内存或者存在依赖链导致的流水线停顿。branch-misses的比例太高（超过百分之五）就要考虑分支预测性能的影响，重排分支逻辑或使用查表法往往能改善。
perf stat也支持同时统计多个事件，比如：
perf stat -e cycles,instructions,cache-misses,cache-references ./myappreports里cache-misses和cache-references的比例就是缓存未命中率。在访问大数据集或者循环嵌套很深的算法中，这个比例对性能影响极大。我遇到过一种典型情况：代码逻辑上优化得很好，但缓存命中率只有一半，实际性能就是上不去。把访问顺序从按行改成按列、或者把大数组拆成小块分阶段处理之后，命中率提上来，性能直接翻倍。
perf stat还有一个大作用是在不同环境之间横向对比，比如对比同一程序在不同编译器优化级别下运行，对比开与不开某项内核参数，对比裸机与容器场景。只需要分别跑一遍perf stat，把各个事件数值放在一起看，就能快速找出性能差异在哪一层。千万不要只看运行时间，因为时间受干扰因素太多，事件计数的变化更能反映真实原因。
6. 精准定位：perf record和perf report的调用链分析
当perf top确认了可疑模块、perf stat确认了整体方向之后，接下来就该用perf record抓取详细的调用链了。这个步骤对应的是“定位到底哪一行代码是元凶”的问题。
perf record -g -p 12345 -- sleep 10这条命令的含义是：对进程号为12345的进程，开启调用链采样，持续10秒，把结果写入当前目录下的perf.data文件。你也可以直接把程序放进来跑，比如：
perf record -g ./myapp args这里-g是关键参数，意思是记录调用链。如果不加-g，只能看到采样点落在哪些函数上，无法还原是从哪里调用进来的。加了-g之后，每个采样点都会记录完整的函数调用栈，生成报告时就能看到“从主函数一直到最热函数”的调用路径。
跑完之后，用perf report查看报告：
perf report报告界面默认按开销从高到低排列，顶部是采样占比最高的函数。按c键可以进入调用链视图，一层层往下展开，查看哪个调用路径贡献了最多的开销。这里最需要集中注意力：别只看单个函数占比，要看完整调用链里累计占比最高的路径。比如A调用B，B内部花了很多时间，那么在perf report里B的占比高，同时A通过B引入的开销也高，我们要找的通常是“整条路径到底是怎么通向B的”，优化时往往要在调用方下手，而不是在B内部打转。
还有一个常见的坑：符号未解析。如果看到十六进制地址而不是函数名，多半是二进制缺少符号表、或者符号表已经被strip。解决方案是找到带调试信息的原始二进制文件，把它放到对应路径，或者用--symfs指定符号文件路径。对于动态编译的语言如Java或Go，还需要额外启用对应的符号解析能力，比如Java要用perf-map-agent生成符号映射，Go需要在编译时保留符号且运行时用GODEBUG=tracebackancestors之类的选项。这些都是实操时的坑，遇到没符号时别一头雾水。
当perf report已经定位到函数，但还想进一步看指令级热点时，就该用perf annotate了：
perf annotate进入函数界面，它会显示汇编指令以及每条指令对应的采样点占比。沿着占比高的几行指令往回看，往往能识别出是循环中的内存读取、还是分支跳转引起的开销。如果你熟悉汇编，这一步能极大帮助理解热点产生的真正原因。即便是偏应用层的开发者，也可以通过关键寄存器操作和C代码行映射来反推是哪一段逻辑。
在生成报告时，有时需要过滤某些不关心的模块，比如只关心某个自研二进制，可以用--symbol筛选符号名，用--dsos筛选二进制所属的库。更精细的分析还可以通过--percent-period和--percent-limit控制报告里展示的最小占比阈值，把噪音剔除掉，让核心热点更醒目。
7. 底层锁与调度问题：用perf sched和perf lock分析阻塞
前面说到普通采样容易漏掉“等待类”问题。当服务的响应时间变长、但CPU占用并不高，或者线程大量处于睡眠状态时，问题往往出在锁等待或者调度延迟上。这时候需要换工具，Perf里对应的一个方向是perf sched，另一个是perf lock。
perf sched可以记录调度器的行为，分析线程的唤醒、切换、等待时间。使用方法是：
perf sched record -- sleep 10 perf sched latencylatency子命令会输出每个线程的调度延迟统计，包括平均延迟和最大延迟。如果某个线程经常触发比较长的调度延迟，说明它经常被抢占、或者本身优先级设置不合理，也可能是所在CPU核被其他高负载任务占满。另一个子命令perf sched map能以时间线方式展示每个CPU上线程的切换情况，类似可视化的调度图谱，有助于观察是否出现“很多线程在一个CPU上争抢”的现象。
perf lock则是分析内核里面锁的竞争情况：
perf lock record -- sleep 10 perf lock report报告会列出锁名称、竞争者数量、等待时间等。对于用户态锁，Perf本身没有直接针对pthread mutex的内置分析，需要在应用程序里通过热点采样判断自旋开销，或者借助其他工具比如malloc调优等辅助。不过底层内核锁的竞争往往也会反映到用户态线程的D状态或长时间阻塞上，值得关注。
处理这类阻塞问题还有一个习惯性的检查项：perf record里加上sched:sched_switch这个tracepoint，可以抓取每一次线程切换时的上下文。通过查看切换之前的栈，可以看到被切换出去的内核栈或者用户栈，从而得知当时线程在等待什么。例如：
perf record -e sched:sched_switch -g -- sleep 5 perf script脚本输出中，每一条sched_switch记录都会打印prev_comm、prev_pid、prev_state以及next线程信息。结合前后的record数据，可以推演阻塞成因。这算是进阶用法，但在排查复杂问题时非常得力。
8. 实战演练：从一次CPU飙升到精确定位并验证的全流程
为了把前面的概念串起来，我写了一个简单但容易踩坑的模拟代码，故意制造一个性能问题，然后完整走一遍排查过程。这个例子里的逻辑是从一个很大的字符串数组里做前缀匹配，代码写得并不高效，正好适合展示分析流程。
#include <stdio.h> #include <string.h> #include <stdlib.h> #define N 500000 char *strings[N]; char prefix[] = "abc"; int main() { for (int i = 0; i < N; i++) { strings[i] = malloc(64); sprintf(strings[i], "abcdef-%d", i); } long count = 0; for (int i = 0; i < N; i++) { for (int j = 0; j < N; j++) { if (strncmp(strings[j], prefix, 3) == 0) { count++; } } } printf("count=%ld\n", count); return 0; }注意到内层循环遍历整个数组，外层遍历也覆盖了整个数组，这个双层循环的复杂度是O(n^2)，即使里面只是strncmp操作，当n等于50万时也够慢的了。编译时记得不要加过高优化，以免编译器直接优化掉无用计算，但也不能完全不优化，因为完全不加-O选项会让循环结构失真。我这里用-O2编译：
gcc -O2 -o demo demo.c第一步先看整体统计：
perf stat ./demo输出会显示任务占用时间、周期数、指令数等。这时候会发现IPC可能不高不低，但整体时间是秒级甚至分钟级。由此确认程序的CPU密集度很高，可以继续采样热点。
第二步记录调用链：
perf record -g ./demo perf report报告里大概率能看到strncmp或者__strncmp_avx2之类出现在热点顶部，占比相当高。到这里很多人会直接下结论“性能问题在strncmp”，但再往下看调用链，就能看到它是从main循环里被调用的。真正需要优化的其实是嵌套循环本身，单纯优化strncmp实现并不能解决数量级的问题。
看annotate，逐条指令观察访存行为。因为字符串数组规模庞大（50万条，每条64字节，再加上字符串本体），访问模式会拉低缓存命中率。如果在perf stat里加上cache-misses，往往会发现未命中率很高。这里的关键是“程序原本是CPU密集型，但很多周期都损耗在等待内存上”。
此时优化的思路自然浮出水面：把双重循环里的重复计算去掉。比如前缀匹配其实只需要对每个字符串判断一次，不需要在外层再循环五十万次。修改代码为：
for (int i = 0; i < N; i++) { if (strncmp(strings[i], prefix, 3) == 0) { count++; } }重新编译，再跑一次perf stat，可以观察到指令数和运行时间显著下降，IPC也大幅提高。这个例子虽然简单，但揭示了排查的根本原则：先找到热点，再看调用路径，最后从算法层面优化，而不要停留在“哪个函数比较热”的表层。
9. 函数级优化之外：内存、磁盘与网络方面Perf还能做什么
Perf不止分析CPU热点。借助各种tracepoint，它也能观察内存换页、磁盘IO、网络收包等方面的性能特征。
内存方面，最常用的是缺页分析。通过perf stat -e page-faults可以统计用户态程序的缺页次数。如果缺页次数高，会导致明显的延迟，因为每次缺页都可能触发磁盘交换或直接内存回收。用perf record -e page-faults -g配合report，可以定位到哪个路径触发了缺页。在内存管理优化中，这个信息非常关键。
磁盘方面，虽然Perf不像iostat那样直接给出IO吞吐，但可以通过block:block_rq_issue、block:block_rq_complete等tracepoint分析IO请求何时发出、何时完成。记录下IO完成时间，可以判断IO路径上的延迟分位点。
网络方面，可以通过net:netif_receive_skb等tracepoint来观察收包处理在软中断中的耗时，也可以统计某进程发起的sendto/recvfrom次数。不过网络性能问题往往链路复杂，Perf更适合做局部验证，全链路的分析还是需要结合tcpdump等工具。
这一节并不是要大家把所有tracepoint都背下来，而是想传达一个意识：Perf里的事件几乎覆盖了Linux系统全栈，从CPU到IO、从内核到用户态，可以组成一套统一的观测语言。遇到“感觉是IO慢、但不确定在哪个环节”的问题，先通过perf record -e各相关事件组抓到全貌，再逐步切片定位，比直接去猜更靠谱。
10. 常见问题与排查技巧实录
10.1 没有权限打开perf事件
运行perf命令有时会报错“perf_event_open() failed: Operation not permitted”。检查perf_event_paranoid的值：
cat /proc/sys/kernel/perf_event_paranoid如果值是2或更高，默认只允许自身进程的采样。临时调低：
sudo sysctl kernel.perf_event_paranoid=1这个配置值含义是：1允许CPU级采样但禁止内核级事件，0允许跟踪内核，-1则完全不限制。生产环境不要为了省事直接改成-1，安全更重要。
10.2 采样结果看不到用户态符号
常见情况是程序被strip了，也可能是在容器里运行但挂载的根文件系统不包含符号。解决方式是把原始二进制放到对应路径，或者用--symfs指定目录。给出一条常用命令组合：
perf record --call-graph dwarf -g ./app perf report --symfs /path/to/debug/symbols如果使用Java，要搭配JIT符号映射，没有映射时热点会显示为未知函数。对Go程序，编译时加上-symbol选项及正确的地址布局，再结合runtime的栈展开，才能看到完整的调用链。
10.3 call-graph采样方式选哪个
perf record在记录调用链时有几种方式：fp（帧指针）、dwarf、lbr。fp基于栈帧指针，需要程序编译时没有省略帧指针，否则链路会断裂。dwarf则借助调试信息做栈回溯，准确性更高但开销也更大。lbr（Last Branch Record）是硬件记录最近分支，开销极小，但有一定深度限制。日常分析推荐优先用--call-graph dwarf，遇到老架构或性能敏感环境再考虑切换。
10.4 采样频率调多少合适
默认的采样频率对长任务够用，但对一些快速退出的小程序可能采不到足够样本。可以通过-F参数指定采样频率，比如1000代表每秒采样1000次。注意频率过大会增加Perf自身开销，也让数据文件膨胀。一般分析一个需要几秒的进程，几千赫兹足够了。
10.5 误判为死循环但实际是自旋锁
高CPU占用不一定是用户态死循环，也可能是内核态自旋等待。perf top里如果热点显示为native_queued_spin_lock_slowpath这类函数，说明存在锁竞争。这时用perf lock分析或者看看系统load是否有过多线程在等待，比单纯优化用户态代码更有针对性。
10.6 数据文件太大
perf record默认把所有采样写入perf.data，长时间监控时文件可能达到几个GB。可以加-F降低频率，或者限定只采关注的事件，或者用-C指定CPU核心。还可以用perf record -a --exclude-perf排除perf自身的数据，减少干扰。
11. 由Perf延伸开来的性能分析方法论
工具用熟练之后，我发现真正值钱的不是那些命令，而是整套分析思路。这里分享几个我从实践中沉淀下来的经验。
先量化，后定位。无论什么性能问题，先跑出周期数、指令数、缓存命中率、进程切换次数这些指标，形成“宏观画像”，再决定继续深挖的方向。不要一上来就perf record抓栈，那容易陷入局部热点而忽略了全局因素。
热点定位要结合调用链。单个函数占用时间高不一定代表该函数有问题，可能只是调用方提供了不合理的参数、或者调用频率过高。始终关注调用链中累计占比最高的路径，才能找到真正值得优化的位置。
优化后一定要重新测量。我用perf做的优化里，大概有两成优化前后perf stat的指标并没有明显改善，说明最初的判断不精确。所以每次改完代码，都要回到perf stat对比优化前后的指令数和周期数，确认优化真实生效。这正是Perf作为验收工具的独特价值。
注意多线程程序带来的一个特殊现象：并发环境下采样到的调用链可能来自多个线程，热点比例是叠加统计，并不代表某个线程自身性能差。遇到复杂并发问题时，先用perf record -t指定线程ID逐一分析，再汇总对比。
如果发现perf自身有开销干扰，可以使用轻量模式：perf record --no-inherit避免跟踪子进程、或者用--exclude-perf过滤自己。对于极敏感的场景，还可以采用循环采样模式，通过--phys-begin和--phys-end之类参数把采样限制在物理内存特定范围，但这类用法一般只在嵌入式环境才会用到。
12. 你还可以在哪些场景依靠Perf
说一个很实际的例子。做Java应用调优时，很多人习惯用JFR或者jstack，但这些工具对“CPU周期到底花在哪个内核函数上”的视角比较弱。Perf配合Java的符号映射，可以同时看到JVM内部和内核态的热点，尤其是在高并发网络IO、JIT编译热点、GC线程竞争等问题上，Perf经常能给出更底层的信息。
编译优化场景也值得提。比较不同的编译选项时，比如-O2与-O3，或者是不同的体系结构参数（-march=native），用perf stat对比指令数和执行周期，能很客观地看出哪一种优化选项更适合当前场景。很多时候-O3并不一定比-O2快，因为代码体积增大可能导致icache压力上升，而这些细微差异run多少次benchmark都说不清，但perf stat里的指令数和周期数变化一目了然。
容器化环境里Perf也很有用。容器的性能隔离通常依赖内核的cgroup和namespace，Perf可以从宿主机视角对容器内进程做采样，发现容器内进程在哪个CPU核上运行、是否发生过cpu migration等。使用nsenter进入容器所在PID命名空间再跑perf record，还能进一步获取对应的调用链，这种跨容器视角对排查“为什么容器中运行的服务比裸机慢”这类问题非常关键。
13. 最后一个实操心得
跑了很多次Perf之后，我的体会是：性能分析本质上是一个“提出假设-验证假设”的过程，而Perf是你手里最趁手的验证工具。它不会直接告诉你“把循环改成这样”，但它能帮你确认“热点在这里”、“调用到这里来的路径是这条”、“优化后这里变快了”。有了这三点，剩下的优化方案往往已经昭然若揭了。
还有一个平时不太会写在文档里的技巧：perf top的输出不要只看第一屏。通常前几行确实是最热的，但真正需要处理的可能是第5到第10名。因为热点排名第一的函数往往是某个基础库的底层实现，比如memcpy、strlen、pow之类，这类函数本身无法再简化，而真正值得优化的是它下面的调用方逻辑，这需要你翻到报告的下半部分，或者用--sort=comm,dso把不同模块分开看，往往能发现是某个模块内部调用频率过高的问题。
另外，当你面对的是一个非常耗时的程序，完全等它跑完再分析不太现实。可以用perf record对正在运行的服务做实时采样，也就是-p指定PID并持续若干秒，这个期间服务照常对外提供服务。采样完成后，再在另一台机器上用perf report分析，把perf.data带过去即可。注意拷贝符号文件或确保那台机器能解析到同样的符号映射。这个玩法在线上定位问题时特别实用，也是我能坚持用Perf的最大理由——它能让你在尽量少影响业务的情况下，拿到最真实的现场数据。
如果你刚开始用，建议挑一个自己写的、逻辑简单但运行较慢的程序练手，配一句perf stat和perf record -g，结合perf report走一遍。只要完整走一次“量化-采样-定位-优化-再量化”的闭环，你对性能分析的理解会发生质变。Perf命令本身并不难，难的是灵活组合它们来解决真实问题，而这恰恰是经验可以快速积累的地方。
