How to fix Container killed due to OOM (Out of Memory) in Docker

First, verify that OOM was the cause of the container exit:

docker inspect --format='{{.State.OOMKilled}}' <container_name>

If this returns true, the container was killed by the OOM killer. Also check the exit code:

docker inspect --format='{{.State.ExitCode}}' <container_name>

Exit code 137 indicates the process received SIGKILL (typically from OOM killer).

Check system logs for OOM events:

dmesg | grep -i "out of memory"
# or
grep -i "oom" /var/log/syslog

Monitor your container's memory usage in real-time:

docker stats <container_name>

Check the current memory limit:

docker inspect --format='{{.HostConfig.Memory}}' <container_name>

This returns bytes (0 means no limit). To see human-readable format:

docker inspect <container_name> | grep -A 5 "Memory"

Run your application under load and observe peak memory usage to understand actual requirements.

Set an appropriate memory limit when running the container:

docker run --memory=1g --memory-swap=1g <image>

Common memory flags:
- --memory or -m: Hard limit on memory usage
- --memory-swap: Total memory + swap limit (set equal to --memory to disable swap)
- --memory-reservation: Soft limit for memory reservation

Example with a 2GB limit:

docker run -d \
  --name myapp \
  --memory=2g \
  --memory-swap=2g \
  --memory-reservation=1g \
  myimage:latest

For Docker Compose, add to your service:

services:
  myapp:
    image: myimage:latest
    deploy:
      resources:
        limits:
          memory: 2G
        reservations:
          memory: 1G

Many runtimes need explicit configuration to respect container limits:

Node.js: Set max heap size to ~75% of container memory:

docker run --memory=1g -e NODE_OPTIONS="--max-old-space-size=768" node-app

Java (JDK 8u191+): Enable container awareness:

docker run --memory=1g \
  -e JAVA_OPTS="-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0" \
  java-app

Python: For memory-intensive operations, consider using generators and chunked processing. Set process limits:

import resource
resource.setrlimit(resource.RLIMIT_AS, (1024*1024*1024, 1024*1024*1024))

Go: Go respects cgroups since Go 1.19. Set GOMEMLIMIT:

docker run --memory=1g -e GOMEMLIMIT=750MiB go-app

Allow some swap to handle temporary memory spikes:

docker run --memory=1g --memory-swap=2g <image>

This gives 1GB RAM + 1GB swap. The container can burst to 2GB total, with excess going to swap.

Note: Swap is slower than RAM and may cause performance issues. Use it as a buffer, not a replacement for adequate memory.

For Docker Desktop, enable swap in Settings > Resources.

To check current swap configuration:

docker info | grep -i swap

If the container keeps getting OOM killed despite adequate limits, investigate memory leaks:

Profile your application: Use language-specific tools:
- Node.js: --inspect flag with Chrome DevTools
- Java: JVisualVM, Eclipse MAT, or async-profiler
- Python: memory_profiler, tracemalloc
- Go: pprof

Check for common leak sources:
- Unbounded caches or queues
- Event listeners not being removed
- Database connection pools growing indefinitely
- Large objects held in memory longer than needed

Add application-level memory limits:

// Node.js example: limit cache size
const LRU = require('lru-cache');
const cache = new LRU({ max: 500 }); // max 500 items

Monitor memory over time to identify gradual growth patterns.

Set up proactive monitoring to catch issues before OOM:

Using docker stats in a script:

#!/bin/bash
while true; do
  docker stats --no-stream --format "{{.Name}}: {{.MemPerc}}" | \
    while read line; do
      pct=$(echo $line | grep -oP '[0-9.]+(?=%)')
      if (( $(echo "$pct > 80" | bc -l) )); then
        echo "WARNING: $line"
      fi
    done
  sleep 10
done

With Docker Compose healthchecks:

healthcheck:
  test: ["CMD", "sh", "-c", "test $(cat /sys/fs/cgroup/memory/memory.usage_in_bytes) -lt 900000000"]
  interval: 30s
  timeout: 10s
  retries: 3

Consider using Prometheus + cAdvisor for production monitoring.