Skip to content

RAM and SWAP management

Introduction

In the previous article, I covered the topic of SWAP management.
🧠 Do you need swap?
In this one, I would like to explain how we can manage RAM and SWAP operations in our system.

vm.min_free_kbytes 📊

Description:
Specifies the minimum amount of free memory (in kilobytes) that the kernel will try to maintain.

Significance:

  • Prevents complete RAM exhaustion
  • Allows kernel to maintain memory reserve for high-priority processes
  • Too high value can cause unnecessary data transfer to SWAP
  • Too low value can lead to performance issues when memory is low

Check and change: 

# Check current value
sysctl vm.min_free_kbytes
# Set new value (e.g., 100MB)
sysctl -w vm.min_free_kbytes=102400

Note

Default value is calculated by kernel based on total memory. For systems with low RAM (< 4GB), values from 16MB to 64MB are appropriate. For systems with more memory (> 32GB), values of 256MB-1GB can be considered.

vm.overcommit_memory

Description:
Controls the kernel's memory allocation policy when processes request more memory than physically available.

Values:

  • 0: (default) heuristic memory allocation. Kernel evaluates each request and denies only when memory is critically low.
  • 1: always allocate memory, regardless of current availability (useful for applications using fork()).
  • 2: deny memory allocation when request exceeds sum of available physical RAM and SWAP space.
# Check current value
sysctl vm.overcommit_memory
# Enable strict memory allocation policy
sysctl -w vm.overcommit_memory=2
🔧 vm.overcommit_memory = 1 (relaxed mode)

Recommended when:

  • 🧠 using applications that allocate lots of memory but don't use it immediately (e.g., Redis, PostgreSQL).
  • ✅ want to avoid allocation errors (malloc() might fail with setting 2).
  • 🛡️ have system with good OOM killer or configured swap.

⚠️ Risk:

  • possibility of memory overload and OOM killer activation
🛑 vm.overcommit_memory = 2 (strict mode)

Recommended when:

  • 🎯 Need predictable memory management (e.g., environments with multiple applications).
  • 🚫 Want to avoid RAM overload risk and OOM killer activation.

❌ Drawbacks:

  • Some applications may not work correctly if they reserve large memory blocks at startup (e.g., Redis, PostgreSQL).

⚙️ Requires setting vm.overcommit_ratio:

  • Default: 50 (% of physical RAM that can be allocated).
  • Can be increased, e.g.:
    sysctl -w vm.overcommit_ratio=80

vm.overcommit_ratio 📈

Description:
Defines the percentage of physical memory that can be allocated when vm.overcommit_memory is set to 2.

Significance:

  • Higher value allows more aggressive memory allocation
  • Default value is usually 50 (50%)

Calculation formula for mode 2:

\[ CommitLimit = \left( RAM \times \frac{overcommit\_ratio}{100} \right) + SWAP \]
# Check current value
sysctl vm.overcommit_ratio
# Increase limit to 80%
sysctl -w vm.overcommit_ratio=80

Note

For systems with large memory and small SWAP space, consider increasing this value to 80-90%. For critical systems where stability is more important than efficient memory usage, lower values (30-50%) might be safer.

vm.dirty_ratio ⚠️

Description:
Maximum percentage of total system memory that can contain dirty memory pages (modified but not yet written to disk) before synchronous disk writing begins.

Significance:

  • When this limit is reached, processes writing data will be forced to wait for disk write completion
  • Can cause noticeable application freezes if value is too high
  • Default value is usually between 10% and 20%
# Check current value
sysctl vm.dirty_ratio
# Set new value
sysctl -w vm.dirty_ratio=15

Note

For desktop systems where smooth operation is priority, consider lower values (5-10%). For servers with high I/O operations and good quality storage, values of 20-30% can be considered.

vm.dirty_background_ratio 🔄

Description:
Percentage of total system memory that can contain dirty memory pages before background writing of this data begins.

Significance:

  • Lower than vm.dirty_ratio
  • Kernel starts writing data in background without blocking processes
  • Allows smoother system operation
  • Default value is usually between 5% and 10%
# Check current value
sysctl vm.dirty_background_ratio
# Set new value
sysctl -w vm.dirty_background_ratio=5

Note

This value should always be lower than vm.dirty_ratio. For general-purpose systems, values of 5-10% are appropriate. For systems with fast disks (SSD/NVMe), lower values (3-5%) can be considered.

vm.vfs_cache_pressure 🔍

Description:
Controls kernel's tendency to reclaim memory used by filesystem cache (dentry and inode).

Significance:

  • Higher value increases reclaim aggressiveness
  • Lower value decreases reclaim aggressiveness
  • Default value is usually 100
# Check current value
sysctl vm.vfs_cache_pressure
# Decrease pressure on cache removal
sysctl -w vm.vfs_cache_pressure=50

Example

You have an application (e.g., Nginx server or backup system) that: - frequently searches large directories, - frequently reads file metadata (size, type, permissions), - but doesn't use much RAM.

📉 Then you can decrease vm.vfs_cache_pressure e.g., to 50, so kernel keeps dentry/inode cache longer, which speeds up directory and file access.

vm.swappiness 🔄

Description:
Determines kernel's tendency to move data from RAM to SWAP space.

Values:

  • 0: Minimal SWAP usage (only as last resort)
  • 1-10: Very low SWAP usage
  • 60: Default value in most distributions
  • 100: Maximum SWAP usage (aggressive)
# Check current value
sysctl vm.swappiness
# Decrease tendency to use SWAP
sysctl -w vm.swappiness=10

Note

Topic covered extensively in this article

vm.page-cluster 📚

Description:
Defines number of memory pages moved simultaneously to SWAP space during swapout operation.

Significance:

  • Higher value increases SWAP write performance
  • May increase delays in single swap operations
  • Default value is usually 3 (meaning 2³ = 8 pages)
# Check current value
sysctl vm.page-cluster
# Decrease number of pages moved simultaneously
sysctl -w vm.page-cluster=2

Note

For systems with SSD/NVME drives using SWAP, values 2-3 are appropriate. For systems with slower HDD drives that heavily use SWAP, higher values (4-5) can be considered for better throughput.

vm.min_slab_ratio 🧱

Description:
Defines minimum percentage of kernel memory that should remain allocated to slab objects before memory reclaim begins.

Significance:

  • Lower value may increase aggressiveness of reclaiming memory from kernel object cache
  • Default value is usually 5%
# Check current value (if available)
sysctl vm.min_slab_ratio
# Set new value
sysctl -w vm.min_slab_ratio=3
🧱 vm.min_slab_ratio – what is SLAB?

SLAB is a memory management mechanism in Linux kernel used for efficient storage and management of small, frequently used data structures (e.g., inode, dentry, task_struct).

🗂️ How it works?
Think of SLAB as a set of drawers (cache), each storing only one type of objects – e.g., inodes. When system needs a new inode, it reaches into this drawer instead of creating it from scratch, which increases efficiency.

📈 Example:

You have a system with 16 GB RAM running as NFS server handling thousands of small files. Setting:

sysctl -w vm.min_slab_ratio=5

ensures that at least 5% RAM (about 800 MB) will be reserved for slab cache, preventing filesystem slowdown.

📌 Default value depends on kernel version but usually ranges between 5–10%.

👀 To check slab cache usage: 

cat /proc/meminfo | grep -i slab

vm.watermark_scale_factor ⚖️

Description:
Affects calculation of memory watermark thresholds that determine when system starts reclaiming memory.

Significance:

  • Higher value increases safety buffer
  • Can affect frequency of kswapd invocation (daemon responsible for swap)
  • Default value is usually 10 (10%)
# Check current value
sysctl vm.watermark_scale_factor
# Increase safety margin
sysctl -w vm.watermark_scale_factor=15

Note

For critical systems that cannot afford memory issues, consider increasing this value to 15-20%. For most systems, default value is appropriate.

Monitoring and testing 📊

Built-in tools 🛠️

  1. free - basic information about RAM and SWAP usage 

    free -h

  2. vmstat - virtual memory statistics, including swap activity 

    vmstat 5

  3. slabtop - kernel slab objects usage 

    slabtop

  4. cat /proc/meminfo - detailed memory state information 

    cat /proc/meminfo

Permanent parameter settings 📝

To preserve kernel parameter settings after system restart, create new file in /etc/sysctl.d/ directory and add them here.

Tip

You can add directly into `/etc/sysctl.conf` but it will not preserve kernel update (always run latest stable)

# /etc/sysctl.d/99-memory-parameters.conf
vm.swappiness = 10
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
vm.min_free_kbytes = 102400
vm.vfs_cache_pressure = 50

After creating or editing file, load new settings:

sysctl -p /etc/sysctl.d/99-memory-parameters.conf

Danger

**Context** - There are no universal "best" settings - optimal values depend on system specifics, hardware, and workload nature.
**Monitoring** - After changing parameters, monitor system for potential performance issues.
**Kernel Updates** - Some parameters may work differently or be removed in newer kernel versions.
**Interactions** - Parameters may interact with each other, so change them gradually and observe results.

Summary 📚

Proper adjustment of kernel parameters related to RAM and SWAP can significantly improve system performance. Values appropriate for one system may be suboptimal for another, depending on workload characteristics and available hardware.