Dominando la memoria compartida de Docker (shm_size e ipc)

Resumen del artículo:
1. shm_size es un espacio temporal que utiliza la RAM.
2. Si se usa ipc: host, shm_size es irrelevante, y se asigna el 50% de los recursos del host.
3. Es común ver configuraciones de modelos de IA donde ipc: host y shm_size se establecen simultáneamente, pero en realidad, configurar solo uno mejora la legibilidad.
4. Para cargas de trabajo de IA, se recomienda un mínimo de 8G~16G o más, por lo que debe configurarse según el entorno individual.

🐳 Configuración esencial para cargas de trabajo de IA/datos: Dominando la memoria compartida de Docker (shm_size e ipc)

Si en sus cargas de trabajo de IA y procesamiento de grandes volúmenes de datos ha experimentado errores inesperados como OSError: No space left on device, esto suele deberse a una configuración insuficiente de la memoria compartida (shm_size) en el contenedor Docker.

Este artículo explica claramente por qué la memoria compartida es crucial en entornos de contenedores y cómo configurar correctamente las opciones shm_size e ipc: host.

1. El rol y la importancia de shm_size

Rol: Determinación del tamaño de la memoria compartida del contenedor

shm_size es una opción que establece el tamaño máximo del sistema de archivos /dev/shm (memoria compartida POSIX) dentro del contenedor.

• El valor predeterminado de Docker es de solo 64MB, lo cual es muy pequeño.
• Advertencia: /dev/shm es un tmpfs (sistema de archivos temporal) que utiliza la RAM del host y no tiene relación con la VRAM (memoria de GPU).

¿Por qué es importante?

Las tareas de procesamiento de IA y datos utilizan esta memoria compartida de forma crucial para intercambiar grandes volúmenes de datos entre procesos.

• PyTorch DataLoader: Cuando se configura num_workers > 0, los procesos worker transfieren tensores/batches a través de la memoria compartida. Si este espacio es insuficiente, se produce el error OSError: No space left on device.
• Construcción/Servicio de motores TensorRT: Utiliza la memoria compartida intensivamente para artefactos intermedios de gran tamaño o búferes IPC. Si es insuficiente, puede fallar la construcción del motor o producirse un error de segmentación.
• Multiprocesamiento y comunicación IPC: Es esencial para compartir arrays/búferes grandes entre procesos en NCCL, OpenCV, NumPy, entre otros.

2. Configuración de ipc: Alcance del aislamiento de la memoria compartida

El namespace de IPC (Inter-Process Communication) es una opción de Docker que define el alcance del aislamiento del espacio de comunicación entre procesos (memoria compartida, semáforos, etc.) de un contenedor.

3. Principio de funcionamiento al usar shm_size e ipc: host simultáneamente (Análisis de ejemplo)

Es común configurar shm_size: "16g" y ipc: host juntos en tareas de IA/LLM. A continuación, analizaremos con un ejemplo real qué configuración se aplica en este caso.

Prueba: Resultados al usar ipc: host

A continuación, configuramos shm_size e ipc: host juntos de la siguiente manera.

shm_size: "16g"
ipc: host

Luego, accedimos al interior del contenedor para verificar el tamaño de /dev/shm.

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

Resultado de la observación: En lugar de los 16GB configurados en shm_size, se muestra el tamaño de /dev/shm del host, que es 60GB.

Conclusión: ipc: host ignora a shm_size.

¿Por qué este resultado?

1. Cuando se aplica ipc: host: El contenedor utiliza directamente el namespace IPC del host.
2. shm_size: "16g" es ignorado: Esta opción solo tiene sentido cuando se utiliza un namespace IPC propio.
3. Origen de los 60G: Los sistemas Linux host suelen configurar /dev/shm por defecto en aproximadamente la mitad de la RAM total. Por lo tanto, en el ejemplo anterior, el contenedor está viendo los 60G, que son la mitad de los 120G del host.

Enfatizamos una vez más

Si se configura ipc: host, el contenedor utiliza directamente el espacio de memoria compartida del host, por lo que la configuración de shm_size no se aplica en la práctica.

4. Elija el método de gestión de memoria que se adapte a su entorno y propósito

Priorizar la estabilidad VS Aislamiento por contenedor

1. Prioridad a la estabilidad: Mantener ipc: host

Este es el método más sencillo. Utiliza directamente los abundantes recursos de RAM del host. Es adecuado para entornos de un solo usuario/un solo proyecto donde múltiples contenedores pueden compartir recursos sin problemas. El uso del 50% del host es solo un máximo; solo la cantidad realmente utilizada ocupa la RAM, por lo que si no hay presión de memoria, es más cómodo dejarlo así.

• Configuración: Mantener solo ipc: host (aunque shm_size aparece en muchos ejemplos, es irrelevante, así que podemos eliminarlo sin dudarlo).
• Resultado: Se utiliza el generoso tamaño de /dev/shm del host (ej: 60G).

2. Imponer un límite por contenedor: Eliminar ipc: host

Se utiliza en entornos multi-tenant o cuando se necesita evitar que un contenedor específico ocupe excesivamente la RAM.

• Configuración: Eliminar ipc: host + especificar shm_size: "8g" o "16g".
• Resultado: Se crea un /dev/shm de 16GB exclusivo para el contenedor.
• Ventaja: Cuando se ejecutan varios contenedores, permite limitar claramente el uso máximo de memoria compartida de cada contenedor, protegiendo y aislando la RAM del host.

Nota: Cómo ajustar el tamaño de la memoria compartida del host (cuando se usa ipc:host)

Si desea cambiar el tamaño de /dev/shm del host mientras usa ipc: host, debe modificar la configuración de tmpfs.

1. Cambiar el tamaño temporalmente (se revierte al reiniciar):

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

Se aplica inmediatamente a todos los procesos/contenedores.

2. Cambiar el tamaño permanentemente (modificar /etc/fstab):

# Añadir/modificar la siguiente línea en el archivo /etc/fstab
tmpfs /dev/shm tmpfs defaults,size=16G 0 0

Guarde y reinicie, o aplique inmediatamente con el comando remount anterior.