¿Usando tmpfs + una partición de intercambio muy grande para / tmp en lugar de un sistema de archivos normal?

Tengo un servidor Linux y tengo una partición de disco de 500 GB de repuesto. Quería formatearlo y usarlo para / tmp. El servidor ocasionalmente ejecuta algunas tareas de procesamiento de datos grandes, por lo que puede suceder que / tmp contenga GB de datos temporales.

Luego tuve la idea de que podría agregarlo como una partición de intercambio y montar / tmp en tmpfs. ¿Es razonable esta idea?

El servidor tiene 6 GB de RAM, por lo que en la mayoría de los casos, los datos en / tmp estarían solo en RAM, con la ventaja de velocidad obvia. La pregunta es, ¿y si habrá, digamos, 10-20 GB de datos en / tmp, cómo funcionará el sistema? ¿Cuál sería el rendimiento en comparación con tener simplemente / tmp montado en una partición ext4? Gracias por la ayuda.

Editar: está claro que el sistema comenzará a intercambiar memoria cuando el uso de tmpfs alcance el límite de RAM. Pero, ¿es Linux lo suficientemente inteligente como para intercambiar datos tmpfs y mantener datos "regulares" en la RAM? En caso afirmativo, supongo que podría comportarse razonablemente. De lo contrario, todo el sistema se verá gravemente afectado.

Esta NO es una buena idea ^TM .

Estarás bien con una gran /tmppartición, montada de esta manera (desde tu /etc/fstab)

tmpfs  /dev/tmp  tmpfs  defaults,nosuid,nodev,noexec,noatime,nodiratime,size=6000M 0 0

Y podría agregar su unidad externa como una partición de intercambio gigante

/dev/sdb1  swap  swap  defaults  0 0

Cuando eso llegue a su límite, su máquina comenzará a intercambiar las páginas de la RAM al disco; en ese momento, los promedios de carga irán por el techo y la máquina se detendrá.

Es una mala idea confiar en SWAP de ninguna manera, sería mejor vender su unidad de 500 GB y simplemente comprar más RAM, es barato.

En resumen

Si realmente desea utilizar su disco de 500 GB, puede montar su disco de 500 GB /tmpcon un sistema de archivos no registrado con atime y diratime desactivado (por ejemplo ext2). Eso sería sustancialmente más rápido que tratar con una máquina que está SWAPing

Esta podría ser una idea razonable.

Poner un sistema de archivos real en / tmp genera gastos generales, porque los sistemas de archivos hacen grandes esfuerzos para asegurarse de que los datos en el disco no estén dañados en caso de falla del sistema. Para un / tmp que se limpia en el momento del arranque, eso obviamente es solo gastos generales. Usar un tmpfs evitaría esa sobrecarga.

Por otro lado, los sistemas de archivos también se aseguran de que los archivos estén organizados en el disco de una manera que optimice el tiempo de acceso, es decir, evitarán la fragmentación. Los accesos de archivo secuenciales típicos (en su mayoría) darán lugar a accesos de disco secuenciales, que son más eficientes que los accesos aleatorios. Este efecto es más pronunciado en discos duros giratorios que en SSD. La combinación swap + tmpfs no puede hacer esto fácilmente, porque swap no sabe qué pieza de memoria pertenece a qué archivo y tmpfs no sabe cómo se asignan las páginas a la memoria física o al disco. Sin embargo, para archivos grandes, debería funcionar bien, ya que tanto tmpfs como swap intentan mantener las cosas contiguas en ese caso. Al menos, siempre que haya mucho espacio libre en el intercambio (de lo contrario, la fragmentación se activa), y las escrituras suceden lo suficientemente lentamente como para que tengan la oportunidad de ser intercambiadas.

El resultado final es: depende, debes probar ambas opciones para ver cuál funciona mejor.

Cuando monte los tmpfs, recuerde establecer el tamaño explícitamente. El valor predeterminado es la mitad de la RAM física, por lo que solo 3 GB.

En realidad, esta es una buena idea cuando generalmente no tiene muchos datos /tmp, pero ocasionalmente consume gigabytes sin fin durante un tiempo limitado. El problema es que el sistema de intercambio de Linux no sabe lo suficiente sobre su caso de uso para hacerlo bien. En general, priorizará el volcado o el intercambio de caché sobre las páginas del programa, pero eso realmente no ayuda. Puede ser posible usar cgroups para lograr su objetivo, es cuando los datos reutilizables se mantienen en la memoria del programa, pero no estoy seguro de cómo configurar cgroups en este caso (supongo que podría usar un FUSE tmpfs ...) . Afortunadamente, eso no es obligatorio. Puede obtener el comportamiento deseado con zram y un dispositivo de respaldo.

zram-inites el programa que automatiza la configuración de zram, que es un dispositivo de bloque de ram comprimido. Generalmente hay un ejemplo en la zram-initconfiguración para montar /tmpcomo zram. Será algo como lo siguiente

type0=/tmp
flag0= 
size0=524288 # 500G of logical space
mlim0=2G # 2G of memory
back0=/dev/loop0 # (or /dev/sdxN, your large slow drive)
notr0= 
maxs0=4 # maximum number of parallel processes for this device
algo0=zstd 
labl0=tmp # the label name
uuid0= 
args0= 

Esto comprimirá y almacenará en la memoria todo lo escrito en / tmp. La compresión habitual es de alrededor del 50%. Consumirá como máximo 2G de memoria física. Si se queda sin memoria física, tomará los archivos más antiguos y los introducirá en el dispositivo de respaldo, aún comprimido. Tenga en cuenta que incurre en una sobrecarga de la CPU para comprimir y descomprimir los archivos, pero esto generalmente se compensa con la reducción de IO.

Se puede usar una configuración similar junto con cgroups para permitir que ciertos procesos se intercambien sin afectar negativamente el rendimiento general del sistema.