Linux OOM Killer Configuration: Disabling Memory Overcommit by Default (vm.overcommit_memory=2) Best Practices


1 views

The Linux Out-of-Memory (OOM) killer has been a persistent pain point for system administrators and developers. The default memory overcommit policy (vm.overcommit_memory=0) can lead to sudden process termination when the system encounters memory pressure, often killing critical applications without warning.

Setting vm.overcommit_memory=2 in /etc/sysctl.conf makes the kernel strictly enforce memory allocation limits. This is particularly valuable for:

  • Production servers running mission-critical applications
  • Database servers (MySQL, PostgreSQL, MongoDB)
  • Containers with strict memory constraints
  • Real-time systems where predictable behavior is essential

To permanently disable overcommit and set a conservative ratio:

# /etc/sysctl.conf
vm.overcommit_memory = 2
vm.overcommit_ratio = 50

Apply changes immediately with:

sudo sysctl -p

With strict overcommit enabled (mode 2), follow these guidelines:

  • Set vm.overcommit_ratio between 50-80% of physical RAM
  • Maintain swap space equal to your RAM size (minimum)
  • For memory-intensive workloads, consider: SWAP = RAM × 1.5

Memory overcommit (vm.overcommit_memory=0 or 1) remains useful for:

  • Development environments with unpredictable memory patterns
  • Systems running many processes with low individual memory needs
  • Legacy applications that assume unlimited memory availability
  • Certain Java applications with aggressive heap allocation patterns

Implement these checks when running with strict overcommit:

# Check available memory
free -h

# Monitor OOM score adjustments
cat /proc/[pid]/oom_score_adj

# Track memory allocation failures
grep -i oom /var/log/syslog

Any sysadmin who's managed Linux servers long enough has horror stories about the OOM (Out-of-Memory) killer. This kernel mechanism randomly terminates processes when the system runs out of memory, often choosing critical applications over actual memory hogs. The fundamental issue lies in how Linux handles memory allocation through overcommitment by default.

Linux provides three overcommit modes through the vm.overcommit_memory parameter:

0 (default): Heuristic overcommit
1: Always overcommit
2: Strict no-overcommit

For servers, mode 2 (vm.overcommit_memory=2) is often preferable as it:

  • Prevents memory exhaustion by enforcing hard limits
  • Gives predictable malloc() behavior
  • Eliminates random OOM kills

To make this change persistent:

# Add to /etc/sysctl.conf
vm.overcommit_memory = 2
vm.overcommit_ratio = 80  # Percentage of RAM available for allocations

# Apply immediately
sysctl -p

With strict overcommit, you need to carefully configure:

# Calculate available commit space:
Total Commit = (RAM * overcommit_ratio/100) + Swap

# Example for 16GB server with 4GB swap:
(16 * 0.8) + 4 = 16.8GB total commit space

Best practices:

  • Start with overcommit_ratio=80 for general workloads
  • Adjust ratio down for memory-intensive applications
  • Maintain swap space at 25-50% of RAM

Some legitimate use cases for overcommit (mode 0 or 1):

  • Applications with sparse memory access patterns (certain scientific computing)
  • Legacy applications written with overcommit assumptions
  • Controlled environments where you fully understand memory requirements

Essential tools for managing memory under strict overcommit:

# Check current memory commitments:
cat /proc/meminfo | grep Commit

# Watch allocation failures:
grep -i oom /var/log/messages
dmesg | grep -i "out of memory"

# Real-time monitoring:
vmstat 1