科技Bestblogs·CNCF [Cloud Native Computing Foundation]··AI 生成
CPU 都去哪了？Datadog 用持续性能剖析定位 OpenSSL 回归
Datadog 在 OS 升级后遭遇多服务 CPU 消耗上涨 70%、年化或增 300 万美元成本，工程师 Nayef Ghattas 借排查过程讲清持续整机性能剖析的工程取舍：eBPF 无埋点覆盖应用、系统进程与第三方库，开销低于 1%；为按服务筛选，把剖析数据与资源对象从主机粒度拆到工作负载粒度，一度使传输量翻倍，引入共享字典后增幅压到约 10%。火焰图对比锁定 OpenSSL 部分函数 CPU 最高涨 12 倍，换修复版即恢复基线。适合做可观测性、云原生成本与 eBPF 的工程师精读。原文 ↗原文 ↗
核心观点
- ▍持续整机性能剖析（主机级 eBPF 采样 + 按工作负载归属元数据）能把 CPU 回归的归因范围从应用代码扩展到系统进程与第三方库，从而定位到应用侧无法发现的成本来源。
- 01Datadog 多个服务在操作系统升级后 CPU 消耗上涨 70%，若按当时规模折算约每年多出 300 万美元计算成本。
- 02eBPF 接收器无需逐个应用埋点，即可同时观察应用进程、系统进程与第三方库；据讲者介绍典型 CPU 开销低于 1%，因此可以长期在生产环境常开。
- 03最初整台主机共用一个资源对象，无法按容器或服务筛选；改为按工作负载拆分剖析数据与资源对象后，才具备调查所需的过滤能力。
- 04按工作负载拆分后，属性和函数信息被各份剖析数据重复携带，传输数据量一度翻倍；引入共享字典让各剖析引用而非复制属性后，增幅降至约 10%。
- 05对比升级前后的火焰图发现，OpenSSL 部分函数的 CPU 消耗最高增至原来的 12 倍；切换到修复后的 OpenSSL 版本后资源消耗恢复基线。
反方 / 局限
- — 共享字典把传输增幅从翻倍压到约 10%，但仍不是零成本；文章未讨论剖析数据长期存储、跨主机聚合与查询延迟的代价。
- — 低于 1% 的 CPU 开销是讲者引用的典型值，文章未给出在超大规模主机或高频采样设置下的分布与最坏情况。
- — 回归定位依赖『升级前后』可比的火焰图，若没有提前持续采集剖析数据，该方法在突发回归出现前无法回溯。
概念锚点
前置背景
平行视角
未来推演
延伸追问