Swap Space and OOM Kills: Surviving Heavy Processing on a Small VPS

This blog has referenced this fix three times already — in the MapLibre tile setup, the OSRM routing guide, and the VPS comparison — because it’s the single most common way a budget VPS setup breaks, and the failure mode is uniquely bad: no error message, no stack trace, just a process that silently vanishes mid-job.

This is the dedicated writeup on why it happens and the actual fix.

What’s actually happening

Linux has a component called the OOM killer (Out-Of-Memory killer) that activates when the system is critically low on memory. Its job is to pick a process and kill it to free up RAM before the whole machine locks up. It doesn’t ask permission, it doesn’t log a friendly message in your application’s output, and it doesn’t care that the process it just killed was three hours into a job you needed to finish.

On a budget VPS (1-2GB RAM is common at the entry tier from providers like Hetzner or Contabo), this happens far more often than people expect — not because the VPS is broken, but because certain workloads spike memory usage well beyond what the steady-state application needs:

osrm-extract and osrm-partition building a routing graph
Tile generation tools processing large OpenStreetMap extracts
npm install or build steps on projects with a large dependency tree
Image or video processing libraries handling large files
Any batch job that loads more data into memory than it streams

Each of these is a short-lived spike, not a sustained need — which is exactly what swap space is good at absorbing.

The actual fix

fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

Line by line:

fallocate -l 4G /swapfile — reserves a 4GB file to use as swap. Adjust the size to roughly match or exceed your RAM for most workloads; heavier jobs (like full-planet OSM processing) may need more.
chmod 600 /swapfile — restricts the file to root only, since swap can contain sensitive memory contents.
mkswap /swapfile — formats the file as swap space.
swapon /swapfile — activates it immediately.

To make it persist across reboots, add it to /etc/fstab:

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

What swap actually buys you

Be precise about this, because it’s a common source of confusion: swap does not make your VPS faster. Disk (even fast NVMe) is orders of magnitude slower than RAM, and a process actively swapping will run noticeably slower than one with enough real memory. What swap buys you is completion instead of termination — a job that would otherwise get OOM-killed at 80% done now finishes, just more slowly during the memory-pressured part.

For the one-time or infrequent heavy jobs common in self-hosted infra (preprocessing a routing graph once, generating tiles for a new region, running a big migration script) this trade is almost always worth it: a slower job that finishes beats a fast job that dies with no error and has to be restarted from scratch, possibly repeatedly, until you figure out why.

Tuning swappiness

Linux’s swappiness setting controls how aggressively the kernel moves memory to swap even when RAM isn’t fully exhausted. The default (60 on most distros) is tuned for desktop use, not for a server running a specific, known workload.

# Check current value
cat /proc/sys/vm/swappiness

# Lower it so the kernel prefers RAM until it's genuinely needed
sudo sysctl vm.swappiness=10

# Make it persistent
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

A lower value (10 is a common recommendation for servers) tells the kernel to hold off on swapping until memory pressure is real, rather than proactively swapping out infrequently-used pages during normal operation. This keeps your steady-state application responsive, while still leaving swap available as a safety net for the occasional heavy job.

Monitoring so you’re not surprised

Don’t wait for a job to die to find out you’re memory-constrained. A quick check before starting anything heavy:

free -h

And to watch it live during a heavy job, in a separate terminal:

watch -n 2 free -h

If you see swap usage climbing steadily and staying high (not just spiking briefly), that’s a sign the job’s real memory need is significantly larger than your RAM, and you might be better off temporarily resizing the VPS for that one job rather than relying on swap alone — most providers, including the ones compared here, let you scale up temporarily and back down without much friction.

The pattern worth remembering

Every silent-failure bug on this blog shares a shape: something fails without telling you clearly why. OOM kills are the server-side version of that pattern — same as the silent glyph failures on the client side. The fix here is cheap (a few minutes of setup) and the failure it prevents is expensive (a job that dies with zero explanation, often hours into a run). Set up swap before you need it, not after you’ve already lost a job to it.