Skip to content

Swap Behavior

Linux systems rely on swap space as a safety net when physical memory (RAM) is exhausted. While swap is slower than RAM, it can prevent out-of-memory (OOM) errors by allowing the kernel to offload inactive memory pages to disk. However, excessive swap usage can degrade performance. This section outlines best practices for configuring swap space and tuning kernel parameters to mitigate OOM issues effectively.

Configuring Swap Space

Guidelines for Swap Size

  • Traditional recommendation: Set swap size equal to RAM (e.g., 4GB RAM → 4GB swap). However, modern systems with large RAM (16GB+) may not require this.
  • Workload-specific adjustments:
  • Applications with memory spikes (e.g., databases, virtualization) may benefit from larger swap.
  • Embedded or low-memory systems should prioritize minimal swap to avoid disk contention.

Creating and Managing Swap Files

Use mkswap and swapon to create swap files dynamically: 

sudo fallocate -l 4G /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
Add the swap file to /etc/fstab for persistence: 
/swapfile none swap sw 0 0

Kernel Parameters for Swap Behavior

vm.swappiness

Controls how aggressively the kernel uses swap: - Default: 60 (balanced approach). - Recommendation: - Low-latency systems (e.g., servers): Set to 10 to prioritize RAM retention. - Workloads with memory spikes: Set to 60 or higher. 

sudo sysctl vm.swappiness=10
Add vm.swappiness=10 to /etc/sysctl.conf for persistence.

vm.vfs_cache_pressure

Affects how aggressively the kernel reclaims memory for file system caches: - Default: 100. - Tuning: Lower values (e.g., 50) retain more data in cache, which can improve I/O performance for read-heavy workloads.

vm.overcommit_memory and vm.overcommit_ratio

Controls memory overcommit behavior: - vm.overcommit_memory=2 (always overcommit) is useful for applications that allocate memory upfront (e.g., databases), but risks OOM if memory is insufficient. - vm.overcommit_ratio (default 50) limits overcommit based on RAM. Adjust based on workload requirements.

OOM Killer Tuning

Prioritizing Critical Processes

The OOM killer selects processes to terminate based on oom_score and oom_score_adj: - oom_score_adj: Lower values (e.g., -500) prioritize processes. Set this for critical services: 

echo -500 | sudo tee /proc/<pid>/oom_score_adj
- oom_score: Higher values indicate higher priority for termination. Avoid setting this manually; rely on oom_score_adj.

While possible via kernel.panic_on_oops=1, this risks system instability. Instead, configure swap and memory limits to avoid OOM scenarios.

Monitoring and Testing

Tools for Analysis

  • free/top/htop: Monitor memory and swap usage in real time.
  • dmesg: Check OOM killer logs (grep -i oom /var/log/dmesg).
  • stress-ng: Simulate memory pressure to test OOM handling: 
    stress-ng --vm-bytes 1G --vm-num 10 --vm-keep --timeout 60s

Key takeaways

  • Configure swap size based on workload and system constraints, not as a substitute for sufficient RAM.
  • Tune vm.swappiness to balance performance and OOM prevention, typically between 10-30 for servers.
  • Prioritize critical processes using oom_score_adj to avoid termination during memory shortages.
  • Monitor swap and memory usage regularly with tools like free and dmesg to detect OOM risks early.
  • Test memory limits with stress tools to validate tuning settings under load.