🐳 Configuration essentielle pour les charges de travail AI/données : Comprendre parfaitement la mémoire partagée Docker (shm_size et ipc)

Commandbox 광고

Si vous avez rencontré des erreurs inconnues telles que OSError: No space left on device lors du traitement de charges de travail AI et de données massives, c'est généralement dû à un paramètre de mémoire partagée (shm_size) insuffisant dans votre conteneur Docker.

Ce post clarifie pourquoi la mémoire partagée est importante dans un environnement de conteneur et comment configurer correctement les options shm_size et ipc: host.

1. Rôle et importance de shm_size

Rôle : Déterminer la taille de la mémoire partagée du conteneur

shm_size est l'option qui définit la taille maximale du système de fichiers /dev/shm (mémoire partagée POSIX) à l'intérieur du conteneur.

  • La valeur par défaut de Docker est très faible à 64 Mo.

  • Attention : /dev/shm est un tmpfs (système de fichiers temporaire) qui utilise la RAM de l'hôte, et n'est pas lié à la VRAM (mémoire GPU).

Pourquoi est-ce important ?

Les tâches de traitement AI/données utilisent cette mémoire partagée de manière cruciale pour échanger de grandes quantités de données entre processus.

  • PyTorch DataLoader : Lorsque num_workers > 0 est configuré, les processus travailleurs partagent des tenseurs/lot par mémoire partagée. Si cet espace est insuffisant, l'erreur OSError: No space left on device se produit.

  • Construction/serving de TensorRT : Utilise beaucoup de mémoire partagée pour les artefacts intermédiaires de grande taille ou pour les tampons IPC, et en cas de manque, cela peut entraîner l'échec de la construction de l'engin ou des fautes de segmentation.

  • Multiprocessing et communication IPC : Essentiel pour le partage de grands tableaux/tampons entre processus dans des bibliothèques comme NCCL, OpenCV, NumPy, etc.

2. Configuration d'ipc : portée d'isolation de la mémoire partagée

Commandbox 광고

L'espace de nom IPC (Inter-Process Communication) est l'option Docker qui détermine comment l'espace de communication entre les processus du conteneur (mémoire partagée, sémaphores, etc.) sera isolé.

Configuration ipc Mode de fonctionnement Détermine la taille de /dev/shm
Par défaut (omis) Utilisation de l'espace de noms IPC du conteneur (isolé) Taille spécifiée par shm_size (valeur par défaut 64 Mo)
ipc: host Partage de l'espace de noms IPC de l'hôte Taille de host /dev/shm (généralement la moitié de la RAM)
ipc: container:<ID> Partage IPC avec un autre conteneur spécifié Suivant la configuration du conteneur partagé

3. Fonctionnement conjoint de shm_size et ipc: host (Analyse d'exemple)

Dans le cadre des tâches AI/LLM, il est courant de configurer ensemble shm_size: "16g" et ipc: host. Découvrons quels paramètres sont appliqués à travers un exemple concret.

Exemple : Analyse des paramètres et des résultats

Extrait de configuration Docker Compose Résultat de la commande df -h /dev/shm à l'intérieur du conteneur
shm_size: "16g"
ipc: host		 Système de fichiers tmpfs Taille 60G
Utilisé 8.3M
Disponible 60G
Utilisation % 1%
Monté sur /dev/shm

Conclusion : ipc: host ignore le shm_size.

  1. Lorsque ipc: host est appliqué : le conteneur utilise l'espace de noms IPC de l'hôte.

  2. shm_size: "16g" est ignoré : cette option n'a de sens que lorsque l'on utilise son propre espace de noms IPC.

  3. Source des 60G : Le système Linux de l'hôte configure généralement /dev/shm à environ la moitié de la RAM totale. Ainsi, dans cet exemple, le conteneur voit directement les 60G qui sont la moitié des 120G de l'hôte.

Résumé clé

En paramétrant ipc: host, le conteneur utilise directement l'espace mémoire partagé de l'hôte, de sorte que la configuration shm_size n'est en réalité pas appliquée.

4. Méthodes d'exploitation recommandées et gestion des limites de mémoire

💡 Options recommandées en pratique

  1. ✅ Prioriser la stabilité (recommandé) : Conserver ipc: host

    • Configuration : Conserver uniquement ipc: host (ou le conserver avec shm_size si besoin)

    • Résultat : Utilisation d'une taille généreuse de /dev/shm de l'hôte (ex. : 60G).

    • Avantage : Prévenir fondamentalement les erreurs de manque de mémoire partagée dans la plupart des travaux AI/données et être le plus stable. 60G n'est qu'une taille maximale, seule la consommation réelle occupe la RAM, donc si aucun problème de mémoire n'est présent, il est facile de le laisser tel quel.

  2. ✅ Limiter la mémoire par conteneur : Supprimer ipc: host

    • Configuration : ipc: host supprimé + shm_size: "8g" ou "16g" explicité

    • Résultat : Création d'un /dev/shm de 16 Go spécifique au conteneur.

    • Avantage : Cela permet de limiter clairement l'utilisation maximale de la mémoire partagée de chaque conteneur lorsque plusieurs conteneurs sont en exécution, ce qui est favorable pour la protection et l'isolation de la RAM de l'hôte.

⚙️ Comment ajuster la taille de /dev/shm de l'hôte (en cas d'utilisation de l'option 1)

Si vous souhaitez changer la taille de /dev/shm de l'hôte tout en utilisant ipc: host, il est nécessaire de modifier la configuration tmpfs.

  • Changement temporaire de la taille (restaurée après redémarrage) :
sudo mount -o remount,size=16G /dev/shm

(Appliqué immédiatement à tous les processus/containeurs.)
  • Changement permanent de la taille (modifier /etc/fstab) :
# Ajouter/Modifier la ligne suivante dans le fichier /etc/fstab
tmpfs /dev/shm tmpfs defaults,size=16G 0 0

Appliquez immédiatement après avoir enregistré ou redémarré.

Quand devez-vous l'augmenter ? Lorsque de nombreux travailleurs DataLoader sont en fonctionnement ou lors de la construction d'un moteur TensorRT, si vous obtenez sporadiquement l'erreur No space left on device, assurez-vous d'ajuster shm_size ou la taille de /dev/shm de l'hôte à au moins 8G.