¿Disco duro? Dónde vamos no necesitamos... ¡disco duro!

Buenas:

Durante todo el tiempo que he dedicado a colaborar me he preocupado sobremanera de mantener memoria libre para que los equipos pudieran trabajar. Quizá hasta obsesivamente, pero tengo razones de peso: El peso de cerca de trescientos sesenta portátiles con un procesador Atom pequeño y sólo un Gigabyte de memoria que he mantenido con gnome desde el Ubuntu 12.04 hasta el curso pasado, cuando ya no tuve más opción que tirarme a lxde y maquillar el escritorio -la mayoría de los usuarios sólo mira eso y ya me costó lo suficiente que se acostumbraran.

Por otra parte, con la creciente imposición de los discos SSD y las memorias como mínimo de 4GB se me han aparecido problemas diferentes; entre ellos, como alargar la vida de esos discos duros que no dejan de ser tarjetas SD gigantes y que tenían -dicen que ya no- límite de escrituras.

Para la memoria he ido explicando afinaciones como ésta o ésta. Por ello ahora os voy a sorprender. Voy a explicaros como acelerar la máquina y alargar la vida de esos SSD, de los discos duros rotatorios, que son la pieza que más trabaja de nuestra máquina aunque no nos demos cuenta.

Recordad. Al menos tres Gigabytes de memoria -raro-. Mejor cuatro y de ahí para arriba.

Tenemos tres carpetas donde el sistema acumula reescrituras mientras trabajamos:

/tmp

/var/tmp

/dev/shm

La primera no requiere explicación, pero con un poco de experiencia sabréis que es uno de los puntos de entrada de problemas en otros sistemas de los cuales no quiero acordarme -¿cuántas veces habíais desinfectado un viejo windows y un fichero temporal volvía a lanzar la infección porque a pesar de todas las órdenes que tu dabas la carpeta no se vaciaba automáticamente al acabar la sesión? ¿O llenaba el disco duro de morralla inútil?

La segunda es equivalente, y sirve para que la gestión interna del sistema haga sus cosas. A mí me ha dado problemas en servidores por ester mal dimensionada, llegando a bloquear la máquina.

La tercera es la memoria compartida (SHared Memory) y nos sirve mientras estamos trabajando.

En cualquier caso, una vez apagamos la máquina no tiene ningún sentido que cualquier cosa que haya en esas carpetas se conserve. De hecho, incluso podría ser peligroso porque se ejecutara algún software malicioso a bajo nivel; o podría dar acceso a otro usuario de la misma máquina a rastros de nuestro trabajo y una de las primeras acciones del sistema cuando arranca, de hecho, consiste en vaciar /tmp.

Centrémonos. Cuatro Gigabytes. Si no nos liamos demasiado -esas cosas nunca me pasan, siempre me han contado que le pasan al amigo de un amigo. ¡SIEMPRE, A MÍ JAMÁS!- y vamos monitorizando, con un gnome oscila entre los nuevecientos y los mil trescientos Megabytes; menos con XFCE o LXDE. No he hecho la prueba con Unity. A eso se le sumarán las caches y no se dispararán si tenemos los dos parámetros que activan el dropcache (aquí).

Es decir... ¿Podríamos ocupar un Gigabyte de la memoria para esas tres carpetas? ¿Podríamos montar un sistema de ficheros directamente en la memoria RAM? ¿Nos quedaría suficiente espacio para trabajar en memoria?

Pues resulta que sí. que funciona perfectamente y que aumenta la velocidad de la máquina puesto que en almacenamiento no hay nada más rápido que la memoria RAM en un ordenador. Además, no tenemos que utilizar escrituras de disco y cuando apagamos la máquina, se pierde todo lo que tenemos en ellas.

¿Y como se monta? con un bonito comando, el tmpfs. El montaje es ridículamente simple. Sólo consiste en editar como root el fichero /etc/fstab.

La configuración os la ajustáis vosotros. Yo os doy mi opción en la máquina de trabajo. Los pasos son sencillos:

1.- Editáis el fichero /etc/fstab. Sudoer o root, como prefiráis.
2.- Añadís al final las siguientes líneas:

# /tmp a RAM
tmpfs   /tmp   tmpfs   size=256M,noexec,nosuid,rw,auto,nouser,sync,relatime,mode=01777       0 0
# /dev/shm a RAM
tmpfs   /dev/shm  tmpfs   size=512M,noexec,nosuid,rw,auto,nouser,sync,relatime,mode=01777       0 0
# /var/tmp a RAM
tmpfs   /var/tmp   tmpfs   size=256M,noexec,nosuid,rw,auto,nouser,sync,relatime,mode=01777       0 0

 3.- Guardáis y reiniciáis. Si la distribución no os sirve, la cambiáis, la anuláis... lo necesario.

La explico: Monto /tmp en memoria con 256 MB, con acceso para cualquier usuario pero ciego entre usuarios diferentes -sólo verás tus propios temporales, y no los de los demás- con un tamaño de 256 MB. Igual es un poco corto pero se me ha desmostrado suficiente desde que quité los temporales de LibreOffice y Audacity del /tmp.

Le doy la parte del león a la compartida (/dev/shm), con las misma condiciones. Comparto entre mis propias llamadas de trabajo, no con los otros potenciales usuarios de la máquina.

Igualo las condiciones con /var/tmp. Le sobrará, en realidad.

¿Y que pasa si se llenan estos tres subsistemas? Pues que se irá a Swap, que sí que tengo definida en disco duro para poder hibernar pero que sólo entra cuando la memoria está ocupada al 90% (vm.swappiness=1 en /etc/sysctl.conf) así que me preocupa relativamente poco.

Pues eso. Probadlo porque no es destructivo y ya me diréis si mejora la velocidad de cualquier máquina. Hasta luego.

Y quedaría por ajustar temporales de software específico y ver si ese sistema sería útil para gestionar la memoria de los teléfonos móviles, pero eso más adelante.

Hasta luego.

FUENTES:

http://hackingthesystem4fun.blogspot.com.es/2012/06/mejorar-el-rendimiento-usando-tmp-como.html

http://gnulinuxvagos.es/topic/1154-tmpfs-montando-los-temporales-en-ram/

https://linuxgnublog.org/sacale-partido-a-tu-ram-usandola-para-ficheros-temporales-como-la-cache/

Tweet