Distinguish a container memory limit from a VPS out-of-memory event

An application can run out of memory while the VPS still has free RAM. A container, service or parent control group may impose a smaller budget. Conversely, an abruptly stopped VPS cannot usually explain a hypervisor incident through its own logs alone. Use evidence from the correct layer before deciding what needs more memory.

Start with the guest and the failed workload

Record the application failure time and whether the whole VPS rebooted.
Check current guest memory and boot time:

free -h
uptime -s
sudo journalctl -k -b --since "30 minutes ago" --no-pager

Look for memory-related kill messages around that time. Current free memory after a process exited is not a measurement of the pressure immediately before it exited. A Java heap error is also not the same event as the kernel killing a process.

Read the container configuration

For a Docker-managed workload, replace my-container with its name:

docker inspect --format 'Memory={{.HostConfig.Memory}} OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}}' my-container
docker stats --no-stream my-container

The configured memory value is in bytes; zero means Docker did not set that specific hard limit. It does not prove that an ancestor cgroup is unlimited. The OOM flag and exit code are clues to combine with timestamps and logs. Exit code 137 by itself only indicates a SIGKILL-style exit, not its cause. Docker access is highly privileged; use it only on a server you administer.

Inspect cgroup v2 events when available

For a systemd service, obtain its control-group path:

systemctl show myapp.service -p ControlGroup

Replace myapp.service. On a cgroup v2 host, read the returned directory beneath /sys/fs/cgroup, using its actual path:

cat /sys/fs/cgroup/ACTUAL-GROUP/memory.current
cat /sys/fs/cgroup/ACTUAL-GROUP/memory.max
cat /sys/fs/cgroup/ACTUAL-GROUP/memory.events

memory.max may contain max. Event counters are cumulative; compare snapshots around a reproduced failure rather than treating an old nonzero count as a new incident. Ancestor limits matter. If these files are absent, check the cgroup version instead of creating files or changing kernel settings.

Decide what the evidence supports

A rising workload OOM counter alongside a finite limit supports investigating that workload’s budget. Guest-wide OOM logs need a broader memory review. A completely unresponsive or restarted VPS without a guest explanation needs provider-side investigation. Send support the service identifier, UTC failure time, relevant counters and redacted log lines. Do not disable the OOM killer or raise every limit to unlimited. After an agreed adjustment, repeat the workload and compare memory use and new event counts over a representative period.