Terracota anuncia BigMemory, usa +100 Gb de RAM sin paradas de GC

Ayer Terracota anunció la disponibilidad de una versión beta de su producto BigMemory. Este producto puede usarse conjuntamente con Ehcache para eliminar los problemas derivados de las pausas del recogedor de basuras cuando está trabajando sobre un heap de gran tamaño. 

En la práctica, la duración de estas pausas suele impedir emplear heaps en cada máquina virtual con un tamaño superior a 2-4 Gb. Si se emplean tamaños mayores, el recogedor de basura tarda demasiado tiempo en ejecutarse y hace que la aplicación se congele durante demasiado tiempo, lo cual a menudo no es admisible desde el punto de vista de proporcionar una calidad adecuada en el servicio.

BigMemory es la solución que Terracota propone a sus usuarios de Ehcache. Con ella, el tiempo de las paradas del recogedor de basuras es constante, independientemente del tamaño de la memoria que se use, pudiendo llegar a emplearse tamaños por encima de 100 Gb.

Según Amit Pandey, el CEO de Terracotta, lo que el producto hace es gestionar la memoria de un modo similar a como se gestionaría en C. Guardan la mayor parte de los objetos en una estructura de datos plana alternativa al heap que ellos gestionan directamente. Mientras que los datos que están almacenados en el heap son manejados por el recogedor de basura, los de su estructura de datos los gestionan ellos directamente. Y el heap puede configurarse para qué tenga un tamaño relativamente pequeño.

BigMemory es una solución implementada 100% Java y sólo es una solución útil para usuarios de Ehcache. Si no estás usando este producto, puedes olvidarte de esta solución.

Recientemente Azul Systems ha anunciado una solución que pretende resolver el mismo problema, Zing Plataform, en este caso a través de la creación de un sistema operativo (basado en Linux) y una máquina virtual (basada en el OpenJDK) específicos para ejecutar aplicaciones Java.

No sé cómo de éxito tendrán ambas soluciones, pero parece obvio que cada vez más gente se va a encontrar con este problema. La memoria RAM es muy barata y no es raro contar con más de 4 Gb en un servidor. Y la realidad es que es complicado tomar ventaja de toda esa memoria con una única máquina virtual.

Un caso práctico del problema que las pausas del recogedor de basura ocasionan es el de LinkedIn. Teniendo una infraestructura casi completamente basada en Java, cuentan con una pequeña parte implementada en C++. Aquella que manipula el grafo de la res social, cuyo tamaño es de varias decenas de Gb. No pudieron hacer esto en Java precisamente porque las pausas del recogedor de basura al tener un tamaño de memoria tan grande no eran tolerables.

¿Alguno de vosotros se ha encontrado con problemas de este tipo en sus aplicaciones?