Course contentsShow
← Linux
Lesson 1792 of 1,81915. Kernel Concepts for Systems AdministratorsFree lesson

Swapping and paging strategies

You will tune swap behavior to balance performance against high memory pressure.

In this lesson, you will learn how to fine-tune the Linux kernel’s swapping behavior to maintain system responsiveness under high memory pressure.

Understanding the Swappiness Heuristic

At the core of Linux memory management is the vm.swappiness parameter. This value, ranging from 0 to 100, controls the kernel's relative preference for reclaiming anonymous memory (processes) versus page cache (files).

A high value tells the kernel to aggressively swap out process memory to make room for file-backed pages, which helps maintain a large disk cache for I/O performance. A low value forces the kernel to favor evicting file-backed pages, keeping processes in RAM as long as possible.

Tuning for Your Environment

If your server is a dedicated database, you often want to prevent the kernel from swapping out your active database buffers. In this scenario, you should reduce swappiness. Conversely, for a general-purpose workstation where responsiveness is prioritized, a moderate value allows the kernel to clear stale memory pages to provide the file system with more cache.

To check your current configuration:

sysctl vm.swappiness

To modify it temporarily for testing, you can use:

sudo sysctl vm.swappiness=10

(Note: A value of 10 is often recommended for database servers to balance reclaim pressure without inducing aggressive paging.)

Beyond Swappiness: The Working Set

While swappiness dictates the aggressiveness of swapping, the kernel's underlying strategy relies on the LRU (Least Recently Used) list. The kernel tracks pages in two lists: active and inactive. When memory pressure increases, the page daemon (kswapd) scans the inactive list, selects pages that haven't been accessed, and writes them to the swap partition.

If you find your system "thrashing"—where the CPU spends more time moving pages between RAM and disk than executing code—adjusting swappiness may help, but it is ultimately a signal that your system is over-committed. Always pair your tuning with introspection via vmstat 1 to monitor si (swap-in) and so (swap-out) activity to verify your changes are having the desired effect on throughput.

Key Takeaway: Tuning vm.swappiness allows you to balance the trade-off between keeping process memory resident and maintaining a healthy page cache for I/O-intensive workloads.