Linux OOM Killer and Swap Tuning for WordPress Servers

The Linux OOM (Out-Of-Memory) Killer terminates processes when the system runs out of RAM and swap space. On WordPress servers, it typically kills either MySQL or PHP-FPM — causing database corruption or 502 errors. Correct swap and OOM configuration makes the difference between a graceful slowdown and a hard crash.

Problem: A WordPress server's PHP-FPM or MySQL process is killed by the Linux OOM killer under memory pressure — the server crashes intermittently under peak load, and the swap configuration either does not exist or is tuned for desktop, not server, workloads.

Solution: Add a dedicated swap file (1–2× RAM, up to 4 GB) with fallocate + mkswap + swapon. Set vm.swappiness = 10 in /etc/sysctl.conf so the kernel prefers freeing page cache over swapping processes. Assign OOM score adjustments with /proc/PID/oom_score_adj to protect MySQL and PHP-FPM from being killed first.

The examples below create and configure a swap file, tune the swappiness kernel parameter, set OOM score adjustments to protect MySQL from being killed first, and monitor swap usage in real time.

# ── CREATE A SWAP FILE (if no swap partition exists) ──
# Recommended swap size: equal to RAM for servers with up to 8 GB; 4-8 GB for larger servers

# 4 GB swap file
fallocate -l 4G /swapfile              # fast allocation
# chmod must be 600 — swap readable by others is a security risk
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# Make permanent — add to /etc/fstab
echo '/swapfile none swap sw 0 0' | tee -a /etc/fstab

# Verify
free -h
swapon --show

# ── SWAPPINESS ──
# vm.swappiness = 0–100
# 0: kernel only swaps to avoid OOM (prefer to keep pages in RAM)
# 10: recommended for databases — minimise swap use
# 60: default — may swap out DB pages even when RAM is available
# 100: swap aggressively

# For a WordPress server with MySQL:
sysctl vm.swappiness=10
echo 'vm.swappiness=10' >> /etc/sysctl.d/99-wordpress.conf

# vm.vfs_cache_pressure — how aggressively to reclaim inode/dentry cache
# Lower = keep more filesystem caches (good for WordPress with many files)
sysctl vm.vfs_cache_pressure=50
echo 'vm.vfs_cache_pressure=50' >> /etc/sysctl.d/99-wordpress.conf

sysctl -p /etc/sysctl.d/99-wordpress.conf   # apply without reboot

Protect MySQL from the OOM Killer and monitor memory pressure:

# ── OOM SCORE ADJUSTMENT ──
# oom_score_adj: -1000 = never kill; +1000 = kill first; 0 = default
# Protect MySQL: -500 (very unlikely to be OOM-killed)
# PHP-FPM workers: +200 (more likely to be killed than MySQL to protect data)

# Find MySQL PID
MYSQL_PID=$(pgrep -x mysqld | head -1)
echo -500 > /proc/${MYSQL_PID}/oom_score_adj

# Find PHP-FPM master PID
PHP_PID=$(pgrep -x php-fpm8.2 | head -1)
echo 200 > /proc/${PHP_PID}/oom_score_adj

# Persist via systemd service override (survives restarts)
# For MySQL:
mkdir -p /etc/systemd/system/mysql.service.d/
cat > /etc/systemd/system/mysql.service.d/oom.conf << 'EOF'
[Service]
OOMScoreAdjust=-500
EOF

# For PHP-FPM:
mkdir -p /etc/systemd/system/php8.2-fpm.service.d/
cat > /etc/systemd/system/php8.2-fpm.service.d/oom.conf << 'EOF'
[Service]
OOMScoreAdjust=200
EOF

systemctl daemon-reload

# ── MONITORING ──
# Watch swap usage in real time
watch -n 2 'free -h && swapon --show'

# Find processes using the most swap
for pid in /proc/[0-9]*/status; do
    name=$(awk '/^Name:/{print $2}' $pid 2>/dev/null)
    swap=$(awk '/^VmSwap:/{print $2}' $pid 2>/dev/null)
    [ -n "$swap" ] && [ "$swap" -gt 0 ] && echo "$swap kB  $name"
done | sort -rn | head -10

# Check OOM kill history
dmesg | grep -i 'oom\|killed process' | tail -20

# vm.overcommit_memory settings:
# 0 = heuristic (default) — kernel estimates if allocation will succeed
# 1 = always allow (never fails allocation, relies on swap + OOM killer)
# 2 = strict — refuse allocations that exceed physical RAM + swap
sysctl vm.overcommit_memory=0  # default is best for WordPress servers

NOTE: On small VPS servers (1-2 GB RAM), the OOM killer is the most common cause of mysterious MySQL crashes. Logs show Out of memory: Kill process [pid] (mysqld) in dmesg. The fix is either more RAM, smaller buffer pool (innodb_buffer_pool_size), fewer PHP-FPM workers, or a swap file — ideally all four together.