Respuestas:
/dev/shmes un sistema de archivos de almacenamiento de archivos temporal, es decir, tmpfs , que usa RAM para el almacén de respaldo. Puede funcionar como una implementación de memoria compartida que facilita el IPC .
Las recientes compilaciones de kernel 2.6 de Linux 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. El soporte / dev / shm es completamente opcional dentro del archivo de configuración del kernel. Se incluye de manera predeterminada en las distribuciones de Fedora y Ubuntu, donde la aplicación Pulseaudio la usa más ampliamente. (Énfasis añadido.)
/tmpes la ubicación de los archivos temporales tal como se define en el Estándar de jerarquía del sistema de archivos , seguido por casi todas las distribuciones de Unix y Linux.
Dado que la RAM es significativamente más rápida que el almacenamiento en disco, puede usarla en /dev/shmlugar de /tmpaumentar el rendimiento , si su proceso es intensivo en E / S y usa ampliamente archivos temporales.
Para responder a sus preguntas: No, no siempre puede confiar en /dev/shmestar presente, ciertamente no en máquinas atadas a la memoria. Debe usarlo a /tmpmenos que tenga una muy buena razón para usarlo /dev/shm.
Recuerde que /tmppuede 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/shmestá 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.
/dev/shm. /dev/shmes la memoria (tmpfs) respaldada por el disco (intercambio). /var/tmpes la memoria (caché de disco) respaldada por el disco (sistema de archivos en disco). En la práctica, el rendimiento es casi el mismo (tmpfs tiene una ligera ventaja pero no lo suficiente como para importar). /tmppuede ser tmpfs o no, dependiendo de cómo lo configuró el administrador. No hay una buena razón para usar /dev/shmen sus scripts.
/tmpes la ubicación normal (con $TMPDIRanulación). La elección de hacer /tmprespaldado por intercambio, otro espacio en disco o nada es del administrador.
En orden descendente de tmpfsprobabilidad:
┌───────────┬──────────────┬────────────────┐
│ /dev/shm │ always tmpfs │ Linux specific │
├───────────┼──────────────┼────────────────┤
│ /tmp │ can be tmpfs │ FHS 1.0 │
├───────────┼──────────────┼────────────────┤
│ /var/tmp │ never tmpfs │ FHS 1.0 │
└───────────┴──────────────┴────────────────┘
Dado que está preguntando acerca de un punto de montaje tmpfs específico de Linux versus un directorio definido de forma portátil que puede ser tmpfs (dependiendo de su administrador de sistemas y cuál es el valor predeterminado para su distribución), su pregunta tiene dos aspectos, que otras respuestas han enfatizado de manera diferente:
Edición conservadora (mezcla de convenciones de FHS y uso común):
/tmp./var/tmppara datos grandes que pueden no encajar fácilmente en ram./var/tmppara datos que sean beneficiosos para mantener reinicios (como un caché)./dev/shmcomo un efecto secundario de la llamada shm_open(). La audiencia prevista son memorias intermedias limitadas que se sobrescriben sin cesar. Así que esto es para archivos de larga duración cuyo contenido es volátil y no terriblemente grande.mktempprograma respeta la TMPDIRvariable de entorno.Edición pragmática:
Úselo /dev/shmcuando sea importante usar tmpfs, /var/tmpcuando sea importante no hacerlo, de lo contrario /tmp.
fsynces un no-op en tmpfs. Este syscall es el enemigo número uno del rendimiento (IO) (y la longevidad flash, si te importa), aunque si te encuentras usando tmpfs (o eatmydata) solo para derrotar a fsync, entonces usted (o algún otro desarrollador de la cadena) está haciendo algo mal. Significa que las transacciones hacia el dispositivo de almacenamiento son innecesariamente específicas para su propósito: está claramente dispuesto a omitir algunos puntos de ahorro para el rendimiento, ya que ahora ha llegado 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 una SSD: cualquier SSD decente funcionará fuera de este mundo en comparación con lo que un disco giratorio puede tomar (7200 rpm = 120 Hz , si está accediendo a otra cosa), sin mencionar las tarjetas de memoria flash, que varían ampliamente en esta métrica (sobre todo porque es una compensación con un rendimiento secuencial, que es por lo que están clasificadas, por ejemplo, clasificación de clase de tarjeta SD). Así que ten cuidado,
¿Quieres escuchar una historia ridícula? Mi primera fsynclección: tenía un trabajo que implicaba "actualizar" rutinariamente un montón de bases de datos Sqlite (guardadas 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 aceleración de la paralelización en absoluto (más bien un pequeño golpe ) porque el proceso estaba completamente vinculado a IO. Hilarantemente, envolver el marco de actualización en un script que copió cada base de datos /dev/shm, lo actualizó allí y lo copió nuevamente al disco fue como 100 veces más rápido (todavía con 8 en paralelo). Como beneficio adicional, la PC era utilizable también, al actualizar bases de datos.
El uso apropiado de tmpfs es evitar la escritura innecesaria de datos volátiles. Deshabilitar efectivamente la reescritura , como establecer el /proc/sys/vm/dirty_writeback_centisecsinfinito en un sistema de archivos normal.
Esto tiene muy poco que ver con el rendimiento, y en su defecto, es una preocupación mucho menor que abusar de fsync: el tiempo de espera de reescritura determina cuán vagamente se actualiza el contenido del disco después del contenido de caché de página, 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 la memoria caché de página, pero el contenido del disco solo se actualiza aproximadamente una vez cada 5 segundos. A menos que la aplicación lo fuerce con fsync, eso es. Piense cuántas veces una aplicación puede generar un archivo pequeño en este momento, y verá por qué sincronizar cada uno de ellos sería un problema mucho mayor.
fsyncsupuesto.Mantener datos fríos . Puede sentirse tentado a pensar que servir archivos fuera de intercambio es tan eficiente como un sistema de archivos normal, pero hay un par de razones por las que no lo es:
mount -t tmpfs "jarno is great" /mnt/jarnosi lo desea! En tercer lugar, el tamaño predeterminado es la mitad de la cantidad de RAM: apuesto a que tiene 4GiB RAM.
Bien, aquí está la realidad.
Tanto tmpfs como un sistema de archivos normal son una memoria caché sobre disco.
El tmpfs usa memoria y espacio de intercambio ya que está almacenando un sistema de archivos que usa un área específica del disco, ni está limitado en el tamaño del sistema de archivos, es muy posible tener un tmpfs de 200GB en una máquina con menos de un GB de RAM si tienes suficiente espacio de intercambio.
La diferencia está en cuando los datos se escriben en el disco. Para un tmpfs, los datos se escriben SOLO cuando la memoria se llena demasiado o es improbable que los datos se usen pronto. OTOH, la mayoría de los sistemas de archivos Linux normales 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 pierde todo.
Personalmente, estoy acostumbrado a tener sistemas operativos que no se bloquean y sistemas UPS (por ejemplo: baterías de computadoras portátiles), así que creo que los sistemas de archivos ext2 / 3 son demasiado paranoicos con su intervalo de punto de control de 5-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 una segunda clase y no lo protege. (ext3 es lo mismo pero no lo notas debido al punto de control de 5 segundos)
Esta verificación frecuente significa que los datos innecesarios se escriben continuamente en el disco, incluso para / tmp.
Por lo tanto, el resultado es que necesita crear un espacio de intercambio tan grande como necesite que sea / 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 que la máquina tiene más que suficiente memoria + intercambio disponible.
Use / tmp / para archivos temporales. Use / dev / shm / cuando desee memoria compartida (es decir, comunicación entre procesos a través de archivos).
Puede confiar en / tmp / estar allí, pero / dev / shm / es una cosa relativamente reciente de Linux.
1>/dev/null 2>&1. Lo haría varias miles de veces, así que un tmpfs sería bueno. Sin embargo, si yo liberar el guión que no puedo confiar en tmpfs que se utiliza para /tmpque yo creo que no es tan común Si es más común para. /dev/shmentonces que es mejor para mí, pero estoy en busca de directrices con respecto a la portabilidad, etc.
Otro momento en el que debe usar / dev / shm (para Linux 2.6 y superior) es cuando necesita un sistema de archivos tmpfs garantizado porque no sabe si puede escribir en el disco.
Un sistema de monitoreo con el que estoy familiarizado necesita escribir archivos temporales mientras crea su informe para enviarlo a un servidor central. Es mucho más probable en la práctica que algo impida las escrituras en un sistema de archivos (ya sea por falta de espacio en disco o por una falla RAID subyacente que ha llevado al sistema a un modo de solo lectura de hardware) pero aún podrá cojear para alertar al respecto que si algo gira en espiral toda la memoria disponible de modo que tmpfs no se pueda usar (y la caja no estará muerta). En casos como este, un sistema de monitoreo preferirá escribir en la RAM para poder potencialmente enviar una alerta sobre un disco lleno o hardware muerto / agonizante.
/ dev / shm se utiliza para controladores y programas de dispositivos específicos del sistema de memoria virtual compartida.
Si está creando un programa que requiere un montón de memoria virtual que debería asignarse a la memoria virtual. Esto se duplica, por lo que si necesita múltiples procesos o subprocesos para poder acceder de forma segura a esa memoria.
El hecho es que solo porque el controlador use una versión especial de tmpfs para él, no significa que deba usarlo como una partición genérica de tmpfs. En su lugar, debería crear otra partición tmpfs si desea una para su directorio temporal.
En PERL, con un mínimo de 8 GB en cualquier máquina (todas ejecutando Linux Mint), creo que es una buena costumbre hacer algoritmos complejos basados en DB_File (estructura de datos en un archivo) con millones de lecturas y escrituras usando / dev / shm
En otros idiomas, al no tener gigether en todas partes, para evitar los inicios y paradas en la transferencia de red (trabajando localmente en un archivo que se encuentra en un servidor en una atmósfera cliente-servidor), utilizando un archivo por lotes de algún tipo, copiaré el archivo completo (300-900MB) a la vez a / dev / shm, ejecute el programa con salida a / dev / shm, escriba los resultados en el servidor y elimine de / dev / shm
Naturalmente, si tuviera menos RAM, no estaría haciendo esto. Normalmente, el sistema de archivos en memoria de / dev / shm se lee como un tamaño que es la mitad de su RAM disponible. Sin embargo, el uso ordinario de RAM es constante. Entonces, realmente no podría hacer esto en un dispositivo con 2GB o menos. Para convertir la paráfrasis en una hipérbole, a menudo hay cosas en la RAM que incluso el sistema no informa bien.
/dev/shmexiste, lo usaré si es así o recurrir a/tmp. ¿Eso suena bien?