服务器性能问题排查是每个后端工程师的必修课。当 CPU 飙到 100% 或者响应延迟突然上升，你需要的不是"重启试试"，而是一套系统化的诊断工具链。本文记录我在实际项目中常用的三个工具：perf、eBPF 和火焰图。

perf：Linux 性能分析的瑞士军刀

perf 是 Linux 内核自带的性能分析工具，无需额外安装。最常用的三个子命令：

# 实时查看系统热点函数（采样频率 99Hz）
perf top -F 99

# 记录某个进程 30 秒的性能数据
perf record -p $(pgrep python) -g -- sleep 30

# 生成可读报告
perf report --stdio

perf top 适合快速定位问题——比如发现某个 Python 函数占比 40%，立刻知道瓶颈在哪。perf record 则用于离线分析，配合 perf report 可以逐函数查看调用栈和 CPU 占比。

火焰图：把调用栈变成热力图

perf 的文本输出对于深层调用栈不够直观。火焰图（Flame Graph）由 Brendan Gregg 发明，用一个 SVG 图表展示整个调用层级——宽度代表 CPU 占比，颜色区分函数类型，鼠标悬浮可看详情。

# 生成火焰图的标准流程
perf record -F 99 -p PID -g -- sleep 30
perf script > out.perf
# 使用 FlameGraph 工具集
stackcollapse-perf.pl out.perf > out.folded
flamegraph.pl out.folded > flame.svg

在火焰图中，如果你看到一大片紫色（Python 解释器内部），说明代码有优化空间——比如把循环中的属性访问提取到局部变量，或者用列表推导替代显式循环。

eBPF：内核级的可观测性

eBPF 是现代 Linux 可观测性的基石。它允许你在内核中运行沙箱化的程序，不影响性能。我常用 bpftrace 做快速诊断：

# 追踪所有 open() 系统调用及其延迟
bpftrace -e 'kprobe:do_sys_open { @start[tid] = nsecs; }
  kretprobe:do_sys_open /@start[tid]/ {
    $ms = (nsecs - @start[tid]) / 1000000;
    printf("%-6d %s\n", $ms, str(arg1));
    delete(@start[tid]); }'

在排查 FastAPI 应用的高延迟问题时，eBPF 帮助我发现了一个隐藏的坑：某个依赖库在每次请求时都会调用 stat() 检查配置文件是否存在，累积产生了数百毫秒的无谓开销。

实战经验

三个工具的使用场景总结：perf top 用于快速确认"是不是我的代码慢"；火焰图 用于向同事和 leader 展示问题；eBPF 用于深入内核层面的根因分析。工具是手段，最重要的是形成"测量→假设→验证"的诊断思维，而不是靠直觉猜。

--- 约 750 字