La estimación del tamaño del montón de JVM máxima de seguridad en Java de 64 bits

Question

En el curso de perfilar una aplicación Java de 64 bits que está teniendo algunos problemas, noto que el generador de perfiles en sí (YourKit) está utilizando cantidades verdaderamente colosales de memoria. Lo que tengo en la secuencia de comandos de lanzamiento YourKit es:

JAVA_HEAP_LIMIT="-Xmx3072m -XX:PermSize=256m -XX:MaxPermSize=768m" 

Ingenuamente, asumiendo cierta sobrecarga, esto me lleva a suponer que YourKit va a usar un máximo de algo tal vez un poco más de cuatro GB. Sin embargo, lo que realmente veo en PS es:

USER  PID %CPU %MEM VSZ RSS TTY  STAT START TIME COMMAND 
dmoles 31379 4.4 68.2 14440032 8321396 ? Sl 11:47 10:42 java -Xmx3072m -XX:PermSize=256m -XX:MaxPermSize=768m -XX:+HeapDumpOnOutOfMemoryError -Dyjp.probe.table.length.limit=20000 -Xbootclasspath/a:/home/dmoles/Applications/yjp-9.5.6/bin/../lib/tools.jar -jar /home/dmoles/Applications/yjp-9.5.6/bin/../lib/yjp.jar 

Eso es un tamaño virtual de casi 14 GB y un tamaño residente de casi 8 GB - casi 3 veces la pila de Java.

Ahora, tengo suficiente memoria en mi cuadro de desarrollo para ejecutar esto, pero volviendo al problema de memoria original que estoy tratando de diagnosticar: ¿Cómo puedo saber con cuánto montón de Java tengo que jugar?

Claramente, si el cliente tiene, digamos, 16 GB de RAM física, no es una gran idea para mí decirles que configuren -Xmx en 16 GB.

Entonces, ¿qué es un número razonable? 12 GB? 8 GB?

¿Y cómo lo calculo?

Answer 1

Claramente, si el cliente tiene, digamos, 16 GB de RAM física, no es una gran idea para mí decirles que configuren -Xmx a 16 GB.

Si el cliente se ejecuta nada más significativa en su/su máquina, a continuación, establecer el tamaño del montón a 16G no es necesariamente una mala idea. Depende de lo que la aplicación está haciendo.

Entonces, ¿qué es un número razonable? 12 GB? 8 GB?

El número ideal sería tener "JVM indirectos no derivados de almacenamiento dinámico de JVM max heap + + + OS otras aplicaciones activas de trabajo conjuntos + búfer de caché del conjunto de trabajo" se suman a la cantidad de memoria física. Pero el problema es que ninguno de esos componentes (aparte del tamaño máximo de almacenamiento dinámico) puede anclarse sin mediciones detalladas en la máquina del cliente ... mientras la aplicación se ejecuta en el problema real.

Y cómo lo estimo que?

La conclusión es que no se puede. Lo mejor que puedes hacer es adivinar ... y ser conservador.

Un enfoque alternativo es estimar cuánto montón necesita realmente la aplicación para el problema que está tratando de resolver. Luego agregue un 50 o 100 por ciento adicional para que la sala de GC funcione de manera eficiente. (Y luego sintonizar ...)