📑 Daftar Isi
Skip the fluff, this one’s quick. In one sentence: vm.swappiness tells the Linux kernel how eager it should be to push memory pages to swap. The default is 60, which is honestly too aggressive for most servers. This guide walks you through checking, setting, and persisting the right value. No theory, just commands you can run right now.
Why should you care? Picture this: a 16GB production box with 6GB free, yet the kernel keeps moving anonymous pages to disk. Your database ends up waiting on disk I/O instead of RAM, and query latency doubles for no obvious reason. I’ve debugged this exact pattern on more client servers than I can count. The kicker? The fix is one sysctl line.
Here’s the thing though – swap isn’t inherently evil. Swap is what keeps the box alive when memory genuinely spikes. The real problem is the threshold. A default swappiness of 60 means the kernel starts swapping while free memory is still healthy, which is wasteful. Dropping it to 10 (or lower) tells the kernel: keep pages in RAM until things actually get tight. That’s the whole trick.
And no, this isn’t just a database problem. Web servers, cache nodes, hosting boxes – they all benefit. The only places I’d keep it higher are dedicated batch-processing boxes and desktops. Everything else? Lower is usually better. So here are the steps.
Step 0: Check where you stand
Never change a kernel parameter without knowing the baseline. Run these three commands:
cat /proc/sys/vm/swappiness
free -h
swapon --showIf the first command prints 60, you’re on defaults. Then watch the Swap row in free -h. High swap usage with plenty of available RAM is your red flag. Here’s what a problem box looks like:
root@web:~# cat /proc/sys/vm/swappiness
60
root@web:~# free -h
total used free shared buff/cache available
Mem: 15Gi 5.2Gi 6.1Gi 120Mi 4.1Gi 9.8Gi
Swap: 4.0Gi 1.9Gi 2.1Gi
root@web:~# swapon --show
NAME TYPE SIZE USED PRIO
/swap.img file 4.0G 1.9G -21.9GB sitting in swap while almost 10GB is available. The kernel made a lazy choice. Let’s fix the behavior.
Step 1: Set swappiness immediately (no reboot)
One command, instant effect:
sysctl -w vm.swappiness=10Verify:
sysctl vm.swappinessIt should print vm.swappiness = 10. This works until the next reboot, which is fine for testing. Run your workload for a day or two and watch free -h. If swap usage trends down and the box feels snappier, you’ll want to make it permanent.
Step 2: Make it permanent
Drop a sysctl file in the distro-agnostic location:
echo "vm.swappiness = 10" | sudo tee /etc/sysctl.d/99-swappiness.confThen apply without rebooting:
sudo sysctl --systemThe 99-prefix matters. /etc/sysctl.d is read in alphabetical order, and 99 wins over distro defaults like 50-default.conf on Ubuntu. After the reload, confirm with sudo sysctl vm.swappiness – and re-check after your next reboot to make sure it stuck.
Step 3: Pick the right value (stop guessing)
Here are the values I actually use on production boxes, workload by workload:
| Workload | swappiness | Why |
|---|---|---|
| Web server (Nginx + PHP-FPM) | 10 | Responsive under spikes, room for page cache |
| MySQL / MariaDB / PostgreSQL | 1-10 | Keep buffer pool in RAM; use 1 if dedicated |
| Redis / Memcached | 1-10 | Data lives in RAM; swapping is an outage risk |
| cPanel / WHM / shared hosting | 10-20 | Many small processes, needs headroom |
| KVM / Proxmox host | 10 | Balance host and guest memory pressure |
| Desktop / workstation | 60 or 10 | Higher = classic behavior, lower = snappier |
The swappiness=0 trap (real, and annoying)
Old guides love recommending 0. On kernel 5.8+ it doesn’t mean no swapping anymore – it means swap only when OOM is imminent. Fine in theory. The problem: tmpfs pages (like /dev/shm used by MySQL or Redis) get treated as aggressively reclaimable, and 0 can evict those earlier than you’d like. Use 1 instead. Same effect on anonymous pages, far fewer surprises.
This is the kind of thing that looks correct in a blog post and then bites you three weeks later at 2am. If you’re running MySQL on a small VPS and have been fighting crashes, pair this with our guide on fixing MySQL crashes on low-RAM VPS boxes.
Don’t stop at swappiness
Swappiness is one knob. For memory tuning that actually holds up, also look at vm.min_free_kbytes (keep about 1-3% of RAM as a kernel reserve) and vm.vfs_cache_pressure for inode and dentry cache. And honestly? Swappiness won’t save you from a genuine memory shortage. If your workload outgrows physical RAM, a low value only delays the pain. Right-size the box or fix the leak first – see our breakdown on diagnosing memory leaks on Linux servers.
Also, if your server is a shared hosting box, note that high load on these systems is rarely caused by swappiness alone. Check our high load troubleshooting guide for cPanel for the full picture. And once you’ve tuned it, monitor memory with Netdata and Grafana so you can see whether your change actually moved the needle over a week.
Quick troubleshooting table
| Symptom | Likely cause | Fix |
|---|---|---|
| High swap usage with plenty of free RAM | Default swappiness=60 too eager | Set 10, monitor with free -h |
| Value resets to 60 after reboot | Wrote to /proc without persisting | Use /etc/sysctl.d/99-swappiness.conf, then sysctl –system |
| Database latency even with free RAM | Kernel swapping buffer pool | swappiness=1, then recover memory |
| OOM killer keeps firing | Physical RAM shortage or a leak | Add RAM or fix the leak; tuning won’t fix this |
| tmpfs filling or evicting early | swappiness=0 with active tmpfs | Switch to 1 or enlarge the tmpfs mount |
FAQ
Q: Does swappiness=0 mean swap is never used?
Not exactly. On modern kernels it means swap only happens when memory is critically low. But it can make tmpfs pages evict sooner. For servers, 1-10 is safer and gives almost the same result.
Q: When should I increase swappiness instead of lowering it?
When you’re running batch jobs or apps that allocate big memory once and rarely touch it again. A higher value lets the kernel reclaim those pages quickly. For latency-sensitive workloads like databases and web servers, keep it low.
Q: Can I set swappiness per application?
Yes. On systems with cgroup v2, every cgroup has its own memory.swappiness. systemd units also support MemorySwapMax and related options. So you don’t have to change the global value for a single exception.
Q: Is a low swappiness safe on a shared hosting server?
Safe at sane values (10-20). Go too low and every small process fights to stay in RAM, which raises OOM risk on noisy-neighbor boxes. Moderate values strike the right balance.
Quick checklist before you close this ticket: 1) baseline recorded with cat /proc/sys/vm/swappiness and free -h, 2) temporary set confirmed via sysctl vm.swappiness, 3) permanent file placed in /etc/sysctl.d/ with the right value, 4) reload verified with sysctl –system. Done. That’s it.