OOMKilled
The container was forcefully terminated by the kernel because its memory usage exceeded the set limit or exhausted host RAM.
Usually happens because:
- ☑ Container memory usage exceeded hard ceiling limit
- ☑ Host machine physical RAM exhausted
- ☑ Memory leak inside runtime process
🔍 Quick Checklist:
What is OOMKilled?
OOMKilled (Out of Memory Killed) is a status set by the Docker daemon when the host operating system's kernel terminates a container process to free up memory. This happens when the container's memory consumption exceeds the hard limit specified by the --memory or -m flag, or when the host machine runs out of physical RAM and swap memory, prompting the Linux kernel's OOM Killer to select and terminate the container process.
Common Causes
- Exceeded container memory limit: The application consumed more RAM than allowed by the container's runtime configurations.
- Host memory exhaustion: The host machine ran out of physical memory, forcing the kernel OOM killer to terminate processes.
- Memory leaks in application: Undetected memory leak issues in the application running inside the container.
| Cause | Frequency |
|---|---|
| Container memory cap limit hit | ⭐⭐⭐⭐⭐ |
| Host system physical RAM depletion | ⭐⭐⭐⭐ |
| Application memory leak | ⭐⭐⭐⭐ |
Common Mistakes
- Setting hard memory limits on containers (`-m 256m`) without setting corresponding application heap limits, leading to silent container crashes.
- Ignoring background memory overheads like sidecars or database caching processes in Docker Compose files.
How to Fix
Docker Operations & Verification
Configure the Node.js garbage collector heap size to stay safely within container memory limits.
# Start node container with memory limit and garbage collection flag
docker run -m 512m node:20 node --max-old-space-size=450 index.js
# Prevents container OOMKilled by crashing Node internally before hitting container limits.Platform Specific Fixes
Check kernel system syslog messages to verify OOM events.
sudo tail -n 100 /var/log/messages | grep -i oom
# Or check systemd journal
journalctl -p 3 -xb | grep -i oomBest Practices
- Configure container restart policies cautiously (`restart: on-failure`) to avoid endless crash loops on memory leaks.
- Always set memory reservations (soft limits) in conjunction with hard limits.
Frequently Asked Questions (FAQ)
Q: What is OOMKilled?
It is a container state flag indicating that the container's main process was terminated by the kernel's Out of Memory killer.
Q: How does OOMKilled differ from exit code 137?
Exit code 137 is a generic exit code representing SIGKILL (which can be triggered manually by 'docker stop' or 'docker kill'). OOMKilled is a specific flag confirming the SIGKILL was triggered by the OOM killer due to memory exhaustion.
Q: Will Docker automatically restart OOMKilled containers?
Only if the container has a restart policy (like 'restart: always' or 'restart: on-failure') configured, but if the memory issue persists, it will enter a crash loop.
Q: How do I prevent OOMKilled on JVM apps?
Set appropriate Java heap memory limits (like '-Xmx') or use `MaxRAMPercentage` to ensure the JVM knows its bounds before hitting the container limits.