GNU/Linux >> Tutoriales Linux >  >> Linux

¿Debo esperar que los programas que se ejecutan desde una carpeta tmpfs se ejecuten más rápido? (con y sin E/S, dentro y fuera de un contenedor Docker)

La ejecución en tmpfs será más rápida solo si tiene una gran cantidad de E/S de disco que no se realiza desde la memoria caché de la página.

Si la E/S es de lectura y los archivos ya están en caché, tmpfs no hará ninguna diferencia.

Si la E/S es escritura asíncrona sin vaciar y la carga de trabajo es en ráfagas en lugar de continua y hay suficiente memoria caché para absorber una ráfaga de escrituras y las escrituras se pueden vaciar en segundo plano entre las ráfagas, tmpfs no hará ninguna diferencia.

Si no hay E/S de disco para realizar, tmpfs no hará ninguna diferencia.

Si tiene mucha E/S de disco y su proceso está bloqueado a la espera de que el almacenamiento se ponga al día, ejecutar tmpfs marcará una gran diferencia. Cuanto más lentos sean sus discos, mayor será la diferencia, hasta el punto en que se convierta en un cuello de botella en la CPU.


(4) El ejecutable se ejecuta desde dentro de un contenedor Docker, y el ejecutable y todos los archivos involucrados están en una carpeta tmpfs creada desde dentro del contenedor, en una unidad "interna" (que no persiste después de que se detiene el contenedor).

(5) El ejecutable se ejecuta desde un contenedor Docker, y el ejecutable y todos los archivos involucrados están en carpetas de disco "normales".

Aparte de Tmpfs (que ya se ha abordado), no notará ninguna diferencia entre ejecutar ejecutables en el host y desde dentro de un contenedor Docker. Lo mismo con el volumen de almacenamiento. Docker se ejecuta con un sistema de archivos superpuesto y probablemente haya un muy pequeño impacto en el rendimiento de la superposición, pero el host ve el ejecutable ejecutándose como un proceso como si se hubiera iniciado en el host.


Siendo realistas, debería haber una diferencia cercana a cero o cero. Puede haber razones válidas para hacer tal cosa, pero me atrevo a decir que en el 99,9 % de los casos es una antioptimización.

La E/S normal irá a la memoria caché del búfer y las páginas sucias se escribirán de forma asíncrona mediante un subproceso del núcleo. Ancho de banda =velocidad de RAM, retraso =retraso de RAM (más, tal vez unos pocos µs por una falla de página aquí y allá).
Cuando el sistema se quede sin RAM física, se bloqueará (obviamente), no hay otra manera. Cuando no queden páginas en las que puedas escribir, tendrás que esperar hasta que se liberen algunas. No hay otra manera.
Sin embargo, quedarse sin RAM es, por definición, poco probable (o posible) que suceda en su caso particular. De lo contrario, si existe la posibilidad real de quedarse sin RAM, la idea de crear un tmpfs sería bastante estúpida en primer lugar.

I/O to tmpfs irá a... la memoria caché del búfer. Sí, ahora se ejecuta con un nombre diferente, pero en realidad es exactamente lo mismo, debido al sistema de VM unificado. Por lo tanto, el ancho de banda y la demora son exactamente iguales (más o menos una diferencia del 1% debido a las sutilezas del sistema de archivos que pueden ser ligeramente diferentes). No se está produciendo una reescritura, sí. Pero a quién le importa, viendo cómo sucedería de forma asincrónica, de todos modos. Por el contrario, ahora no puede darse el lujo de que alguien libere páginas sucias en segundo plano, por lo que la probabilidad de tocar el techo, si es posible, es en realidad mayor.

Cuando el sistema se queda sin RAM física, todavía solo está escribiendo en páginas asignadas en la memoria, por lo que, en teoría, debería poder hacerlo más rápido. Sin embargo, en la práctica, todavía hay tanto y tanto RAM físico, ¡y te acabas de quedar sin él! Seguro, todavía puede haber espacio en su tmpfs, pero por alguna razón, usted también necesito escribir una página de memoria de lo contrario, y no queda ninguna.
Entonces el núcleo debe hacer algo para mantener el sistema en funcionamiento. Tiene que de alguna manera reorganizar sus recursos para mitigar el problema (¿posiblemente cambiar el proceso de la ventana acoplable y todo el contenedor?!). El núcleo se esforzará, pero no es como si pudiera hacer magia, tiene que hacer algo , y sus opciones son limitadas. Más aún, ya que ha quitado deliberadamente una gran cantidad de páginas que, de lo contrario, podría usar libremente según sea necesario para cualquier propósito (incluida la solicitud que se debe atender en este momento).


Linux
  1. ¿Cómo ejecutar un programa dentro de un contenedor Docker?

  2. Cómo desconectarse de un contenedor Docker sin detenerlo

  3. ¿Se puede ejecutar docker dentro de un contenedor de Linux?

  4. ¿Qué hay dentro de una imagen/contenedor de Docker?

  5. Use perf dentro de un contenedor docker sin --privileged

Cómo ejecutar Jenkins Container como servicio Systemd con Docker

Cómo instalar Docker en Ubuntu 20.04 y ejecutar Nginx Container

Instale y ejecute Jenkins con Systemd y Docker

Cómo usar SSH en un contenedor Docker y ejecutar comandos

Cómo:Introducción a los contenedores de Windows y Docker

Contenedores Docker y Linux en Windows, con o sin máquinas virtuales Hyper-V