Why your Linux server needs a swap file, and what happens without one

A Linux server needs a swap file so that, when RAM runs out, it slows down instead of killing processes. Without one, the kernel kills the biggest process to free memory, and on a WordPress server that’s often MySQL. Most cloud servers don’t have swap by default, and adding it takes six commands.

One Sunday morning, a client’s WordPress site went down for hours because its 2GB server had no swap. The database corrupted, and it took a full rebuild to bring the site back.

What happened

The server was a DigitalOcean droplet running a standard LAMP stack: Ubuntu 24.04, Apache, MySQL 8, PHP 8.2. It had been running fine for months.

At 08:07 that Sunday, the site stopped responding. WordPress showed “Error establishing a database connection”, the usual sign that MySQL has stopped.

When I investigated, MySQL was in a restart loop. It would start, immediately crash, and systemd would try again. The restart counter showed 13,851 attempts.

The kernel logs showed why:

Out of memory: Killed process 1045049 (mysqld) total-vm:1837208kB

The server had run out of RAM. Linux killed MySQL to free up memory. But MySQL was mid-write when it died, corrupting the InnoDB system tablespace. Every restart attempt failed because the database files were damaged.

Why the server ran out of memory

Two things combined to cause this.

First, the server was under a brute-force attack. A single IP address had made more than 1,000 requests to wp-login.php in one night, trying to guess the admin password. Each request started PHP processes and database connections, which gradually ate into the available memory.

Second, and more important, the site was running Wordfence. The security plugin detected the attack and tried to send the attack data to its servers. At 08:07, it set off roughly 25 to 30 simultaneous HTTP requests to process this sync:

0.0.0.0 - "POST /?wordfence_syncAttackData HTTP/1.1" 200 "WordPress; https://example.com"
0.0.0.0 - "POST /?wordfence_syncAttackData HTTP/1.1" 500 "WordPress; https://example.com"
0.0.0.0 - "POST /?wordfence_syncAttackData HTTP/1.1" 500 "WordPress; https://example.com"
0.0.0.0 - "POST /?wordfence_syncAttackData HTTP/1.1" 500 "WordPress; https://example.com"
0.0.0.0 - "POST /?wordfence_syncAttackData HTTP/1.1" 500 "WordPress; https://example.com"
0.0.0.0 - "POST /?wordfence_syncAttackData HTTP/1.1" 500 "WordPress; https://example.com"
0.0.0.0 - "POST /?wordfence_syncAttackData HTTP/1.1" 500 "WordPress; https://example.com"
... 20+ more ...

On a server with 2GB of RAM and no swap file, that was enough to run out of memory. The kernel’s out-of-memory killer did what it’s designed to do: it killed the biggest memory consumer to save the system, and that was MySQL.

What is swap and why it matters

Swap is disk space that Linux uses as overflow when RAM runs low. It’s slower than RAM, but it gives the system a buffer.

Without swap, when memory fills up, the kernel has one option: kill processes. It picks the biggest one and stops it at once, with no clean shutdown and no chance to finish writing data.

With swap, the system can move less-used memory pages to disk, so things slow down instead of crashing. MySQL might become sluggish under memory pressure, but it won’t be killed mid-transaction.

DigitalOcean and AWS, among others, leave it to you to provision enough RAM or set up swap yourself. On a 2GB droplet running WordPress, MySQL and a memory-hungry security plugin, it’s an easy detail to miss until it causes an outage.

How I recovered the database

Recovery took about 90 minutes:

1. Enable InnoDB recovery mode. MySQL has a built-in recovery option that skips corrupted pages. Adding innodb_force_recovery = 1 to the config let it start in a degraded state.

2. Dump the databases. With MySQL running in that state, I ran mysqldump --all-databases to export everything. It worked, and gave me a clean 70MB backup.

3. Rebuild the data directory. I moved the corrupted files aside, ran mysqld --initialize-insecure to create fresh InnoDB system files, and restored from the dump.

4. Recreate the database user. The restore brought back the data but not the database user WordPress needed. CREATE USER and GRANT ALL PRIVILEGES fixed that.

Adding a swap file

This is the fix for the cause:

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

These six commands take a few seconds to run, and would have prevented the outage.

Additional hardening

I fixed three other problems while I was there:

Fail2ban for WordPress. The brute-force attack should have been blocked at the firewall. I added a fail2ban jail that bans any IP address making more than five POST requests to wp-login.php within ten minutes. It stops attacks before they reach PHP, which saves CPU and memory.

Binary logging turned off. MySQL was writing binary logs that had grown to 1.5GB. They’re useful for replication and point-in-time recovery, but this single-server WordPress site needed neither. Turning them off with skip-log-bin stops them filling the disk.

Wordfence tuned. The security plugin that triggered the crash wasn’t configured for a server with limited resources. Turning on “low resource scanning”, lowering its memory limit from 256MB to 128MB and trimming live traffic logging all reduce its footprint. Configuring plugins properly is ongoing maintenance, like keeping WordPress updated.

How much swap do you need?

For most WordPress servers:

• 1 to 2GB of RAM: add 1 to 2GB of swap
• 4GB of RAM: add 1 to 2GB of swap
• 8GB of RAM or more: add 2GB of swap as a safety net

Swap is a buffer for when something unexpected happens, rather than memory to use every day. If the server swaps heavily, it needs more RAM.

Check your server now

SSH into your server and run:

free -h

If the swap line shows 0B, you’re vulnerable to the same failure. Adding swap takes under a minute and persists across reboots.

Checking the hosting is part of the health check that starts my WordPress maintenance work.