RAM Planning: Spotting Memory Pressure Before the OOM Killer

Most RAM disasters are visible hours before they happen, if you look at the right numbers. The Linux out-of-memory killer does not strike randomly; it strikes when the kernel can no longer reclaim enough memory to satisfy a demanding allocation. The skill is reading the run-up: the buff/cache column, the pressure metrics, and swap activity that reveals you were already past the tipping point.

The columns that mislead you

free at the surface looks simple, but its columns hide the real state. The buff/cache column is not wasted RAM nobody is using; it is page cache, recently read file data that the kernel will drop instantly when an application needs memory. High buff/cache is normal and good. The trap is confusing it with pressure.

What actually matters is the memory that cannot be reclaimed without work: anonymous pages, backing processes, and locked regions. Watch those, not the raw free number, which the kernel will always push toward zero.

Pressure during the climb

The kernel exposes memory pressure precisely through the PSI interface. memory.pressure reports how often tasks were delayed waiting for memory, over the last ten seconds, minute, and five minutes. When the ten-second average on the some line climbs and stays high, tasks are actively blocked on memory; that is pressure, not noise.

cat /proc/pressure/memory
cat /proc/pressure/cpu
free -m
grep AnonPages /proc/meminfo

The AnonPages number is the ground truth for how much anonymous memory your processes own. If it grows steadily while the available column shrinks, you are filling real usage, not cache. That is the precursor to the OOM killer.

A watch loop that catches the climb

Rather than check once, sample a rolling window so you can see the trend rather than a single snapshot. This loop logs the numbers that predict out-of-memory:

while true; do
  date +%FT%T
  grep -E '^(MemAvailable|MemFree|SwapFree|AnonPages):' /proc/meminfo
  awk '{ print "mem-some", $1 }' /proc/pressure/memory
  sleep 30
done > /var/log/memwatch.log 2>&1

Leave that running for a day. The pattern that predicts trouble is AnonPages climbing linearly while MemAvailable falls and the ten-second memory pressure stays elevated. If swap is present and SwapFree is dropping, you are already past the point of comfort.

Understanding what the OOM killer sees

When the kernel needs memory it cannot reclaim, it scores processes and kills the most expensive one. The score weighs resident set size against how much that process is actively using. The common surprise is that a caches-friendly machine can OOM while free still shows gigabytes in buff/cache, because cache is reclaimable in theory but the kernel was unwilling to wait.

Practically that means two failure shapes:

• **Steady leak**: a process grows until the kernel kills it, restarts, grows again. Logs show repeating PID kills.
• **Sudden spike**: a single request allocates a huge chunk and exhausts the budget in seconds.

The steady leak is fixable by finding and capping the leak. The spike is fixed by raising available RAM or limiting the largest allocations.

Swap and overcommit change the maths

Two kernel settings shape how a memory crunch plays out, and both are worth knowing before you debug a mystery kill. Swappiness (vm.swappiness) decides how eagerly the kernel moves anonymous pages to swap. On a VPS with solid-state storage, a modest swappiness value keeps file cache working while still allowing a slow bleed of cold anonymous pages rather than an abrupt OOM.

cat /proc/sys/vm/swappiness
cat /proc/sys/vm/overcommit_memory
# tune for a cache-heavy web server
sysctl -w vm.swappiness=10

Overcommit memory controls whether the kernel approves allocations that may not be covered by real backing memory. The default heuristic mode works for most apps but hides the true worst case. If an application asks for far more than it will actually touch, the heuristic happily over-commits and a bursting process can still cross the real physical line. The numbers in /proc/pressure are the honest signal regardless of the mode you set.

The practical consequence: seeing a quick spike in swap activity right before a process dies often means the working set briefly exceeded memory, the kernel relocated pages, and the OOM killer then removed the offender. That pattern, not a slow leak, points at a request that briefly demanded too much. Capping the request path or adding memory addresses it directly.

What to do once you see pressure

• Confirm it is real usage: AnonPages growing with MemAvailable dropping, not just cache turnover.
• Check process-level RSS to find the top consumer with ps aux --sort=-rss.
• Cap or cache the leak if it is a slow growth inside one process.
• If the workload legitimately needs more, increase RAM rather than fight it with ulimits.

Takeaway

Buff/cache is your friend; AnonPages pressure is the storm signal. Sample the trend, not a snapshot, and act on the climb before the kernel acts for you. When the workload really needs more headroom, resize to a larger plan on Netbay from the dashboard or the API at netbayhosts.in.