Alles over Docker Shared Memory (shm_size en ipc)

Samenvatting:
1. shm_size is een tijdelijke opslagruimte die gebruikmaakt van RAM.
2. Wanneer je ipc: host gebruikt, wordt shm_size genegeerd en wordt er 50% van de hostbronnen toegewezen.
3. In veel AI-modelconfiguraties zie je vaak dat ipc: host en shm_size tegelijkertijd zijn ingesteld, terwijl het voor de leesbaarheid beter is om slechts één van de twee te gebruiken.
4. Voor AI-workloads wordt minimaal 8G~16G of meer aanbevolen; stel dit in op basis van je eigen omgeving.

🐳 Essentiële configuratie voor AI/data-workloads: Docker gedeeld geheugen (shm_size en ipc) volledig begrijpen

Als je bij AI- en grootschalige dataverwerkingsworkloads onverwachte fouten hebt ervaren, zoals OSError: No space left on device, komt dit vaak door een tekort aan gedeeld geheugen (shm_size) in de Docker-container.

Deze post verduidelijkt waarom gedeeld geheugen belangrijk is in een containeromgeving en hoe je de opties shm_size en ipc: host correct configureert.

1. De rol en het belang van shm_size

Rol: De grootte van het gedeelde geheugen van de container bepalen

shm_size is een optie die de maximale grootte instelt van het /dev/shm (POSIX shared memory) bestandssysteem binnen een container.

• De standaardwaarde van Docker is 64MB, wat erg klein is.
• Let op: /dev/shm is een tmpfs (tijdelijk bestandssysteem) dat host-RAM gebruikt en heeft niets te maken met VRAM (GPU-geheugen).

Waarom is dit belangrijk?

AI/dataverwerkingstaken maken essentieel gebruik van dit gedeelde geheugen wanneer ze grote hoeveelheden gegevens uitwisselen tussen processen.

• PyTorch DataLoader: Wanneer num_workers > 0 is ingesteld, geeft het tensors/batches door via gedeeld geheugen tussen worker-processen. Als deze ruimte onvoldoende is, treedt de fout OSError: No space left on device op.
• TensorRT engine build/serving: Maakt uitgebreid gebruik van gedeeld geheugen voor grote tussenliggende artefacten of IPC-buffers, en bij onvoldoende ruimte kan dit leiden tot mislukte engine builds of segmentatiefouten.
• Multiprocessing en IPC-communicatie: Essentieel voor het delen van grote arrays/buffers tussen processen in onder andere NCCL, OpenCV en NumPy.

2. IPC-instelling: Isolatiebereik van gedeeld geheugen

IPC (Inter-Process Communication) namespace is een Docker-optie die bepaalt in welke mate de interprocescommunicatieruimte (gedeeld geheugen, semaforen, etc.) van een container wordt geïsoleerd.

3. Werkingsprincipe bij gelijktijdig gebruik van shm_size en ipc: host (voorbeeldanalyse)

Bij AI/LLM-taken worden shm_size: "16g" en ipc: host vaak tegelijkertijd geconfigureerd. Laten we met een praktisch voorbeeld bekijken welke instelling dan van toepassing is.

Test: Resultaten bij gebruik van ipc: host

We hebben shm_size en ipc: host samen geconfigureerd, zoals hieronder.

shm_size: "16g"
ipc: host

Vervolgens hebben we de grootte van /dev/shm in de container gecontroleerd.

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

Waargenomen resultaat: In plaats van de ingestelde 16GB voor shm_size, wordt de /dev/shm-grootte van de host (60GB) weergegeven.

Conclusie: ipc: host negeert shm_size.

Waarom dit resultaat??

1. Wanneer ipc: host wordt toegepast: Gebruikt de container de IPC-namespace van de host ongewijzigd.
2. shm_size: "16g" wordt genegeerd: Deze optie is alleen relevant wanneer een eigen IPC-namespace wordt gebruikt.
3. Herkomst van 60G: Host Linux-systemen configureren /dev/shm standaard vaak als de helft van het totale RAM. In het bovenstaande voorbeeld ziet de container dus de 60G, wat de helft is van de 120G van de host.

Nogmaals benadrukt

Wanneer ipc: host is ingesteld, gebruikt de container de gedeelde geheugenruimte van de host ongewijzigd, waardoor de shm_size-instelling in feite niet wordt toegepast.

4. Kies de geheugenbeheerstrategie die past bij jouw omgeving en doel

Streven naar stabiliteit versus containerisolatie

1. Stabiliteit eerst: ipc: host behouden

Dit is de meest zorgeloze methode. Je gebruikt de royale RAM-bronnen van de host direct. Geschikt voor een omgeving met één gebruiker/één project waar het delen van resources tussen meerdere containers geen probleem is. Het gebruik van 50% van de host is slechts een maximum; alleen het daadwerkelijke gebruik neemt RAM in beslag, dus als er geen geheugendruk is, is het handig om dit zo te laten.

• Configuratie: Behoud alleen ipc: host (Hoewel shm_size vaak samen met ipc: host in voorbeelden voorkomt, is het overbodig; wees gerust om het te verwijderen.)
• Resultaat: Gebruikt de ruime /dev/shm-grootte van de host (bijv. 60G).

2. Maximale limiet per container afdwingen: ipc: host verwijderen

Te gebruiken in een multi-tenant omgeving of wanneer je wilt voorkomen dat een specifieke container buitensporig veel RAM in beslag neemt.

• Configuratie: ipc: host VERWIJDEREN + shm_size: "8g" of "16g" expliciet opgeven
• Resultaat: Er wordt een 16GB /dev/shm specifiek voor de container aangemaakt.
• Voordelen: Wanneer meerdere containers draaien, kan de maximale limiet voor gedeeld geheugengebruik van elke container duidelijk worden beperkt, waardoor host-RAM wordt beschermd en isolatie mogelijk is.

Opmerking: Hoe de grootte van het gedeelde hostgeheugen aan te passen (bij gebruik van ipc:host)

Als je de /dev/shm-grootte van de host zelf wilt wijzigen terwijl je ipc: host gebruikt, moet je de tmpfs-instellingen aanpassen.

1. Tijdelijk de grootte wijzigen (teruggezet na herstart):

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

Wordt onmiddellijk toegepast op alle processen/containers.

2. Permanent de grootte wijzigen (/etc/fstab aanpassen):

# /etc/fstab bestand toevoegen/wijzigen met de volgende regel
tmpfs /dev/shm tmpfs defaults,size=16G 0 0

Na opslaan opnieuw opstarten of direct toepassen met het remount-commando.