How to Spot Memory Pressure on a VPS Before the OOM Killer Hits

A common support ticket across hosting providers starts with a sudden database crash. A website throws a database connection error, the administrator logs into their VPS, restarts MySQL or MariaDB, and notices that the standard hosting control panel dashboard shows memory usage sitting comfortably around seventy percent. Because the server never reached a flat one hundred percent on the provider graph, the disappearance of the process looks like a bug, a corrupted table, or a hypervisor fault. In reality, Linux servers rarely die from a neat, gradual consumption curve that reaches full capacity. The Linux Out-of-Memory (OOM) killer triggers when the kernel cannot satisfy an immediate allocation request for a memory page, even if total memory usage over a five-minute monitoring interval looked manageable. If you want to stop these unexpected crashes, you need to look past generic utilization graphs and examine how much time the kernel spends fighting to reclaim pages.

Checking the Kernel Ring Buffer for the Eviction Event

When a service disappears without writing an error to its own application logs, the first step is to confirm whether the kernel terminated it. When memory becomes critically exhausted and synchronous page reclaim fails to free sufficient contiguous space, the kernel invokes out_of_memory(). It calculates a badness score for running processes—heavily weighting the proportion of physical RAM consumed—and abruptly terminates the highest-scoring candidate to keep the operating system functional. You can verify this immediately using dmesg or journalctl to search for kernel messages associated with the invocation:

BASH

dmesg -T | grep -E -i 'oom[-_]killer|killed process'

If the OOM killer was active, the output displays the timestamp, the victim process name, its process ID (PID), and the total virtual and physical memory pages it held at termination. Standard database engines are prime targets because their buffer pools naturally occupy the largest contiguous chunks of RAM on a web server. If this log entry exists, your service did not fail on its own; the kernel sacrificed it to save the rest of the operating system.

Reading Pressure Stall Information

Knowing that the OOM killer struck tells you what happened, but it does not tell you how close the server was to failing before the crash occurred. Traditional metrics like the free or used counters in free -m are misleading because Linux deliberately uses spare memory for file system caching (page cache) and reclaims it dynamically when applications request more space. To see whether the system is struggling to satisfy memory requests, modern Linux kernels (version 4.20 and newer, with CONFIG_PSI=y enabled) provide Pressure Stall Information (PSI). PSI measures the real execution time lost because tasks are waiting for memory-related work, such as paging in code or waiting for direct page reclaim. You can inspect memory pressure directly from the /proc filesystem:

BASH

cat /proc/pressure/memory

The output contains two metrics: some and full. Both display rolling stall percentages over ten seconds, sixty seconds, and three hundred seconds (five minutes), alongside an absolute counter in microseconds showing the total cumulative stall time. The some metric shows the percentage of time during which at least one active task on the system was blocked waiting for memory. This commonly happens during normal background writeback or routine page reclaim when web workers handle traffic. A small non-zero value on some during traffic peaks is normal for a small VPS. The full metric represents complete stall time: the percentage of time during which all runnable tasks on the system were stalled waiting for memory simultaneously. In this state, no productive CPU work occurs because every active thread is waiting for the kernel to scavenge or swap pages. If the sixty-second or three-hundred-second average on the full line climbs above zero, your VPS is suffering severe memory thrashing. The OOM killer typically arrives shortly after full pressure stays sustained, because allocation requests begin to time out or queue up faster than the kernel can free physical pages.

Assessing True Headroom and Reclaim Health

If PSI indicates rising pressure, the next diagnostic step is evaluating your actual headroom. Rather than calculating memory as total minus used, read /proc/meminfo and focus on MemAvailable. MemAvailable is the kernel's estimate of how much RAM can be allocated to a new or expanding process without forcing the system into swap or direct reclaim. It takes into account non-reclaimable slab caches and the minimum watermark thresholds that the kernel reserves for its own core allocations. When MemAvailable drops below five to ten percent of total physical RAM, any sudden concurrency spike—such as multiple PHP-FPM workers spawning simultaneously—will drive allocation latency sharply upward. At the same time, check whether your VPS has swap space configured and active. A small VPS without swap gives the kernel zero flexibility when anonymous memory (process heap and stack) expands. Without swap, the kernel can only free memory by dropping clean file-backed page caches. Once the page cache is depleted down to its essential binaries and libraries, the kernel has no further pages it can drop, leaving direct allocation failure as the only possible outcome. Adding a modest swap file on NVMe or SSD storage does not degrade database performance under normal conditions; instead, it provides a buffer. It gives the kernel a place to push dormant background processes (such as logging daemons or idle SSH sessions), preserving unfragmented RAM for the primary web and database engines.

Establishing Headroom Before the Kernel Intervenes

Preventing unexpected terminations requires addressing both headroom and visibility. For visibility, monitoring systems should scrape /proc/pressure/memory or set up kernel threshold notifications via epoll rather than relying solely on total RAM utilization. Alerting on a sustained rise in the 60-second some pressure gives administrators minutes of warning to adjust pool sizes or investigate traffic anomalies before the system drops into full stalls. For service stability, database buffer pools must be scaled to account for bursty neighbours on the same host, especially PHP processes. If an instance runs both a web server and MySQL, capping the database pool to leave ample room for peak web worker spikes prevents synchronous allocation stalls. By diagnosing pressure via PSI and maintaining a healthy MemAvailable reserve, you turn silent service drops into predictable, measurable capacity planning.