Esto no es algo nuevo, pero lo recordé cuando un colega, me comentó que Fuduntu lo trae por defecto, para usar menos el disco, y asi gastar menos energia, dado que es una distro orientada a notebooks.
La idea, es montar el /tmp como tpmfs, es decir, un tipo de sistema de archivos que usa la memoria RAM, y no el disco.
Esto tiene una ventaja y desventaja, ustedes evaluen.
La ventaja, es que los datos temporales que se escriben en /tmp, serán mas rapidos de leer y escribir, dado que será la memoria RAM la que se use, y no el disco.
Asimismo, al reiniciar el sistema, si hubo un error y quedaba algo en /tmp, que puede ocasionar problemas, sera eliminado, porque la memoria RAM es volatil. Por defecto /tmp se limpia cada 7 dias, en este caso, será al reiniciar la PC.
La desventaja, es que si apagan la PC de forma brusca, como sacar el cable, por ej, los datos en /tmp se habrán perdido, aunque, nunca se recomienda usar /tmp como respaldo de nada, por algo es Temporal.
Ademas, para hacer test de cosas, y guardar los resultados, en vez de /tmp ahora deben usar /root u otra carpeta, para mi es una ventaja, aclaro, dado que muchas veces trabajo sobre /tmp para testear bajadas, scripts, etc, asi que si se borra solo su contenido, me hace un favor, sin contar el hecho de que /tmp tiene permisos 777 mientras que /root no.
tmpfs es un kernel page cache, algo de lo que hablamos hace poco, las cache RAM.... drop_caches, asi que de paso puede limpiarse con el mismo comando.
Los pasos son MUY sencillos, solo se loguean como root y editan /etc/fstab, y colocan a lo ultimo esta linea:
tmpfs /tmp tmpfs size=2G,noexec,nosuid,rw,auto,nouser,sync,relatime,mode=01777 0 0
La idea, es montar el /tmp como tpmfs, es decir, un tipo de sistema de archivos que usa la memoria RAM, y no el disco.
Esto tiene una ventaja y desventaja, ustedes evaluen.
La ventaja, es que los datos temporales que se escriben en /tmp, serán mas rapidos de leer y escribir, dado que será la memoria RAM la que se use, y no el disco.
Asimismo, al reiniciar el sistema, si hubo un error y quedaba algo en /tmp, que puede ocasionar problemas, sera eliminado, porque la memoria RAM es volatil. Por defecto /tmp se limpia cada 7 dias, en este caso, será al reiniciar la PC.
La desventaja, es que si apagan la PC de forma brusca, como sacar el cable, por ej, los datos en /tmp se habrán perdido, aunque, nunca se recomienda usar /tmp como respaldo de nada, por algo es Temporal.
Ademas, para hacer test de cosas, y guardar los resultados, en vez de /tmp ahora deben usar /root u otra carpeta, para mi es una ventaja, aclaro, dado que muchas veces trabajo sobre /tmp para testear bajadas, scripts, etc, asi que si se borra solo su contenido, me hace un favor, sin contar el hecho de que /tmp tiene permisos 777 mientras que /root no.
tmpfs es un kernel page cache, algo de lo que hablamos hace poco, las cache RAM.... drop_caches, asi que de paso puede limpiarse con el mismo comando.
Los pasos son MUY sencillos, solo se loguean como root y editan /etc/fstab, y colocan a lo ultimo esta linea:
tmpfs /tmp tmpfs size=2G,noexec,nosuid,rw,auto,nouser,sync,relatime,mode=01777 0 0
Salvan y salen. Al reiniciar el sistema, tendran acceso a /tmp, pero es la ram. Prueben de poner mount en consola, y veran algo asi:
tmpfs on /tmp type tmpfs (rw,noexec,nosuid,sync,relatime,size=2G,mode=01777)
Ahora, explico un poco esos parametros, de noexec, nosuid y 2G.
size=2G: indica el maximo de tamaño para ese punto de montaje, /tmp que ahora es un tmpfs, si van a probar isos, bajarlas o cosas mas pesadas, pueden poner 4gb, o lo que quieran. No se usarán a menos que sea necesario, asi que... no es que será usado.
Lo normal es poner 512mb, pero para el comun de los usuarios, 128mb esta mas que bien.
noexec: En /tmp no se ejecuta nada, de hecho muchos rootkit usan eso para poder instalarse, y hasta hace poco habia un bug en gnome-terminal donde parte de los datos de ssh iban a parar al /tmp, asi que, con esto le indican que NADA puede ejecutarse en /tmp, como debe ser.
nosuid: Evita que el bit setuid se aplique a algun archivo en /tmp
sync: Como es memoria RAM, aca todo dato que se escribe va a parar a RAM y no a disco directo, especificamos que sea sincronica la escritura/lectura de datos, a diferencia del resto de un sistema Linux, donde los datos son asincronicos, para mejorar la performance de disco. Además, con esto evitamos algunos problemas que se producen en Chrome y Firefox, al usar su caché en /tmp, e intentar refrescar o volcar datos muy rapidamente. Al usar 15 segundos de tiempo para volcado de disco (visitar este post: http://hackingthesystem4fun.blogspot.com.ar/2012/06/reducir-el-io-de-disco-para-escrituras.html), si bien mejoramos performance y usamos menos el disco, tambien debemos tener en cuenta las aplicaciones que requieren y hacen uso de cache, de forma externa al kernel y requieren una respuesta rapida, asi no veremos ningun "Chrome no puede acceder a la cache" o bien paginas mal cargadas, algo frecuente usando 15 segundos y a veces de forma nativa, recordemos que Firefox y Chrome fueron concebidos para Windows, un OS que usa NTFS, un FS sincronico.
Esto es algo que veremos mas adelante aca:
http://hackingthesystem4fun.blogspot.com.ar/2012/06/usar-ram-para-la-cache-de-disco-de.html
sync: Como es memoria RAM, aca todo dato que se escribe va a parar a RAM y no a disco directo, especificamos que sea sincronica la escritura/lectura de datos, a diferencia del resto de un sistema Linux, donde los datos son asincronicos, para mejorar la performance de disco. Además, con esto evitamos algunos problemas que se producen en Chrome y Firefox, al usar su caché en /tmp, e intentar refrescar o volcar datos muy rapidamente. Al usar 15 segundos de tiempo para volcado de disco (visitar este post: http://hackingthesystem4fun.blogspot.com.ar/2012/06/reducir-el-io-de-disco-para-escrituras.html), si bien mejoramos performance y usamos menos el disco, tambien debemos tener en cuenta las aplicaciones que requieren y hacen uso de cache, de forma externa al kernel y requieren una respuesta rapida, asi no veremos ningun "Chrome no puede acceder a la cache" o bien paginas mal cargadas, algo frecuente usando 15 segundos y a veces de forma nativa, recordemos que Firefox y Chrome fueron concebidos para Windows, un OS que usa NTFS, un FS sincronico.
Esto es algo que veremos mas adelante aca:
http://hackingthesystem4fun.blogspot.com.ar/2012/06/usar-ram-para-la-cache-de-disco-de.html
0 0: Significa que ni debe ser chequeado por fsck, ni tampoco backupeado.
Eso es todo, reinicien y verán un cambio de velocidad minimo, pero util al fin, unos 3 seg o 2, en GDM, audio, en general, y un incremento en mi caso, de 125 a 128 mb de ram, solo 3mb pero he ganado mucho mas.
19 comentarios:
Hola SynFlag. Muy buen post. Te queria preguntar ¿Que distro usas y con qué entorno de escritorio que te consume tan poco?. Un saludo
Gracias, al momento de hacer este post, Scientific Linux 6.2 con un kernel custom 3.4.3, entorno gnome 2.28, conky, parcellite, pulseaudio, etc.
gracias por el post.
Como hago esto en el navegador Iron
Hola, según tengo entendido Iron es otro fork mas de Chromium, asi que el metodo es el mismo que se describe aca, pero siguiendo los pasos del post: http://hackingthesystem4fun.blogspot.com.ar/2012/06/usar-ram-para-la-cache-de-disco-de.html.
Basicamente, te copio y pego los pasos:
Si usan KDE o GNOME2 o GNOME3 o lo que sea, es lo mismo, la orden es la misma.
Por defecto, los lanzadores de Chrome vienen con esta orden:
/opt/google/chrome/google-chrome %U
Bueno, solo debemos cambiar eso, por esto otro:
/opt/google/chrome/google-chrome %U --disk-cache-dir="/tmp/google-chrome/"
Si usas el metodo para Iron & Firefox al mismo tiempo, OJO dado que se pueden pisar las cache en /tmp, asi que lo que haces en firefox, cuando le das la ruta es esto:
Por ultimo, para que no se pisen entre Chrome y Firefox, en /tmp, debemos crear un directorio aparte para Chrome, o bien Firefox, yo lo hice con Chrome, como /tmp ahora es RAM, en cada reinicio se borrará lo que hagamos, asi que en /etc/rc.local, colocamos lo siguiente:
mkdir -p -m 700 /tmp/google-chrome/ && chown -R synflag:synflag /tmp/google-chrome/ && chmod -R 700 /tmp/google-chrome/
Reemplacen synflag por su usuario, si?.
/opt/google/chrome/google-chrome %U
Lo unico que tengo en la capeta /pot es libreofice
A Iron lo instale coo .deb y esta en la carpeta /usr/share.
alguna idea?
gracias
Entonces cambia la ruta, nada mas!, el resto es lo mismo!
saludos, me gustaría conocer su opinión sobre esto:
http://rwmj.wordpress.com/2012/09/12/tmpfs-considered-harmful/
Que tal, te diré mi opinion al respecto:
1.- primero que nada, te recomiendo que veas esto: http://slacy.com/blog/2008/08/tmpfs-vs-ext3-performance-on-large-file-sets/
En sistemas modernos, que usan memorias DDR3-1333 en el caso promedio, o bien 1066 en el peor de los casos, incluso algunos usan 1600mhz, reporta un gran beneficio frente a los discos HDD 7200 RPM, ni hablar de los 5400 RPM.
En ese post lo que se plantea, es el hecho de que mucha gente almacena cosas en /tmp (no es mi caso, su nombre lo dice, es tmp), asi como el tamaño del mismo, en mi caso lo monto con un maximo de 2GB, es distinto tmpfs que ramfs, el ramfs una vez llegado el limite, puede excederse si lo necesita, el tmpfs no.
Si te fijas, las cosas que se almacenan en tmpfs, son cosas pequeñas, muy pequeñas, y que no revisten importancia.
Un ejemplo, claro, es, en este momento que te escribo:
tmpfs 2,0G 280K 2,0G 1% /tmp, solo 280K en uso
La velocidad de los programas o demonios que usan /tmp se incrementa, asi como la limpieza, en cada reinicio, el directorio se vacia por razones obvias, reside en RAM, no en disco.
Evitas la escritura en disco constante, y usas la RAM, asi alivianando el uso de disco, y por consiguiente extendiendo su vida util.
En caso de bajar cosas usando Firefox o lo que fuese que use /tmp, si excede los 2GB, comenzará a dar errores. Lo que se almacena ahi, en el caso de firefox y chrome, es su cache, por lo tanto, reporta otro beneficio (al configurar chrome y firefox para que usen /tmp claro, sino, no lo usan), que es el de no tener que vaciar la cache de navegacion, ni de forma manual, ni que el navegador deba hacerlo implicando eso una minima, pero algo de carga de disco y cpu, o mejor dicho I/O, usando /tmp en RAM, esto, no sucederá nunca.
Fuduntu, usa el mismo metodo, y muchos "tunning" de sistemas lo usan, sobre todo en maquinas con olgada RAM, como es mi caso, 8GB.
Lo que dice el articulo ese, es que ya tenemos un sistema que usa las cosas en RAM y luego las vuelca, si, ext4 cada 5 segundos, usando /tmp como tmpfs, no se vuelca nunca, con lo cual tenes un uso menos, ademas, esta mezclando conceptos el autor, una cosa son los datos en RAM que corresponden a transacciones de ext4 y otra es el sistema de archivos temporal.
Por defecto, /tmp se limpia cada 7 dias, entonces, pro y contra, si usas mucho /tmp, en 7 dias tienes unos 40GB quizas?, mientras yo, lo tendré siempre limpio para cada sesion.
Los datos relevantes, se guardan en otros lugares, /tmp, no es lugar apropiado, sea RAM o disco, para guardar nada, eso lo sabe cualquier persona.
En sistemas con buena ram, disco no SSD, esto reporta un enorme beneficio, incluso, dejame decirte, que en algunos servidores con 64Gb de RAM, se hace esto, para la cache de Apache, porque?, velocidad, y dejar el disco libre para transacciones de mysql quiza. Con lo cual demuestra que no representa un problema de estabilidad alguna, claro, siempre y cuando no tengas las memorias en mal estado, con lo cual, es el mismo problema si fuera el disco... si esta en mal estado?, e incluso, a favor de tmpfs, tiene mas posibilidades de fallar un disco que una memoria RAM, siempre.
Espero que te sea satisfactoria mi respuesta y si tenés algo mas que comentar, sos bienvenido.
Añado, en caso de tener un disco SSD, posiblemente, esto no tendria sentido, si lees bin el trac de fedorahosted, comentan eso, y el problema es el tamaño que se le ha dado, chico, por eso yo explique los parametros, cada uno coloca al size a como mas le conviene por su cantidad de RAM y el uso que le de a su PC.
En lo que a mi respecta, en la notebook, con un disco de 5400 RPM, 8GB de RAM, me reporta un gran beneficio, sino, tendria que comprar un disco SSD de 500GB?, no gracias jaja
Te agradesco el tiempo que te tomaste para contestar a mi pregunta, ya me queda mas claro sobre el tema.
por eso es que lo van a implementar en Fedora 18.
Solo queda agradecerte por los articulos que haz publicado.
Saludos.
De nada, queria aclarar las dudas y comentarte un poco mas sobre el tema, para que veas los pro y contra, asimismo los entornos en que se debe o no usar, o afecta y en que medida. Si, de hecho tengo Fedora 18 Alpha en una VM, y te digo que anda fenomenal. Gracias a vos
Hola, espero y no se muy tarde para comentar, aun soy algo nuevo en esto de linux. Mi duda es que ocupas el parámetro relatime, ¿No seria mejor el parámetro noatime, como explicabas en otro de tus posts?.
Posdata: Excelente Blog
Depende de que particion hablemos y depende del uso. Por defecto linux usa atime, escribe en el disco cada vez que cualquier de la page cache es accesado y actualiza el inodo. Relatime actualiza solo si la fecha de actualizacion del inodo es anterior a la actual. Noatime no actualiza nunca nada.
Ahora, porque digo esto, por un motivo, no hablemos de que mutt necesita relatime como minimo, sino de mas cosas, como el comando stat. No es relevante usar relatime en el swap o en el /boot, pero para mi si en / y /home. Si necesito saber cuando fue modificado o accesado por ultima vez un archivo, realizando stat lo puedo saber si es que uso relatime, si usara noatime no y en caso de intrusion o corrupcion de datos, no saber cuando fue accesado un archivo de sistema o personal, es un problema al menos para mi, para otras personas no, eso va en cada gusto.
A mi en lo personal, mantener los datos de acceso en /home y / me resulta util, usar atime como viene por defecto me parece demasiado, a menos que sea un server, pero no usar nada me parece el extremo, en por ganar velocidad perder control sobre el acceso a archivos personales y de sistema.
Desde el kernel 2.6.30 (que salio en 2009) Linux usa relatime por defecto,
Fuente: http://unix.stackexchange.com/questions/17844/when-was-relatime-made-the-default
Buen dato, pensé que el default era hacerlo siempre, no relatime, como lo vi aclarado en post incluso de comunidades de distros... no pensé que fuera así por defecto.
Buen día, yo tengo una duda, la cantidad de RAM limita el tamaño de la tmfs? lo digo porque default en Oracle linux me instalo 2g mi servidor tiene 4g pero para instalar una segunda base de datos me pide que incremente esta particion y me aconseja que ponga 4g, siendo conservador lo incremente a 3g pero con algo de sentimiento de inseguridad por problemas de desbordamiento, que opinan?
Mirá, el sistema de archivos montado como tmpfs, es en ram, asi que desde ya te digo, que todo (shm, /tmp) montado como tmpfs, es en RAM
Ok, te agradezco, hasta ahora no ha presentado problema, entiendo que va a ser un repositorio para fragmentos temporales, un saludo y buena pagina
Muchas gracias a vos por pasarte y el halago.
Es muy util para caches o cosas que requieran velocidad cuando no se posee de un disco SSD, que igualmente nunca sera mas rapido que una DDR3.
Publicar un comentario