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.
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
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.
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.
It’s the solution, a simple value that you put in environement variable.
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.