升级Node.js至18.15.0后，AWS Lambda中npm install报Too Many Open Files错误

问题背景 #

将Node.js版本从16.8.0升级至18.15.0后，AWS Lambda函数在挂载的EFS卷上执行npm install时触发Too Many Open Files错误，此前16.8.0版本下流程正常。当前场景为Lambda同步GitHub仓库源码后执行依赖安装，相同操作在ECS Fargate实例上可正常完成，推测是Lambda环境限制+新版npm更高的文件句柄消耗导致，EFS挂载可能加剧了该问题。目前考虑过分批安装依赖，但不确定可行性，临时方案是触发EC2实例执行安装。

原因分析 #

• npm版本差异：Node.js 18.x配套的npm（默认v8.19.2）相比16.x的npm（默认v8.1.3），优化了依赖安装的并发逻辑，会同时打开更多文件句柄以提升安装速度，而Lambda默认文件句柄软限制仅为1024，硬限制4096，远低于EC2/Fargate环境。
• EFS挂载影响：Lambda中挂载EFS时，文件句柄会占用Lambda进程的配额，EFS的远程文件系统特性导致句柄释放速度慢于本地磁盘，进一步加速了句柄耗尽。

可行解决方案 #

1. 降低npm安装并发数 #

通过npm参数或配置文件限制并发操作，减少文件句柄占用：

• 执行安装时添加参数：

  npm install --maxsockets 1 --fetch-retries 0
  

• 或在项目根目录创建.npmrc文件，持久化配置：

  maxsockets=1
  fetch-retries=0
  

  该配置会限制npm的网络请求并发数，同时关闭重试逻辑，减少重复的文件句柄占用。

2. 拆分依赖分批安装 #

将package.json中的依赖拆分为多组，分批执行安装，降低单次操作的文件句柄消耗：

• 先安装核心生产依赖：

  npm install express lodash # 替换为你的核心依赖包
  

• 再安装剩余依赖：

  npm install
  

3. 预构建依赖包（推荐） #

避免在Lambda运行时执行npm install，提前在CI/CD流程或本地环境完成依赖构建：

• 使用npm ci替代npm install，确保依赖版本一致。
• 将包含node_modules的代码包上传至Lambda或同步到EFS，直接使用预构建的依赖。这是最符合Lambda运行环境特性的方案，彻底规避句柄限制问题。

4. 提升Lambda资源配置 #

Lambda的内存配置与CPU、网络带宽及文件句柄配额正相关，提升内存至1GB以上，部分场景下文件句柄软限制会提升至2048，缓解句柄不足问题。

5. 优化EFS配置 #

• 确保EFS使用generalPurpose性能模式，maxIO模式适合高并发读写场景，但会占用更多文件句柄；
• 检查EFS挂载的transit encryption设置，虽加密对句柄影响较小，但可确保配置最优。

临时方案优化 #

若以上方案无法快速落地，触发ECS Fargate任务执行npm install并同步至EFS，相比EC2更节省成本，且无需维护EC2实例，管理更高效。

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