Ubuntu服务器CPU突然飙到100%，top命令一刷全是某个进程占满，这时候你需要的不是重启，而是用perf采集性能数据再用FlameGraph生成火焰图，精准定位到具体是哪个函数在疯狂吃CPU。这套组合拳是Linux运维排查性能问题的核心武器，从内核态到用户态，从采样到可视化，一套流程走完，问题根因基本就浮出水面了。下面我把整个实战流程从环境准备到最终定位，一步一步给你讲透。

一、为什么选perf+火焰图而不是其他工具

排查CPU飙升的工具很多，strace看系统调用、eBPF做动态追踪、Valgrind做指令级分析，但perf+FlameGraph的组合有几个不可替代的优势：第一，perf是Linux内核自带的性能分析工具，不需要额外装第三方软件，几乎所有Ubuntu发行版都支持；第二，perf可以同时采集内核态和用户态的调用栈，不像某些工具只能看一边；第三，FlameGraph生成的火焰图直观到什么程度？你一眼就能看出哪个函数是"热点"，哪条调用链最长，不需要逐行看日志。对于生产环境来说，perf的开销极低，采样模式下对业务影响可以忽略不计，这一点非常关键。

二、环境准备：装好必要的工具链

在Ubuntu上开始之前，先把工具装齐。需要安装perf本身、FlameGraph脚本以及一些编译依赖。

sudo apt update
sudo apt install linux-tools-common linux-tools-generic linux-tools-$(uname -r)
sudo apt install git build-essential perl python3-flamegraph
git clone https://github.com/brendangregg/FlameGraph.git
cd FlameGraph

这里有个坑要注意：linux-tools-generic这个包的版本必须和你当前运行的内核版本匹配，否则perf跑不起来。用uname -r确认内核版本，如果装的包版本对不上，去Ubuntu的kernel仓库里找对应版本的linux-tools包手动装。

三、用perf record采集性能数据

CPU飙高的时候，第一步是用perf record抓取采样数据。假设你已经通过top或者htop发现PID为12345的进程CPU占用异常高，执行以下命令：

sudo perf record -F 99 -p 12345 -g -- sleep 30

参数解释一下：-F 99表示每秒采样99次（接近100Hz，频率越高数据越精确但开销也越大）；-p指定进程PID；-g表示采集调用栈信息，这是生成火焰图的关键，没有-g就只有函数地址没有调用关系；sleep 30表示采样30秒后自动停止。如果是全系统级别的CPU飙升，不指定-p，直接跑：

sudo perf record -F 99 -a -g -- sleep 30

-a表示采集所有CPU上的所有进程。30秒采样结束后，当前目录下会生成一个perf.data文件，这就是后续分析的原材料。

四、用perf report快速预览热点

在生成火焰图之前，先用perf report快速看一眼数据，确认采样是否有效。执行：

sudo perf report

这个命令会打开一个交互式界面，按CPU占用从高到低排列所有函数。你可以用方向键上下翻，回车展开看调用栈。如果看到某个函数占了百分之六七十的CPU，基本就锁定方向了。不过这个界面信息密度有限，真正的杀手锏是下一步的火焰图。

五、生成火焰图：从数据到可视化

FlameGraph目录下有一套脚本链，核心流程是：perf script把perf.data转成文本，然后stackcollapse-perf.pl折叠调用栈，最后flamegraph.pl画图。一步到位的命令：

sudo perf script | ../FlameGraph/stackcollapse-perf.pl | ../FlameGraph/flamegraph.pl > cpu_flame.svg

如果你没有指定输出文件，默认会生成一个SVG格式的火焰图，用浏览器直接打开就能看。火焰图的横轴没有绝对意义，它表示的是采样数量的占比，纵轴是调用栈的深度。最宽的那个"方块"就是CPU消耗最大的函数，往下看它的父函数就能知道调用链路。比如你看到最宽的是一个叫"do_work"的函数，再往上追溯发现是"process_request"调用了它，再往上是"main_loop"，那问题就定位到了业务逻辑层。

六、实战案例：一个真实的CPU飙升场景

举个实际例子。某次Ubuntu服务器上的Java应用突然CPU飙到95%以上，top显示java进程占满。用perf record -F 99 -p <java_pid> -g -- sleep 30采集数据后，生成火焰图发现最宽的条是JVM内部的一个JIT编译后的方法，展开调用栈发现是某个正则表达式匹配函数被高频调用。进一步查代码，发现是一个日志过滤模块在循环里用了一个复杂的正则，每次请求都触发全量匹配。修复方案是把正则预编译成Pattern对象复用，改完之后CPU直接降到15%以下。这就是火焰图的威力——不用猜，直接看到是哪行代码的哪个函数在吃CPU。

七、进阶技巧：多维度分析提升排查效率

基础流程跑通之后，有几个进阶点值得掌握。第一，如果你怀疑是内核态问题（比如某个驱动或者内核模块），用perf record -F 99 -a -g -- sleep 30采集全系统数据，生成的火焰图里如果看到大量内核函数在顶部，说明问题在内核层。第二，可以用perf stat先做一个宏观统计，看看上下文切换、缓存命中率、分支预测这些指标是否异常：

sudo perf stat -p 12345 -e cycles,instructions,cache-misses,branch-misses -- sleep 10

如果cache-misses特别高，说明程序内存访问模式有问题，可能是数据结构设计不合理导致大量缓存未命中。第三，对于长时间运行的服务，可以用perf record -F 99 -p <pid> -g -- sleep 60采集更长时间的数据，样本量越大结论越可靠。第四，如果服务器上没有root权限或者内核不支持perf，可以考虑用bpftrace或者SystemTap作为替代方案，但功能和精度会打折扣。

八、常见坑和注意事项

实战中有几个容易踩的坑。第一，perf需要内核开启CONFIG_PERF_EVENTS和CONFIG_FRAME_POINTER选项，有些精简版内核默认关了frame pointer，会导致调用栈不完整，火焰图里看不到完整的函数名只有地址。解决办法是在grub里加上kernel参数"noopt=0"或者重新编译内核开启frame pointer。第二，采样频率不是越高越好，99Hz对大多数场景够用了，设到999Hz甚至更高会显著增加系统开销，在生产环境要慎重。第三，perf.data文件可能很大，几十秒的采样就可能几百MB，注意磁盘空间。第四，FlameGraph的脚本依赖Perl和一些系统工具，确保FlameGraph目录下的脚本有执行权限。

九、总结：建立常态化的性能监控思维

perf+火焰图不是只有出问题才用的救火工具，更应该是日常运维的标配能力。建议在Ubuntu服务器上配置好自动化的perf采集脚本，定期（比如每天凌晨低峰期）跑一次采样，生成火焰图存档。这样当CPU异常时，你手里有基线数据可以对比，能更快判断是新增代码引入的问题还是既有问题恶化。Linux运维的核心竞争力不在于会重启，而在于能在不重启的情况下精准定位问题，perf和火焰图就是你手里最硬的那把刀。