How to handle high memory usage and optimize resource allocation for custom server setups on a VPS?

Hi there,

For finding memory leaks in Node.js specifically, start with:

node --inspect server.js

Then connect Chrome DevTools and take heap snapshots over time. If memory grows without coming back down between requests, you have a leak. Common culprits are event listeners not being removed, global arrays accumulating data, or closures holding references longer than expected.

For system-level memory tracking beyond htop, install the DigitalOcean monitoring agent if you have not already:

curl -sSL https://repos.insights.digitalocean.com/install.sh | sudo bash

This gives you memory graphs over time in the control panel which is much more useful than watching htop in real time. Set an alert for memory above 85% so you get notified before swap kicks in.

For long-term profiling, pm2 monit gives you per-process memory over time, and pm2 logs will show you if processes are restarting due to OOM. If a specific worker keeps climbing and restarting, that is your leak.

A quick win before diving deep into profiling: add --max-old-space-size=512 to your Node startup command to cap the heap and force earlier garbage collection. It will not fix a leak but it prevents one process from consuming all available RAM before you have time to diagnose it.

Heya,

htop and ps report RSS, which double-counts shared libraries when multiple processes use them, so it can overstate what any one process is actually responsible for and make it harder to tell whether the leak is in Node or in one of your background scripts. smem reports PSS instead, memory proportionally divided across the processes actually sharing it, which gives you a real per-process picture:

sudo apt install smem
smem -tk

Sort that by the last column and you’ll see which process, Node, a background script, or something else entirely, is actually accounting for the growth.

Whether swap is a symptom or a separate problem. Swap kicking in during traffic peaks doesn’t necessarily mean RAM is fully exhausted, vm.swappiness (default 60) controls how eagerly the kernel swaps out inactive pages before RAM pressure is severe. Check dmesg for actual OOM killer activity first to see if anything’s being killed outright:

dmesg -T | grep -i "out of memory"

If nothing’s showing up there, the swap usage may just be swappiness being aggressive rather than a leak forcing it. Lowering swappiness to somewhere in the 1 to 10 range is a common adjustment for a server workload like this, though it does raise OOM-kill risk if you’re actually short on RAM rather than just seeing early swapping, so confirm which situation you’re in before changing it.

Regards