生产环境抓 CPU 瓶颈：perf 火焰图真的过时了？聊聊它与 eBPF profile 的底层开销与取舍

生产排障抓 CPU 飙高，大家现在更倾向无脑 perf 还是直接上 eBPF profile 工具（比如 BCC 的 profile.py 或 Parca）？

先抛我的测试结论： 上周在 5.15 内核压测机器上对比了一下：

1. perf record -F 99 -a -g -- sleep 30：落盘的 perf.data 动辄大几百 MB，高压下如果不小心开了 DWARF 解栈，上下文切换开销肉眼可见地涨，perf report 解析符号表还吃了一波本地 CPU。
2. eBPF profile.py -F 99 30：内核态直接在 BPF map 里聚合调用栈，传回用户态的只有聚类后的数据，开销确实低得惊人。

但是！只要生产环境的二进制编译时省掉了 Frame Pointer（-fomit-frame-pointer），eBPF 抓出来的栈底经常断片成 [unknown]。虽然现在有基于 eBPF 的 DWARF unwinder 方案，但落地成本还是有点蛋疼；反倒是老掉牙的 perf 配合 debuginfo 还能硬解。另外 BPF_MAX_STACK_DEPTH 默认 127 层的硬编码，遇到某些深调用栈的 Java/Go 服务直接把顶层给截断了。

大家生产环境（5.x/6.x 内核）都彻底转向 eBPF 持续性能分析（Continuous Profiling）了吗？还是遇到复杂栈回溯依然得靠 perf 兜底？