VPS & Linux
Linux OOM troubleshooting: find what exhausted memory
The Linux OOM killer is a last-resort response when the kernel cannot satisfy memory allocations under the current constraints. The process it kills is evidence of a system-wide pressure event; it is not always the process that originally caused the memory problem.
Read the kernel record first
Use journalctl or kernel logs to find the OOM event, cgroup context, memory totals, process scores, and killed process. Container or service limits can trigger an OOM inside a cgroup even when the whole VPS still has memory available.
Preserve the timestamp and the process table around the event if monitoring has it. Restarting the application restores service but removes useful context.
Find growth before the kill
Compare memory time series, worker counts, queue depth, request concurrency, database/cache sizes, imports, builds, and deployments. A leak often shows a steady trend; a batch job may create a sharp temporary peak.
Check whether swap was available and whether the system was already reclaiming aggressively.
Reduce the actual allocation pressure
Fix leaks, bound concurrency, cap queues, tune oversized caches or heaps, and move large maintenance jobs when those are the cause. Service-level memory limits can protect the rest of the server, but a limit that is too low simply moves the OOM boundary inward.
Do not disable the OOM killer; a system that cannot reclaim or terminate anything may become less recoverable.
Resize when the healthy peak is legitimate
If the measured working set and legitimate peak do not fit the plan after tuning, add memory. Retest the same scenario and verify that application latency, memory pressure and restart behavior improve and that the change does more than delay another kill.
- Capture the kernel OOM record.
- Check cgroup versus host pressure.
- Find the growth pattern before the event.
- Retest after tuning or resize.