domingo, 29 de junio de 2008

Tamaño máximo de heap (y tamaño mínimo del heap)

En otro artículo desgranaré algunos posibles argumentos / parámetros de lanzamiento de la máquina virtual. Pero una nota muy rápida para que quede claro, porque es una pregunta muy usada: ¿cuál es el tamaño máximo de heap adecuado para establecer con -Xmx?

Muy sencillo: la regla general es que en un servidor donde se está ejecutando una máquina virtual JAMÁS debe agotarse la memoria física. Jamás debe llegar a utilizarse el swap a disco. Nunca. Never. Jamais. Nie. Mai. Nooit.

Esto significa que sumando los heaps máximos de todas las máquinas virtuales que pueden ejecutarse en un servidor, deberemos asignar como máximo entre 0,5 y 1,5 GBytes menos de tamaños máximos de heap (sumados) que la memoria física de que dispone nuestra máquina. Nota: esta regla es fruto de mi experiencia, quizás por ahí haya otras medidas... ummm... ¿qué tal un 80%-20% o un 90%-10%? :-)

Es decir, si tenemos 16 gigas, usar siempre como máximo 14,5-15,5, el resto debe ser sufiente para tareas de automantenimiento, backups, scripts de consulta o consolas o sorpresas.

¿Por qué? Muy sencillo: el recolector de basura debe recorrer todo el heap, eso implica que si parte de éste está swapeado, el proceso de recolección generará un montón de fallos de página, lo que puede derivar en un auténtico desastre por OutOfMemoryError's muy frecuentes a poca carga que tengamos. Es decir, el modelo de GC no se lleva nada bien con un sistema de swapping a disco.

Y por cierto, para evitar fragmentación del heap y redimensionamientos no deseados en entornos de producción el tamaño inicial (-Xms) debe igualarse al máximo (-Xmx). Las pruebas demuestran que esto último tiene más importancia en la máquina virtual de Bea que en la de Sun.

También hay otras consideraciones a tener en cuenta, como el establecimiento de -Xmn para el tamaño de la zona de young generation (zona "Eden" + survivors), así como las políticas de promoción entre zonas y recolección de basura. Pero eso será objeto de ese artículo y no suele ser necesario si ayudamos a la JVM con -server/-client.

P.D: Aunque no es mi caso actualmente, además, tengamos en cuenta que cuanto mayor sea el heap, más le costará al GC hacer su trabajo, por lo que debemos tener cuidado con heaps de más de 50 gigas por mucho maquinón que nos pongan. Tenía por ahí alúna otra referencia que ahora no encuentro, dejo un link a http://dev2dev.bea.com/blog/hstahl/archive/2007/03/the_biggest_jvm.html ¿3,5 TBytes de heap? Guau!!!!.

Lo cierto, como aparece en un comentario que leí por ahí, es que si necesitamos semejante heap es que tenemos un problema de diseño de cojones en nuestra aplicación...

No hay comentarios: