AL2 Elastic Beanstalk上Node.js应用JavaScript堆内存不足问题解决

从日志能明确核心问题是JavaScript堆内存不足（FATAL ERROR: Reached heap limit Allocation failed），结合t2.micro实例仅1GB内存的限制，以及批量删除操作的场景，可按以下步骤解决：

1. 调整Node.js堆内存上限 #

Node.js默认堆内存上限（旧空间）约为512MB（32位）或1GB（64位），但t2.micro总内存仅1GB，需合理分配堆内存：

• 修改项目package.json的启动脚本：

  "scripts": {
    "start": "node --max-old-space-size=512 app.js"
  }
  

• 或通过Elastic Beanstalk配置文件（.ebextensions/node.config）全局设置：

  option_settings:
    aws:elasticbeanstalk:container:nodejs:
      NodeCommand: "node --max-old-space-size=512 app.js"
  

  注意：堆内存上限不要超过实例总内存的70%，避免挤占系统内存导致其他问题。

2. 优化批量删除逻辑 #

批量操作是内存暴涨的直接诱因，需从代码层面优化：

• 避免全量加载数据：如果使用数据库（如MongoDB），直接调用原生批量删除方法（如deleteMany），不要先查询所有待删文档再逐个删除，减少内存占用。
• 分批处理删除任务：将大批次删除拆分为多个小批次（比如每次删50条），用异步循环执行，每批执行完成后释放内存，避免一次性占用大量堆空间。
• 排查内存泄漏：检查删除操作中是否存在未释放的变量、未移除的事件监听器，或者长期缓存的无效数据。可使用node --inspect启动应用，通过Chrome DevTools的内存面板分析快照，定位内存泄漏点。

3. 升级EC2实例规格 #

t2.micro的1GB内存对于有批量操作的Node.js应用来说过于紧张，直接升级到t2.small（2GB内存）或更高规格的实例，能从硬件层面解决内存不足问题，是最快速的临时解决方案。

4. 优化Elastic Beanstalk健康检查与重启策略 #

服务器无响应10分钟，说明EB的故障恢复机制不够及时：

• 在EB控制台的「配置」->「实例」->「健康检查」中，设置合理的健康检查路径（比如一个轻量的/health接口），缩短健康检查间隔和超时时间。
• 配置自动重启策略，当实例健康状态异常时，EB会快速替换故障实例，大幅缩短无响应时间。

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