Troubleshooting the Linux OOM Killer on a VPS

An application that disappears without its usual shutdown message may have been killed because memory ran out, but that conclusion needs evidence. A crash, administrative action, or container limit can look similar from the application side. Establish what terminated the process before adding memory or changing kernel settings. The process chosen as a victim is not automatically the process that created all the pressure.

Find evidence around the failure time

On a systemd guest, inspect the kernel journal around the incident with journalctl -k --since "30 minutes ago" --no-pager. Look for messages describing memory exhaustion and the affected process or control group. Pair those timestamps with the application and service-manager logs. Access to kernel messages may require administrative privileges. Preserve a small relevant excerpt privately, removing any sensitive paths or data before sharing it. If persistent logs were not enabled, a reboot may have removed the previous boot's evidence.

Distinguish a local limit from whole-guest pressure

A service can hit its own memory boundary while the rest of the VPS still has memory available. Linux control groups expose memory limits and events; the kernel's cgroup v2 documentation describes the relevant controls. Inspect the actual configuration used by your service manager or container runtime. Do not assume that increasing the VPS allocation also increases a separately configured container limit. Conversely, removing a limit can let one workload consume memory needed by unrelated services.

Reconstruct the workload at the time

Write down which jobs ran, how many application workers existed, and whether a deployment overlapped traffic. For example, an export that loads a large query result into memory may be harmless on a small test database but fail on production data. If the service restarts automatically, current memory usage can look healthy because the large allocation is already gone. Historical metrics and the job's input size are more useful than a single post-restart process list.

Reduce a known peak before changing everything

Choose a targeted remedy supported by the evidence. Process records in bounded batches, cap concurrent jobs, review cache size, or reserve maintenance capacity. If demand is legitimate and unavoidable, choose a plan that covers the measured peak with room for the other services. Do not disable the OOM mechanism or protect every process from selection as a generic fix. The machine still has finite memory, and hiding the symptom does not provide the missing capacity.

Test the same failure condition deliberately

Repeat the triggering operation with representative data in a controlled environment. Observe memory growth, completion time, request latency, and any service-limit events. An export that succeeds only because nobody is visiting the site has not passed the original scenario. Also check the integrity of work interrupted by the earlier kill: partial files, incomplete jobs, and retries may need application-specific recovery. Preserve retry identifiers where the application uses them so a failed attempt does not accidentally create duplicate business actions.

Keep the recovery record with your guest administration notes and use LayerOne documentation for platform access if SSH becomes unreliable. The plan catalog is the place to compare memory allocations once you know whether the limit is inside the guest or at the VPS resource level.