Docker Exit Code 137 in Kubernetes und Deep Learning: Vollständige Schritt-für-Schritt-Anleitung zur Behebung von OOMKilled-Containern

Um den Docker Exit Code 137 (Linux fatal signal 9 SIGKILL: 128 + 9 = 137) in Kubernetes oder containerisierten KI-Pipelines zu beheben, müssen Sie umgehend die Speicherlimits für den Container in Ihrer Pod-Spezifikation (resources.limits.memory) erhöhen oder ein IPC-Volume für gemeinsamen Speicher (/dev/shm) für PyTorch-DataLoader-Worker einbinden. Wenn der Linux-Cgroups-v2-Kernel erkennt, dass die Speicherauslastung eines Prozesses das harte Cgroup-Limit überschreitet, löst er den OOM Killer aus, um PID 1 zu beenden. Eine Erweiterung von /dev/shm über ein speicherbasiertes Volume oder --ipc=host stoppt Abstürze des PyTorch DataLoaders sofort.

Was den Exit Code 137 in containerisierten KI-Workloads auslöst

Der Exit Code 137 tritt auf, wenn ein containerisierter Prozess durch SIGKILL beendet wird. Dies wird fast ausschließlich durch den Out-Of-Memory (OOM) Killer des Linux-Kernels verursacht, der die Speicher-Cgroup-Limits durchsetzt. Bei Workloads im Bereich des maschinellen Lernens übergeben Multiprocessing-Instanzen von PyTorch via DataLoader(num_workers > 0) Tensor-Batches über /dev/shm (Shared Memory). Docker-Container sind standardmäßig auf eine winzige zugewiesene Shared-Memory-Größe von 64 MB eingestellt, wodurch Worker an die Kernel-Grenzen stoßen und sofort den Code 137 auslösen.

Schritt 1: Diagnose des Beendigungsgrunds mit dmesg und kubectl

Überprüfen Sie, ob der Absturz durch OOM auf Systemebene oder durch Container-Cgroup-Limits verursacht wurde, indem Sie Folgendes ausführen:

# Inspect host kernel ring buffer for OOM events
dmesg -T | grep -E -i "killed process|oom_reaper|out of memory"

# For Kubernetes Pod inspection
kubectl describe pod ai-inference-worker-pod -n production | grep -A 8 "Last State"
# Look for: Exit Code: 137, Reason: OOMKilled

Schritt 2: Shared Memory (/dev/shm) in Docker und Compose erweitern

Überschreiben Sie das standardmäßige Shared-Memory-Limit von 64 MB in Ihrem Docker-CLI-Aufruf oder Ihrer Compose-Datei:

# Docker CLI: Set shared memory size to 16GB
docker run --gpus all --shm-size=16g -it pytorch-training:latest

# Docker Compose Configuration
services:
  training-node:
    image: pytorch-training:latest
    shm_size: '16gb'
    deploy:
      resources:
        limits:
          memory: 32G

Schritt 3: Kubernetes Shared Memory mit emptyDir konfigurieren

Kubernetes verfügt über keinen nativen shmSize-Parameter. Binden Sie stattdessen ein speicherbasiertes emptyDir-Volume in Ihrer Pod-Spezifikation an /dev/shm ein:

apiVersion: v1
kind: Pod
metadata:
  name: pytorch-worker-cluster
spec:
  containers:
  - name: trainer
    image: nvcr.io/nvidia/pytorch:26.02-py3
    resources:
      requests:
        memory: "28Gi"
      limits:
        memory: "32Gi"
    volumeMounts:
    - mountPath: /dev/shm
      name: dshm
  volumes:
  - name: dshm
    emptyDir:
      medium: Memory
      sizeLimit: "16Gi"

Wenn Ihre Workload neben dem Containerspeicher-Engpass auch eine VRAM-Erschöpfung aufweist, lesen Sie unseren Leitfaden zur Fehlerbehebung unter CUDA Out of Memory in PyTorch and vLLM.

Schritt 4: Absicherung von Hintergrund-Webhook-Workern gegen OOM-Spitzen

Ereignisgesteuerte Mikroservices, die Webhook-Nutzdaten verarbeiten, starten unter Last oft unbegrenzte Subprozesse, was zu OOM-Abstürzen des Containers führt. In unserer Produktionsreferenz zu Production Webhook Pipelines with Node.js and Stripe erfahren Sie, wie Sie ein Backpressure-Queueing implementieren.

Schritt 5: Feinabstimmung der vLLM-Speicherzuteilungen

Bei der Modellinferenz im großen Maßstab müssen die Speicherlimits innerhalb von Container die RAM-Kapazität des Host-Systems mit dem GPU-VRAM in Einklang bringen. In unserem umfassenden Leitfaden zur vLLM PagedAttention Optimization erfahren Sie, wie Sie physische Speicherseiten anpassen.