Red Hat propone un nuevo recogedor de basura para el OpenJDK orientado a heaps enormes
AbrahamRed Hat ha propuesto la inclusión de un nuevo recogedor de basura para el OpenJDK orientado a heaps enormes. Según Red Hat Este nuevo recogedor de basura (GC), con nombre Shenandoah, cuando se ejecute provocaría pausas con una duración inferior a 10 ms en heaps de hasta 100 GB.
Shenandoah está orientado uso sólo en situaciones donde estemos trabajando con una máquina con gran cantidad de cores y memoria RAM. Según sus propios autores, no tiene sentido emplear este GC si estás trabajando con un heap de menos de 20 GB o si la máquina en la que se está usando tiene menos de ocho cores.
También advierten que Shenandoah provoca un decremento en el rendimiento total de la aplicación que puede estar cercano a un 10% cuando se le compara con la misma aplicación funcionando con los actuales GCs y no hay ningún tipo de pausa ocasionada por el GC. Si los actuales GCs se disparan, entonces el rendimiento total de Shenandoah es similar al de los GCs actuales, pero con la ventaja de que las pausas que puede provocar en la aplicación tienen una duración considerablemente inferior cuando se trabaja con heap grande.
¿Veis alguna utilidad para un GC de este tipo en vuestras aplicaciones? ¿Os habéis encontrado alguna vez con la necesidad de tener que tunear el GC para evitar pausas por estar usando un heap muy grande?
Reader Comments (3)
Si, en mi caso si. Tengo un heap de 32Gb y 8 cores. Las pausas del GC en la old generation sobre todo (que son stop-world) eran enormes.
Luego de tunning de la aplicación, con mucho profiling (para tratar de que la Old Generation tarde en llenarse, teniendo en cuenta el precepto de que "en java good die young" , caimos en un GC que permite asignar algunos nucleos al GC y mantener el resto de los nucleos para el thread acceptor y otros hilos del pool de hilos.
Me parece que para estos contextos (2000 usuarios concurrentes), es util (igualmente, el esquema de tener múltiples servidores más pequeños, en cluster o balanceados tal vez sea mejor, aun virtualizados).
saludos.
Por curiosidad ¿Qué máquina virtual estás usando?
Buena pregunta, siempre hotspot.
Los problemas de performance los tuve con el JDK 6, hoy estamos en el 7u45.
Se que en la versión 7 hubo algunas mejoras, en lo que hace a GC, no profundicé mucho, tal vez debería, pero como dicen los libros de refactoring "si funciona bien no lo toques".
Saludos.