B 站这两天发表了一篇总结去年那场大事故的文章：https://mp.weixin.qq.com/s/nGtC5lBX_Iaj57HIdXq3Qg 当时我们 OpenResty Inc 公司团队帮助 B 站在线上快速定位了导致 CPU 100% 的 Lua 代码路径。B 站是我们的 OpenResty XRay 产品的商业客户。
文中提到的 Lua 火焰图就是 OpenResty XRay 在 B 站生产服务器上采样有问题的 OpenResty 服务进程得到的。生成火焰图也就花了几分钟的时间，因为使用 100% 非侵入的动态追踪技术，并不需要对 B 站的进程进行任何修改。根据 Lua 火焰图最终确认根源问题是 B 站的业务往 Redis 服务器里写入了个字符串类型的权重 0 值的坏数据（即 "0"），而 Lua 代码期望的是数值类型的权重值，从而导致了无限递归和无限循环。文中提到的 LuaJIT 的 JIT 编译器的问题其实并不存在；JIT 编译器在这里并没有 bug。
感谢 Bilibili 对我们公司产品和技术的信任和支持！当然，B 站线上系统使用的也是我们的开源 OpenResty 软件。OpenResty XRay 产品主页：https://openresty.com.cn/cn/xray/
文中提到的 Lua 火焰图就是 OpenResty XRay 在 B 站生产服务器上采样有问题的 OpenResty 服务进程得到的。生成火焰图也就花了几分钟的时间，因为使用 100% 非侵入的动态追踪技术，并不需要对 B 站的进程进行任何修改。根据 Lua 火焰图最终确认根源问题是 B 站的业务往 Redis 服务器里写入了个字符串类型的权重 0 值的坏数据（即 "0"），而 Lua 代码期望的是数值类型的权重值，从而导致了无限递归和无限循环。文中提到的 LuaJIT 的 JIT 编译器的问题其实并不存在；JIT 编译器在这里并没有 bug。
感谢 Bilibili 对我们公司产品和技术的信任和支持！当然，B 站线上系统使用的也是我们的开源 OpenResty 软件。OpenResty XRay 产品主页：https://openresty.com.cn/cn/xray/
