VPS memory pressure: how to spot RAM exhaustion before an OOM kill

Separate available memory from free memory

Start with MemAvailable, working-set behavior, cache, anonymous memory and swap. The Free column alone does not describe usable memory. Cache that the kernel can reclaim is different from application memory that must remain resident to avoid repeated faults.

Container limits, JVM heaps, database buffers, and PHP or worker concurrency can create pressure even when the machine-wide total looks comfortable at a glance.

Look for reclaim and swap symptoms

vmstat, pressure stall information, sar, and kernel logs can show whether the system is spending time reclaiming pages, swapping actively, or stalling allocations. A small amount of old data in swap is less important than sustained swap-in/swap-out while the application is busy.

Measure latency during the same window. Memory pressure often appears as long-tail response time, worker churn, slow database access or process restarts. A neat “memory full” error may never appear.

Find which workload owns the growth

Compare RSS or proportional memory by process, application pool sizes, database configuration, caches, queue workers, and recent deployments. A leak that grows slowly needs a time series; a one-time import or build may simply need a controlled maintenance window.

Do not raise every memory limit at once. That can let more processes consume RAM simultaneously and make the machine fail faster.

Choose between tuning and more RAM

Reduce unnecessary concurrency or oversized caches when the same work can fit efficiently. Add RAM when the healthy working set genuinely exceeds the current plan and the workload benefits from keeping that state resident. Preserve a rollback and monitor after the change.

• Track MemAvailable and PSI.
• Watch active swap traffic, not only swap occupancy.
• Identify the growing process class.
• Retest the same workload after tuning or resize.