Cloudflare Adds On-Demand CPU and Memory Profiling for Workers

Cloudflare 为 Workers 和 Durable Objects 引入了按需 CPU 与内存性能剖析功能，开发者可以借助交互式火焰图调查生产环境中的性能瓶颈。该功能于 2026 年 10 月 9 日发布，可通过 Workers Observability 控制台或 cf CLI 生成交互式火焰图，帮助团队找出耗费资源的函数和内存分配，而不必只依赖日志和汇总指标。

开发者可以针对已部署的 Worker 版本采集 CPU 或堆内存分配剖析数据，并以火焰图查看结果。图中越宽的部分，表示相应函数占用的 CPU 时间或采样到的内存分配比例越高。剖析数据也可以下载，供离线分析。

关键区别在于，该功能针对的是已经运行的隔离实例，而不是启动一个新实例。这让开发者能够检查真实生产流量下执行的代码。Durable Objects 还支持针对某个指定实例进行性能剖析，便于调查与有状态工作负载相关的问题。不过，目标实例必须在采集期间接收到足够的流量；TypeScript 开发者也应启用源码映射，以便更容易辨认函数名称。

这一实现需要考虑 Workers 分布在 Cloudflare 边缘基础设施各处的情况：同一个脚本可能在不同数据中心和物理机器上运行多个隔离实例。因此，性能剖析请求必须识别所需的 Worker 版本，并找到合适的活跃隔离实例。Durable Objects 带来了另一项挑战，因为它们有状态，而且可能在不同位置之间迁移；Cloudflare 会将性能剖析请求路由到托管指定对象的机器。

运行时不会在整个采集过程中一直持有隔离实例锁。进行 CPU 性能剖析时，它会启动一个以 1 毫秒为间隔采样的 V8 性能分析器，随后释放锁，让请求继续执行；结束剖析并收集结果时，再重新获取锁。这使平台能够观察实时执行情况，而不必在采集期间暂停正常的请求处理。

CPU 和内存剖析回答的也是不同的问题。CPU 剖析通过采样调用栈，揭示执行时间花在了哪里，帮助找出耗时较多的函数、重复计算和潜在的优化机会。相比之下，内存剖析突出显示与函数相关的内存分配，帮助开发者找到创建过多对象或加重内存压力的代码。

这一区别对于诊断性能问题很重要：一个函数可能消耗大量 CPU，却几乎不分配内存；另一个函数则可能产生大量内存分配，但并非执行时间的主要来源。查看相应的剖析数据，有助于将调查范围缩小到相关的资源瓶颈。

Cloudflare 在内部使用该功能找出了不必要的计算和内存消耗。对一个使用 R2 绑定的 Worker 进行性能剖析时，团队发现一个递归 JSON 替换函数反复遍历嵌套数据，执行了多余的工作。据称，修正实现后，该函数的运行速度提高到原来的 2.7 倍。另一份剖析数据则发现一次不必要的重复指标调用，约占 CPU 时间的 1%。

内存剖析还发现了另一个问题：据称，部分禁用的 Prometheus 插桩代码仍在消耗大量内存。Cloudflare 称，移除剩余代码后，该 Worker 的第 99.9 百分位内存使用量从 133 MB 降至 118 MB，低于 128 MB 的限制。

Cloudflare 的功能是对现有工具的补充，而不是替代。Chrome DevTools 支持本地 CPU 性能剖析，适合开发阶段使用，但生产流量和数据可能难以复现。pprof 广泛用于 Go 及其他受支持的性能剖析工作流，提供强大的离线剖析数据分析能力；Cloudflare 也允许使用 pprof 检查下载的剖析数据。Cloudflare 这项功能的主要区别在于，可以通过平台现有的运维界面，对正在运行的 Workers 和 Durable Objects 发起性能剖析。

该功能也补充了日志、指标和分布式追踪。这些工具有助于发现服务何时变慢或消耗过多资源，而剖析数据可以帮助定位负有责任的函数。结合使用，便能更全面地了解应用的运行情况。

按需采集并非持续监控。较短的性能剖析窗口可能错过间歇性问题；堆内存剖析记录的是采集期间的分配情况，不能完整反映留存内存。Cloudflare 表示正在推进持续性能剖析，以便在无须预先判断问题何时出现的情况下，更容易调查罕见的性能问题。

对于在 Cloudflare Workers 上运行生产工作负载的团队，此次发布增加了一项实用的调试能力：无须先在本地复现问题，就能从发现资源压力进一步定位到造成问题的代码。

原文链接：

https://www.infoq.com/news/2026/10/cloudflare-cpu-memory-profiling/