Why Was a VPS Process OOM-Killed?

The Linux out-of-memory mechanism may terminate a process when memory cannot be reclaimed sufficiently. A container-specific memory limit can also trigger a kill even when the guest as a whole has some memory available.

Look for evidence

Inspect relevant kernel messages where permissions allow, for example sudo journalctl -k --since "1 hour ago" --no-pager. Look for out-of-memory or killed-process messages near the failure time. Review the service's own logs and container status if applicable.

An exit code associated with a kill is not proof of OOM by itself; administrators and other software can send the same signal. Correlate timestamps and memory evidence before concluding.

Find the actual limit

Check free -h, active swap, the largest processes and any systemd or container memory limits. A 1 GiB guest may have enough RAM for its steady workload but fail during an upgrade, build, cache expansion or traffic burst.

Multiple worker processes often duplicate memory. Database connection pools, per-query buffers and unbounded queues can also multiply consumption. Measure peak usage rather than relying only on an application's minimum requirement.

Prevent recurrence

Reduce concurrency, cap caches and correct leaks. Swap can cushion a short spike but is not a replacement for adequate RAM. A restart policy may restore service briefly while repeating the same failure; fix the resource mismatch or application behavior.

Keep a backup before changing database or memory configuration. If asking for help, share a redacted error and resource timeline, not process environment variables or secrets.

See memory and swap, Budget plan sizing and service logs.

Reference: Linux cgroup v2 memory documentation.