Swap is disk space the kernel uses when physical memory runs out. On a VPS it is the difference between a server that slows down under pressure and one that kills your database.
It is also frequently absent, because many VPS images ship without any.
What happens with no swap
When memory is exhausted and there is nowhere to put anything, the kernel picks a process and kills it.
It chooses the largest consumer, which is almost always the database. So the symptom is a site that works, then reports a database connection error, then works again after the database is restarted, with nothing in the application's own logs explaining it.
Checking for this is the first thing to do when a server misbehaves at intervals:
sudo dmesg | grep -i "out of memory" sudo journalctl -k | grep -i "killed process"
An entry naming your database process is the whole answer, and it takes ten seconds to find.
What swap does instead
With swap, the kernel moves inactive pages to disk rather than killing anything. The server gets slower: sometimes much slower, and it stays up.
That is the trade, and for a web server it is nearly always the right one. A slow server can be diagnosed and fixed; a killed database is an outage.
Swap is not extra memory. A server constantly swapping needs more RAM, and swap is buying you time to notice.
How much
For a VPS running a website, one to two times the physical memory is a reasonable range, and 2 GB is a sensible figure on a small server.
Very large swap on a small machine is not helpful. If the kernel is paging tens of gigabytes to disk, the server is unusable long before the swap fills, and you are prolonging a bad state rather than surviving a spike.
Creating a swap file
A file is easier than a partition and performs the same on modern systems.
sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile
The permissions matter. A swap file readable by anyone exposes whatever memory has been paged out to it, which can include credentials.
Then make it permanent by adding it to /etc/fstab:
/swapfile none swap sw 0 0
Without that line it disappears at the next reboot, and the server is back to the original problem at the least convenient moment.
Check it worked
free -h swapon --show
The first shows total and used memory including swap; the second confirms the swap device is active.
Do this after creating it and again after a reboot. A swap file that was never added to fstab looks correct all week.
Swappiness
This setting controls how eagerly the kernel moves pages to swap, from 0 to 100. The default on many systems is 60, which is tuned for desktops.
For a server, a lower value is usually better:
sudo sysctl vm.swappiness=10
That means "use swap when you have to, not as a matter of routine", which keeps the database's working set in memory where it belongs.
Make it permanent in /etc/sysctl.conf, or the next reboot restores the default.
Do not set it to 0. That does not disable swap; it makes the kernel avoid it until the last possible moment, which brings back the behaviour you added swap to prevent.
On SSD storage
Swapping writes to disk, and heavy sustained swapping does write a lot.
Modern SSDs handle this without a practical lifespan concern for a normally-behaved server. What you should not do is treat swap as a way to run permanently beyond your memory: that is both slow and genuinely hard on the disk.
Swap is a safety net. If it is in constant use, the answer is more memory or less software.
Reading memory correctly
The number that alarms people is usually not the problem.
Linux uses free memory for disk caching, so "free" memory is always low on a healthy server. That is the kernel doing its job, and the cache is released instantly when an application needs the space.
The figure to read in free -h is available, not free. Available accounts for reclaimable cache and tells you what an application could actually get.
A server with almost no free memory and plenty available is fine. One with little available and swap filling is the one to act on. There is more on the wider set of numbers in managing VPS resources.
Reduce what is using it
Swap buys time; it does not fix consumption. Three things account for most memory use on a small VPS.
Database buffer settings configured for a larger machine. A default configuration assuming several gigabytes on a 1 GB server is a common cause of the kill described above.
Too many PHP worker processes. Each holds memory; the total is what matters, and a worker count copied from a bigger server will exhaust a small one under load.
Services you are not using started at boot and holding memory permanently. Removing rather than disabling them is cleaner. There is more on reducing what runs in securing your VPS.
When swap is not appropriate
Some providers charge for disk operations, or run storage where sustained writes are costly. Check before creating a large swap file on that kind of plan.
And on a server whose whole purpose is a latency-sensitive service, swapping may be worse than failing, but that is a deliberate decision made by someone who knows the workload, not a default. For a normal website, swap on and swappiness low is the right configuration.
There is a second way a server refuses to write while appearing to have room, and it has nothing to do with memory or bytes. For that, see Understanding Inodes and Running Out of Them.
Adding a separate volume is frequently simpler than growing the existing one. How to Add or Resize a Disk on a VPS walks through both, including the fstab entry that hangs a boot.