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 fresh install, you don’t have SWAP.

I always create a little swapfile to avoid an EC2 stuck due to out of memory or your software 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… Really, I’m not a NodeJS/JavaScript fan.

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

max-old-space-size

It’s the solution, a simple value that you put in environement 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, I’ve a latency between 50 and 200 ms with UptimeRobot.

Just defining this amount (1.5GB), resolved latency and stability issue 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.