← 返回

UDB + OpenResty XRay：解锁 OpenResty 应用性能之谜

章亦春发布于 Jul 11, 2025 更新于 May 23, 2025

用时 7 分钟

阅读次数

在开发和维护 OpenResty 应用时，您可能经常面临这些令人头疼的情况：Lua 代码中的错误难以追踪；性能瓶颈隐藏在复杂的调用栈中；生产环境中的偶发性问题几乎无法在开发环境重现；当应用崩溃时，只留下片段错误信息，无法了解完整上下文。传统调试工具常常让我们感到束手无策，一旦错过关键时机，就只能从头来过，既低效又容易遗漏问题本质。

通过 UDB（Undo Debugger）与 OpenResty XRay 的强大组合，我们终于拥有了在程序执行历史中自由穿梭的能力，就像拥有了调试世界的“时光机”。无论是追踪内存分配模式、分析特定请求的执行路径，还是定位导致崩溃的代码片段，这种革命性的调试方法都能让您看到传统工具无法展现的全景视图。让我们通过一个 OpenResty 应用的实际案例，一起探索这种突破性技术如何改变我们解决问题的方式。

立即申请 OpenResty XRay 试用

OpenResty XRay 如何协同 UDB 增效

UDB 如何揭开 OpenResty 应用中 Lua 代码的神秘面纱

UDB 作为 Undo 公司推出的时间旅行调试工具，它为开发团队提供了前所未有的可视化能力：

时间维度的探索：告别传统“重现 - 修复 - 验证”的繁琐循环。您在程序执行轨迹上自由穿行，捕捉每一个关键瞬间。
洞察问题本质：通过智能断点和监视机制，直击异常行为的触发条件，将模糊的错误报告转化为清晰的问题画像。
透视运行状态：实时剖析 Lua 变量和内存结构，揭示 OpenResty 应用内部运作机制，快速识别异常模式。
Lua 生态完美适配：UDB 与 OpenResty 环境无缝集成，为 Lua 开发者提供了专业级调试体验，支持对复杂应用进行立体化分析。

与 OpenResty XRay 强强联合，打造无死角的调试体系

OpenResty XRay 能够自动分析 OpenResty 应用中的 Lua 代码运行时的行为，精确定位各类技术痛点。当它与 UDB 联手时，将为您带来：

全景式问题诊断：从请求处理到底层执行的立体化视图
Lua 代码性能剖析：直观展现热点函数和资源消耗
零干扰分析体验：保持应用原有行为的同时获取深度洞察
实操导向的优化指南：基于真实负载提供针对性改进方案

通过 UDB 与 OpenResty XRay 的协同作用，开发团队能够迅速突破技术瓶颈，将复杂的故障排查转化为清晰的解决路径。这一组合不仅能够加速问题解决流程，更能从根本上提升 OpenResty 应用的质量和稳定性，为业务持续创新提供坚实技术保障。

实战：使用 UDB 与 OpenResty XRay 分析 OpenResty 应用的 Lua 代码调用栈

下面我们通过一个实际案例，演示如何使用 UDB 精确分析 OpenResty 的 Lua 应用的调用栈：

步骤一：录制应用执行轨迹并重放录制样本

首先使用 UDB 的 Live Record 工具录制 OpenResty 应用的执行过程：

使用 Live Record 工具录制一个正在运行的 OpenResty 应用样本。 1.1 在 OpenResty XRay 的控制台选择 现场录制。 1.2 选择目标应用和目标进程，单击 开始录制。 1.3 单击 生成录制文件 的图标生成一个录制文件。 1.4 生成解释后单击 停止录制 结束录制过程。 1.5 下载录制文件进行分析。
在 OpenResty XRay 上编译相关的工具，并将编译后的工具下载到本地。
使用 UDB 工具加载录制样本，并设置调试环境：

udb --sessions=no -ex "set pagination off" -ex "set python print-stack full" openresty.rec

步骤二：分析录制样本

本文以分析 Lua 内存分配为例来介绍 udb 中查看 OpenResty Lua 的执行调用栈。我们将断点打在 lua_alloc_realloc 函数。

0% 51> b lj_alloc_realloc
Breakpoint 1 at 0x55560961bca0: file lj_alloc.c, line 1520.
0% 51> c
Continuing.
Thread 1 "nginx" hit Breakpoint 1, lj_alloc_realloc (msp=0x7f5657a9d010, ptr=ptr@entry=0x7f549be49108, nsize=40) at lj_alloc.c:1520
1520    lj_alloc.c: No such file or directory.

步骤三：分析底层 C 调用栈

使用 bt 命令查看当前的 C 层调用栈：

0% 853> bt
#0  lj_alloc_realloc (msp=0x7f5657a9d010, ptr=ptr@entry=0x7f549be49108, nsize=40) at lj_alloc.c:1520
#1  0x000055560961c053 in lj_alloc_f (msp=<optimized out>, ptr=0x7f549be49108, osize=<optimized out>, nsize=<optimized out>) at lj_alloc.c:1582
#2  0x0000555609625270 in lj_mem_realloc (L=0x7f54b4bd1628, p=p@entry=0x7f549be49108, osz=osz@entry=24, nsz=40) at lj_gc.c:883
#3  0x0000555609626e3d in lj_tab_resize (L=0x7f54b4bd1628, t=0x7f54b5065cf0, asize=5, hbits=0) at lj_tab.c:256
#4  0x0000555609626986 in rehashtab (ek=<optimized out>, t=<optimized out>, L=<optimized out>) at lj_tab.c:375
#5  lj_tab_newkey (L=0x7f54b4bd1628, t=0x7f54b5065cf0, key=0x7f549ea60380) at lj_tab.c:453
#6  0x00005556469832df in ?? ()
#7  0x00007ffe8a54b9f0 in ?? ()
#8  0x000055560957e8dd in ngx_lua_conf_ffi_get (keys=<optimized out>, keys_len=0x7f5656ab5dd0, values=0x7f5657a80c78 "x\003\250WV\177", values_len=0x7f5656ab5e70, 
    db=<optimized out>) at ../lua-resty-config-1.0.6/src/ngx_lua_config_module.c:389
#9  0x0000001200000000 in ?? ()
#10 0x00007f549bc917a8 in ?? ()
#11 0x00007f549bc917b6 in ?? ()
#12 0x00007f549cf27568 in ?? ()
#13 0x00007f54b547d508 in ?? ()
#14 0x00007f54b6825e30 in ?? ()
#15 0x00007f549eb0d1a0 in ?? ()
#16 0x00007f549cf275a8 in ?? ()

从 C 调用栈可以看到系统底层的 lj_alloc_realloc 函数调用被触发，但这仅显示了 C 语言层面的信息，无法直接看到 Lua 业务代码的完整调用路径。

步骤四：分析 Lua 代码的完整调用栈

加载 OpenResty XRay 提供的 Lua 调用栈分析工具：

4% 7,955> source lj-lua-on-cpu.y.py

使用 lj_lua_on_cpu 命令获取完整的 Lua 调用栈：

0% 853> lj_lua_on_cpu 
C:lj_alloc_realloc
trace#6786:http-runtime-20181201.lua:4028
@1:890
helper_5
@1:1538
[builtin#xpcall]
xpcall
@1:1424
run_access_phase
@edge.lua:187
access
@access_by_lua(nginx.conf:766):2

通过这个完整的 Lua 调用栈，我们可以清晰地看到从业务代码正在运行 access_by_lua 阶段的代码。当前正在执行的是 trace 6786 这个即时编译的代码，这也就是为什么前面的 bt 命令获取的 C 调用栈到 ngx_lua_conf_ffi_get 这个函数后就没有正确展开了。

时间旅行调试的优势

UDB 的时间旅行调试能力是其最强大的特性之一。通过这一功能，我们可以在录制的执行轨迹中自由地前进或回溯，精确定位到不同的内存分配操作时间点，并全面分析每次分配操作的完整上下文和调用栈。

为了验证这一点，我们可以继续执行程序，捕获下一个 lj_alloc_realloc 调用：

0% 51> c
Continuing.
Thread 1 "nginx" hit Breakpoint 1, lj_alloc_realloc (msp=0x7f5657a9d010, ptr=ptr@entry=0x7f549be49108, nsize=40) at lj_alloc.c:1520
1520    lj_alloc.c: No such file or directory.
1% 849,555> lj_lua_on_cpu 
C:lj_alloc_realloc
trace#177:common-runtime-20181201.lua:393
@common-runtime-20181201.lua:383
bit32_to_strtbl
@common-runtime-20181201.lua:435
inet_to_bitstr
@1:1459
[builtin#xpcall]
xpcall
@1:1424
run_rewrite_phase
@edge.lua:187
access
@access_by_lua(nginx.conf:766):2

通过对比两次捕获的调用栈，我们可以一目了然地发现关键差异：

第一次内存分配来自 trace 6786
第二次内存分配则来自 trace 177

这种精准定位能力不仅仅适用于内存分配分析，它更是解决复杂问题的利器。无论是分析特定 URI 请求的 Lua 代码执行路径，还是追踪导致进程崩溃的 Lua 代码片段，这种方法都能游刃有余地应对。

传统的 GDB coredump 分析就像是事故现场的一张照片，只能看到最终结果；而 UDB 则像是一部高清回放的视频，让您能够观察事故发生前的每一个细节。即使原始进程早已不在运行，您依然可以在完整的程序执行历史中如鱼得水，精确检视任意时间点的程序状态与行为细节，真正实现了“时光倒流”式的全方位调试体验。

总结

通过本文的实践探索，我们展示了 UDB 的时间旅行调试功能与 OpenResty XRay 分析工具的完美结合如何深入剖析 OpenResty 应用中 Lua 代码的执行过程。这种组合提供了几个显著优势：

全面的执行上下文：不仅能看到底层 C 调用栈，还能精确追踪 Lua 业务代码的完整调用路径，包括即时编译（JIT）后的代码执行情况。
时间维度的调试能力：UDB 允许在程序执行历史中自由穿梭，无需重启应用即可分析不同时间点的程序状态，这对排查间歇性问题和复杂场景尤为重要。
深度性能分析：结合 OpenResty XRay 的分析工具，可以精确定位性能瓶颈，如内存分配模式、热点函数等。
事后分析能力：即使在原始进程已经终止的情况下，依然可以通过录制样本进行全面分析，这远超传统 coredump 分析只能提供崩溃瞬间静态快照的局限。

对于追求卓越的软件开发者和运维专家来说，掌握这种前沿调试技术不再是可选项，而是在竞争激烈的技术世界中保持领先的必备能力。通过 UDB 和 OpenResty XRay 的强大组合，您能够以前所未有的精确度理解应用行为，从而构建更加稳定、高性能的应用系统。

立即申请 OpenResty XRay 试用

关于 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 多个开源软件库。