Asciiroot Systems

Linux troubleshooting guide

Linux memory pressure and OOM: an investigation guide

High memory use, an application termination and a confirmed out-of-memory event are not interchangeable. Identify the affected workload and event before changing memory limits or kernel settings.

Before you begin: The examples are for Linux. The journal command requires systemd; container and cgroup paths depend on the runtime and version. These examples are not executed or verified against your system. Obtain authorization, protect sensitive output and involve the responsible owner.

Clarify the incident

Collect the relevant scope and timeline before choosing an action:

  • Which process or container was affected, and was an OOM event actually recorded?
  • What are the host and container memory limits, workload trend and time of the event?
  • Did the workload, deployment or resource limits change recently?

Possible explanations

These are alternatives to investigate, not confirmed causes:

  • A workload spike, leak or insufficient host capacity may cause pressure; compare usage over time.
  • A container or service limit may be exhausted even when the host still has available memory.

Read-only checks

Replace example names and paths only after confirming the applicable platform, permissions and change policy. Command output can contain sensitive data.

Linux: memory overview

Compare available memory and swap with workload history. If the host has headroom but a container failed, inspect that container’s own limit; this snapshot does not establish a cause.

free -h

Linux with systemd: kernel events

Look for an event matching the affected process and time. No matching event in the last 50 lines does not rule out an earlier or container-level limit; logs may be sensitive.

journalctl -k -n 50 --no-pager

Interpret the evidence

Host memory overview

Compare available memory, swap and trends rather than treating low free memory alone as an OOM event. A single snapshot cannot establish whether a workload has a leak.

A process was killed

A SIGKILL or exit status 137 is not, by itself, proof of an OOM kill. Correlate kernel or runtime evidence with the process, host and event time.

Host has headroom but a container fails

Inspect the affected workload and its actual cgroup or runtime limit. Host-wide memory figures do not establish how much memory that container can use.

Plan recovery and verification

  1. Confirm impact and safety: Identify affected workloads, users and the responsible on-call team. Avoid unapproved restarts or tuning changes.
  2. Collect evidence: Review redacted memory, process, container-limit and kernel-event information appropriate to the actual operating system and version.
  3. Investigate the cause: Compare workload behavior, limits, recent changes and available capacity before deciding whether the issue is a leak, limit or transient demand.
  4. Prepare rollback: Keep prior settings and a recovery plan available; test changes in an approved environment before production.
  5. Plan and verify a change: Agree on a controlled mitigation, record the baseline, and verify application health and memory trends afterward.

Watch for recurrence: Record baseline and post-change workload, memory and limit trends. If the termination recurs, capture the same event details and compare workload demand, configured limits and recent changes before adjusting values again.

Documentation pointers

Check the documentation for your product and installed version. These links are references, not live verification.

Explore a safe demonstration

The scenario lab illustrates a fixed example. It does not reproduce this incident or verify a production fix, and it never executes your commands.

Open the related scenario lab

Related Linux guides