Alles über Docker Shared Memory (shm_size und ipc)

Zusammenfassung des Beitrags:
1. shm_size ist ein temporärer Speicherbereich, der RAM nutzt.
2. Bei Verwendung von ipc: host wird shm_size ignoriert, und stattdessen werden 50% der Host-Ressourcen zugewiesen.
3. Oft sieht man in AI-Modell-Beispielen ipc: host und shm_size gleichzeitig konfiguriert, obwohl es für die Lesbarkeit besser ist, nur eines davon einzustellen.
4. Für AI-Workloads werden mindestens 8G-16G oder mehr empfohlen; passen Sie die Einstellung an Ihre Umgebung an.

🐳 Essenzielle Einstellung für AI-/Daten-Workloads: Docker Shared Memory (shm_size und ipc) vollständig verstehen

Wenn Sie bei AI- und großen Datenverarbeitungs-Workloads unerklärliche Fehler wie OSError: No space left on device erlebt haben, liegt dies meist an einer unzureichenden Shared-Memory-Einstellung (shm_size) des Docker-Containers.

Dieser Beitrag erklärt klar, warum Shared Memory in Container-Umgebungen wichtig ist und wie die Optionen shm_size und ipc: host korrekt konfiguriert werden sollten.

1. Rolle und Bedeutung von shm_size

Rolle: Bestimmung der Shared-Memory-Größe des Containers

shm_size ist eine Option, die die maximale Größe des /dev/shm (POSIX shared memory) Dateisystems innerhalb des Containers festlegt.

• Docker-Standardwert ist 64MB, was sehr klein ist.
• Achtung: /dev/shm ist ein tmpfs (temporäres Dateisystem), das den Host-RAM verwendet und nichts mit VRAM (GPU-Speicher) zu tun hat.

Warum ist es wichtig?

AI-/Datenverarbeitungsaufgaben nutzen diesen Shared Memory intensiv, um große Datenmengen zwischen Prozessen auszutauschen.

• PyTorch DataLoader: Wenn num_workers > 0 eingestellt ist, werden Tensoren/Batches über Shared Memory zwischen Worker-Prozessen übertragen. Ist dieser Speicherplatz unzureichend, tritt der Fehler OSError: No space left on device auf.
• TensorRT Engine Build/Serving: Verwendet Shared Memory für große temporäre Artefakte oder IPC-Puffer. Bei unzureichendem Speicher kann der Engine-Build fehlschlagen oder es kommt zu Segmentierungsfehlern.
• Multiprocessing und IPC-Kommunikation: Unverzichtbar für den Austausch großer Arrays/Puffer zwischen Prozessen in NCCL, OpenCV, NumPy und anderen Anwendungen.

2. ipc-Einstellungen: Isolationsbereich des Shared Memory

Der IPC (Inter-Process Communication) Namespace ist eine Docker-Option, die festlegt, in welchem Umfang der Inter-Prozess-Kommunikationsbereich (Shared Memory, Semaphore usw.) eines Containers isoliert werden soll.

3. Funktionsweise bei gleichzeitiger Verwendung von shm_size und ipc: host (Beispielanalyse)

Bei AI-/LLM-Aufgaben werden oft shm_size: "16g" und ipc: host zusammen konfiguriert. Wir werden anhand eines praktischen Beispiels untersuchen, welche Einstellung dabei tatsächlich angewendet wird.

Test: Ergebnisse bei Verwendung von ipc: host

Wir haben shm_size und ipc: host wie folgt gemeinsam eingestellt:

shm_size: "16g"
ipc: host

Anschließend haben wir die Größe von /dev/shm innerhalb des Containers überprüft.

~$df -h /dev/shm
Filesystem      Size  Used Avail Use% Mounted on
tmpfs            60G  8.3M   60G   1% /dev/shm

Beobachtungsergebnis: Statt der in shm_size eingestellten 16GB wird die /dev/shm-Größe des Hosts von 60GB angezeigt.

Fazit: ipc: host ignoriert shm_size.

Warum dieses Ergebnis??

1. Wenn ipc: host angewendet wird: Der Container verwendet den IPC-Namespace des Hosts unverändert.
2. shm_size: "16g" wird ignoriert: Diese Option ist nur relevant, wenn ein eigener IPC-Namespace verwendet wird.
3. Herkunft der 60G: Ein Host-Linux-System konfiguriert /dev/shm standardmäßig oft auf etwa die Hälfte des gesamten RAMs. Im obigen Beispiel sieht der Container also 60G, die Hälfte der 120G des Hosts.

Nochmals betont

Wenn ipc: host eingestellt ist, verwendet der Container den Shared-Memory-Bereich des Hosts direkt, sodass die shm_size-Einstellung tatsächlich nicht angewendet wird.

4. Wählen Sie die Speicherverwaltungsmethode passend zu Ihrer Umgebung und Ihrem Zweck

Stabilität vs. Container-spezifische Isolation

1. Stabilität zuerst: ipc: host beibehalten

Dies ist die bequemste Methode. Sie nutzt die großzügigen RAM-Ressourcen des Hosts direkt. Sie eignet sich für Einzelbenutzer-/Einzelprojektumgebungen, in denen mehrere Container Ressourcen ohne Probleme teilen können. Die 50%ige Nutzung des Hosts ist nur ein Höchstwert; nur der tatsächlich genutzte Speicher belegt RAM, daher ist es bequemer, diese Einstellung beizubehalten, solange kein Speicherdruck besteht.

• Einstellung: Nur ipc: host beibehalten (man sieht oft shm_size zusammen damit, aber es ist bedeutungslos, also löschen Sie shm_size ruhig).
• Ergebnis: Es wird die großzügige /dev/shm-Größe des Hosts verwendet (z. B. 60G).

2. Erzwingung einer Obergrenze pro Container: ipc: host entfernen

Wird in Multi-Tenant-Umgebungen verwendet oder wenn verhindert werden muss, dass ein bestimmter Container übermäßig viel RAM belegt.

• Einstellung: ipc: host entfernen + shm_size: "8g" oder "16g" explizit angeben.
• Ergebnis: Ein dedizierter 16GB /dev/shm für den Container wird erstellt.
• Vorteil: Wenn mehrere Container laufen, kann die Obergrenze für die Shared-Memory-Nutzung jedes Containers klar begrenzt werden, um den Host-RAM zu schützen und zu isolieren.

Hinweis: So passen Sie die Größe des Host-Shared-Memory an (bei Verwendung von ipc:host)

Wenn Sie bei Verwendung von ipc: host die Größe von /dev/shm des Hosts selbst ändern möchten, müssen Sie die tmpfs-Einstellungen anpassen.

1. Temporäre Größenänderung (wird nach Neustart zurückgesetzt):

sudo mount -o remount,size=16G /dev/shm

Wird sofort auf alle Prozesse/Container angewendet.

2. Permanente Größenänderung (Änderung in /etc/fstab):

# Fügen Sie die folgende Zeile zur Datei /etc/fstab hinzu/ändern Sie sie
tmpfs /dev/shm tmpfs defaults,size=16G 0 0

Nach dem Speichern neu starten oder den obigen remount-Befehl für die sofortige Anwendung verwenden.