Linux Virtual Memory Swappiness Tuning: Complete Guide 2026

Alright, let’s talk about something that’s quietly ruining your server’s performance — and you might not even know it. vm.swappiness. It’s that one little kernel parameter that controls how aggressively your Linux system shoves things into swap space. And honestly? Most people never touch it. That’s the problem.

What’s Swappiness and Why Should You Care?

So here’s the deal. Every Linux system has this thing called virtual memory — it uses a combination of physical RAM and disk-based swap space to handle memory allocation. The kernel needs to decide when to start moving data from fast RAM to slow disk swap. That decision is controlled by vm.swappiness.

By default, most distros set this to 60. That’s a balanced setting that works fine for desktops where you’ve got a mix of interactive and background processes. But for servers? It’s often too aggressive. A value of 60 means the kernel starts pushing pages to swap way before it absolutely needs to. And swap on a disk — even an NVMe — is orders of magnitude slower than RAM. We’re talking nanoseconds vs. milliseconds. When your database query takes 200ms instead of 2ms because the working set got swapped out, your users notice. Your monitoring alerts go crazy. And you’re left wondering what happened.

I’ve seen this cause some really nasty production issues. One time, a client’s e-commerce site was intermittently slow during peak hours. Load average was fine, CPU was fine, but disk I/O was through the roof. Turns out, their PostgreSQL instance had been swapped out because nobody ever touched the default swappiness setting. Once we set it to 10, the problem literally disappeared. Ten minutes of config change, hours of debugging avoided.

Understanding the Values

Here’s something a lot of people get wrong. Swappiness doesn’t go from 0 to 100. It goes from 0 to 200. Yeah, 200. Most people only ever see 0-100 in tutorials, but the kernel actually supports up to 200. Values above 100 tell the kernel to prioritize swap even more aggressively than RAM — useful in some edge cases but not something you’d normally set on a server.

At the common range of 0-100:

• 0: Kernel avoids swap as much as possible, only swapping as an absolute last resort under extreme memory pressure
• 1-10: Minimal swapping. Good for servers where you want to maximize RAM usage
• 30-60: Balanced. Default 60 falls here. Fine for desktops, often too aggressive for servers
• 70-100: Aggressive swapping. Basically tells the kernel to use swap early and often

Check Your Current Setting

Before you change anything, know where you stand:

cat /proc/sys/vm/swappiness

Or the slightly more readable version:

sysctl vm.swappiness

Now also check your actual swap usage:

free -h

If your swap used is creeping up toward swap total, and you’ve got available RAM sitting idle, that’s your smoking gun. The kernel is being too eager to swap things out.

3 Ways to Tune Swappiness

Method 1: Runtime (Lost on Reboot)

Great for testing. Applies immediately:

sudo sysctl -w vm.swappiness=10

Done. Active right now. But reboot and it’s gone. Use this to test the waters — set it, monitor for a few hours, see if performance improves. If it does, make it permanent.

Method 2: Permanent via /etc/sysctl.conf

The classic approach:

sudo nano /etc/sysctl.conf

Add this line at the end:

vm.swappiness = 10

Save and apply:

sudo sysctl -p

Verify with cat /proc/sys/vm/swappiness — should show your new value. This survives reboots.

Method 3: via sysctl.d (Recommended)

This is the cleaner, more modern approach:

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

sudo sysctl --system

Why is this better? It keeps your swappiness config separate from everything else in sysctl.conf. More modular, easier to maintain, and dead simple to roll back if needed. This is what I use on all production servers I manage.

Recommended Values by Use Case

What to Monitor After Changing Swappiness

Look, changing the value is the easy part. Making sure it doesn’t break anything — that takes a bit more effort. Here’s what I always do after a swappiness change:

First, watch swap usage for at least a few hours:

watch -n 5 'free -h'

If swap usage stays low and there are no OOM killer events, you’re golden. If OOM starts showing up in dmesg, your swappiness is too low for that server’s workload — bump it up to 20 or 30.

Second, check kernel logs for memory pressure events:

sudo dmesg | grep -i "out of memory"

Third, if you’re using monitoring tools like Netdata or Grafana, set up an alert for swap usage above 50%. Catching it early is always better than getting a panicked call at 3 AM.

Troubleshooting When Swappiness Alone Isn’t Enough

If you’ve tuned swappiness but swap is still high, the root cause might be something else entirely:

1. Actual RAM exhaustion: Run ps aux --sort=-%mem | head -20 and check which processes are eating your memory. If something’s hogging 50%+ of RAM, that’s your real problem.
2. Memory leaks: Use smem -t -k -s pss to get real per-process memory numbers. If you see a process’s memory growing steadily over hours, you’ve got a leak.
3. HugePages: On database servers, huge pages can make memory usage look artificially high. Check with grep HugePages /proc/meminfo.
4. Overcommit settings: Check cat /proc/sys/vm/overcommit_memory. If it’s 1, the kernel allows memory allocation beyond physical RAM, which can lead to more frequent OOM events.

Best Practices for Production

Here’s my quick-reference checklist:

1. Default vm.swappiness = 10 for all production servers
2. For databases with ample RAM (16GB+), consider swappiness = 1
3. For Redis/Memcached, always 1 — these are in-memory systems
4. Monitor for at least 48 hours after any change
5. Alert on swap usage > 50%
6. In container environments, set swappiness on the host, not inside containers
7. Document every swappiness change in your CMDB or server notes
8. Test on staging before touching production

One more thing — if you’re running on NVMe SSDs, high swap usage actually accelerates SSD wear due to write amplification. So tuning swappiness isn’t just about performance — it’s about hardware longevity too.

Related Articles

• Complete Linux Server Performance Optimization Guide
• How to Fix OOM Killer Issues on Production Linux
• Server Monitoring Setup with Netdata and Grafana
• Docker Container Memory Limit Best Practices

So yeah, that’s it. Check your swappiness, tune it based on your workload, monitor for 48 hours, set alerts. Done. Don’t overthink it — start with 10, see how it goes, and adjust from there. Your servers will thank you.