An out-of-memory kill is a protective action taken when a relevant memory domain cannot satisfy demand. Identify whether the kernel, a cgroup limit or userspace memory-pressure policy terminated the process before choosing a remedy.
IN THIS ARTICLE
Gather the details you will need
Record the process, incident time, workload and recent deployment. Preserve kernel and service logs. Confirm actual host memory and any container or systemd memory limit, because a local limit can be exhausted independently of total machine RAM.
01 Investigate an out-of-memory process kill on Linux
- Inspect kernel logs around the incident for OOM messages and the selected victim. Read the surrounding memory information rather than assuming the killed process was the only cause.
- Check the service journal and, where enabled, systemd-oomd events. Userspace pressure-based termination can have a different trigger from a kernel allocation failure.
- For a cgroup-managed service, inspect its effective memory limit, current use and memory.events counters through the supported management interface. Compare the limit with the application's legitimate peak demand.
- Review process growth, concurrency, cache sizing and recent changes. A restart may temporarily release memory while leaving a leak or traffic overload unresolved.
- Apply the measured correction: fix application growth, reduce worker concurrency, adjust an appropriate limit or increase physical capacity. Use swap only as part of an assessed memory plan.
02 Example: distinguish a kernel OOM event from a service limit
On a systemd-based Linux server, inspect recent kernel records and the memory settings of the affected service. Replace example-app.service with its actual unit name. These commands collect evidence without changing limits or restarting the application.
sudo journalctl -k -b --grep="Out of memory|Killed process" --no-pager
systemctl show example-app.service -p MemoryCurrent -p MemoryMax -p ResultRead the result: A matching kernel event identifies the process selected during an out-of-memory incident. MemoryMax can reveal an explicit service boundary. In systemctl output, MemoryMax=infinity means that unit setting has no finite limit. A parent slice, container or hosting platform can still impose a separate restriction.
If the kernel log is empty, inspect the service log and systemd-oomd events where that component is used. Correlate the incident with traffic and recent jobs. Adding host RAM alone may not resolve a low per-service limit or an application memory leak.
Was the process that was killed definitely leaking memory?
No. Victim selection does not prove root cause. Correlate memory usage and limits across the workload before attributing the incident to one process.
Confirm the expected result
Repeat a representative safe workload and monitor peak memory, pressure and application latency. Confirm no new OOM events and that the service's restart behavior does not create a crash loop or repeated transaction processing.
If the problem continues
Do not universally exempt important-looking processes with extreme OOM adjustments or disable all memory limits. That can move the failure to the whole host. If multiple guests are affected, investigate host overcommit. If one container fails with free host RAM, inspect its limit and workload before purchasing unrelated capacity.