docker lxc

Uso de recursos por contenedores Docker detenidos



lxc (1)

Docker hace que sea fácil detener y reiniciar los contenedores. También tiene la capacidad de pausar y luego recuperar los contenedores. El estado de Docker docs

Cuando se sale del contenedor, se conserva el estado del sistema de archivos y su valor de salida. Puede iniciar, detener y reiniciar un contenedor. Los procesos se reinician desde cero (su estado de memoria no se conserva en un contenedor), pero el sistema de archivos es como estaba cuando se detuvo el contenedor.

Probé esto configurando un contenedor con memcached en ejecución, escribí un valor en memcache y luego

  • Detuvo y luego reinició el contenedor - el valor de memcached se fue
  • Pausó y luego no pausó el contenedor - el valor de memcached aún estaba intacto

En algún lugar de la documentación, ya no puedo encontrar el documento preciso, leí que los contenedores detenidos no consumen CPU ni memoria. Sin embargo:

  • Supongo que el hecho de que el estado del sistema de archivos esté preservado significa que el contenedor aún consume algo de espacio en el sistema de archivos del host.
  • ¿Hay un impacto en el rendimiento (aparte del consumo de espacio en el disco del host) asociado con tener 10, o incluso 100, de contenedores detenidos en el sistema? Por ejemplo, ¿hace que sea más difícil para Docker iniciar y administrar nuevos contenedores?
  • Y, finalmente, si los contenedores en pausa mantienen su estado de memoria cuando no están en pausa, como lo demuestra su capacidad para recordar las claves de memcached, ¿tienen un impacto diferente en la CPU y la memoria?

Estaría muy agradecido a cualquiera que pueda aclarar estas cuestiones.


No soy un experto en el núcleo de la ventana acoplable, pero intentaré responder algunas de estas preguntas.

  1. Supongo que el hecho de que el estado del sistema de archivos esté preservado significa que el contenedor aún consume algo de espacio en el sistema de archivos del host.

Sí. Docker guarda todos los datos del contenedor y de la imagen en /var/lib/docker . La forma predeterminada de guardar el contenedor y los datos de imagen es usar aufs. Los datos de cada capa se guardan en /var/lib/docker/aufs/diff . Cuando se crea un nuevo contenedor, también se crea una nueva capa con su carpeta, y allí se almacenan los cambios de las capas de la imagen de origen.

  1. ¿Hay un impacto en el rendimiento (aparte del consumo de espacio en el disco del host) asociado con tener 10, o incluso 100, de contenedores detenidos en el sistema? Por ejemplo, ¿hace que sea más difícil para Docker iniciar y administrar nuevos contenedores?

Por lo que yo sé, no debería ser ningún golpe de rendimiento. Cuando detiene un contenedor, el demonio docker envía SIGTERM y SIGKILL a todo el proceso de ese contenedor, como se describe en la documentación de la CLI de docker :

Uso: parada acoplable [OPCIONES] CONTENEDOR [CONTENEDOR ...]

Detenga un contenedor en ejecución enviando SIGTERM y luego SIGKILL después de un período de gracia

-t, --time = 10 Número de segundos para esperar a que el contenedor se detenga antes de matarlo. El valor predeterminado es 10 segundos.

3. Y, finalmente, si los contenedores en pausa mantienen su estado de memoria cuando no están en pausa, como lo demuestra su capacidad para recordar las claves de memcached, ¿tienen un impacto diferente en la CPU y la memoria?

Como dijo @Usman, la ventana acoplable implementa pausa / reanudación usando el congelador cgroup. Si no estoy equivocado, cuando pones un proceso en el congelador (o su cgroup), bloqueas la ejecución de una nueva tarea de ese proceso desde el programador de tareas del kernel (es decir: detiene el proceso), pero no lo haces. mátelos y siguen consumiendo la memoria que están utilizando (aunque el Kernel puede mover esa memoria para intercambiar o para un disco sólido). Y los recursos de la CPU utilizados por un contenedor en pausa los consideraría insignificantes. Para obtener más información sobre esto, revisaría la solicitud de extracción de esta característica, problema de Docker # 5948