我其实一直觉得Perf 性能分析工具是 Linux 上最容易被“看见”却最容易被“误用”的性能排查武器。上周同事丢过来一张火焰图perf top里某个字符串处理函数占了 70%他兴冲冲改了一天缓存结果线上吞吐一点没变。后来重新采样才发现真正的瓶颈根本不在 CPU 上——是锁等待把线程全挂住了那个函数之所以占用高是因为它恰好被调度器扔进了自旋队列真正在转圈的是锁本身。这事我见过太多次了。很多人第一次接触 Perf都是从perf top开始看到哪个函数排第一就改哪个。但性能优化最难的地方从来不是“看数据”而是理解数据背后的事件模型Perf 到底采了什么、没采什么、什么指标能说明问题、什么指标会骗人。这篇文章我想把 Perf 从命令行工具开始一直讲到火焰图、锁竞争、缓存缺失、容器采样、回归监控这些实战场景适合后端开发、SRE、以及所有想系统掌握 Perf 的人。读完你至少能知道一次性能排查应该从哪里入手哪些数据可信哪些数据需要交叉验证。1. 量化能力边界perf 到底靠什么“看见”性能问题1.1 三类事件源硬件计数器、软件事件与内核 tracepointPerf 之所以被称为“万能瑞士军刀”根源在于它把三类完全不同的观测源统一到了同一个框架里底层都是通过perf_event_open这个系统调用来打开事件流。第一类是硬件事件来自 CPU 内部的性能监测单元PMU比如cyclesCPU 周期、instructions退休指令数、cache-misses缓存缺失、branch-misses分支预测失败。这类事件精度高、开销极小但依赖具体的 CPU 微架构同一条命令在 Intel 和 AMD 上的事件名可能不一样。第二类是软件事件由内核维护的软件计数器模拟比如cpu-clock、task-clock、page-faults、context-switches它们不依赖特定硬件几乎所有平台都能用。第三类是内核 tracepoint也就是内核里静态埋好的跟踪点比如sched:sched_switch调度切换、block:block_rq_complete块设备 IO 完成、syscalls:sys_enter_openat系统调用进入。理解这三类事件非常关键因为很多人用 Perf 时从来不看事件类型直接默认cycles就是“真实运行时间”。实际上cycles只统计 CPU 执行指令的周期如果线程被切换出去等锁、等 IO、等网络这段等待时间根本不会出现在cycles里。换句话说用perf record默认采样得到的火焰图本质上是一张on-CPU 火焰图只回答“CPU 在执行什么”不回答“线程在等什么”。1.2 计数与采样两种模式各有各的用途Perf 有两种工作模式对应两种完全不同的问题。计数模式用perf stat它会在整个命令执行期间把事件累加一遍最后输出总数适合快速判断全局状态。比如perf stat -d sleep 10可以告诉你 10 秒内总共执行了多少指令、发生了多少次缓存缺失、上下文切换有多少次。它的优点是没有采样误差缺点是看不到时间分布某个事件集中在哪一秒发生完全不知道。采样模式用perf record它会让 PMU 按固定频率或固定周期产生中断每次中断记录一次当前 CPU 正在执行的指令地址和调用栈。比如-F 99表示每秒钟采样 99 次这是一种很经典的频率选择。为什么用 99 而不是 100因为很多内核定时器和应用定时器都以 100Hz 为基底如果采样频率正好是 100Hz就会和这些周期性任务产生相位锁定导致采样点永远落在同一状态形成系统性偏差。99Hz 是无理数式的错开看起来只差 1实际意义很大这是最容易被人忽略的小细节。采样模式决定了 Perf 最终给出的是一份“概率分布”而不是精确测量。如果某个函数只占运行时间的 1%在 99Hz 采样下一秒内可能采不到一次需要把采样时间拉长到几十秒甚至几分钟才能让热点稳定浮现。这也是为什么所有做 Perf 分析的人都会告诉你样本数量不够的时候不要随便下结论。1.3 为什么“perf top 第一名”不一定是根因回到开头那个案例。perf top把某个字符串处理函数排在第一位但这个函数本身没有任何优化空间因为它在等锁。这背后的机制值得展开讲。当线程遇到锁冲突时有多种等待方式。如果锁只有一个等待者内核通常会让它自旋一段时间再睡眠而自旋发生在用户态还是内核态取决于锁的实现。某些用户态锁比如自旋锁或带乐观重试的互斥锁在获取失败后会在用户态循环pause指令这个循环会消耗 CPU 周期很容易成为perf top的热点。但真正的问题是锁的持有者迟迟不释放——持有者可能在做磁盘 IO、可能被调度出去了、可能在等下游网络响应这些等待完全不消耗持有者的 CPU。所以你在火焰图上看到某一个函数“又宽又平”只能说明采样时刻执行流停在那里但不能说明它是因为计算量大而停还是因为等待而停。区分这两种情况要么看关联事件上下文切换是否剧烈、instructions是否同步很高要么走 off-CPU 分析。至少不要看一眼perf top第一就去改代码这是 Perf 新手最容易犯的错误也是所有“优化无效”事故的共同起点。2. 跑通第一次 perf权限、内核符号与最小基线2.1 权限参数与内核符号表Perf 刚装好的第一关往往不是命令记不住而是权限。Linux 为了安全默认限制了普通用户访问硬件性能计数器限制级别由一个内核参数控制cat /proc/sys/kernel/perf_event_paranoid这个值的含义大致是-1表示完全不限制0表示允许用户态性能事件但不允许内核态采样1表示允许 CPU 事件但更严格2是发行版常见默认值普通用户基本只能看软件事件3则只允许内核自身测量。很多开发机上直接跑perf top会看到No permission to enable ... event大概率就是 paranoid 值太高。临时放开可以写sudo sysctl kernel.perf_event_paranoid-1但我建议永远不要在产品环境随便改成-1因为 Perf 的采样本质上是一种低开销但仍然存在的中断风暴攻击者也可以通过它观测敏感数据。更合理的方案是保留限制在需要分析时用sudo perf或者只允许特定用户组访问。另一个跟权限高度相关的是内核符号/proc/kallsyms在内核开启kptr_restrict时会对非特权用户隐藏实际地址所有内核态函数都显示为[unknown]这时候必须提升权限才能看到内核态调用栈。2.2 用 perf stat 建立最小基线并读懂输出我第一次建议任何项目做性能分析都会让先跑一个最小基线而不是马上抓火焰图perf stat -d -p PID -- sleep 30-d会带上默认的硬件事件组-p指定进程sleep 30表示采集 30 秒。输出大致长这样Performance counter stats for process 12345: 479021.23 msec task-clock # 1.000 CPUs utilized 1873110 context-switches # 3.910 K/sec 156789 cpu-migrations # 0.327 K/sec 493123 page-faults # 1.029 K/sec 78390213441 cycles # 0.164 GHz 16111324420 instructions # 0.21 insn per cycle 7881034 branch-misses # 4.32% of all branches先看task-clock和实际wall time这里是 30 秒的比值。如果task-clock远小于 30 秒说明进程大量时间在睡眠或者被调度出去这时候 on-CPU 分析很难看到全貌需要转 off-CPU。再看context-switches每秒几千次对于单进程来说已经算频繁如果这个时候正好出现性能下降锁竞争、IO 等待、频繁唤醒这三件事需要优先查。IPCinstructions per cycle低于 0.3 是很多人的“直觉红线”但我会提醒低 IPC 可能是内存墙、分支预测失败、也可能是 CPU 频率过高导致的周期数值失真必须结合cycles的实际频率判断。task-clock / 1000算出来的 CPU 利用率只有 100%说明进程根本没有吃满核这时候优化 CPU 使用率是没有意义的要去看它为什么饿着。2.3 数据可信度与常见误读今年以来新出的 CPU 几乎都支持频率动态调整这就带来一个 Perf 老用户都知道的问题cycles是真实硬件周期数它会随频率变化。如果一个进程全速跑在 4GHz另一个进程被电压限制在 1.5GHz两者执行相同指令数时cycles完全不同。因此跨机器、跨时间段比较IPC之前一定要确认 CPU 频率是否一致或者把cycles换算成墙上时间来看。另一个常见误读是把page-faults当成性能问题。实际上缺页中断分为软缺页和硬缺页软缺页只需要内核分配物理页开销相对小硬缺页需要磁盘 IO 参与一次可能是几毫秒这才是大头。perf stat默认不分类型如果你看到 page-faults 很高我会建议进一步用perf record -e page-faults采样看看缺页时执行栈停在哪里再判断是程序冷启动时的大量软缺页还是内存池设计不合理导致的重复硬缺页。3. 火焰图不只是一张图从采集、折叠到定位调用链3.1 生成一张可用火焰图的完整链路火焰图是 Perf 最常见的可视化形式但生成过程远比“跑一条命令”复杂。标准的链路是perf record采集原始样本perf script把二进制数据转成带调用栈的文本然后用stackcollapse-perf.pl折叠栈帧、flamegraph.pl生成 SVG。perf record -F 99 -g -p PID -- sleep 60 perf script -i perf.data | stackcollapse-perf.pl | flamegraph.pl flame.svg这里最值得注意的参数是-g它决定调用栈怎么采集。Perf 支持两种栈回溯方式基于帧指针frame pointer和基于 DWARF 调试信息。现代编译器默认开启-O2优化时往往会省略帧指针寄存器导致-g默认的模式采不到完整用户态栈大量函数显示为[unknown]。解决方法是编译时加上-fno-omit-frame-pointer或者在perf record时改用--call-graph dwarf靠调试信息做栈回溯但 DWARF 模式每次采样都要读取调试信息开销显著更大生产环境要权衡。我个人的经验是能改编译参数就改-fno-omit-frame-pointer改不了才用--call-graph dwarf并且尽量把采样时间控制在 60 秒以内避免采样开销和磁盘写入影响服务本身。内核态栈通常不需要额外处理只要权限够Perf 会通过内核栈回溯机制拿到。3.2 读图顺序先看平顶再看上下文很多人拿到火焰图后第一反应是找最宽的色块然后顺着往下看这是错的。火焰图是从下往上生长的调用栈顶部每个小矩形代表采样点落在这个函数上矩形越宽说明采样次数越多也就是 CPU 时间占比越大。正确的读图顺序是三步第一步看最上面的“平顶”也就是有没有一个特别宽、特别平的块。平顶通常意味着某一段循环体长期占着 CPU要么是算法热点要么是自旋等待第二步从平顶往下逐层展开看它是由谁调进来的、兄弟调用占多少、父级消耗分布是否均匀第三步把注意力从“最宽”转移到“调用路径最可疑”的地方比如一个函数有很多叶节点都很窄但层次极深这往往不是 CPU 密集问题而是调度和锁导致的栈杂乱。一个特别容易被忽略的细节是火焰图底部根节点的宽度是整个采样 CPU 时间的 100%如果根节点是[unknown]或者只有一段很短的符号那说明栈回溯在很浅的地方就断了整张图的可信度都要打个问号。先修符号问题再谈分析。3.3 符号化失败背后帧指针、debuginfo 与随机化生产环境里火焰图大量出现[unknown]几乎是常态。除了帧指针被优化掉还有几个原因。第一个原因是可执行文件使用strip去掉了符号表或者只保留动态符号表Perf 找不到函数名。第二个原因是地址空间布局随机化ASLR进程每次启动后函数地址都不同Perf 依赖/proc/pid/maps里的映射关系做符号化如果采集完进程就退出或者分析时二进制文件路径变了就可能导致符号对不上。第三个原因是容器环境进程看到的文件路径和宿主机看到的路径不一致Perf 在宿主机上分析时找不到容器内的库文件。解决这些问题没有统一的银弹。我的处理习惯是采集时尽量保留足够的符号比如服务镜像里不要着急 strip分析时用perf archive把二进制和.debug文件打包带到分析机如果符号化仍然失败就用perf report --symfs 路径指定一个符号文件根目录这个命令能手动告诉 Perf 去哪里找二进制和调试信息。这些操作在文末第 6 节会配合容器场景再讲一次因为那里才是真正的高发地带。4. 并发问题的另一半从 on-CPU 走向 off-CPU 与锁等待4.1 off-CPU 分析原理与命令如果火焰图已经做了context-switches还是很高基本可以断定问题有一半发生在 CPU 之外。Perf 默认是 on-CPU 视角但换一个事件源就能看到线程被切走的一瞬间。原理很简单内核在每次调度切换时都会触发sched:sched_switchtracepoint这个事件记录了“旧线程被切走”和“新线程被切上”的时间戳。只要把时间戳和线程号记录下来就能算出每个线程在 CPU 上跑了多久被切走后多久才被再次调度回来。用 Perf 做 off-CPU 分析最直接的做法是perf record -e sched:sched_switch -ag -- sleep 30 perf script -i perf.data | grep sched_switch但sched_switch原始输出非常啰嗦需要自己写脚本解析。我更推荐两种方式一是用 BCC 工具里的offcputime它会自动把“线程不在 CPU 上的等待时间”按调用栈聚合成直方图二是用 Perf 自带的perf sched系列命令做调度延迟分析比如perf sched timehist可以展示每个线程在每个 CPU 上的运行时间和唤醒延迟。很多人不知道的是off-CPU 时间也可以生成火焰图而且往往比 on-CPU 火焰图更能揭示问题。思路是把sched:sched_switch事件采集下来针对每个线程计算它两次被调度上 CPU 之间的时间差把这段等待按当时的内核/用户栈聚合成“off-CPU 火焰图”。市面上很多工具已经把这个流程封装好了但核心思想不变所有等待都需要一个归宿要么等锁、等 IO、等网络要么等调度器。4.2 回放一次真实的锁竞争定位过程之前帮一家公司的订单服务做压测现象非常典型TPS 上不去CPU 总利用率只有 40% 左右但perf stat里context-switches高得离谱每秒接近十万次。显然线程们不是在“忙”而是在“换人”。我先用perf record -F 99 -g -p抓了 30 秒的 on-CPU 数据火焰图上能看到大量线程在同一个锁的获取逻辑处自旋。接着用perf sched timehist看调度历史发现几乎所有线程的wakeup latency被唤醒到真正上 CPU 的时间都有几百微秒这在多核机器上很不正常。再配合perf record -e sched:sched_switch -ag的原始数据我锁定了两个关键证据一是所有业务线程都在等同一个内核等待队列二是持锁线程恰恰在做 IO 等待导致锁被握得很久。修复方案并不复杂把一把全局锁拆成多把分段锁同时把锁内不必要的 IO 操作移到锁外。改动之后同样的压测剧本context-switches从每秒十万降到两万附近TPS 提升了将近一倍。这个案例最值得复盘的并不是“拆锁”这个结论而是证据链先看全局上下文切换确认是 off-CPU 问题再用调度事件确认唤醒延迟异常最后才动代码。如果你一上来就拿火焰图看到那个自旋函数很容易去优化自旋逻辑方向完全错误。4.3 锁事件追踪的边界Perf 还有一个专门的perf lock工具可以在内核启用了锁调试CONFIG_LOCKDEP的情况下记录锁事件的获取、冲突和等待情况perf lock record -p PID -- sleep 30 perf lock report它输出的锁冲突次数和等待时间确实很有说服力但有两个明显的边界必须清楚。第一perf lock主要分析内核锁用户态pthread_mutex的锁内部实现最终也会进入futex系统调用但perf lock report是否能准确还原到用户态调用栈取决于符号和栈回溯常常不够直观。第二开启 LOCKDEP 的内核本身运行开销更大生产环境很少默认开启因此perf lock通常只能在测试环境复现问题。对于用户态锁我的经验是配合 uprobe用户态动态跟踪或者直接看用户态火焰图上的futex、pthread_mutex_lock相关栈帧。只要记住一点当你看到线程卡在futex等待或者大量sched_switch都围绕着同一个线程唤起那么问题几乎可以确定在锁竞争这时候你要看的是持有者而不是等待者。5. 内存墙比 CPU 墙更难缠用组合计数器判断 cache miss 与 IPC5.1 一次 perf stat -d 能告诉你的关键指标CPU 算力增长多年内存延迟虽然也降了但速度差始终差着一个数量级。对很多现代服务来说真正的瓶颈不是 CPU 在“跑”而是 CPU 在“等数据”。用perf stat加一组组合计数器可以快速判断内存墙到底有多严重perf stat -e cycles,instructions,branches,branch-misses,cache-references,cache-misses \ -e stalled-cycles-frontend,stalled-cycles-backend -p PID -- sleep 30输出里我会重点关注四个指标。第一个是IPC它告诉你每个 CPU 周期平均退休多少条指令IPC 高于 1 通常意味着流水线很满低于 0.5 就要警惕但到底是被什么卡的要看下面三个。第二个是branch-misses分支预测失败会导致流水线清空代价极高如果它的比率超过 5%检查代码里的分支布局和数据相关性比如switch-case顺序、二分查找的热路径。第三个是cache-misses / cache-references这个比率超过一定阈值说明数据访存模式很差但单独看它很容易误判下面专门说。第四个是stalled-cycles-frontend和stalled-cycles-backendfrontend 停滞代表 CPU 在取指、译码环节饿了常见原因是指令缓存I-cache缺失和分支预测器跟不上backend 停滞代表执行单元在等数据常见原因是数据缓存缺失、TLB 缺失、内存延迟。这四个指标如果全部变差那大概率是数据结构和访问模式出了问题如果只有 backend 停滞高而 IPC 不低则可能是乱序执行的掩盖效应需要进一步做内存采样。5.2 拆缓存行优化案例分析有一回排查一个数据处理服务的耗时perf stat -d显示cache-misses比率接近 25%后端停滞周期占了将近一半。看一眼代码发现典型问题程序遍历一份由大结构体组成的数组每个结构体包含 64 字节的元数据加 64 字节的标签字符串但热循环只用了前 16 字节。也就是说每一个缓存行64 字节里只有 16 字节是实际需要的剩余 48 字节纯粹是“陪着逛街”。这种问题叫结构体数组Array of Struct带来的缓存利用率低下。把它改成数组结构体Struct of Array之后热数据连续排列每次缓存行都能被充分使用// 原结构 struct Item { int64_t id; double score; char tag[64]; }; // 拆分后 struct ItemView { int64_t id; double score; }; struct ItemTags { char tag[64]; };改完再跑同样的压测cache-misses从 25% 降到 8%后端停滞周期明显下降整体吞吐提升了约四成。这里有一个细节值得注意优化前后instructions几乎没变因为算法逻辑完全没改变的只是数据布局。如果只看火焰图你根本发现不了这个问题因为 CPU 时间都花在了同一个“读取数组元素”的函数上它看起来好像已经足够精简了。5.3 为什么不能单独迷信 cache-misses我必须给 cache-misses 泼一盆冷水。有些场景下 cache-misses 很高但根本不是瓶颈比如顺序扫描一个超大数组。这种流式访问天然没有缓存复用率每一次读取都可能是 cache miss但因为现代 CPU 有硬件预取器和内存并发带宽流水线照样能跑得很满。此时如果只看 cache-misses 比率你会得出一个“必须优化缓存”的结论实际上改成更复杂的访问模式反而可能更慢。所以我会把IPC当作第一判断条件如果 IPC 已经很高说明 CPU 没有被内存等待卡住cache-misses 高只是访存模式的特征不是性能缺陷。如果 IPC 低且 backend 停滞高cache-misses 才值得深挖。再往深一层可以使用perf mem对内存访问本身采样它会给出 load 延迟分布、本地/远端内存访问比例。在 NUMA 多路服务器上perf c2c还能定位 false sharing伪共享——即多个 CPU 频繁修改同一个缓存行的不同字段导致缓存行颠簸。这些工具组合起来才能把“内存墙”的位置画清楚。6. 生产与容器环境下的采样姿势权限、开销与离线分析6.1 容器内跑 perf 的权限映射现在几乎不存在“裸跑”的生产服务容器环境才是 Perf 的日常战场。容器技术带来的第一个变化是命名空间隔离容器内的 PID 是 1、2、3但宿主机看到的可能是 12345、23456而且很多容器默认没有挂载debugfs也没有开放perf_event_open系统调用。结果就是你在容器里执行perf top要么直接权限报错要么只能看到空数据。常见的生产采样姿势不是在容器里跑 perf而是在宿主机上对容器内进程进行采样。步骤很简单先在宿主机用ps -ef找到业务进程的真实 PID比如通过容器 ID 过滤 cgroup 路径然后直接在宿主机上执行perf record -F 99 -g -p host_pid -- sleep 60这样 Perf 能访问到宿主机的 PMU 和内核符号采样本身不会因为容器隔离而失效。但符号化问题依然存在容器内的应用库位于容器镜像的路径比如/app/bin/service宿主机上同一路径可能不存在。这就要用到前面提到的--symfs或者把容器镜像的根目录打包给分析环境。还有一种更“重”的方案是容器以 privileged 模式运行并挂载/sys/kernel/debug然后直接在容器内采样但安全代价太高我不建议常规操作。6.2 低开销采样策略生产环境最关心的问题永远是“你采样会不会把服务采挂了”。Perf 的采样确实有开销但可以通过几个手段压到很低。频率是第一道开关。-F 99在大多数场景下开销可以忽略而-F 1000会让 CPU 每秒被采样中断打一千次在大量核数的机器上这种中断可能成为新的热点。我的经验是定位阶段用-F 99采 60 秒足够如果确认了方向想抓更细的短时热点再临时把频率调到 500 左右采 20 秒就行。第二道开关是--no-inherit它告诉 Perf 不要跟随 fork 出来的子进程避免把采样开销放大到整个进程组。第三道开关是避免全系统采样尽量用-p PID锁定目标进程除非你在排查多进程互相干扰的问题否则-a全系统采样会采入大量无关的 idle 时间反而让数据变难读。另外不要在 CPU 频率动态调整的虚拟机上做严格的性能对比因为 PMU 计数受频率影响虚拟化层也会干扰时间戳。如果在云平台上排查最好先确认 CPU 型号和频率锁定策略再解释数据。6.3 数据归档与离线分析采集完的perf.data不是一台机器独享的它可以离线分析但前提是符号信息完整。Perf 内部有一个 buildid 机制它会为每个被采样的二进制文件生成唯一标识你可以在采集后执行perf archive这个命令会把所有带 buildid 的二进制和调试文件打包成一个 tar 文件连同perf.data一起拷到分析机就能保证符号解析一致。如果不做这一步直接把perf.data拷到另一台没有对应二进制的机器上perf report会显示大量[unknown]等于白采。实践中我经常把采样子流程写成一个脚本放在发布流水线旁边触发时采集 60 秒、自动perf archive、归档到对象存储等排查时直接拉下来分析。这比每次现场手敲命令可靠得多也更容易让团队其他人复现采样条件。7. 脚本化与回归检查让 perf 从临时工变成长期监控7.1 用 perf script 导出并加工事件流perf record存的二进制数据是给人用perf report看的但如果你想做自定义分析就需要把事件流导成文本。perf script就是这个转换器perf script -i perf.data events.txt输出里每一行都会包含comm进程名、pid、cpu、time、event、ip和sym等字段。你可以用 awk、python 或者任意文本处理工具去聚合这些数据。比如统计某个进程在采样期间各事件的次数、统计每个调用栈出现的采样数量远远比在交互式菜单里翻页更方便。举个我常用的例子想快速得到每个线程的调度次数可以先采集sched:sched_switch和sched:sched_wakeup然后用perf script导出按pid聚合。这比看perf sched timehist的原始输出更灵活你可以自由筛选特定时间段、特定线程、特定 CPU。脚本化并不神秘本质就是把 Perf 当成一个高性能事件采集器真正分析逻辑完全掌握在自己手里。7.2 最小可行的性能回归 CI长期来看Perf 的价值不仅在于救火还在于守住性能红线。我们团队做过一个很轻量的方案每个服务的关键接口压测脚本跑完后接着执行一次perf stat把关键指标输出成 CSV交给流水线判断。perf stat -x, -e instructions,cycles,context-switches,cache-misses \ -p PID -- sleep 30 perf_result.csv这里的-x,会让输出使用逗号分隔方便机器解析。流水线脚本读取instructions和cycles算出 IPC再对比上一版本构建的结果。如果 IPC 下降超过 5%就自动打回 MR附上火焰图。这套方案并不复杂但它把“性能优化靠人的灵光一现”变成了“每次变更都有可对比的基线”价值非常大。需要注意的是不要在共享 CI 机器上做这个对比因为其他任务的干扰会导致上下文切换和 cache-misses 波动剧烈。最理想的是用固定 CPU 核心、关闭超线程漂移、并且把待测进程绑到特定 NUMA 节点上才能得到可重复的结果。7.3 用 Perf 时最常踩的几个坑最后把使用 Perf 几年里踩过、也看别人反复踩的坑集中列一遍。第一个坑是采样频率过高开头就提过不只是开销问题还可能干扰被采样进程。第二个坑是短任务采不到样本比如进程只跑了 200 毫秒99Hz 采样只有 20 个样本左右火焰图会非常稀碎。这时候应该在采样命令中让进程重复多次或者用-- 前加一个 sleep的写法让采集器先跑起来再接业务。更规范的写法是perf record -F 99 -g -p PID -- sleep 60第三个坑是忘记-g分析时才发现没有调用栈只能重新采。第四个坑是过度关注单次采样不做重复实验Perf 的采样本身有随机性热点的排序会有波动至少跑三次看稳定性再下结论。第五个坑是只看 on-CPU 火焰图完全忽略 off-CPU这基本等于只看了问题的一半。最后想分享一个我自己的习惯拿到一次性能报告永远先做三件事。第一用perf stat -d看全局数据记住task-clock和context-switches的关系第二确认 IPC 和缓存缺失率是否同时异常如果只有前者异常优先查调度如果两者同时异常才去碰数据结构和算法第三再打开火焰图看调用路径而不是一上来就追求“最宽的色块”。大多数故障在前面两步就能锁定六成方向火焰图只是用来补充证据链的最后一块拼图。Perf 并不难难的是你愿不愿意在动手改代码之前先把这些计数器背后的逻辑想清楚。
