VPS Memory Tuning: Swap, OOM Killer, and vm.* Settings

On a 1–2 GB RAM VPS, memory is the resource you run out of first — and how the kernel reacts when you do determines whether your site slows down or your process gets killed mid-request. The default Linux memory settings are tuned for workstations with plenty of RAM, not for small virtual servers under constant load. This guide covers the three levers that actually matter: swap sizing and vm.swappiness, the OOM killer’s decision process, and the vm.* kernel parameters that control how aggressively the kernel reclaims memory. If you’re still shopping for hardware, see how RAM sizing differs across VPS plans before committing to a 1 GB instance.

Read free -h Like a Sysadmin, Not a Beginner

Before tuning anything, you need to know which numbers matter. Here’s typical output on a 2 GB VPS:

               total        used        free      shared  buff/cache   available
Mem:           1.9Gi       1.1Gi       145Mi       123Mi       695Mi       612Mi
Swap:          2.0Gi        80Mi       1.9Gi

The available column is the only one that reflects real spare capacity — memory the kernel can reclaim from cache the moment an application asks for it. A low free value is normal and healthy on Linux; buff/cache is not wasted RAM, it’s the page cache accelerating your disk I/O. If available is consistently close to zero and swap usage keeps climbing, you have a genuine memory shortage and need the tuning below — or a bigger plan.

Right-Size Swap for Your RAM

Swap is disk pretending to be RAM — roughly 1000x slower — but on a small VPS it’s the difference between a slow response and a crashed process. Sensible starting points:

• 1 GB RAM: 2 GB swap (2x RAM).
• 2–4 GB RAM: swap equal to RAM size.
• 4 GB+ RAM: 2 GB swap is usually enough; rely on it only as a safety net.

Create it with fallocate (fast on modern filesystems) and mount it permanently:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Verify
swapon --show
free -h

Tune vm.swappiness: When the Kernel Decides to Swap

vm.swappiness (default 60) controls how eagerly the kernel pushes anonymous pages to swap versus reclaiming page cache. The higher the value, the sooner the kernel swaps under pressure. On a server, you want the kernel to prefer dropping cache — which is free to re-read — over swapping application memory.

# 1-2 GB RAM VPS: start at 10
# 4+ GB RAM: can go as low as 1
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-memory.conf
sudo sysctl --system
cat /proc/sys/vm/swappiness

Set it too low (0) and the kernel will starve the page cache, causing heavy disk reads under load; set it too high and your application threads block on disk I/O while idle pages get swapped out. Ten is a solid default for small VPS instances; adjust after observing si/so columns in vmstat 5 — sustained swap-in activity means you’re too aggressive.

Keep Metadata in RAM with vm.vfs_cache_pressure

Linux caches directory entries and inodes (the VFS cache) to avoid repeated disk metadata lookups. The default vm.vfs_cache_pressure=100 lets the kernel reclaim this cache as aggressively as page cache. On a web server hammered with file stat() calls — think PHP-FPM or Node.js serving many small files — dropping that cache forces expensive disk seeks. Lowering the value to 50 makes the kernel retain inode/dentry caches twice as long:

echo 'vm.vfs_cache_pressure=50' | sudo tee -a /etc/sysctl.d/99-memory.conf
sudo sysctl --system

Don’t go below ~40 on a tiny VPS: metadata cache still consumes RAM, and on a 1 GB instance you can trade one bottleneck for another.

Control the OOM Killer Instead of Fighting It

When memory is exhausted, the kernel’s OOM killer picks a process to terminate using a heuristic oom_score — and its picks are often surprising (it has a known bias against long-running root daemons). You can steer it deterministically:

# Protect your database: lower its score so it's never the first choice
sudo systemctl set-property postgresql.service OOMScoreAdjust=-500

# Sacrifice a batch job first: raise its score
sudo systemctl set-property celery-worker.service OOMScoreAdjust=500

# Inspect current scores (higher = more likely to be killed)
for p in $(pgrep -f postgres); do
  echo "PID $p: $(cat /proc/$p/oom_score)";
done

For interactive protection, install earlyoom — it watches memory pressure and kills the largest consumer before the kernel’s OOM killer panics the whole box:

sudo apt install earlyoom -y
sudo systemctl enable --now earlyoom
# It fires at 90% RAM / 10% swap by default; tune with -r and -m flags
sudo systemctl status earlyoom

Verify the Tuning Under Real Pressure

Load-test your tuned memory settings with a controlled allocation bomb (in a disposable container or on a test instance — it will freeze your shell briefly):

# Allocate 150% of RAM in 100 MB chunks
python3 -c "
import time
buf = []
for i in range(int(__import__('os').sysconf(2) * 1.5) // (100*1024*1024) + 1):
    buf.append(bytearray(100*1024*1024)); time.sleep(0.2)
"
# In a second terminal, watch:
vmstat 1
dmesg -T | tail -20   # OOM / earlyoom messages land here

You want to see the kernel reclaim cache, then swap gradually, and finally earlyoom (or the OOM killer) terminating the allocator — not your web server. If the wrong process dies, adjust OOMScoreAdjust accordingly.

When Tuning Isn’t Enough

Memory tuning squeezes the last drops out of 1–2 GB, but if available sits at zero and swap is permanently active even after tuning, the honest fix is more RAM. Before you pay for an upgrade, compare VPS providers on our comparison table — some charge a premium for the same 2 GB that others include at half the price. If you’d rather not babysit kernel parameters, Cloudways managed plans apply sane memory defaults out of the box, and InterServer’s unmanaged VPS line gives you full control at a low fixed price if you prefer the DIY route.

Start with swap sizing, set swappiness to 10 and vfs_cache_pressure to 50, assign explicit OOM scores to your critical services, and verify under load. That sequence has kept 1 GB instances serving production traffic comfortably — and it’s entirely reversible if your workload behaves differently.