AWS弹性Beanstalk部署失败，出现ENOMEM错误。

Question

AWS弹性Beanstalk部署失败，出现ENOMEM错误。

node.jsamazon-web-servicesout-of-memoryamazon-elastic-beanstalkenomem

16

您的AWS Elastic Beanstalk部署失败： - 间歇性 - 没有真正明显的原因

步骤1：检查明显的日志

/var/log/eb-activity.log

  Running npm install:  /opt/elasticbeanstalk/node-install/node-v6.10.0-linux-x64/bin/npm
  Setting npm config jobs to 1
  npm config jobs set to 1
  Running npm with --production flag
  Failed to run npm install. Snapshot logs for more details.
  Traceback (most recent call last):
    File "/opt/elasticbeanstalk/containerfiles/ebnode.py", line 695, in <module>
      main()
    File "/opt/elasticbeanstalk/containerfiles/ebnode.py", line 677, in main
      node_version_manager.run_npm_install(options.app_path)
    File "/opt/elasticbeanstalk/containerfiles/ebnode.py", line 136, in run_npm_install
      self.npm_install(bin_path, self.config_manager.get_container_config('app_staging_dir'))
    File "/opt/elasticbeanstalk/containerfiles/ebnode.py", line 180, in npm_install
      raise e
  subprocess.CalledProcessError: Command '['/opt/elasticbeanstalk/node-install/node-v6.10.0-linux-x64/bin/npm', '--production', 'install']' returned non-zero exit status 1 (ElasticBeanstalk::ExternalInvocationError)
caused by: + /opt/elasticbeanstalk/containerfiles/ebnode.py --action npm-install

第二步：在Google中查找适当的快照日志文件...

/var/log/nodejs/npm-debug.log

58089 verbose stack Error: spawn ENOMEM
58089 verbose stack     at exports._errnoException (util.js:1022:11)
58089 verbose stack     at ChildProcess.spawn (internal/child_process.js:313:11)
58089 verbose stack     at exports.spawn (child_process.js:380:9)
58089 verbose stack     at spawn (/opt/elasticbeanstalk/node-install/node-v6.10.0-linux-x64/lib/node_modules/npm/lib/utils/spawn.js:21:13)
58089 verbose stack     at runCmd_ (/opt/elasticbeanstalk/node-install/node-v6.10.0-linux-x64/lib/node_modules/npm/lib/utils/lifecycle.js:247:14)
58089 verbose stack     at /opt/elasticbeanstalk/node-install/node-v6.10.0-linux-x64/lib/node_modules/npm/lib/utils/lifecycle.js:211:7
58089 verbose stack     at _combinedTickCallback (internal/process/next_tick.js:67:7)
58089 verbose stack     at process._tickCallback (internal/process/next_tick.js:98:9)
58090 verbose cwd /tmp/deployment/application
58091 error Linux 4.4.44-39.55.amzn1.x86_64
58092 error argv "/opt/elasticbeanstalk/node-install/node-v6.10.0-linux-x64/bin/node" "/opt/elasticbeanstalk/node-install/node-v6.10.0-linux-x64/bin/npm" "--production" "install"
58093 error node v6.10.0
58094 error npm  v3.10.10
58095 error code ENOMEM
58096 error errno ENOMEM
58097 error syscall spawn
58098 error spawn ENOMEM

步骤三：明显的选项...

使用更大的实例，它可以正常工作...
不要修复，只需重试
- 再次部署，它可以正常工作...
- 克隆环境，它可以正常工作...
- 重新构建环境，它可以正常工作....
感觉很不舒服和不正确

- rmharrison

2个回答

2

很少情况下我们会在开发中使用这么大的内存；然而，ElasticBeanstalk将构建过程的某些部分并行化处理，通过生成的worker。这意味着，在安装过程中，对于较大的软件包，可能会耗尽内存，操作将失败。

这正是我的问题所在！我的node.js服务器在开发环境中的ec2 t2-micro上运行良好，但当我在elastic beanstalk上部署一个staging环境(同样使用t2-micro)时，出现了这个错误，将eb实例更改为t2-small即可解决问题。

- Ricardo Mutti

1

可能通过升级到npm v5版本来解决：“大型软件包的下载是通过磁盘流式传输的。现在，npm能够安装任何大小的软件包而不会耗尽内存。由于注册表限制，对其进行发布的支持仍在等待中。” - rmharrison

@rmharrison，也许你应该将你的评论发布为可能的答案？对我来说，这似乎是最简单的解决方案（尽管它会增加部署过程的额外延迟）。 - Jakub Holý

1

FYI：我已经升级到npm@5，但还需要在.npmrc中设置unsafe-perm=true以防止在node-gyp运行期间出现EACCES错误，请参见https://dev59.com/6FYO5IYBdhLWcg3wU_-M#46001517。 - Jakub Holý

1

@rmharrison 很遗憾，npm v5.4.2并没有起到帮助的作用。 - André Werlang

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- rmharrison · Accepted Answer

简介

如果您的实例（在我的情况下是t2.micro）因为实例的并行启动而耗尽了内存。

解决方法：在实例上提供SWAP空间并重试

如果只需要一次性操作，可以在登录到实例后执行以下步骤：

sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
sudo /sbin/mkswap /var/swap.1
sudo chmod 600 /var/swap.1
sudo /sbin/swapon /var/swap.1

源自 / 更多细节请参见：如何将交换空间添加到EC2实例？

在部署过程中我们使用了一些交换空间，但没有崩溃。

Mem:   1019116k total,   840880k used,   178236k free,    15064k buffers
Swap:  1048572k total,    12540k used,  1036032k free,    62440k cached

实际分辨率

更大的实例

尽管存储可以通过 EBS 扩展，但实例具有固定的 CPU 和 RAM，AWS 来源。
需要花费金钱，而这些仅仅是开发实例，在启动期间 mem 只是一个问题。

自动化 ElasticBeanStalk 中交换分配

可能是.ebextensions/
开放问题：云形成式或部署 / 重新启动时的挂钩？

跳上“无服务器”车

API Gateway + Lambda + Friends 的承诺是我们不应该处理这个 ish。
您是否足够高？云原生微服务是否适合您的问题，当类似 SOA 这样平凡 / 不时髦的东西就足以满足您的要求。
一旦开始云优先，返回本地将变得困难，这是某些人的要求。

使用较少臃肿的软件包

有时您会被遗留下来
可能是由必要的传递或子依赖性引起的。它会在何处结束...分解其他人的库吗？

解释

快速搜索显示， ENOMEM 是内存不足错误。t2.micro实例只有1GB RAM。

很少情况下我们会在开发中使用这么多内存；但是，ElasticBeanstalk 通过生成的工作进程并行化构建过程的某些部分。这意味着在设置期间，对于较大的软件包，可能会耗尽内存并且操作将失败。

使用 free -m 我们可以看到...

开始（有足够的可用内存）

             total       used       free     shared    buffers     cached
Mem:       1019116     609672     409444        144      45448     240064
-/+ buffers/cache:     324160     694956
Swap:            0          0          0

在下一个时钟周期内内存耗尽了

Mem:       1019116     947232      71884        144      11544      81280
-/+ buffers/cache:     854408     164708
Swap:            0          0          0

部署过程中止

             total       used       free     shared    buffers     cached
Mem:       1019116     411892     607224        144      13000      95460
-/+ buffers/cache:     303432     715684
Swap:            0          0          0