Introducción
Revisando algunas de las ideas que he ido escribiendo en artículos anteriores, como en «Liberando la memoria Cache«, o «Menos swap y mas Ubuntu para empezar el año«, y tras haber realizado algunas modificaciones a la aplicación que «controla» y libera la memoria, me he decidido a escribir este artículo, que sirva como recopilatorio, con el objetivo de mejorar el rendimiento de tu máquina.
Las ideas
Swappiness
La primera de las operaciones a realizar es la reducción del uso de la memoria de intercambio swap. Actualmente, esta viene definida por defecto al 60%, sin embargo en los equipos de sobremesa esta se puede reducir drásticamente, mejorando sensiblemente el comportamiento del equipo a un 5%. Esto lo traté en un artículo que escribí hace ya algún tiempo, «Menos swap y mas Ubuntu para empezar el año«, para la que escribí una sencilla aplicación, que puedes instalar, añadiendo el repositorio y actualizando:
sudo add-apt-repository ppa:atareao/atareao && sudo apt-get update
Una vez instalado, puedes instalar la aplicación haciendo clic en VMM, o bien desde el terminal:
sudo apt-get install vmm
Puedes iniciar la aplicación desde el Dash escribibiendo vmm, y verás la siguiente ventana de diálogo:
Seleccionas la cantidad de memoria de intercambio, que ya te digo que con un 5% te sobra, y a correr.
Liberando la Memoria Cache
La siguiente operación es liberar la memoria cache conforme deja de estar en uso, para ello, utilizaremos el script del artículo Liberando la memoria Cache que creamos a propuesta de Miquel Mayol, que ya comentó lo que sucedía con la memoria RAM y la memoria Caché. En esta nueva versión, he modificado ligeramente el comportamiento del script, pero en esencia, y a los efectos de lo que nos interesa funciona igual.
Primero, y tal y como comentábamos en Liberando la memoria Cache, modificaremos las opciones del kernel para obligarlo a que libere la memoria caché:
sudo su echo 10000 > /proc/sys/vm/vfs_cache_pressure exit
Ahora nos descargamos de la página el paquete en cuestión:
[wpfilebase tag=file path=’scripts/freecache.tar(3).gz’]
Una vez descargado, tienes que cambiar el propietario a root, darle permisos de ejecución y copiarlo en el directorio /usr/bin:
tar xvzf freecache.tar.gz sudo chown root:root freecache sudo chmod +x freecache sudo mv freecache /usr/bin
El siguiente paso, para que se inicie con tu sistema para todos los usuarios, consiste en editar el archivo /etc/rc.local:
sudo nano /etc/rc.local
y añadir la siguiente línea, justo antes de «exit 0»:
/usr/bin/freecache start
Si no lo quieres añadir aquí, siempre puedes hacerlo en aplicaciones al inicio, pero ten en cuenta que solo funcionará para aquellos a los que lo hayas instalado, pero sin lugar a dudas es una opción.
Preload
La siguiente operación a realizar es instalar preload, que es una aplicación que se encarga de precargar las librerías mas utilizadas, acelerando sensiblemente la carga de cualquier aplicación. Preload está en los repositorios de Ubuntu, con lo que puedes instalarlo, haciendo clic en Preload, o bien, desde el terminal:
sudo apt-get install preload
Acelerando el arranque de OpenOffice/LibreOffice
Por último, si las herramientas que mas utilizas es OpenOffice o LibreOffice, puedes habilitar el inicio rápido. Para ello, en cualquiera de las herramientas de LibreOffice, seleccionas Herramientas > Opciones > Memoria, y marcas la opción que hay en la parte inferior de la ventana «Habilitar el inicio rápido en la bandeja del sistema».
Una observación, ten en cuenta que en Ubuntu Oneiric Ocelot, ya no aparece el «Systray», la bandeja del sistema, con lo que tu no verás el icono, pero cuando inicies LibreOffice o OpenOffice desde el Dash, enseguida te darás cuenta de que está funcionando, porque el arranque es casi inmediato.
Conclusiones
Estas son algunas de las ideas que he ido recopilando en estos últimos días, puedes aplicarlas todas, o las que mas te interesen. Y por supuesto, si tienes alguna recomendación, aquí tienes tu sitio. Desde luego, que la rapidez y el funcionamiento del sistema se notan, pero como me pasa con el navegador, tarde o temprano dejo de observarlo.
A mi me funciona más fluido si subo el swappiness a 95. Miralo de este modo: cuanto mas cosas tengo grabadas en la partición de swap, menos cosas tengo que escribir cuando quiero liberar memoria para poner otra cosa. Es decir, voy a tener mas escrituras a swap mientras tenga memoria fisica libre, pero cuando necesite más memoria, va a ser más rápido.
Realmente swappiness lo que indica de memoria será RAM y que porcentaje es MEMORIA VIRTUAL alojada en disco duro (SWAP). Cuanto mas escribas sobre el disco duro mas lento va.
No termino de entender porqué a ti te va mas rápido
No dije que fuera mas rápido. Dije más fluido.
Que algo se escriba en la memoria virtual no significa que deje de estar en la memoria física. Si tengo muchas escrituras mientras la máquina tiene poca carga, no me molesta demasiado.
Ahora, supongamos que ocupo toda mi memoria física, y YA necesito más.
No hay problema, muchas de las páginas de mi memoria física va a estar replicadas en el swap y la voy a liberar rápidamente.
En cambio, si el swap está vacío, primero voy a tener que volcar esas páginas al swap y solo después las voy a poder liberar.
Además, si fuera tan simple como lo que tu o yo proponemos, ¿puede ser la gente de Canonical tan insensata como para setear un valor de 60%?
tambien otro post de este blog:
https://atareao.es/ubuntu/conociendo-ubuntu/aumenta-la-velocidad-de-navegacion-en-firefox/
Yo lo he optimizado muchísimo (porque todos estos trucos ayudan, pero no resuelven) cambiando el disco duro por un ssd.
Cambio Brutal…
Una pregunta, el uso de zRam no ayuda en el rendimiento?
Cierto, esto se me había olvidado por completo.
Gracias por el apunte
te falta el «sudo» mv freecache /usr/bin
si se sigue paso a paso
eso me pasa por recomendarte tanto
Corregido @mitcoes:disqus
Gracias y Saludos
No sé de donde habéis sacado que swappiness indica un porcentaje de uso de Swap. Nada más lejos de la realidad. Lo que indica es digamos la «agresividad» con la que el kernel decide o no enviar páginas de memoria a swap y el cálculo que hace para esto es bastante complejo por cierto. Si buscáis un poco en google veréis sitios donde esto está bien explicado. Ahora bien, evidentemente bajando el swappiness indicas al kernel que no sea tan agresivo enviando cosas a swap lo cual puede favorecer algo la latencia de las aplicaciones. En cambio, en un servidor sería al revés y lo que nos interesaría es tener cuanto menos «memoria inútil ocupada» mejor.
Otro tema aparte es lo del script que habéis montado para «liberar» las caches…no termino de entender la necesidad de tal cosa cuando la memoria en buffers y caches está libre a todos los efectos (asi lo refleja free) y se puede disponer de ella en el momento de que sea necesaria. Realmente dudo mucho que aprecieis mejora alguna en sacar la memoria de las caches o del espacio libre directamente pero bueno…efecto placebo.
El problema es ese que hay veces que la caché no se borra para que los programas la ocupen y ralentiza el sistema, incluso con 4 Gbs de RAM, mucho más en sistemas con menos memoria.
En esos casos – el script no borra la caché si no es en estas condiciones – se borra la cache, y el sistema nota la mejora.
A mi me pasaba con Qbittorrent, ahora ya no.
Me falta por ver el primer servidor que no libera búffers de disco y caché de páginas cuando escasea la ram, sinceramente. Y digamos que veo muchos.
Esas configuraciones del kernel las establece los hackers del mismo, que son gente que entiende bastante más que nosotros del tema y esto no se establece así a la ligera. No es un error y no se haría si ralentizase la máquina.
En cualquier caso, cada uno evidentemente puede «tunear» como mejor le parezca claro está y si a él la parece que aumenta rendimiento pues genial.
En mi sobremesa te aseguro que ocurre y busqué y encontré el comando con un artículo que hablaba sobre la existencia del problema que yo tenía y como solucionarlo, le sugerí a el atareao que hiciese un script – yo no se tanto – él verificó que a veces ocurría, e hizo el script que no sólo va de maravilla si se da este problema, sino que además fue citado en varios otros blogs.
En sevidores, con menos paquetes corriendo que puedan originar estos fallos puede que no ocurra, pero un defectillo en la programación de algún paquete puede dar lugar a esta circunstancia y lo que hace el script es detectar el síntoma y borrar la caché si esta sumada a la ram usada ocupa casi el 100% de la memoria – lo que ralentiza el sistema – sobre todo de escritorio y si sigues la evolución la cache vuelve a crecer, pero no llega en el corto plazo ni a la mitad de lo que estaba «estancado» en cache sin ser cache.