Stabilizing NodeJS container about RAM and SWAP

Having some NodeJS containers in production isn’t a start-and-forget due to CPU and memory management.

Let’s see how I managed my last NodeJS containers running on AWS EC2.

Adding a little of SWAP

On a fresh install, you don’t have SWAP.

I always create a little swapfile to avoid an EC2 being stuck due to being out of memory or your software being killed by the OOM killer.

Example to create a 4GB (128*32 = 4096) swapfile

sudo dd if=/dev/zero of=/swapfile bs=128M count=32
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo "/swapfile swap swap defaults 0 0" >> /etc/fstab

Tuning kernel to prioritize RAM

I always prefer to prioritize RAM instead of swapfile.

A little tuning to do it:

echo "vm.swappiness=1" | sudo tee -a /etc/sysctl.d/swap.conf
sudo sysctl -p /etc/sysctl.d/swap.conf

In my case, the value 1 works well but the best is to begin at 10 and lower it during your tests.

NodeJS: tuning V8 is the key

You can’t tune NodeJS itself, you need to tune V8… I’m not a NodeJS/JavaScript fan.

Before setting a special value, I had a latency of up to 3 seconds… just impossible to accept for a website and an API.
A lot of memory was used and a very unstable container that restarted too frequently.

max-old-space-size

It’s the solution, a simple value that you put in an environment variable.

NODE_OPTIONS="--max-old-space-size=1536"

The EC2 (t3a.medium) has 4GB of memory and 4GB of swap. After setting this environment variable, the latency is between 50 and 200 ms with UptimeRobot.

Just defining this amount (1.5GB), resolved latency and stability issues so reachability.

Now, I’ll already set this environment variable because it’s fixing a major issue.

Like vm.swappiness, you need to test and find the right value for your use case.