Durante años han estado unos seis servidores del curro con un problema bastante gordo de memoria. Esos servidores eran específicos de base de datos Oracle para unas aplicaciones de la consejería. Al ser aplicaciones muy especiales, el proveedor exigía conservar los soportes de RedHat Enterprise Linux 3 para x86_64 y Oracle 9-10. Impidiendo cualquier cambio a nivel de sistema operativo.
El problema consistía en que cuando se lanzaban las tareas de backup de base de datos con el RMAN de oracle, los equipos empezaban a tirar de memoria de intercambio, toda la que tuviera y más. Daba igual la cantidad de memoria física que tuviese. Ralentizando el proceso de copia de seguridad e incrementando la carga. Como era una tarea nocturna, el problema no afectaba a los usuarios, quedando latente y sólo saliendo a relucir de vez en cuando.
Así pasó el tiempo hasta que hace unos días, a uno de esos servidores se le pudo incrementar la RAM, que pasó de 4 GB a 8 GB. Creyendo que esa era la solución nos olvidamos nuevamente del problema.
Pero hijo mio, pasadas unas semanas vimos que pasaba igual. Así que esta vez me olvidé de todo lo que me habían contado y me puse manos a la obra con el vmstat. Este me decia que pese a tener 7 GB de memoria cache, el sistema operativo empezaba a tirar de swap. Cosa algo ilógica.
Linux asigna memoria para sus procesos y el resto, que queda libre, la usa para memoria cache (buffers de disco y otras cosas) tendiendo a utilizar toda la memoria RAM disponible. En el caso de que necesite más memoria para algún proceso, no tira de memoria de intercambio, sino que libera memoria cache y solo en el caso de que no tenga memoria cache (toda la memoria este siendo utilizado por procesos) es cuando empieza a utilizar la memoria de intercambio.
Tras lo cual, queda claro que el kernel no libera la memoria cache que consume.
Viendo esto y que ademas era una redhat antigua, con un kernel 2.4.21-20.ELsmp, me puse a mirar en san google posibles perdidasleves de orina memoria en el kernel. Bingo! El bug estaba ahí, tan bonito, esperando que alguien lo encontrase Bug 151916 - kernel memory leaks, memory cached never flushed en modo CLOSED WONTFIX desde el 23 de Marzo de 2005.
Ahora toca compilar un kernel más moderno o actualizar el sistema. En ambos casos, el proveedor se desentiende del soporte y se lava las manos, pero visto lo visto, el soporte que tanto se ha cuidado de poca ayuda ha servido. Es para darle a mas de uno con las matrices de compatibilidad y las licencias enterprise del software en la cara, si cuando pasa algo serio, no sirven de nada.
De hecho, creo que este problema influyó decisivamente en un proyecto de migración a una plataforma PrimeQuest de Fujitsu de todas esas máquinas. Un proyecto bastante caro por cierto y que también debe mantener la dichosa matrix de compatibilidad por exigencias del guión.
El problema consistía en que cuando se lanzaban las tareas de backup de base de datos con el RMAN de oracle, los equipos empezaban a tirar de memoria de intercambio, toda la que tuviera y más. Daba igual la cantidad de memoria física que tuviese. Ralentizando el proceso de copia de seguridad e incrementando la carga. Como era una tarea nocturna, el problema no afectaba a los usuarios, quedando latente y sólo saliendo a relucir de vez en cuando.
Así pasó el tiempo hasta que hace unos días, a uno de esos servidores se le pudo incrementar la RAM, que pasó de 4 GB a 8 GB. Creyendo que esa era la solución nos olvidamos nuevamente del problema.
Pero hijo mio, pasadas unas semanas vimos que pasaba igual. Así que esta vez me olvidé de todo lo que me habían contado y me puse manos a la obra con el vmstat. Este me decia que pese a tener 7 GB de memoria cache, el sistema operativo empezaba a tirar de swap. Cosa algo ilógica.
Linux asigna memoria para sus procesos y el resto, que queda libre, la usa para memoria cache (buffers de disco y otras cosas) tendiendo a utilizar toda la memoria RAM disponible. En el caso de que necesite más memoria para algún proceso, no tira de memoria de intercambio, sino que libera memoria cache y solo en el caso de que no tenga memoria cache (toda la memoria este siendo utilizado por procesos) es cuando empieza a utilizar la memoria de intercambio.
Tras lo cual, queda claro que el kernel no libera la memoria cache que consume.
Viendo esto y que ademas era una redhat antigua, con un kernel 2.4.21-20.ELsmp, me puse a mirar en san google posibles perdidas
Ahora toca compilar un kernel más moderno o actualizar el sistema. En ambos casos, el proveedor se desentiende del soporte y se lava las manos, pero visto lo visto, el soporte que tanto se ha cuidado de poca ayuda ha servido. Es para darle a mas de uno con las matrices de compatibilidad y las licencias enterprise del software en la cara, si cuando pasa algo serio, no sirven de nada.
De hecho, creo que este problema influyó decisivamente en un proyecto de migración a una plataforma PrimeQuest de Fujitsu de todas esas máquinas. Un proyecto bastante caro por cierto y que también debe mantener la dichosa matrix de compatibilidad por exigencias del guión.
Tengo el mismo problema y quisiera saber si has encontrado alguna solución. Muchas gracias de antemano.
ResponderEliminar