Skip to content 
I'll show you how to configure `vm.swappiness` so that web and database services on hosting servers respond faster and generate less I/O. With clear steps, sensible starting values, and monitoring, you can get more out of your existing RAM and reduce Latencies and prevents unnecessary swapping.
Key points
These points give you a quick overview of tuning tips you can put into practice right away.
- Swappiness Behavior: Controls how early the kernel moves RAM to swap.
- Workload-Based: Adjust the values based on the application type, such as a database or a website.
- Test temporarily: Test it in a live environment first, then make it permanent.
- Swap Layout: Consider size, scope, and priorities.
- Monitoring: Monitor and adjust I/O, RAM, and response times.
What vm.swappiness Is and How It Works
The kernel parameter vm.swappiness Determines how aggressively Linux moves memory pages from RAM to swap. You can find the current value in the pseudo-filesystem at /proc/sys/vm/swappiness and can change it at runtime or permanently. A high value results in earlier swapping, while a low value keeps data in RAM longer. The goal is to strike a good balance between RAM utilization, the page cache, and controlled swapping behavior. I keep in mind that RAM is much faster than any SSD, so I prefer Working memory clearly before the swap.
Why Swappiness Matters on Hosting Servers
On web and application servers, the setting for Swappiness regarding response time and throughput. Aggressive swapping generates additional I/O load and slows down requests, especially with database-intensive workloads. On the other hand, values that are too low carry the risk of future OOM events, which abruptly terminate processes. That’s why, in addition to RAM and swap, I also evaluate typical load spikes, caches, and query patterns. Reducing latency prevents stuttering and keeps transactions noticeably liquid.
Recommendations Based on Workload
A single value rarely works for all scenarios, so I start with tried-and-true ranges and then adjust them based on measurement data. Databases benefit from very low settings, while pure web servers can often handle slightly higher values. Test or development systems can run closer to the standard because user convenience plays a bigger role. I use the following scheme as a pragmatic starting point for Hosting-Workloads. After that, I monitor I/O, swap usage, and response times, and make adjustments as needed.
| Workload | Recommended Swappiness | Goal |
|---|---|---|
| Databases (MySQL, PostgreSQL) | 0–10 | Keep buffers in RAM; keep latencies low |
| Real-Time/Low-Latency | 0–10 | Avoiding I/O Spikes Caused by Swapping |
| Web server with caches | 10–20 (in some cases 10–30) | Outsource cold pages; keep active requests in RAM |
| Dev/Testing | 30–60 | Comfort and Stability Over Latency |
Check Current Value
Before I change any values, I read the status and document the Baseline. I use `cat /proc/sys/vm/swappiness` or `sysctl vm.swappiness` for this; both methods return a number like 60. At the same time, I use `free -h` to check the RAM and swap usage. Using `swapon --show`, I can determine the size, priority, and medium of the active swap devices. This initial data helps me assess the effects later allocate to be able to.
Test temporarily instead of making permanent changes right away
I'm going to try out Swappiness first to see how people react in a real-world Load to see. The command `sysctl vm.swappiness=10` takes effect immediately but only lasts until the next reboot. During the tests, I monitor `top` or `htop`, check `vmstat` and `iostat`, and measure service response times. If the swap rate decreases and latencies remain stable, I proceed in reasonable increments. Only when the metrics are satisfactory do I set the value permanent fixed.
Configure Permanently
If the test value is correct, I enter it into a sysctl configuration file and reload the settings. In /etc/sysctl.conf, I add the line vm.swappiness=10 and activate it with sysctl -p. For better organization, I prefer to use a separate file in /etc/sysctl.d/, such as 99-swappiness.conf, and load it using `sysctl -system`. This makes it easy to version the file and incorporate it into automation workflows. This article provides an in-depth overview of related parameters: sysctl tuning, who helps me organize the changes and Clarity brings.
Swap Size, Memory Layout, and Storage Media
Swappiness never acts in isolation, which is why I evaluate the size and location of the Swap Always keep this in mind. Too little swap space fills up quickly, while an oversized swap file prolongs I/O phases under heavy load. Swap is faster on SSDs or NVMe than on HDDs, but RAM remains several orders of magnitude faster. Using multiple swap devices with priorities helps ensure that the fastest medium is used first. If you want to delve deeper into the pros and cons, check out this overview of Swap in Hosting helpful food for thought for the Practice.
Practice Workflow: Step by Step
I'll start by taking stock of the current situation: record the current Swappiness value, RAM and swap usage, CPU, and I/O, and save them as Reference Save. Next, I classify the workload: primarily database, web with cache, mixed, or containerized. Then I define a target: 0–10 for databases, usually 10–20 for web, and proceed cautiously with mixed workloads. I set the value temporarily, observe several load phases, and compare metrics. If the results are consistent over time, I finalize the value, document the change, and verify it after kernel, hardware, or Release-Switch again.
Special Scenarios: Containers, VMs, and the Cloud
In containers and VMs, I evaluate swappiness at the host and guest levels together . Orchestration platforms like Kubernetes typically benefit from very low settings on the worker nodes to keep pod latencies low. In VMs, I set appropriate values internally but make sure the hypervisor isn’t working against them. In elastic cloud setups, conservative values help smooth out spikes until scaling kicks in. I avoid a single container causing the entire Platform slows down.
Monitoring and troubleshooting
I look for typical warning signs of inappropriate swappiness, such as high I/O load despite available RAM, erratic response times, and sluggish database queries. I check for these patterns using vmstat, iostat, sar, and metrics from my observability stack. If the system shows high swap usage despite having free RAM, I usually lower the swappiness. If I see OOM logs or crashes when RAM is tight, I moderately increase the swappiness or adjust the swap configuration. The following table categorizes symptoms of a likely Cause and provides an initial direction.
| Symptom | Probable cause | Next step |
|---|---|---|
| High I/O when there is free RAM | Swappiness too high | Reduce the value, measure the impact |
| OOM events under load | Swappiness too low or not enough swap | Increase the value, check the swap size |
| Slow Queries despite CPU headroom | Database buffer swapped out | Value between 0 and 10; analyze DB buffer |
| Load peaks without a CPU bottleneck | Swap-induced I/O spikes | Reduce Swappiness, Check Cache Hits |
Understanding Fine-Grained Metrics
To objectively evaluate swappiness, I take a closer look at kernel counters. In /proc/vmstat, pswpin and pswpout indicate the number of pages brought in and swapped out, respectively. pgscan_kswapd_* and pgsteal_* show how aggressively the reclaimer is operating. If pgmajfault (major page faults) occur frequently, this indicates I/O-intensive reloads. I monitor these values repeatedly or using `sar -B` and `sar -W` to track rates, not just snapshots. Using `vmstat 1`, I can track `si/so` (swap in/out) and correlate spikes with actual events. Additionally, `/proc/pressure/memory` provides an estimate of how severely tasks are affected by memory pressure block (PSI). If those values rise slightly or significantly, that's a clear indication of overly aggressive reclaim or inappropriate swappiness.
Swappiness 0 vs. 1: What the Kernel Actually Does
It is often assumed that Swappiness=0 completely disables swapping. That is not entirely true. A value of 0 signals to the kernel to avoid swapping as much as possible and to use it only when there is genuine memory pressure. In practice, a value of 1–10 is sufficient to achieve very conservative behavior, while 0 can occasionally lead to delayed but intense reclaim phases in certain versions. For latency-critical services, I usually set it to 1–5 and monitor whether pswpout/pswpin remain practically at zero. If setting it to 0 causes OOM events during burst periods, I increase the value slightly so that the kernel gently relieves pressure earlier rather than abruptly. to break in.
Making Good Use of Zswap and ZRAM
In addition to traditional disk swapping, I use Zswap or ZRAM depending on the system profile. Zswap compresses swapped-out pages and keeps them in RAM initially before moving them to the disk when needed. This reduces I/O and smooths out latency, but it consumes CPU resources. On hosts with ample CPU headroom, this is a more profitable Trade-off. ZRAM provides compressed swap directly in RAM—ideal for bursty workloads or very small VMs, where I prefer to use compressed RAM rather than slow I/O. Important: I deliberately choose one of the approaches and set priorities so that the fastest path is served first. Swappiness remains a control lever: even with Zswap/ZRAM, I want to avoid unnecessary reclaim waves.
Page Cache, vfs_cache_pressure, and Cache Hits
Swappiness interacts with the page cache, which holds files and inodes in RAM. I use `vm.vfs_cache_pressure` to control how aggressively the kernel evicts these caches to make room for anonymous pages. Values that are too high cause metadata caches to disappear too quickly, which slows down web servers. I usually start with 50–100, measure cache hit rates, and observe how latencies behave for static assets and API responses. The goal is to keep frequently accessed content in RAM without letting rarely accessed pages clog up memory. If the hit rate remains good and I/O stays low, the balance is right; otherwise, I adjust swappiness and vfs_cache_pressure in the Tandem.
Avoiding Dirty Writebacks and I/O Spikes
Write paths affect latencies just as much as swap. Using `vm.dirty_background_ratio/bytes` and `vm.dirty_ratio/bytes`, I determine how much dirty cache is built up before the kernel writes it out. I prefer *_bytes over percentages to set defined upper limits—especially in configurations with large amounts of RAM, where percentages can generate massive writeback surges. Goal: continuous, predictable write-back instead of sporadic bursts that, together with swap, cause I/O locks. I monitor iostat and the writeback queues and maintain values so that SSD/NVMe are consistently utilized but not run over become.
NUMA, Zone Reclaim, and Large Hosts
On NUMA systems, memory locality plays a role. If `vm.zone_reclaim_mode` is enabled, the kernel may reclaim memory on the local NUMA node more aggressively, which can unintentionally trigger reclaim spikes. For many hosting workloads, I disable zone reclaim and let the scheduler handle placement to achieve smoother behavior. I also check Transparent Huge Pages (THP): Databases often perform better with THP=never or madvise, because unplanned defragmentation and THP allocations can cause latency spikes. Swappiness can be set to the optimal value—but if THP or NUMA policies interfere, the Stuttering.
Container and Cgroups Details
With Cgroups v2, I have additional controls beyond host swappiness: `memory.high` triggers soft reclamation, `memory.max` sets hard limits, and `memory.swap.max` limits swap usage per workload. This prevents individual containers from slowing down the host via swap. I set low swappiness values on the node and prioritize critical workloads using `memory.low` so that their hot sets remain in RAM longer. In Kubernetes, I monitor how the node handles swap and test changes first in non-production pools. It’s important to take a holistic view: host parameters, cgroup limits, and the orchestrator must all align; otherwise, the pressure simply shifts from one level to others.
Rollout, Automation, and Relapse
I roll out Swappiness changes—like any performance optimization—in a controlled manner: first on a small group of nearly identical nodes (Canary), then gradually expanding the scope. Systemd-sysctl or configuration management tools incorporate the values in a reproducible way. I document starting and target values, timestamps, the hosts involved, and Metrics. In case of a relapse, I plan the reversal in advance (e.g., sysctl vm.swappiness=60) and keep the previous sysctl files. During maintenance windows, I deliberately measure typical load scenarios so that I don’t confuse changes with fluctuations in the time of day or traffic. This is the only way to ensure that decisions remain reliable and consistent across the team. comprehensible.
Common Misconceptions and Anti-Patterns
- „Swappiness=0 disables swapping“: No, the kernel continues to use swap—but only very sparingly.
- „More swap is always safer“: Too much swap space prolongs periods of high load and masks RAM bottlenecks rather than resolving them.
- „With NVMe, swapping doesn't matter“: NVMe is fast, but orders of magnitude slower than RAM. Latency remains noticeable.
- „One value for all servers“: Workloads vary greatly. Without measurement, tuning is left to chance.
- „Swappiness fixes any latency“: Problems often stem from cache hits, writeback, THP, query plans, or network paths.
Quick start summary
I typically set vm.swappiness to 10–20 for web servers and 0–10 for databases, test the effect, and monitor I/O, latencies, and Swap-ratio. I set the final value in /etc/sysctl.d/ using sysctl and keep track of any changes. At the same time, I ensure a consistent swap layout: appropriate size, fast storage medium, and sensible priorities. When it comes to memory pressure, I also monitor the page cache and its behavior; this overview provides a good starting point for Page Cache Eviction, which helps me analyze the causes and Context . This approach allows me to achieve reliable response times, prevent page-out storms, and make effective use of available RAM.
