Continuous Profiling 的真实开销：从 1.3% 压到 0.3%，以及那些没人告诉你的坑
接入 Continuous Profiling 之前，所有人都会先问一句：这东西到底吃掉多少 CPU？ 答案往往是一个听起来很美的数字：eBPF 采样 profiler 理论上只要 0.035%。但等你真的跑起来，数字可能变成 1.3%。差距不在采样本身，而在你没算进去的那两步。
一、名义开销 0.035% vs 实际开销 1.3%
Pixie 团队在公开分享中给过一个测算：eBPF 采样 profiler 采集一条栈大约需要 3500 条 CPU 指令，按 100Hz 采样频率估算，理论开销仅 0.035%（来源：Pixie 团队工程博客）。
但他们的首版实现跑到了 1.3%。额外成本几乎全部出在采样环节之外：
- 栈符号化（stack symbolization）：把内核栈和用户态栈地址翻译成函数名，这个动作极其昂贵，尤其是在用户态。
- 内核态到用户态的数据搬运：每次采样把原始栈数据拷到用户态，大量 syscall 和内存拷贝。
他们用火焰图给自己做了热点分析，然后做了三件事把 CPU 开销压到约 0.3%：
- 加符号缓存，避免重复解析；
- 减少遍历 BPF map 时的 syscall 次数；
- 改用 perf buffer（环形缓冲）替代逐条上报。
结论：eBPF 采样本身便宜，贵的是符号化和搬运。 选型时别只看"采样器开销"，要看整套管线的开销。
二、采样频率：为什么是 19/49/99Hz
采样频率的选择比你想的更讲究，一个常见推荐是 素数频率：19Hz、49Hz、99Hz。
原因在于：如果采样频率与内核调度器的时间片边界对齐（比如用整数的 100Hz），采样点会周期性落在相似的代码路径上，产生 锁步采样（lock-step）偏差，结果不具代表性。素数频率可以让采样点跟调度时隙错开，统计学上更均匀。
具体数字（来自社区实践与 Parca/Pyroscope 文档整理，具体数值建议结合自身 workload 实测）：
- 99Hz：多数服务的甜点位，火焰图细节足够，开销可接受。
- 499Hz：开销约 3-5%（需实测确认）。
- 999Hz：开销约 8-12%（需实测确认）。
- 持续运行建议 19-49Hz，能在长期运行中保持开销极低。
配置示例（Pyroscope Go SDK）：
// 99Hz 适合排查特定问题，短时间跑
runtime.SetCPUProfileRate(99)
// 持续运行建议 19-49Hz
runtime.SetCPUProfileRate(19)
注意：上面的
runtime.SetCPUProfileRate是个危险 API，和pprof.StartCPUProfile互斥，详见下文。
三、eBPF 为什么能长期跑在 <1% 开销
关键在于 聚合发生在内核里，而不是用户态。
传统 perf record 的做法：每采样一次就把原始栈搬到用户态，由用户态程序处理——数据搬运量巨大。eBPF 的做法：采样时只在 BPF hash map 里做一次计数，key 是 (pid, user_stack_id, kernel_stack_id) 的组合，value 是命中次数。用户态程序每几秒读一次聚合后的计数结果，而不是每秒接收几千上万条原始样本。
想验证这条链路，可以直接看 BPF map：
bpftool map dump name stacks
实际生产环境中，这条路线的 CPU 开销通常能控制在 1% 以下，前提是符号化和 map 读取逻辑写得足够克制（参考 Pixie 的优化路径）。
四、on-cpu 火焰图的根本盲区：off-cpu 时间完全不可见
CPU 采样火焰图只统计 TASK_RUNNING 状态下在 CPU 上执行的时间。以下情况它完全看不见：
- 锁等待（mutex / spinlock）
- 磁盘 / 网络 IO
- epoll 等待
- 线程被调度走之后的排队时间
一个经典案例：服务 P99 = 500ms，但 CPU 火焰图几乎全空——瓶颈根本不在 CPU 上。这时候把采样频率从 99Hz 调到 999Hz 毫无意义，你应该做 off-cpu profiling，思路是挂到 sched_switch tracepoint 上，记录线程被换出的原因和持续时间。
# 用 bpftrace 粗看 off-cpu 分布
bpftrace -e 'tracepoint:sched:sched_switch { @[args->prev_comm] = hist(args->prev_state); }'
什么情况下别这么做： 如果你的服务本身就是 CPU 密集（比如计算引擎、视频编码），CPU 火焰图已经能看到大量热点，先解决 on-cpu 问题，再考虑 off-cpu。不要一上来就上两套 profiling，运维负担翻倍。
五、Go 的一个坑：runtime profiler 只能跑一路
Go 的运行时 CPU profiler（runtime/pprof）有一个限制：同一进程内同时只能有一路采样。也就是说：
- 手动触发
/debug/pprof/profile和 Pyroscope Go SDK 的 CPU profiler 会互相抢； runtime.SetCPUProfileRate和pprof.StartCPUProfile互斥，后者内部会调前者，重复调用会报错。
如果你用 Go 自带的 profiler 排查问题期间，Pyroscope 的采集会静默失效，反之亦然。
绕过方案：用 eBPF 路线的 profiler（如 Parca），它是从内核侧采样的，不经过 Go runtime，不受单实例约束，跟 runtime/pprof 完全不冲突。
什么情况下别这么做： 如果你只是想快速看一眼当前 goroutine 栈，直接用 go tool pprof http://localhost:6060/debug/pprof/goroutine 就够了，不需要为此上 eBPF。
六、存储账单：pprof 很省，但不代表你不用付钱
pprof 是 Google 设计的事实标准二进制格式，效率很高，一份 30 秒的 CPU profile 压缩后可能只有 10-30KB（具体大小取决于栈深度和样本数，未实测）。
但规模一放大，账就变脸了。算一笔账：1000 个 pod，每 10 秒传一份 profile，一天就是 2.6 亿份。即便每份只有 20KB，总量也是 TB 级。这在生产环境不是理论推演，是常态。
常见的存储对策：
- 分层保留：详细数据留 7 天，compact 聚合数据留 30 天；
- 抽样上报：不是每个 pod 每次都传，按比例抽样；
- 按服务 tier 差异化采样频率：核心服务 10 秒一次，边缘服务 60 秒一次；
- 冷数据归档到对象存储：S3 / OSS，而不是留在集群里。
Grafana Pyroscope 官方给出的量级参考：每 pod 内存开销 <50MB（CPU + alloc + goroutine + mutex + block 全部开启），CPU 开销为低个位数百分比（来源：Grafana Pyroscope 官方文档）。
七、选型一句话
- 已经在用 Grafana 生态 → Grafana Pyroscope，和 Prometheus/Loki 打通最顺；
- 要 eBPF 整机零侵入、存储想落 S3/Parquet 自己掌控 → Parca；
- 预算够、不想运维 → 托管方案（Grafana Cloud Profiles / Datadog）。
以及一条血泪经验：别同时跑两套 profiling 后端。两个 agent 各自采样、各自存、各自出图，排查问题时数据对不上，运维面直接翻倍。先把一套跑明白，再谈对比。
最后补充一条：本文引用的大部分数字来自 Pixie 团队博客、Parca/Pyroscope 文档和社区实测，具体到你的服务和硬件上，开销可能差出一个量级。上生产之前，先在 staging 压测环境跑 24 小时，对比开 profiler 前后的 CPU 和 P99。 这才是最可靠的验证方式。