在生产环境分析一个实时运行的 Python 应用,最大的顾虑往往不是能不能定位问题,而是分析工具本身会不会拖垮线上服务。我们在一个实时运行的 gunicorn(WSGI)应用上、以生产模式实测了 OpenResty XRay 的开销:采样期间最大吞吐量仅下降 3.4%、平均延时仅增加 0.16 毫秒,而 Agent 空闲时性能开销严格为零。 之所以能做到这一点,是因为它与常驻式 APM Agent 不同,不对目标进程做任何代码注入或修改,只在用户主动发起分析时才低频采集数据;下文用一组逐项实测数据,还原它对 CPU、内存、负载,以及吞吐量和延时的真实影响;完整的实测与操作过程,可观看本文上方的视频版本。

测试环境与性能基线

为建立对比基准,在分析器运行前,我们通过 top 命令捕获了系统性能基线。如下图所示,目标 gunicorn 进程(Python 编写的应用)的 CPU 占用约为 46.5%,整个系统过去一分钟的平均负载值为 0.7,当前 CPU 空闲率约为 87.2%,可用内存约 2632 MB

gunicorn 进程基线

gunicorn 进程基线

分析期间对 CPU、内存和负载有何影响?

为模拟真实诊断场景,我们通过 OpenResty XRay 控制台,在生产模式下,针对该 Python 进程发起了一次持续 300 秒(5 分钟)的 “High CPU usage” 场景分析(路径:Guided Analysis → High CPU usage → 选择目标进程)。

分析进行中,持续 300 秒

选择“生产模式”至关重要,因为它专为线上环境设计,通过低频采样等优化,旨在将性能影响降至最低。不过这也意味着分析时间可能会更长。

在分析器运行期间,我们观察到系统各项指标的细微变化:

  • 目标进程 CPU 占用率:上升至 ~48%,相比基线增加约 1.5 个百分点。
  • 整个系统过去一分钟的平均负载值:上升至 0.84,比之前的 0.7 增加了 0.14。
  • CPU 空闲率:下降至 ~86.7%,与基线 87.2% 相差无几。
  • 系统可用内存:维持在 ~2631 MB,仅降低约 1 MB,无明显变化。

分析器运行期间系统指标

System metrics during analyzer operation

结论是,OpenResty XRay 分析器在采样期间对系统级资源(CPU、内存、负载)的影响是存在的,但幅度轻微,并未对系统稳定性构成压力。

分析对吞吐量与延时的影响有多大?

对于线上服务而言,吞吐量和延时是衡量性能的生命线。我们对这两项核心指标进行了三轮对比测试。下表汇总了三种状态下的结果:

状态最大吞吐量平均延时
未安装 OpenResty XRay 的 Agent约 2300 RPS4.32 毫秒
已安装 Agent、分析器空闲约 2300 RPS(不变)4.32 毫秒(不变)
分析器正在采样约 2220 RPS(−3.4%)4.48 毫秒(+0.16 毫秒)

1. 最大吞吐量

我们使用压测工具,测量了不同状态下服务器的最大吞吐量。

  • 没有安装 OpenResty XRay 的 Agent 时,最大吞吐量约为每秒 2300 个请求。
  • 当 Agent 已安装但未运行分析器时,最大吞吐量保持不变。
  • 当分析器正在采样时,最大吞吐量约为 2220 RPS,仅比不进行采样时低 3.4%。

结果显示,当分析器正在采样时,最大吞吐量约为每秒 2220 个请求,仅比不采样时低 3.4%

分析器运行时吞吐量

2. 平均请求延时

我们测量了采样过程中,对请求延时的影响。

  • 没有安装 OpenResty XRay 的 Agent 时,平均请求延时为 4.32 毫秒。
  • 当 Agent 已安装但分析器未运行时,平均请求延时没有变化。
  • 当分析器正在运行时,请求延时变为 4.48 毫秒。仅仅增加了 0.16 毫秒。

分析器运行时请求延时

总结

通过对系统资源、应用吞吐量和请求延时的全面测量,可以得出结论:OpenResty XRay 的动态追踪架构,使其在对生产环境 Python 应用进行实时诊断时,性能开销可量化、可预期,且对核心业务指标的影响极小。这证明了它是一款可以安全、放心地在生产环境中常态化使用的性能分析工具。

InsightsDashboard 页面进行自动分析的开销也同样极低。

Insights 和 Dashboard 页面

如果你的 Python 进程 CPU 占用很低、吞吐却上不去,可参考用 off-CPU 分析定位阻塞的 subprocess.run 调用的实战:Python 应用 off-CPU 分析。同样的生产模式开销实测我们也在其他语言上做过,可查看 GoRustPHPPerl 应用的实测结果。

OpenResty XRay 与常驻式 APM Agent 的对比

开销之所以能维持在如此低的水平,根源在于架构差异。传统 APM Agent 会向目标进程注入代码并持续采集数据,因此无论是否有人在观察,都会始终带来运行时开销。OpenResty XRay 采取相反的思路:非侵入式,且仅按需采样。

传统常驻式 APM AgentOpenResty XRay
数据采集持续、始终开启按需,仅在用户发起分析时
目标进程代码注入 / 插桩非侵入,不修改代码
空闲时开销持续存在严格为零
采样时开销持续存在约 3.4% 吞吐、+0.16 毫秒延时

常见问题

OpenResty XRay 对生产环境的 Python 应用会带来多大的性能开销?

在分析进行期间,OpenResty XRay 使最大吞吐量下降约 3.4%(从约 2300 降至约 2220 每秒请求数),平均延时增加约 0.16 毫秒(从 4.32 毫秒到 4.48 毫秒)。当 Agent 已安装但未在采样时,吞吐量和延时均无变化;当其空闲时,性能开销严格为零。

在生产环境的 gunicorn 或 Django 应用上运行 OpenResty XRay 安全吗?

安全。OpenResty XRay 的 Agent 是非侵入式的——它不对目标进程做任何代码注入或修改,只在你主动发起分析时才低频采集数据。在对一个实时运行的 gunicorn 进程做 300 秒生产模式分析期间,系统过去一分钟的平均负载仅从 0.7 升至 0.84,目标进程 CPU 仅从 46.5% 升至约 48%,因此可以在生产环境中常态化部署。

OpenResty XRay 在未执行分析时会拖慢我的 Python 应用吗?

不会。Agent 只在用户发起的分析运行期间采集数据。当其已安装但处于空闲状态时,最大吞吐量和请求延时与完全没有安装 Agent 时完全一致——性能开销严格为零。

OpenResty XRay 的开销与传统常驻式 APM Agent 相比如何?

传统 APM Agent 向目标进程注入代码并持续运行,始终带来开销。OpenResty XRay 则按需、低频采样,因此空闲时开销为零,采样时也仅有约 3.4% 的吞吐影响。

OpenResty XRay 在分析 Python 进程时占用多少 CPU 和内存?

在对 gunicorn 进程采样期间,目标进程 CPU 占用从基线 46.5% 升至约 48%(约 1.5 个百分点),CPU 空闲率仅从 87.2% 降至 86.7%,可用内存稳定在约 2631 MB——变化约 1 MB。

关于 OpenResty XRay

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

关于作者

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

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

关注我们

如果您喜欢本文,欢迎关注我们 OpenResty Inc. 公司的博客网站 。也欢迎扫码关注我们的微信公众号:

我们的微信公众号

翻译

我们提供了英文版原文和中译版(本文)。我们也欢迎读者提供其他语言的翻译版本,只要是全文翻译不带省略,我们都将会考虑采用,非常感谢!