> 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 {#sec-2161daf65756} 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. ![Vergleichsbild von shm_size und ipc-Methoden](/media/whitedec/blog_img/5c8cd9fb5f93404fb70bc6019e296acf.webp) --- ## 1. Rolle und Bedeutung von shm_size {#sec-21161777e576} ### Rolle: Bestimmung der Shared-Memory-Größe des Containers {#sec-5e3ff7cb88f8} **`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? {#sec-8127b7b9aeb4} 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 {#sec-6d4d31fe3ee4} 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. | **ipc-Einstellung** | **Verhaltensweise** | **Größenbestimmung von /dev/shm** | | --- | --- | --- | | **Standard (weggelassen)** | Verwendet den **eigenen IPC-Namespace** des Containers (isoliert) | Die mit `shm_size` angegebene Größe (Standard **64MB**) | | **`ipc: host`** | Container teilt den **IPC-Namespace des Hosts** | **Größe von `/dev/shm` des Hosts** (üblicherweise die Hälfte des RAM) | | **`ipc: container:`** | IPC-Teilung mit einem anderen angegebenen Container | Folgt der Einstellung des Zielcontainers | --- ## 3. Funktionsweise bei gleichzeitiger Verwendung von shm_size und ipc: host (Beispielanalyse) {#sec-77e6ca4c4b62} 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` {#sec-f473e8607f63} Wir haben `shm_size` und `ipc: host` wie folgt gemeinsam eingestellt: ```yaml shm_size: "16g" ipc: host ``` Anschließend haben wir die Größe von /dev/shm innerhalb des Containers überprüft. ```bash ~$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 {#sec-d62a63904765} ### Stabilität vs. Container-spezifische Isolation {#sec-870976b9ffe0} #### 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) {#sec-5e365d4f36e8} 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.