Twice your RAM. That is the answer most people still give, and it has been wrong for about fifteen years. It comes from an era when a server had 256 MB of memory and swap was where you put most of your working set. Apply it to a modern 2 GB cloud instance and you spend 4 GB of a 20 GB disk on space the kernel will barely touch.

The opposite advice is just as common and just as wrong: that swap is a relic, that memory is cheap, and that a server with none is a server that runs at full speed. That one ends with a process being killed in the middle of a job.

This article covers what swap is actually for, how much of it a server needs, and how to add it properly so it survives a reboot.

Swap is not extra RAM

This is the misunderstanding that produces every bad sizing decision. Swap is not a slower reserve tank that your programs run out of once memory fills up. Disk is thousands of times slower than RAM, and a server genuinely running its working set from swap is not slow, it is unusable.

What swap actually provides is somewhere to put memory that nothing is using. A long-running server accumulates a surprising amount of it: the initialisation code of every daemon, configuration parsed once at boot, a logging library loaded by a service that has not logged since Tuesday. None of it will be read again, and all of it is sitting in RAM.

With swap available, the kernel can move those cold pages to disk and use the RAM it recovers for page cache, which is memory that actively makes your database and your web server faster. Without swap, the kernel has one option for reclaiming memory: evict page cache. So a server with no swap does not avoid disk activity, it trades useful cached data for useless resident data, and reads more from disk as a result.

The second thing swap provides is time. When something briefly demands more memory than exists, swap absorbs the spike instead of the OOM killer ending a process. It does not make the machine immune. It converts an instant failure into a slow patch you can notice and react to.

How much you actually need

Size it from installed RAM. Here is a rule that holds up on real servers:

Installed RAM	Swap	Why
Under 2 GB	1.5x RAM	Small instances spike hardest relative to their size, and the disk cost is trivial
2 GB to 4 GB	1x RAM	Enough to absorb a spike without reserving space nothing will use
Over 4 GB	4 GB is plenty	Cold pages do not scale with RAM. A 32 GB server does not have 32 GB of idle memory
Any size	Never below 512 MB	Below this there is not enough room to absorb anything meaningful

A 1 GB instance gets 1.5 GB. A 2 GB instance gets 2 GB. An 8 GB instance gets 4 GB, and so does a 64 GB instance.

That last row surprises people, so it is worth being explicit: the amount of cold memory on a server is roughly a property of how many services it runs, not of how much RAM you bought. Doubling RAM does not double the idle pages waiting to be paged out. Past a few gigabytes, more swap buys you nothing except a longer, more painful death spiral when something really does run away.

Two cases where the rule does not apply

Hibernation. Suspending to disk writes the entire contents of RAM into swap, so swap has to be at least the size of RAM, with a little to spare. This is a laptop concern. Servers do not hibernate.

Latency-critical databases. If a query touching a swapped-out page would breach an SLA, you may genuinely want the OOM killer to act immediately rather than let the machine limp. That is a deliberate trade, and it is made by people who know exactly why they are making it. It is not the default, and it is not a good reason for a general-purpose server to run with no swap.

Disk size is the wrong input

Plenty of guides size swap as a percentage of the disk, and some tools still do it. It produces nonsense in both directions.

A 1 GB instance with a 200 GB data volume does not need 20 GB of swap. It has 1 GB of RAM, so it has at most a few hundred megabytes of cold pages, and the kernel will never fill the rest. Meanwhile a 16 GB machine on a small root disk gets almost none, which is the case where a little swap would have helped most.

Disk matters in exactly one way: you need enough free space to create the file, plus headroom so that filling it does not fill the filesystem. Check it before you allocate. It does not belong in the size calculation.

Creating the swap file

A swap file, not a swap partition. Files are resizable, removable and need no repartitioning, and on any kernel from the last decade the performance difference is not measurable.

First check what you have. If either command shows existing swap, deal with that before adding more:

swapon --show
free -m

free -m also tells you the RAM figure to size from. Take the total, apply the table above, and create the file. For a 2 GB server, that is 2048 MB:

sudo fallocate -l 2048M /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

The chmod 600 is not optional. A swap file holds whatever was in memory, which can include credentials and session tokens. Created with default permissions it is world-readable, and swapon will warn you and then enable it anyway.

If mkswap rejects the file

On btrfs and zfs, fallocate produces a file whose extents are not laid out the way swap requires, and mkswap or swapon refuses it. Allocate it the slow way instead:

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress

On btrfs specifically, the file also needs copy-on-write disabled before anything is written to it, with chattr +C applied while the file is still empty.

Making it survive a reboot

Everything so far is lost on restart. Swap is only persistent once it is in /etc/fstab:

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

Back that file up first, and verify it afterwards. A malformed /etc/fstab can stop the machine booting, and on a cloud instance with no console access that is a genuinely bad afternoon. Copy it somewhere before you edit, then check your work while you can still fix it:

findmnt --verify

Swappiness, and what it does not mean

The most repeated claim about vm.swappiness is that it sets the percentage of RAM that must be used before the kernel starts swapping. It does not, and that is not a small distinction.

It is a relative preference. When the kernel needs to reclaim memory, it chooses between evicting page cache and paging out anonymous memory. Swappiness weights that choice. Higher values make it more willing to page out application memory; lower values make it lean on the page cache instead.

Most distributions ship with 60, which suits a desktop. On a server where the page cache is doing useful work, something around 10 is a better default: swap stays available for genuinely cold pages, but the kernel stops reaching for it ahead of cache it should be dropping.

sudo sysctl -w vm.swappiness=10
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/60-swap.conf

Do not set it to 0 thinking it is a safe minimum. On current kernels 0 means avoid swapping almost entirely, which is close to having no swap at all and reintroduces exactly the OOM behaviour you added swap to prevent. If you want minimal swapping, use 1.

Checking it worked

swapon --show
free -h
cat /proc/sys/vm/swappiness

Then reboot and run the first two again. Until you have done that, you have not confirmed persistence, you have confirmed that swapon works.

Afterwards, a healthy server shows a small amount of swap in use and almost no paging activity. Used swap is not a problem by itself, it is the system doing its job. What matters is the rate: constant paging in and out under normal load means the machine is short of RAM, and no amount of swap tuning fixes that.

One place none of this applies

Do not run any of the above inside a container. Swap is a kernel facility and it is not namespaced, so swapon in a container does not give the container swap, it alters the swap configuration of the host it is running on. If you want a container to have more memory headroom, that is a setting on the host or the orchestrator, not something you configure from inside.

Doing it without the steps

Everything above is roughly fifteen minutes of careful work per server, and most of the care is in the parts that are easy to skip: the permissions, the fstab backup, the filesystem check, confirming it came back after a reboot.

Linux Auto Swap File Creator is that sequence as a single script. It reads the installed RAM, applies the sizing table above, checks there is disk space before it writes anything, falls back to dd when fallocate produces a file mkswap will not take, backs up /etc/fstab before editing it and verifies the result with findmnt, and sets swappiness persistently. Running it twice is safe: it resizes an existing /swapfile only if the size is wrong, and leaves any other swap device alone.

It runs on AlmaLinux, Rocky, RHEL, Ubuntu and Debian, it is plain readable bash rather than a binary, and --dry-run prints the entire plan without touching the system. You are going to run it as root, so read it first.