Tamaño apropiado de heap y antigua generación para JVM para aplicaciones pesadas de datos

Question

• Estoy ejecutando una aplicación de servidor usando JVM sunjava-1.6.0_21.
• Mi aplicación tiene datos pesados ​​y actúa como un servidor de caché. Por lo tanto, almacena una gran cantidad de datos de larga duración que no esperamos obtener GC durante la ejecución de la aplicación.
• Estoy configurando los siguientes parámetros de JVM -Xmx16384M y -Xms16384M.
• Después de que los datos requeridos se ha cargado, siguiente es el uso de la memoria de la solicitud
• espacio total montón es: 13969522688
• espacio máximo de almacenamiento dinámico es: 15271002112
• espacio de almacenamiento dinámico libre es: 3031718040
• a largo plazo (antigua generación) almacenamiento de almacenamiento dinámico: Used=10426MB Max=10922MB Used/Max=95%

Uso de la antigua generación - He confirmado que se debe a datos reales y no se espera que obtenga gratis . Mi pregunta es que, de forma predeterminada, el tamaño JVM del espacio de montón (está asignando 10922 MB de la antigua generación), lo que deja muy poco espacio libre en la sección de la antigua generación.

• ¿Puede tener menos espacio libre en la generación anterior y afectar la aplicación?
• En caso afirmativo, ¿cómo debo manejar esto? Debo experimentar con los parámetros de ajuste de JVM como newratio y tratar de aumentar el espacio disponible para la generación anterior o de cualquier otra forma que deba ajustar la aplicación.

Answer 1

¿Puede tener menos espacio libre en la generación anterior y afectar la aplicación?

Si su Gerente General se llena una colección importante sucederá y este tipo de colección es costoso. Puede usar las opciones: -verbose:gc y -XX:+PrintGCDetails para saber si el GC completo sucedió con demasiada frecuencia. Si es así, entonces sí puede afectar el rendimiento de su aplicación.

En caso afirmativo, ¿cómo debo manejar esto? Debo experimentar con los parámetros de ajuste de JVM como newratio y tratar de aumentar el espacio disponible para la generación anterior o de cualquier otra forma que deba ajustar la aplicación.

Puede probar NewRatio, pero tenga en cuenta que si su eden es demasiado corto, su gen titular probablemente se llene más rápido.

Para finalizar, debe utilizar una herramienta de supervisión para tener una mejor idea de las opciones de VM que tiene que utilizar. Le mostrará fácilmente cómo se llenan sus generaciones durante la ejecución de la aplicación, es más fácil de leer y comprender que los registros de gc;)

Answer 2

Si sabe que la duración de la vida de sus objetos es tan larga, juegue con los parámetros que establecen el tamaño de las regiones entre sí.

Puede establecer relaciones en young generation y old generation (espacios enteros y ternurados), así como en ambos sobrevivientes.

El objetivo es minimizar la recolección de basura completa al permitir que la recolección de basura menor libere toda la memoria.

Usted evita que la recolección de basura libere objetos al mantenerlos accesibles en su aplicación. Quiero decir que solo debería preocuparse por esos objetos que son eliminados por colecciones de basura menores.

Habilitar los parámetros

-verbose:gc -Xloggc:/opt/tomcat/logs/gc.out -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 

Luego, con una herramienta GCViewer se puede ver el tiempo dedicado a gc y el número (tamaño) de los objetos eliminados. Entre algunas métricas útiles.