Understanding VPS swap

When RAM fills up, the kernel can move rarely used pages to disk: that is swap. It avoids an immediate stop, but it is hundreds of times slower than memory. On a container VPS, swap is not configured like on a physical machine, and mistaking it for extra RAM leads to bad decisions.

What swap does

Swap absorbs temporary peaks and keeps genuinely active pages in memory. It adds no capacity: if RAM and swap are both full at the same time, the kernel triggers the OOM killer, which kills a process to free memory. For an application this means a brutal restart, not a gradual slowdown.

Check what is available

free -h
swapon --show
cat /proc/swaps
grep -E 'SwapTotal|SwapFree' /proc/meminfo

If SwapTotal is 0, no swap is visible inside the container. That is not necessarily a fault: in a container, memory and swap may be managed by the platform, and the value exposed to the container may stay at zero even when the platform has swap.

What a system container allows

A NeoHeberg VPS is an isolated system container. You are root inside it, but you do not have rights on the infrastructure that runs it. Practical consequences:

• creating a swap file with fallocate then swapon /swapfile usually fails with Operation not permitted;
• mknod is denied, so no manual swap device;
• /proc/sys/vm/swappiness is generally read-only in the container namespace;
• adding a swap line to /etc/fstab can prevent a clean boot.

Do not try to tune swap as on a dedicated server. Treat it as a platform characteristic and work on actual consumption.

Reduce memory pressure

First measure who consumes memory:

free -h
ps -eo pid,rss,comm --sort=-rss | head -n 15
vmstat 1 5
sudo journalctl -k | grep -i oom

The si/so columns in vmstat show memory exchanged with disk. A sustained non-zero value means real pressure. Then tune the biggest consumers:

• PHP-FPM: lower pm.max_children, add pm.max_requests to recycle workers;
• MariaDB: adjust innodb_buffer_pool_size (often 25 to 50% of RAM);
• Node.js: cap the heap with --max-old-space-size;
• Redis: set maxmemory and an eviction policy;
• Nginx: reduce worker_processes and worker_connections if needed.

Restart the relevant service, then measure again. One change at a time tells you what had an effect.

Good practice

• Do not disable swap without reason: it protects against peaks.
• Do not rely on it for a permanent load.
• Watch the trend over several days, not a single snapshot.
• If processes are still killed despite reasonable settings, move to a plan with more RAM: swap is not a capacity plan.