Optimizando el Sistema Linux – Memoria Virtual

By | 0 Comments

  Hola de nuevo, puesto que adquirí hace poco un nuevo laptop, me pareció oportuno compartir con ustedes lo que estoy haciendo, tras instalar el sistema Linux, para de alguna manera conseguir optimizarlo. El sistema que he instalado es Debian Jessie, que es ahora la versión estable.

  Primero de todo, vamos a hablar de la memoria virtual, en la propia instalación según la memoria RAM que tenga tu equipo, te puedes plantear si usar o no partición SWAP. Yo creo que para equipos con 4G de RAM quizás aún necesites la memoria SWAP. Pero en mi caso tengo 8G así que de la SWAP me puedo ir olvidando. De todas formas si tienes 4G, te recomiendo que compres otros 4G que estarán entre 20 y 30€ ahora. Aunque siempre puedes indicar al sistema que use lo menos posible la SWAP, el acceso a la memoria de disco puede llegar a ser miles de veces mas lenta que a la RAM, lo que va a ralentizar tu sistema y aplicaciones. Y lo mismo ocurre en el archivo de paginación de Windows.

Info de memoria con top
(Click para agrandar)

  Resumiendo, intenta tener RAM suficiente para no tener que ocupar memoria en disco. Al instalar el sistema sin SWAP te advertirá, pero puedes continuar sin ningún problema, además que si lo necesitases, hay muchas formas de habilitar la SWAP después.

  Otra de las razones que dan los desarrolladores respecto al uso de SWAP, es que hay muchas paginas de memoria que hacen referencia a inicios de procesos, que esos propios procesos nunca más van a necesitar. Y por tanto es mejor que se saquen de la RAM, pero tranquilos que de dejar la RAM bien “limpia” ya nos vamos a encargar nosotros.

  Además que todas las acciones de lectura y escritura, es un desgaste para el disco duro, por no hablar de los continuos movimientos de páginas entre RAM y SWAP. A groso modo, cada página que se saca de la RAM debe ser cuidadosamente copiada, guardando también la información necesaria para que se pueda volver a meter en RAM cuando se libere más espacio (punto de entrada). El proceso de copia a la swap es bastante rápido, pero el proceso de vuelta a la RAM es mucho más costoso, ya que tiene que hacer una búsqueda por toda la tabla de paginación hasta encontrar el punto de entrada. Para mejorar los tiempo de búsqueda, usan una cache, pero bueno no voy a profundizar más.

  Creo que no se puede tomar una decisión sin saber que riesgo estamos tomando. En este caso, que pasaría si me quedo sin memoria RAM, ya que SWAP no voy a poner. Pues bueno, los sistemas linux manejan un complejo sistema de procesos para trabajar con la memoria. Si una aplicación requiere la reserva de una cantidad de memoria, que excede de la que tenemos libre, el kernel puede perfectamente aceptar esa solicitud ya que sabe que la aplicación esta reservando esa memoria, pero no la va a usar de golpe. Es lo que se denomina “overcommit”. Todo esto requiere de unos algoritmo complejos y de una heurística, se busca el espacio libre real, entre paginas libres, caches, etc, y un porcentaje de la memoria física que podemos setear nosotros.

  También se preparan para ser liberadas aquellas páginas inactivas, con un algoritmo basado en las páginas que más tiempo llevan sin usarse (LRU), por el cual se forma una cola FIFO con las páginas que en un momento de apuro se pueden llegar a liberar.

  Pero si aún así sigue sin haber memoria disponible, se produce un error del sistema ENOMEM (Error No Memory), que puedes capturar en tu aplicación, la reserva de memoria ya sabéis que se hace con funciones como malloc(). Y se desata la bestia …

la bestia
(Click para agrandar)

  Bueno, digamos que aún no sale la bestia, primero se hace una llamada al OOM (Out Of Memory) para que realice una ultima comprobación, antes de dejar que el pánico se apodere de los procesos. Esta función lo que hace es asegurarse de que realmente no hay más espacio en la SWAP (si existe), y otra serie de factores relativos al número de errores respecto al tiempo, mas o menos parecido a como se configuraban los servicios anti-flood del irc , ya me entendéis.

  Poniéndonos en lo peor, si la comprobación verifica el problema, se manda a la bestia a que haga su trabajo. Ésta se denomina OOM Killer (sí, yo me lo imagino como en la imagen), y básicamente hará lo necesario para conseguir liberar recursos, matando los procesos que estime oportuno. Pero ¿ que procesos matar ?, ¿ por qué debería cerrarse un proceso y no otro ?, ¿ en base a qué ?. Bueno, esto me hace recordar la analogía que leí hace tiempo sobre el tema en cuestión, donde se tenia un avión con el combustible justo para el viaje, pero que a veces no era suficiente para llegar, entonces se creo un mecanismo llamado OOF (Out Of Fuel), que tiraría del avión a una persona cada vez que andasen escasos de combustible. Entonces se planteaban la duda de a que pasajero tirar, ¿ al mas gordo ?, ¿ al más viejo ?, ¿ y si el más viejo es el piloto habría que dejarle ?, y así una serie de cuestiones casi interminables (me parto de risa cada vez que lo recuerdo).

  El caso es que los desarrolladores también han sufrido el mismo problema, y han desarrollado un algoritmo para saber que proceso matar primero. Primero se buscará el proceso que mas memoria esta consumiendo, pero que no lleve mucho tiempo en ejecución. Esto es perfectamente entendible ya que un proceso muy antiguo tiene pocas posibilidades haber sido la causa del OOM, además que puede ser algún cálculo que lleve días en el servidor y no le haría mucha gracia al administrador que lo killease. Si el proceso es de root, lo que hace es rebajar la probabilidad en 1/4. Y aún así, en el caso de que los procesos seleccionados tengan otros “proceso hijos”, se intentarán cerrar por las buenas o por las malas estos procesos, para que el principal pueda sobrevivir. No si al final la bestia tiene su corazoncito.

  En cada nueva versión del kernel van intentando mejorarlo, para que sea más seguro (o menos agresivo), etc. Incluso creo recordar que se puede agregar a los procesos información referente al OOM, no he investigado sobre esto. Aún así, hay muchas personas que hablan “sapos y culebras” sobre esta utilidad, aunque otra gente opina que peor sería que no estuviera. Ésto en verdad, donde importa es en los entornos de producción, nosotros como usuarios aislados, no podemos tener una opinión de mucho peso.

  Ok, la teoría esta bien pero ¿ que tengo yo en mi sistema ?. Bueno, pues vamos a verlo. Todos estos parámetros referentes al sistema, kernel, proceso, etc, están el un directorio especial que seguramente conoceréis o habréis visto en un “ls” (por lo menos), llamado /proc. Por ejemplo, podemos ver información de la memoria con un cat /proc/meminfo. No son ficheros reales, son “archivos virtuales”, sin peso en disco, pero que también nos permiten interactuar con el kernel en tiempo real.

  Pues vamos a ver por ejemplo que nivel de overcommit tenemos en Debian Jessie, que tengo actualmente con kernel 3.16.7 .

/proc/sys/vm/overcommit_memory     0

  Tengo el valor 0, que si vamos a la documentación este valor indica que se comportará como he descrito arriba, haciendo overcommit ante una petición de recursos por parte de una aplicación. Y podemos setearla a 1, el kernel va a decir que si a todas las aplicaciones, pidan lo que pidan. O setearla a 2, que es lo opuesto, no se hará overcommit, si no hay mas memoria no se ejecuta y listo (el porcentaje también cuenta). Una cosa esta clara si lo ponemos a 2, casi sería lo mismo que deshabilitar el OOM por que simplemente no va a dejar correr las aplicaciones, aunque igual es un poco drástico, ¿ no creéis ?. Yo lo dejo como está.

  El porcentaje de memoria física que os comentaba antes, podemos verlo aquí.

/proc/sys/vm/overcommit_ratio     50

  Un 50% por defecto, pues bien. Como comprobar que esto es verdad, pues mirando en el fichero de información de la memoria que he puesto antes.

$ cat /proc/meminfo | grep -i "commit"
CommitLimit: 4057116 kB
Committed_AS: 1341664 kB

  En mi caso que tengo 8G pues el limite lo tengo en 4G (el 50%) y el otro valor marca lo que actualmente tengo en overcommit.

  Para el OOM tenemos alguna configuración, como por ejemplo decirle si lanzará un kernel Panic (y reinicio).

/proc/sys/vm/panic_on_oom     0

  Por defecto no lo hará, si lo ponemos a 1 sí.

  Estos serían los parámetros que más nos podría interesar tocar, yo lo dejo todo por defecto, pero si tenéis algún problema con la memoria, ya sabéis donde tocar.

  Saludos y no desatéis a la bestia!

 

  Continuación: http://blog.hackxcrack.net/optimizando-el-sistema-linux-memoria-virtual-2/