Geek Answers Handbook

AWS Elastic Bean Plume Deployment Fails with ENOMEM Error

Your AWAS Elastic Beanstalk deployment is failing: - Intermittent - For no real apparent reason

Step 1: Check The Obvious Log

/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

Step 2: Google for the corresponding snapshot log file ...

/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

Step 3: Obvious Parameters ...

  • Use a larger instance and it works ...

  • Do not fix, just try again

    • Deploy again and it works ...

    • Clone the environment and it works ...

    • Restore the environment and it works.

  • Left feeling dirty and wrong

+7
out-of-memory amazon-web-services elastic-beanstalk enomem
source share
2 answers

TL; DR

In your instances (t2.micro in my case) the memory runs out, because the instance promotion is parallelized.

Hacking Resolution: Specify instance SWAP space and try again

For one-time use, at the time of entry into the instance ...

 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

From / in more detail: How to add swap to an EC2 instance?

During deployment, we use the SWAP bit, but without fail

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

Actual Permissions

Large instances

  • While storage can be scaled through EBS, instances come with a fixed processor and RAM, the source of AWS .
  • The cost of money, and these are just instances of dev, where mem is just a problem during promotion

Automate swap preparation in ElasticBeanStalk

  • Maybe .ebextensions/
  • Open question: cloud formation style or hook when deploying / restarting?

Switch to "no server"

  • The promise of the Gateway + Lambda + Friends API is that we do not need to deal with this ish.
  • Are you tall enough for cloud microservices? Are they even suitable for your problem when something unstable / unfashionable such as SOA is enough.
  • Once you switch to cloud mode, returning to on-prem will be difficult, which is a requirement for some.

Use less bloated packages

  • Sometimes you are stuck in outdated
  • May be caused by necessary transitive or subdependent. Where does it end ... the decomposition of other people's libraries?

Description

A quick google shows that ENOMEM is an out-of-memory error. t2.micro instances have only 1 GB of RAM.

Rarely will we use this amount on dev; however, ElasticBeanstalk parallelizes parts of the assembly process through the generated workers. This means that during SETUP for large packets, out of memory may end and the operation will fail.

Using free -m , we can see ...

Get started (plenty of free memory)

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

Exit the memory at the next tick)

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

Process Deployment Aborted

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

Rarely will we use this amount on dev; however, ElasticBeanstalk parallelizes parts of the assembly process through the generated workers. This means that during SETUP for large packets, out of memory may end and the operation will fail.

This is exactly what happened to me! My node.js server worked fine on my dev ec2 t2-micro, but when I deployed the intermediate medium on an elastic beanstalk (also with t2-micro) this error appeared, change the eb instance to t2-small, the trick.

+1
source share

More articles:


All Articles