在Debian系统上排查CPU占用过高的问题时，只靠top或ps往往只能看到某个进程的整体使用率，很难知道具体是哪个函数在持续消耗CPU。火焰图把采样到的函数调用栈按照出现频率堆叠起来，调用关系自下而上排列，横向宽度代表CPU占比，可以直观定位热点代码。生成一张CPU火焰图通常需要三个步骤：安装perf采集工具、用perf record记录调用栈、把采样结果转换成SVG火焰图。整个过程在Debian上可以完全使用官方仓库和开源脚本完成。
不过实际执行时有一些细节容易被忽略。perf的可用性与内核版本、权限设置、软件包名称都有关系；如果符号表缺失，火焰图里只会出现十六进制地址；如果采集命令参数不对，栈信息不完整，图也没有分析价值。下文会按照环境准备、数据采集、火焰图生成与解读的顺序展开，并给出可以复现的示例。
一、确认Debian环境并安装perf
Debian仓库提供了与系统内核对应的perf软件包，但名称和可用性会因版本不同有所变化。可以先通过uname -r查看内核版本，再使用apt search perf查找可用包。多数情况下，安装linux-perf即可满足需求，如果仓库中的linux-perf与当前内核不完全匹配，也可以尝试安装linux-perf-$(uname -r)这样的版本化包名。安装完成后执行perf --version确认命令行工具可以运行，同时注意输出中的内核版本信息是否与uname -r一致。
perf在采集调用栈时依赖内核的perf_event接口，Debian默认的权限限制可能阻止普通用户使用。可以通过cat /proc/sys/kernel/perf_event_paranoid查看当前等级，默认值通常为2或更高，这代表普通用户只能测量自己的进程，不能采集系统级事件。临时放宽限制可以执行sudo sysctl kernel.perf_event_paranoid=1，但更推荐使用sudo运行perf命令，以避免全局改动物理机安全策略。另一个需要关注的是/proc/sys/kernel/kptr_restrict，如果该值大于0，普通用户无法读取内核符号地址，火焰图底部的内核调用栈可能显示不完整。
安装步骤示例如下：
sudo apt update sudo apt install linux-perf perf --version sudo sysctl kernel.perf_event_paranoid=1 sudo sysctl kernel.kptr_restrict=0
如果安装的是linux-perf-$(uname -r)，需要把命令中的软件包名替换为对应值。执行perf --version时如果提示缺少特定内核模块或无法打开计数器，通常说明perf工具与运行内核版本不匹配，应该重新从仓库安装正确的版本化包。
二、使用perf record采集CPU调用栈
perf record是采集数据的核心命令。它与普通性能监控工具不同，不是计算某个进程的平均CPU使用率，而是按照固定频率对CPU执行上下文进行采样，记录每次采样时的函数调用栈。默认采样频率为4000Hz，但排查业务进程热点时通常使用99Hz或999Hz，避免采样本身占用过多资源。参数-g表示记录调用栈，这是生成火焰图的前提条件，缺少它后续无法还原调用链。
如果目标是一个已知的进程，可以先通过ps获取PID，然后使用-p指定进程。例如对一个PID为12345的进程采集30秒：
sudo perf record -F 99 -p 12345 -g -- sleep 30
也可以使用-a参数对全系统所有CPU进行采样，适合短期定位整体负载来源。但这种方式的输出会比单进程大很多，需要提前规划采样时长。执行结束后，perf会在当前目录生成perf.data文件，这就是原始采样数据。可以用sudo perf report --stdio快速查看文本格式的统计结果，验证调用栈是否正常，但文本报告在复杂调用链面前不够直观，下一步需要转换成火焰图。
采样时经常会遇到两个问题：一是普通用户运行perf record被拒绝，这通常是因为perf_event_paranoid等级过高，需要按第一节调整或直接加sudo；二是只看到地址而没有函数名，说明二进制文件缺少调试符号。Debian上可以用apt安装对应包的-dbg版本，或使用debuginfod自动获取符号，但至少先确认核心程序没有被strip掉符号表。
三、用FlameGraph生成可交互火焰图
火焰图通常指Brendan Gregg提出的交互式SVG火焰图。原始perf.data不能直接用于绘图，需要先导出成折叠栈格式。整个过程依赖FlameGraph仓库中的几个Perl脚本，可以从GitHub获取。将perf.data转换成文本调用栈时使用perf script命令，输出中的每一行代表一次采样对应的完整调用链。然后通过stackcollapse-perf.pl把调用链折叠成函数路径和计数的两列格式，最后交给flamegraph.pl生成SVG。
下面是Debian上的完整命令序列：
sudo perf script > out.perf ./stackcollapse-perf.pl out.perf > out.folded ./flamegraph.pl out.folded > cpu.svg
需要注意，perf script输出可能很大，尤其是在使用-a全系统采样时，中间文件out.perf会占用大量磁盘空间。如果只是分析单个进程，建议先缩小采样范围再导出。生成的cpu.svg可以用浏览器打开，把鼠标悬停在某个函数块上会显示采样占比，点击函数块可以局部放大查看子调用。这些交互能力来自SVG内嵌的JavaScript代码，但不需要服务器环境，直接用文件方式打开即可。
如果火焰图出现大片空白或函数名缺失，问题通常出在符号解析阶段。可以检查perf script输出中是否包含类似unknown或十六进制地址的内容。对于用户态程序，常见的解决办法是安装-dbg符号包；对于内核符号，则需要确认kptr_restrict已经允许读取，并且perf命令有足够权限。另外，FlameGraph脚本本身不直接处理perf.data，不要跳过perf script这个转换步骤。
四、火焰图阅读与常见问题排查
看懂火焰图的关键在于理解坐标系。横轴不是时间，而是采样占比，宽度越宽的块代表出现在采样栈中的次数越多；纵轴表示调用栈深度，从下到上表示从父函数到子函数的调用关系。比如最底部是入口函数，向上是逐层调用，最顶部通常就是CPU实际执行的热点函数。一个函数如果自身宽度较大，说明它本身占用了大量CPU；如果宽度大但上方还有很宽的子函数，则真正消耗可能集中在子函数内部。
实际排查中，优先看顶部最宽的叶子节点，因为叶子节点直接对应执行代码。例如一个业务进程的火焰图顶部长期出现与JSON解析相关的函数，就可以重点优化序列化与反序列化逻辑。相反，如果顶部出现大量内核调用如copy_user或tcp_sendmsg，需要判断是磁盘、网络还是系统调用开销造成。对于服务端程序，还可能看到锁等待或上下文切换相关的热点，这需要结合具体函数名和调用路径判断。
常见的问题还包括：容器内perf可能因为缺少CAP_PERFMON权限而无法采样，可在宿主机侧采集或给容器添加权限；perf script生成的文件过大导致磁盘写满，可以先使用perf report限制数量；火焰图颜色默认按函数名随机生成，不能把颜色当成性能指标，颜色主要用来区分不同函数。最后，单次采样时间太短可能漏掉周期性任务，建议至少覆盖一个完整的业务周期，并对比多次火焰图确认热点是否稳定。