← 返回

Erlang 高 CPU 使用率：通过火焰图追踪 PCRE 正则瓶颈

章亦春发布于 Apr 1, 2024 更新于 Aug 24, 2026

用时 6 分钟

阅读次数

当 Erlang 应用的 CPU 使用率超过 200% 时，瓶颈往往深藏在 BEAM VM 运行时内部。我们使用 OpenResty XRay 分析了一个正在运行的 Erlang 进程，将 Erlang 高 CPU 使用率追踪定位到了 check_resp_content 中的 PCRE 正则回溯 —— 具体来说是 Erlang 运行时中封装 PCRE 库的 erts_pcre_exec C 函数。整个过程无需修改代码、无需重新编译、也无需重启进程。

本文展示了完整的分析过程 —— 从在 top 中观察到一个 Erlang 进程消耗超过 200% 的 CPU，到 Erlang 语言级别和 C 语言级别的火焰图分析，再到精确定位导致问题的源文件和行号。

观察 Erlang 进程 CPU 使用率超过 200%

Erlang 高 CPU 使用率通常在 top 或 htop 的输出中表现为一个繁忙的 BEAM VM 进程 —— 通常名为 beam.smp，或者像本例一样，显示为启动它的 escript 名称。无论哪种情况，真正的问题是哪条 Erlang 代码路径导致了高 CPU 占用。

运行 top 命令来检查目标进程的 CPU 使用情况。

可以看到，这个进程消耗超过 200% 的 CPU 资源。

它名为 rebar3，是管理和构建 Erlang 项目的工具，这里我们用来启动项目。

运行 ps 命令来查看这个进程的详情。

这个 rebar3 二进制可执行文件是 Linux 发行版自带的。这个程序自然也是用标准发行版自带的 Erlang 编译的。

使用 OpenResty XRay 分析 Erlang CPU 使用率

OpenResty XRay 可以实时分析这个未经修改的 Erlang 进程 —— 同时在 Erlang 语言级别和 BEAM VM 底层的 C 语言级别进行分析 —— 无需在目标应用中安装任何模块或插件。在 Web 控制台中，进入 Guided Analysis 页面，选择 High CPU Usage 作为问题类型，然后选择目标机器上的 Erlang 应用。

选择消耗接近 200% CPU 资源的进程 —— 也就是我们之前在 top 中看到的。

OpenResty XRay 可以在多种不同语言的级别上同时进行分析。这里保持 Erlang 和 C/C++ 都选中，以同时查看 Erlang 代码层面和 BEAM VM 内部的热点，最长分析时间保持默认的 300 秒不变。

开始分析后，系统将持续执行多轮分析。对这个例子来说，两轮就够了。

系统自动生成了一份分析报告。

Erlang 语言级别 CPU 火焰图：check_resp_content 中的正则匹配

这条是占用 CPU 时间最多的 Erlang 代码路径。

check_resp_content 函数是用于检查内容的业务函数。

它调用了 lists 模块的 filter 函数对列表进行过滤筛选。

而筛选条件是一个匿名函数，这个匿名函数内使用正则表达式匹配。这些调用都发生在 check_resp_content 函数内。

点击查看更多。

这条热代码路径是由这个 Erlang 语言级别的 CPU 火焰图自动推导出来的。

这是对问题更详细的解释和建议。

回到之前的热代码路径。将鼠标悬停在这个函数的绿框上。在提示框中可以看到它的源文件路径。

Erlang 源码的行号是 15。

点击复制源文件路径。

使用 Vim 编辑器打开 Erlang 源文件。您可以使用任何您喜欢的编辑器。

按照 OpenResty XRay 的建议，跳转到第 15 行。

这是 re 模块的 run 函数 —— Erlang 标准库中连接 PCRE 正则引擎的接口。

这是我们之前看到的 lists:filter 函数调用。

这行代码确实在函数 check_resp_content 中。您可以通过优化这里的正则，避免正则引擎进行代价高昂的回溯操作，或者改用非回溯的正则引擎。

这两条代码路径类似，都是在执行正则匹配。

第三条路径是在匹配前计算输入字符串的长度。

iolist 是要匹配的输入字符串，erts_iolist_size 就是在将字符串传递给 PCRE 引擎之前计算其长度。

这里的 Content 就是待匹配的输入字符串。

C 语言级别分析：erts_pcre_exec 与 PCRE 回溯

回到 Web 控制台。C 语言级别的分析揭示了 BEAM VM 内部的性能热点 —— 确认 CPU 瓶颈一直深入到了 PCRE 库层面。

这个名为 match 的 C 函数是 PCRE 库中负责执行正则匹配的函数。

erts_pcre_exec 函数是 Erlang 运行时对 PCRE 库中的 pcre_exec 函数的封装。

re_run 是 Erlang 中 re 模块用于执行正则匹配的函数。

这个 16 进制地址表示这个代码路径是在 JIT 编译的 Erlang 代码中执行的。

PCRE 正则回溯在 BEAM VM 中为何代价高昂

C 语言级别的火焰图确认 CPU 时间花费在 erts_pcre_exec 上 —— 这是 BEAM VM 内置的 PCRE 库绑定。Erlang 的 re 模块将所有正则操作委托给 PCRE，而 PCRE 使用回溯 NFA 引擎。当正则模式包含 .*、.+ 等量词或嵌套的选择分支时，引擎可能需要探索指数级数量的匹配路径才能得出不匹配的结论。这就是所谓的灾难性回溯。

要修复此类 PCRE 正则瓶颈，您可以优化正则表达式以避免正则引擎进行代价高昂的回溯操作，或者考虑使用非回溯的正则引擎。

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

自动监控与报告

对于生产环境的工作负载，OpenResty XRay 会持续监控 Erlang 进程，并在 Insights 页面自动生成每日和每周报告 —— 无需手动执行引导式分析。

常见问题：Erlang 高 CPU 使用率

为什么我的 Erlang 进程 CPU 使用率这么高？

Erlang 高 CPU 使用率的常见原因是热代码路径中存在高开销的操作 —— 通常是正则匹配、垃圾回收压力或低效的列表处理。在本例中，OpenResty XRay 将 CPU 瓶颈追踪定位到了 check_resp_content 函数中的 PCRE 正则回溯，其中 re:run/2 在 lists:filter/2 循环中对每个元素都被调用。Erlang 和 C 两个级别的 CPU 火焰图揭示了直达 erts_pcre_exec 的完整调用链。

如何找到导致高 CPU 的 Erlang 代码？

使用 OpenResty XRay 的引导式分析功能，在 Erlang 和 C 两个语言级别生成 CPU 火焰图。火焰图以堆叠的函数调用形式展示，宽度代表 CPU 时间。将鼠标悬停在函数框上即可查看源文件路径和行号，然后用任何编辑器打开该文件即可检查导致问题的具体代码。整个过程无需修改代码或重启 —— OpenResty XRay 直接附加到正在运行的 Erlang 进程。

PCRE 正则模式会导致 Erlang 高 CPU 吗？

会的。Erlang 的 re 模块通过 erts_pcre_exec 将正则操作委托给 PCRE 库，而 PCRE 使用回溯 NFA 引擎。包含嵌套量词或选择分支的模式可能触发灾难性回溯，消耗指数级的 CPU 时间。在本例中，PCRE 的 match 函数在 C 语言级别的火焰图中显示为叶节点 CPU 消耗者，确认正则回溯就是 Erlang 高 CPU 使用率的根本原因。

关于 OpenResty XRay

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

立即申请 OpenResty XRay 试用

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

关于作者

章亦春是开源 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 多个开源软件库。