← 返回

定位 Go 应用 CPU 最热的代码路径：Prometheus 高 CPU 实例分析（OpenResty XRay）

章亦春发布于 Jan 16, 2024 更新于 Aug 27, 2026

用时 6 分钟

阅读次数

本文速览：一个标准的 Prometheus 进程 CPU 占用超过 160%。使用 OpenResty XRay 对其未经修改的 Go 进程做引导式分析后发现，Go 垃圾回收（GC）消耗了 99% 以上的 CPU 时间；而 GC 压力的主要来源是 loadWAL 函数在从预写日志（WAL）加载数据时快速分配了大量 GC 对象——分配对象最多的这条代码路径就占了新分配对象总数的 19% 以上。下文演示完整的定位过程。

在这个教程中，我们会一步步地教您使用 OpenResty XRay 来识别普罗米修斯（Prometheus）应用中最耗 CPU 的 Go（golang）代码路径。这些代码路径消耗最多的 CPU 时间，严重影响普罗米修斯应用的性能。

问题：高 CPU 使用率

首先运行 top 命令检查 CPU 使用情况。

可以看到，这个 Prometheus 进程消耗了超过 160% 的 CPU 核心资源。

再运行 ps 命令查看完整命令行，可以确认这是一个 Linux 发行版自带的标准 Prometheus 二进制可执行文件（/usr/bin/prometheus），并未做过任何修改。

使用 OpenResty XRay 的引导式分析功能定位 CPU 最热的 Go 代码路径

让我们直接用 OpenResty XRay 对这个未经修改的进程做实时分析。在 Web 控制台确认目标机器后，进入 “Guided Analysis”（引导式分析）页面，从系统支持的问题类型中选择 “High CPU usage”（高 CPU 使用率）。

接着选中我们之前在 top 中看到的那个 Go 进程——PID 50785，CPU 占用 125%，可执行文件为 /usr/bin/prometheus。语言级别选择 “Go”，采样时间保持默认的 300 秒，然后开始分析。

OpenResty XRay 会对目标进程持续执行多轮采样。对这个例子来说，运行两三轮后即可停止，系统会自动生成一份分析报告。

这是我们要分析的问题类型，“CPU”。

可以看到，Go 垃圾回收消耗了超过 99% 的 CPU 时间。

例如，这条在执行垃圾回收的 Go 代码路径占用了超过 21% 的 CPU 时间。

scanobject 是 Go 语言的一个运行时函数，它负责垃圾回收的工作。它会在堆内存中寻找 GC 对象，并把它们能够访问到的对象都标记出来。

gcDrain 函数的作用是把工作队列中的 GC 对象都标记并清除掉。

快速分配众多的 GC 对象会导致 GC 开销很高。所以，报告给出了那些分配对象最多最快的 Go 代码路径。

看一下这条 Go 代码路径，它分配了最多的 GC 对象。

函数 loadWAL 是从 Prometheus 的预写日志中加载数据。

函数 Series 函数从缓冲区中解码出时序数据，并将其添加到指定的切片中。

函数 slicebytetostring 将字节切片转换为字符串。

点击 “More” 查看更多细节。

这条代码路径是从这个 Go GC 对象分配火焰图中自动推导出来的。

下面是对当前问题更详细的解释和建议。

它提到了函数 loadWAL.

这个函数从预写日志中加载数据。

它也提到了函数 Series，

和函数 slicebytetostring。

让我们回到刚才的代码路径上来。把鼠标放在函数 loadWAL 的绿色框上。

可以看到这个函数的源文件名。在提示框中还可以看到文件的完整路径。

源代码行号是 141。

点击这个图标，复制这个函数完整的 Go 源文件路径。

使用 vim 编辑器打开源文件，查看这个文件里的 golang 代码。

正如 OpenResty XRay 建议的那样跳转到第 141 行。

函数 dec.Series 是从一个记录中解码一组时间序列。

在状态栏中可以看到这行代码也确实在 loadWAL 函数中，正如之前报告中提到的。

Prometheus 的 TSDB 创建内存序列用来管理最新的数据。这条代码路径新分配的 GC 对象数目超过了新分配总数的 19%。

这里可以看到，动态分配新 GC 对象的操作占用了将近 11% 的 CPU 时间。这不仅增加了垃圾回收器的负担，本身也消耗大量的 CPU 资源。

通过 OpenResty XRay 产品提升您应用的性能

全自动分析与报告

除了引导式分析，OpenResty XRay 还能自动监控在线进程并定期生成报告。进入 “Insights” 页面，即可查看以日和周为周期的分析报告——同样能自动定位到 Go 垃圾回收及最热的代码路径，无需任何手动操作。

所以您不一定要手动使用 “Guided Analysis” 功能；当然，它在应用开发和问题演示时依然非常有用。

如果您喜欢这个教程，请订阅这个博客网站和我们的 YouTube 频道或 B 站频道。谢谢！

常见问题

为什么 Prometheus 进程的 CPU 占用这么高？

在本例中，一个标准的、未经修改的 Prometheus 二进制程序（/usr/bin/prometheus）占用了超过 160% 的 CPU。使用 OpenResty XRay 做引导式分析后发现，Go 垃圾回收消耗了超过 99% 的 CPU 时间；而 GC 压力的来源是 loadWAL 函数在从预写日志（WAL）加载数据时快速分配了大量 GC 对象——仅这一条代码路径新分配的 GC 对象就超过了新分配总数的 19%。

为什么 Go 垃圾回收会消耗这么多 CPU？

快速分配众多的 GC 对象会导致 GC 开销很高。垃圾回收器需要花费 CPU 时间去扫描和标记这些对象——分析报告中突出显示了 scanobject（在堆内存中寻找 GC 对象并标记可达对象）和 gcDrain（处理待标记 GC 对象的工作队列）这样的运行时函数。而且分配操作本身也不便宜：在本例中，动态分配新 GC 对象就占用了将近 11% 的 CPU 时间，这还不算垃圾回收本身的开销。

如何找到导致 Prometheus 高 CPU 的 Go 代码路径？

对正在运行的进程使用 OpenResty XRay 的引导式分析即可，无需修改程序、无需插桩。报告会列出分配对象最多最快的 Go 代码路径，这些路径是从 Go GC 对象分配火焰图中自动推导出来的。把鼠标悬停在函数框（比如 loadWAL）上，就能看到源文件路径和行号（本例中是第 141 行），然后用任意编辑器打开该文件检查具体代码。Insights 页面的日报和周报也能自动得出同样的结论。

关于 OpenResty XRay

OpenResty XRay 是一个动态追踪产品，它可以自动分析运行中的应用，以解决性能问题、行为问题和安全漏洞，并提供可行的建议。在底层实现上，OpenResty XRay 由我们的 Y 语言驱动，可以在不同环境下支持多种不同的运行时，如 Stap+、eBPF+、GDB 和 ODB。

立即申请 OpenResty XRay 试用

关于作者

章亦春是开源 OpenResty^® 项目创始人兼 OpenResty Inc. 公司 CEO 和创始人。

章亦春（Github ID: agentzh），生于中国江苏，现定居美国湾区。他是中国早期开源技术和文化的倡导者和领军人物，曾供职于多家国际知名的高科技企业，如 Cloudflare、雅虎、阿里巴巴, 是 “边缘计算“、”动态追踪 “和 “机器编程 “的先驱，拥有超过 22 年的编程及 16 年的开源经验。作为拥有超过 4000 万全球域名用户的开源项目的领导者。他基于其 OpenResty^® 开源项目打造的高科技企业 OpenResty Inc. 位于美国硅谷中心。其主打的两个产品 OpenResty XRay（利用动态追踪技术的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最适合微服务和分布式流量的全能型网关软件），广受全球众多上市及大型企业青睐。在 OpenResty 以外，章亦春为多个开源项目贡献了累计超过百万行代码，其中包括，Linux 内核、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，并编写过 60 多个开源软件库。