Dandole Tuning al swappiness para prevenir una catastrofe en RAM improvisada
Swappiness es el termino que los desarrolladores del kernel de linux dieron al rendimiento entre aplicaciones que paginan hacia el disco y (en la practica) a la contraccion de las caches. Si Swappiness fuece establecida a 0, Linux preferirá mantener applicaciones en RAM y no engrandecer los caches. Caso contrario, si establecieramos Swappiness a 100, Linux preferirá hacer swap a las aplicaciones, y alargar los caches lo mas posible. El parametro de 60 por default que viene en la mayoria de los sistemas linux suele ser algo saludable.
La ironia de esta preferencia Swappiness radica en este factor, paginando una aplicacion no esta siendo utilizada generalmente producira un incremento sobre el rendimiento de red, ya que el cache realmente ayuda a esto muchisimo cuando este es requerido — pero este aumento sobre el rendimiento de red, se traducira en una fuga del rendimiento percivida, lo notaras cuando tu aplicacion descomprima un archivo con algunos segunditos de retraso, tal vez eso no te importe en el momento que suceda, pero cuando si te llega a importar, sera el momento en que tu aplicacion ya no te responda de manera instantanea :).
Sobre mi laptop, se me ha ocurrido aplicar el swappiness lo mas cercano a cero. La razon de por que se me ocurrio hacer esto? Lo hago por que deseo inmunizar mi laptop contra esas pequeñas interrupciones de tiempo causadas por la manipulacion de grandes archivos temporales (pienso hacer una copia de un archivo grande de video hacia otro disco). El cache debera de ser lo mas grande posible, pero esto no debera desplazar a las demas aplicaciones que ya se encuentran corriendo.
No me crees ? Si tienes 2 gb para usar sobre tu particion / , entonces que esperas incredulo corre los siguientes comandos en el siguiente orden:
sync echo 3 > /proc/sys/vm/drop_caches dd if=/dev/zero of=/tmp/archivobasurita count=1 bs=900M find / > /dev/null && cp /tmp/archivobasurita /tmp/archivobasurita2
La tiempo consumido en la ejecucion de los anteriores comandos fue de 6:20 min:seg. Desesperantemente lento no ? Imagina como pueden tus aplicaciones podrian esperar, mientras el disco duro centellea con su lucecita frenéticamente :)…..
Muy bien, ahora modifiquemos el swappiness de nuestro sistema. (por supuesto como root):
sysctl -w vm.swappiness=1
intenta otra vez con los comandos de arriba. Sientes la diferencia, el tiempo se redujo a 2:05 min:seg?
La razon de esta rapidez, cuando tenemos el swappiness casi a cero, El nucleo de Linux no aumenta el cache para que las aplicaciones paginen, dandote una experiencia de rapido acceso a memoria.
Para hacer este cambio permanente, escribe vm.swappiness=1 sobre tu archivo /etc/sysctl.conf.
Los caches del sistema de archivos son mas importantes que otros caches
Existen dos tipos de caches en un Linux VFS.
* Block cache: contiene cache de dispositivos de bloque
* inode/dentry(inodo y de entrada de directorio): una capa sobre el block cache, el cache de entrada de directorios y otros sistemas de archivos relacionados, tienen para el sistema linux un costo de busqueda mucho mayor, al del cache de dispositivos de bloque.
Ya establecimos que la cache del sistema de archivos es importante ya que, sin esta, la busqueda y manejo de los archivos seria extremadamente lenta. Ahora aprenderemos como decirle a linux que cache preferimos inode/dentry u otras caches.
Probemos esto:
sync echo 3 > /proc/sys/vm/drop_caches dd if=/dev/zero of=/tmp/basurita count=1 bs=900M
sysctl -w vm.vfs_cache_pressure=100 find / > /dev/null cp /tmp/basurita /tmp/basurita2 time find / > /dev/null
sysctl -w vm.vfs_cache_pressure=50 find / > /dev/null cp /tmp/basurita2 /tmp/basurita3 time find / > /dev/null rm -f /tmp/basurita /tmp/basurita2 /tmp/basurita3
Esta serie de comandos lo que hace basicamente es, buscar todos los archivos sobre tu disco, despues crear grandes archivos. Esto se hace 2 veces, la primera vez con las parametros por default del cache, y la segunda vez con los parametros del cache fuertemente orientados a favor de la cache inode/dentry.
Observaste la salida de los anteriores comandos. Notaste que la segunda vez que se corren los comandos realmente se consume menos tiempo? Esto definitivamente reduce los tiempos sobre nuestro equipo gnu linux. Cuando este knob(perilla o boton de mando, segun el diccionario de proyecto lucas Ver 0.1.6 ) esta cercano a 1, el kernel preferira proteger la cache inode/dentry por estar liberando block cache primero.
Para hacer este cambio permanente, agrega vm.vfs_cache_pressure=50 sobre tu archivo /etc/sysctl.conf.
Experimenta con este valor. Valores proximos a 100 no proveen ninguna ganancia en rendimiento. Valores cercanos a cero pueden causar enorme actividad swap durante la escaneo de grandes sistemas de archivos.
