Confirm the OOM cause
Match a terminated process to a time-specific kernel, cgroup or systemd-oomd record before calling it an OOM event.
A worker or job can disappear while the VPS remains up. 'Killed', exit 137 or a failed unit alone does not prove OOM. Record the service, incident time and zone, last successful request and any guest reboot; preserve errors before restarting.
This guide investigates a terminated process. For a general CPU/RAM trend without a known termination, use the linked resource-pressure guide. If the whole VPS is unreachable, follow the console and boot guides first. For VM Start with Managed OS, the customer retains root access; coordinate OS changes with Novasean and keep application analysis with its owner.
Look for a matching OOM record
An authorised guest operator can check systemctl status example.service for the affected unit, replacing the name with the real service. A result such as oom-kill is stronger evidence than an isolated exit code. Then inspect kernel messages for the relevant boot and time window with sudo journalctl -k -b --since "2026-10-13 10:00" --until "2026-10-13 10:30"; replace both example times and convert the observed incident time to the guest journal's local time basis. Add --no-pager for a non-interactive read. Search that output for Out of memory, oom-kill or Killed process, and match the process or cgroup, timestamp and service. If the guest rebooted, sudo journalctl -k -b -1 selects the previous boot where retained journal data exists.
No matching entry does not prove that memory was adequate: journals may be volatile, rotated, inaccessible, or from the wrong boot. Preserve the complete relevant event and the surrounding resource readings in an access-controlled incident record. Do not paste application arguments, environment variables or unredacted logs into a public ticket.
A normal memory snapshot after a kill can hide the earlier peak; use the incident-time record and cumulative counters with their time context.
Distinguish a service limit from whole-guest pressure
Linux can terminate a process when a memory-controlled service or container reaches its own limit even while the VPS has apparent free RAM. Ask the authorised operator to compare the service’s configured memory limit and cgroup OOM evidence with guest-wide available memory, swap use and time-aligned workload metrics. On systems using cgroup v2, memory.events records counters including oom and oom_kill. Its counts are hierarchical and can include descendant cgroups; memory.events.local reports local events. Check the affected service's actual cgroup path and descendants. A counter is also cumulative, so a before/after change or matching journal event is needed to associate it with this incident. Some systems also run systemd-oomd, a userspace memory-pressure killer; check its service journal before attributing every termination to the kernel OOM killer.
Do not assume that a high “used memory” number proves exhaustion: Linux can reclaim some cache. Equally, a normal snapshot taken after a process was killed may hide the earlier peak. Match the evidence to the failure time rather than diagnosing from a single current reading.
Illustrative distinction: a cgroup OOM counter rose during a worker kill while guest-wide memory remained available. Review the service limit and matching journal event before requesting more VM RAM.
Choose a reversible response and verify
If the affected application recently changed, have its owner review the release, workload, concurrency, cache and memory growth; keep a known-good application version available. If the service limit is intentional, do not raise it blindly: confirm that the guest and other services have headroom. If whole-guest memory pressure is sustained, ask for a capacity review with the same time-stamped evidence. Swap can change how pressure behaves, but is not a substitute for adequate RAM and may trade a kill for severe latency. Changing OOM scores or disabling an OOM handler can move the failure to another service and is not a first response.
For a VPS under an agreed Novasean managed-service scope, route privileged guest and included-service changes to the named platform operator; the application owner should investigate its workload and accept the result. Check the accepted order for any different access or responsibility arrangement. Agree a maintenance and rollback route before a limit, package or size change. After the change, reproduce the original workload if safe, compare the same service outcome and memory evidence, and watch for a repeat termination. Escalate promptly if a stateful service such as a database was killed; verify application data and recovery needs before resuming writes.
Common questions
Does exit status 137 mean the VPS needs more RAM? No. It commonly reflects a SIGKILL termination, which can have other causes. Match it to a kernel, cgroup or userspace OOM record and the workload before deciding.
Can a VPS have free RAM while one service is OOM-killed? Yes. A service or container memory limit can be exhausted independently of guest-wide memory.
Will rebooting fix the cause? A reboot may restore availability but remove volatile evidence. Record the failure and agree a recovery step with the responsible operator first.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.