How to fix OOMKilled in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 221 views

OOMKilled (exit code 137) means the Linux kernel terminated your container for exceeding its memory limit. Increase memory limits or optimize your application memory usage.

Quick fix

Fixes OOMKilled

kubectl describe pod <pod-name>
  1. Confirm OOMKilled is the termination reason
  2. Check current memory limits and usage
  3. Increase memory limits appropriately
  4. For Java applications, align JVM and container memory
kubernetes — error
kubectl describe pod <pod-name>
OOMKilled

What this error means

OOMKilled indicates that the Linux kernel's Out-Of-Memory (OOM) killer terminated a container because it exceeded its allocated memory limit. The container receives SIGKILL (signal 9), resulting in exit code 137 (128 + 9). This is a hard limit enforcement—unlike CPU throttling, memory overuse results in immediate termination. Importantly, OOMKilled applies to individual containers, not entire pods. If a pod has multiple containers, only the container that exceeded its limit is killed. The pod may continue running with remaining containers and will restart the killed container according to its restart policy.

Typical symptoms

  • Container shows OOMKilled as the termination reason in kubectl describe pod
  • Exit code 137 in container status or logs
  • Container restarts repeatedly with no application error logs
  • Memory usage graphs show container hitting its limit before restart
  • Application becomes unresponsive just before being killed
  • Sudden termination with no graceful shutdown messages in logs
  • Pod events show Back-off restarting failed container after OOM events

Common causes

  1. Memory limit set too low for actual application requirements
  2. Application has a memory leak causing gradual consumption growth
  3. Unexpected traffic spike causing higher than normal memory usage
  4. JVM heap configured larger than container memory limit allows
  5. Application spawning threads or processes that consume additional memory
  6. Large file processing or caching loading more data than expected
  7. Missing memory limits allowing unbounded growth until node pressure triggers OOM

How to fix "OOMKilled"

1Confirm OOMKilled is the termination reason

Check the container termination status:

bash
kubectl describe pod <pod-name>

Look for the Last State section showing:

bash
Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137

Also check kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[*].lastState}'

2Check current memory limits and usage

View the current resource configuration:

bash
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].resources}'

Monitor actual memory usage:

bash
kubectl top pod <pod-name>

Note: kubectl top requires metrics-server to be installed in your cluster.

3Increase memory limits appropriately

Update your deployment with higher limits based on observed usage:

yaml
resources:
  requests:
    memory: "512Mi"
  limits:
    memory: "1Gi"

Set requests to typical usage and limits to handle peak load. A common starting point is limits = 1.5x to 2x the requests value.

Apply changes: kubectl apply -f deployment.yaml

4For Java applications, align JVM and container memory

JVM heap is only part of Java memory usage. Account for metaspace, threads, and native memory:

yaml
env:
  - name: JAVA_OPTS
    value: "-XX:MaxRAMPercentage=75.0 -XX:+UseContainerSupport"

Or set explicit heap limits lower than container limits:

yaml
env:
  - name: JAVA_OPTS
    value: "-Xmx768m -Xms512m"  # For a 1Gi container limit

Leave at least 25% of container memory for non-heap usage.

5Profile application memory to identify issues

If limits seem adequate, the application may have a memory leak. Enable profiling:

bash
# For Java, generate heap dump on OOM
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof

For other languages, use appropriate profiling tools. Monitor memory growth over time with Prometheus/Grafana to identify leak patterns.

6Consider using Guaranteed QoS class

Set identical requests and limits to get Guaranteed QoS, which has the lowest OOM score:

yaml
resources:
  requests:
    memory: "1Gi"
    cpu: "500m"
  limits:
    memory: "1Gi"
    cpu: "500m"

Guaranteed pods are killed last when a node is under memory pressure. BestEffort pods (no limits) are killed first.

Advanced notes

Understanding QoS classes helps prevent OOMKilled: Guaranteed pods (requests = limits) have the lowest oom_score_adj (-997), Burstable pods (requests < limits) have medium priority, and BestEffort pods (no requests/limits) are killed first.

On EKS, use CloudWatch Container Insights to track memory trends. On GKE, note that the Cloud Console memory graphs may differ from kubectl top—always verify with kubectl for accurate readings. On AKS, the "Diagnose and Solve Problems" blade can help identify memory patterns.

For applications with unpredictable memory spikes, consider using Vertical Pod Autoscaler (VPA) to automatically adjust limits based on observed usage. However, be aware that VPA currently requires pod restarts to apply changes.

Node-level memory pressure can also trigger OOM kills even if individual containers are within limits. Monitor node memory with kubectl describe node and look for MemoryPressure conditions.

Frequently asked questions

What does "OOMKilled" mean?
OOMKilled indicates that the Linux kernel's Out-Of-Memory (OOM) killer terminated a container because it exceeded its allocated memory limit. The container receives SIGKILL (signal 9), resulting in exit code 137 (128 + 9). This is a hard limit enforcement—unlike CPU throttling, memory overuse results in immediate termination.
How do I fix "OOMKilled"?
OOMKilled (exit code 137) means the Linux kernel terminated your container for exceeding its memory limit. Increase memory limits or optimize your application memory usage.
What causes "OOMKilled"?
Memory limit set too low for actual application requirements Application has a memory leak causing gradual consumption growth Unexpected traffic spike causing higher than normal memory usage
Is the "OOMKilled" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading