¿Cuándo debo usar /dev/shm/ y cuándo debo usar /tmp/?

Las compilaciones recientes del kernel de Linux 2.6 han comenzado a ofrecer /dev/shm como memoria compartida en forma de ramdisk, más específicamente como un directorio de escritura mundial que se almacena en la memoria con un límite definido en /etc/default/tmpfs. La compatibilidad con /dev/shm es completamente opcional dentro del archivo de configuración del kernel. Se incluye de forma predeterminada en las distribuciones de Fedora y Ubuntu, donde la aplicación Pulseaudio la utiliza más ampliamente.

/tmp es la ubicación de los archivos temporales tal como se define en el estándar de jerarquía del sistema de archivos, que se sigue en casi todas las distribuciones de Unix y Linux.

Dado que la RAM es significativamente más rápida que el almacenamiento en disco, puede usar /dev/shm en lugar de /tmp para aumentar el rendimiento, si su proceso es intensivo en E/S y utiliza archivos temporales de forma extensiva.

Para responder a sus preguntas:No, no siempre puede confiar en /dev/shm estar presente, ciertamente no en máquinas atadas a la memoria. Deberías usar /tmp a menos que tenga una muy buena razón para usar /dev/shm .

Recuerda que /tmp puede ser parte del / sistema de archivos en lugar de un montaje separado y, por lo tanto, puede crecer según sea necesario. El tamaño de /dev/shm está limitado por el exceso de RAM en el sistema y, por lo tanto, es más probable que se quede sin espacio en este sistema de archivos.

En orden descendente de tmpfs probabilidad:

┌───────────┬──────────────┬────────────────┐
│ /dev/shm  │ always tmpfs │ Linux specific │
├───────────┼──────────────┼────────────────┤
│ /tmp      │ can be tmpfs │ FHS 1.0        │
├───────────┼──────────────┼────────────────┤
│ /var/tmp  │ never tmpfs  │ FHS 1.0        │
└───────────┴──────────────┴────────────────┘

Ya que está preguntando sobre un tmpfs específico de Linux punto de montaje frente a un directorio definido de forma portátil que puede sea ​​tmpfs (dependiendo de su administrador de sistemas y de lo que sea predeterminado para su distribución), su pregunta tiene dos aspectos, que otras respuestas han enfatizado de manera diferente:

1. Uso apropiado de varios directorios tmp
2. Uso apropiado de tmpfs

Uso apropiado de varios directorios tmp

Basado en el antiguo estándar de jerarquía del sistema de archivos y lo que dice Systemd al respecto.

• En caso de duda, utilice /tmp .
• Utilice /var/tmp para los datos que deberían persistir entre reinicios.
• Utilice /var/tmp para datos grandes que pueden no caber fácilmente en la RAM (suponiendo que /var/tmp tiene más espacio disponible - generalmente una suposición justa).
• Utilice /dev/shm solo como un efecto secundario de llamar a shm_open() . La audiencia prevista son búferes acotados que se sobrescriben sin cesar. Esto es para archivos de larga duración cuyo contenido es volátil y no demasiado grande.
• Definitivamente no uses /dev/shm para ejecutables (de cualquier tipo), ya que comúnmente se monta noexec .
• Si aún tiene dudas, proporcione una manera para que el usuario la anule. Para la menor sorpresa, haz clic en mktemp y respeta el TMPDIR variable de entorno.

Donde sobresale tmpfs

Es importante decir que donde tmpfs realmente sobresale, por encima de todo, es en ocultar un error de rendimiento que es dolorosamente significativo en un disco giratorio. Entonces, si arreglarlo es una opción, esto es, por supuesto, el uso inapropiado de tmpfs :

fsync es un no-op en tmpfs. Esta llamada del sistema le dice al sistema operativo que vacíe su caché de página asociada con un archivo, hasta vaciar el caché de escritura del dispositivo de almacenamiento relevante, todo mientras bloquea el programa que lo emitió para que no haga ningún progreso:una barrera de escritura muy cruda. . Es una herramienta necesaria en la caja solo porque los protocolos de almacenamiento no se crean teniendo en cuenta las transacciones. Y el almacenamiento en caché está ahí, en primer lugar, para hacer posible que los programas realicen millones de pequeñas escrituras en un archivo sin darse cuenta de lo lento que es escribir en un dispositivo de almacenamiento:toda la escritura real ocurre de forma asíncrona, o hasta fsync se llama, que es el único lugar donde el programa siente directamente el rendimiento de escritura.

Entonces, si usa tmpfs (o eatmydata) solo para derrotar a fsync, entonces usted (o algún otro desarrollador en la cadena) está haciendo algo mal. Significa que las transacciones hacia el dispositivo de almacenamiento son innecesariamente detalladas para su propósito:claramente está dispuesto a omitir algunos puntos de guardado para el rendimiento, ya que ahora ha ido al extremo de sabotearlos a todos, rara vez el mejor compromiso. Además, es aquí en el terreno del rendimiento de las transacciones donde se encuentran algunos de los mayores beneficios de tener un SSD:cualquier SSD que se precie tendrá un rendimiento fuera de este mundo en comparación con lo que un disco giratorio puede soportar (7200 rpm =120 Hz, si nada más lo está accediendo). Las tarjetas de memoria flash también varían mucho en esta métrica (es una compensación con el rendimiento secuencial, y la calificación de clase de la tarjeta SD solo considera este último). ¡Así que tengan cuidado, desarrolladores con SSD ultrarrápidos, de no forzar a sus usuarios a este caso de uso!

¿Quieres escuchar una historia ridícula? Mi primer fsync Lección:tenía un trabajo que implicaba "actualizar" rutinariamente un montón de bases de datos Sqlite (mantenidas como casos de prueba) a un formato actual en constante cambio. El marco de "actualización" ejecutaría un montón de scripts, haciendo al menos una transacción cada uno, para actualizar una base de datos. Por supuesto, actualicé mis bases de datos en paralelo (8 en paralelo, ya que fui bendecido con una poderosa CPU de 8 núcleos). Pero como descubrí, no hubo ningún tipo de aceleración de paralelización (más bien un ligero golpe ) porque el proceso estaba completamente ligado a IO. Graciosamente, envolviendo el marco de actualización en un script que copió cada base de datos a /dev/shm , lo actualicé allí y lo volví a copiar en el disco fue como 100 veces más rápido (todavía con 8 en paralelo). Como beneficio adicional, la PC era utilizable también, mientras se actualizan las bases de datos.

Dónde tmpfs es apropiado

El uso apropiado de tmpfs es evitar la escritura innecesaria de datos volátiles. Deshabilitar efectivamente writeback , como configurar /proc/sys/vm/dirty_writeback_centisecs hasta el infinito en un sistema de archivos normal.

Esto tiene muy poco que ver con el rendimiento, y fallar es una preocupación mucho menor que abusar de fsync:el tiempo de espera de reescritura determina la pereza con la que se actualiza el contenido del disco después del contenido de la caché de páginas, y el valor predeterminado de 5 segundos es mucho tiempo para una computadora. – una aplicación puede sobrescribir un archivo con la frecuencia que desee, en el caché de página, pero el contenido en el disco solo se actualiza aproximadamente una vez cada 5 segundos. A menos que la aplicación lo fuerce con fsync, eso es. Piense en cuántas veces una aplicación puede generar un archivo pequeño en este tiempo y verá por qué sincronizar cada uno de ellos sería un problema mucho mayor.

Con qué tmpfs no puede ayudarte

• Rendimiento de lectura. Si sus datos están calientes (lo cual es mejor si considera mantenerlos en tmpfs), accederá al caché de la página de todos modos. La diferencia es cuando no se golpea el caché de página; si este es el caso, vaya a "Dónde tmpfs sux", a continuación.
• Archivos de corta duración. Estos pueden vivir toda su vida en el caché de página (como sucio páginas) antes de ser escrito. A menos que lo fuerces con fsync por supuesto.

Donde tmpfs sux

Mantener frío datos. Puede sentirse tentado a pensar que servir archivos fuera del intercambio es tan eficiente como un sistema de archivos normal, pero hay un par de razones por las que no lo es:

• La razón más simple:no hay nada que a los dispositivos de almacenamiento contemporáneos (ya sea basados ​​en disco duro o flash) les guste más que leer archivos bastante secuenciales cuidadosamente organizados por un sistema de archivos adecuado. Es poco probable que el intercambio en bloques de 4KiB mejore eso.
• El costo oculto:intercambiar fuera . Las páginas de Tmpfs están sucias — deben estar escritos en alguna parte (para intercambiar) para ser desalojados de la memoria caché de la página, a diferencia del archivo respaldado limpio páginas que se pueden soltar al instante. Esta es una penalización de escritura adicional en todo lo demás que compite por la memoria:afecta algo más en un momento diferente al uso de esas páginas tmpfs.

Bien, esta es la realidad.

Tanto tmpfs como un sistema de archivos normal son un caché de memoria en disco.

El tmpfs usa memoria y espacio de intercambio como almacenamiento de respaldo, un sistema de archivos usa un área específica del disco, ninguno está limitado en el tamaño que puede tener el sistema de archivos, es muy posible tener un tmpfs de 200 GB en una máquina con menos de un GB de RAM si tienes suficiente espacio de intercambio.

La diferencia está en cuándo se escriben los datos en el disco. Para un tmpfs, los datos se escriben SOLAMENTE cuando la memoria se llena demasiado o es poco probable que los datos se utilicen pronto. OTOH, la mayoría de los sistemas de archivos normales de Linux están diseñados para tener siempre un conjunto de datos más o menos consistente en el disco, de modo que si el usuario desconecta, no lo pierde todo.

Personalmente, estoy acostumbrado a tener sistemas operativos que no fallan y sistemas UPS (por ejemplo, baterías de computadoras portátiles), por lo que creo que los sistemas de archivos ext2/3 son demasiado paranoicos con su intervalo de control de 5 a 10 segundos. El sistema de archivos ext4 es mejor con un punto de control de 10 minutos, excepto que trata los datos del usuario como de segunda clase y no los protege. (ext3 es lo mismo pero no lo nota debido al punto de control de 5 segundos)

Esta verificación frecuente significa que se escriben continuamente datos innecesarios en el disco, incluso para /tmp.

Entonces, el resultado es que necesita crear un espacio de intercambio tan grande como necesite que sea su /tmp (incluso si tiene que crear un archivo de intercambio) y usar ese espacio para montar un tmpfs del tamaño requerido en /tmp.

NUNCA use /dev/shm.

A menos que lo esté utilizando para archivos IPC muy pequeños (probablemente mmap'd) y esté seguro de que existe (no es un estándar) y la máquina tiene más que suficiente memoria + intercambio disponible.