排查 Node.js 服务内存泄漏，没想到竟是它？

vlambda
2020-11-20

排查 Node.js 服务内存泄漏，没想到竟是它？

背景

团队最近将两个项目迁移至 degg 2.0 中，两个项目均出现比较严重的内存泄漏问题，此处以本人维护的埋点服务为例进行排查。服务上线后内存增长如下图，其中红框为 degg 2.0 线上运行的时间窗口，在短短 36 小时内，内存已经增长到 50%，而平时内存稳定在 20%-30%，可知十之八九出现了内存泄漏。

排查思路

由于两个接入 degg 2.0 的服务均出现内存泄漏问题，因此初步将排查范围锁定在 degg 2.0 引入或重写的基础组件上，重点怀疑对象为 nodex-logger 组件；同时为了排查内存泄漏，我们需要获取服务运行进程的堆快照（heapsnapshot），获取方式可参看文章 hyj1991：Node 案发现场揭秘 —— 快速定位线上内存泄漏https://zhuanlan.zhihu.com/p/36340263 。

排查过程

一、获取堆快照

使用 alinode 获取堆快照，服务启动后，使用小流量预热一两分钟便记录第1份堆快照（2020-4-16-16:52），接着设置 qps 为 125 对服务进行施压，经过大约一个小时（2020-4-16-15:46）获取第2份堆快照。

使用 Chrome dev 工具载入两份堆快照，如下图所示，发现服务仅短短运行一小时，其堆快照文件就增大了 45MB，而初始大小也不过 39.7MB；我们按 Retained Size 列进行排序，很快就发现了一个『嫌疑犯』，即 generator ；该项占用了 55% 的大小，同时 Shallow Size 却为 0%，一项一项地展开，锁定到了图中高亮的这行，但是继续展开却提示 0%，线索突然断了。

盯着 generator 进入思考，我的服务代码并没有 generator 语法，为什么会出现 generator 对象的内存泄漏呢？此时我把注意力转到 node_modules 目录中，由于最近一直在优化 nodex-kafka 组件，有时直接在 node_modules 目录中修改该组件的代码进行调试，因此几乎每个文件头部都有的一段代码引起了我的注意：

这个代码是 typescript 源码编译后的产出，由于代码使用了 async/await 语法，因此都编译成 __awaiter 的形式，在源码中使用 async 函数的地方，在编译后都使用 __awaiter 进行包裹：

同时一个关于 generator 内存泄漏的 #30753 generator functions - memory leak https://github.com/nodejs/node/issues/30753 也引起了我的注意，该 issue 遇到的问题无论从 Node.js 的版本和内存泄漏的表现都和我遇到的问题十分相似。所以我在工程的 node_modules 中搜索所有 __awaiter 字符串，发现了 3 个模块编译出了上述代码，分别是：

nodex-logger
nodex-kafka
nodex-apollo

由于模块的 tsconfig.json 的 target 字段将目标产出为 es6 ，因此才会使用 g enerator 去模拟 async/await 语法，但是从 Node.js v8.10.0 开始已经 100% 支持了 ES2017 的所有特性，所以本不该编译 async/await 语法，此处遂将这 3 个模块的目标产出配置改为 es2017 ，这样 tsc 就不会编译 async/await 语法。