Lambda持续负载下内存持续攀升直至崩溃问题求助

问题背景 #

AWS Lambda函数基于konva.js和node-canvas（通过Layer部署）按需生成图像，前端接入APIGWv2 HTTP端点，部署在VPC私有子网搭配NAT网关，CDK管理资源。持续负载下，无论并发量高低，每次调用后内存占用持续攀升，直至100%触发运行时终止；扩容内存（1GB→5GB）仅能延长崩溃前的调用次数（5GB约170次），无法解决根本问题。

函数执行流程：

1. 解析请求URL
2. 检查目标图像是否存在于S3，存在则直接返回
3. 不存在则执行：
   • 从MySQL Aurora获取数据（数据库连接为处理器外全局变量）
   • 从S3下载字体至/tmp/fonts（仅首次调用下载，磁盘占用无增长）
   • 下载URL指定的关联图像，结合数据生成目标图像
   • 上传生成的图像至S3
   • 以Buffer.toString('base64')格式返回结果

补充信息：

• TypeScript编写
• Lambda Insights监测显示每次调用后内存占比逐步上升
• 无触发器，排除无限循环可能

核心排查与修复措施 #

1. 手动清理konva/canvas实例（关键修复） #

node-canvas的底层C++绑定易因未手动销毁导致内存泄漏，Lambda容器复用会放大这个问题。每次图像生成完成后，必须显式清理所有相关实例：

// 生成图像后立即执行清理逻辑
stage.destroy(); // 销毁konva Stage
layer.destroy(); // 销毁konva Layer
// 清理canvas上下文
const ctx = canvas.getContext('2d');
ctx.clearRect(0, 0, canvas.width, canvas.height);
// 解除引用并销毁canvas
canvas.remove();
canvas = null;

确保konva的destroy()递归清理所有子元素，避免残留对象引用。

2. 释放图像Buffer资源 #

生成和下载的图像Buffer需在使用后手动解除引用，防止内存滞留：

// 下载的关联图像Buffer使用完毕后
imageBuffer = null;
// 生成的图像Buffer上传S3并返回后
generatedImageBuffer = null;

3. 避免全局变量累积资源 #

所有图像生成相关的变量（canvas实例、图像数据、临时对象）必须定义在函数处理逻辑内部，而非处理器外的全局作用域。全局变量会在容器复用时持续存在，导致资源不断累积。

4. 优化数据库连接管理 #

虽然数据库连接设为全局变量，但需检查是否存在泄漏：

• 每次查询后确保释放结果集，关闭未使用的游标
• 定期检查连接状态，若连接异常则主动销毁并重建，避免无效连接占用内存

5. 强制垃圾回收（应急方案） #

在函数调用结束前，手动触发Node.js垃圾回收（需Lambda运行时添加--expose-gc启动参数）：

if (global.gc) {
  global.gc();
}

注意：仅作为临时应急手段，长期依赖会掩盖根本问题，需配合资源清理使用。

6. 调整容器复用策略 #

通过APIGW节流或Lambda Function URL设置，控制单个容器的调用次数；或使用Provisioned Concurrency搭配CloudWatch Events定期重启容器，避免单个容器累积过多泄漏资源。

7. 验证node-canvas版本兼容性 #

确认使用的node-canvas版本与Lambda运行时（如Node.js 18.x/20.x）兼容，升级至最新稳定版修复已知内存泄漏问题。

验证方法 #

• 用Lambda Insights持续监测内存变化，修复后观察每次调用后内存是否回落至稳定区间
• 本地测试时使用--inspect参数启动函数，结合Chrome DevTools Memory面板分析内存快照，定位未释放的对象

内容的提问来源于stack exchange，提问作者jacobm