Troubleshooting VPS Out-Of-Memory (OOM) Errors and RAM Spikes

Virtual Private Servers (VPS) allocate dedicated slices of physical server resources (like CPU cores and RAM) to individual environments using virtualized isolation. While this provides consistent performance, a virtual server has strict memory boundaries. If your web server, database, or applications consume more memory than allocated, the server will experience a critical RAM spike. When system memory is exhausted, the Linux kernel triggers the Out-Of-Memory (OOM) Killer daemon, terminating active processes like Apache, LiteSpeed, or MySQL to keep the OS running.

When the OOM Killer strikes, services crash unexpectedly without standard warning logs, leaving administrators wondering why their site is suddenly offline. In this guide, we will analyze how Linux manages memory allocation, check system crash logs, and walk through the SSH commands needed to configure swap space, tune application memory limits, and prevent OOM crashes.

1. How the Linux OOM Killer Operates

The Linux kernel uses memory overcommit rules to optimize resource usage. The kernel assumes that applications will not use all of their allocated RAM at the same time, allowing it to allocate more virtual memory than is physically available in the system.

However, if applications simultaneously request more memory than the server has available, the kernel faces a memory deficit. To prevent the operating system from crashing or freezing, the kernel activates the OOM Killer. The daemon assigns an OOM score to each active process based on its RAM consumption and runtime priority. The process with the highest score—often your primary web server or database engine—is terminated immediately, and a crash log is written to system event logs.

2. Step-by-Step Memory Diagnostics via SSH

To troubleshoot OOM errors, log into your server via SSH as the root user. Run these diagnostic commands to check log events, monitor active memory usage, and set up swap files.

Step 2.1: Search System Logs for OOM Events

When the OOM Killer terminates a process, it logs the event in system messages. Check your system logs for OOM records by running:

grep -i -E 'oom-killer|kill process' /var/log/messages
# Or on Ubuntu/Debian systems
grep -i -E 'oom-killer|kill process' /var/log/syslog

If the search returns matches, the output will list the date, time, process name, and PID of the terminated application (e.g., Killed process 1234 (mysqld) total-vm:1850380kB, anon-rss:720540kB), confirming that a RAM spike occurred.

Step 2.2: Monitor Real-Time Memory Usage

To view your server's current RAM allocations, active processes, and cache sizes, run the following commands:

free -m                      # View RAM usage in megabytes
top -o %MEM                  # View active processes sorted by memory usage
htop                         # Interactive process monitor (if installed)

Review the output to see if a specific process is consuming high volumes of RAM, or if memory caches are not releasing resources. Pay attention to database processes like MySQL/MariaDB and web server daemons.

Step 2.3: Configure Linux Swap Space

If your VPS does not have a swap partition configured, the system has no buffer when physical RAM is exhausted, leading to quick OOM crashes. Setting up a swap file allocates disk space to act as temporary virtual memory, helping absorb sudden memory spikes.

To create and activate a 2GB swap file on your server, run the following commands:

dd if=/dev/zero of=/swapfile bs=1M count=2048   # Create swap file
chmod 600 /swapfile                            # Set secure permissions
mkswap /swapfile                               # Format as swap space
swapon /swapfile                               # Activate the swap file

To ensure the swap space is mounted automatically during server reboots, append the mount rule to your fstab file:

echo '/swapfile none swap sw 0 0' >> /etc/fstab

Verify that the swap space is active by running free -m or swapon --show.

Step 2.4: Tune MySQL and Web Server Memory Pools

Adding swap space helps prevent crashes, but resolving the underlying issue requires tuning your applications to operate within your server's physical RAM boundaries. For MySQL/MariaDB, configure the InnoDB buffer pool size (which should be set to approximately 50-70% of available RAM on dedicated database servers, or lower on shared hosting servers) in your configuration file:

# Edit /etc/my.cnf
[mysqld]
innodb_buffer_pool_size = 512M  # Set based on server RAM limits

For web servers like Apache or LiteSpeed, restrict the maximum number of worker processes or child connections to prevent memory exhaustion under high traffic loads.

3. Memory Optimization Checklist

Frequently Asked Questions (FAQ)

Why does the kernel kill MySQL instead of other processes?

The OOM Killer calculates scores based on RAM consumption. Because MySQL/MariaDB database engines typically consume the highest amount of memory on web hosting servers, they are often assigned the highest OOM score and terminated during memory spikes.

Does swap space slow down my website?

Yes. Disk read/write speeds are significantly slower than physical RAM speeds. When the system uses swap space (a process called swapping), website response times can slow down. Swap space should be used as a backup buffer to prevent service crashes, not as a replacement for physical RAM.

What is swappiness in Linux?

Swappiness is a Linux kernel parameter (value 0 to 100) that defines how aggressively the system uses swap space. A higher value increases swap usage, while a lower value instructs the kernel to prioritize physical RAM. For web hosting servers, we recommend setting swappiness to 10 or 15 to prioritize physical memory performance.