java - how - Afinación JVM y GC-teoría para no GC completo

garbage collector java example

Question

Tengo una aplicación a gran escala con dos tipos de objetos: vida larga (caché) y vida corta (solicitud-proceso-respuesta). Teóricamente, con este tipo de aplicación, creo que es posible configurar espacios Young vs Old, por lo que el consumo de espacio antiguo es constante, lo que resulta en que no hay GC completo.

Cambié newSize-maxNewSize params, pero, Old heap sigue aumentando hasta completar GC. Después de cada GC completo, el consumo se reduce al 20% (la memoria caché toma el 20%). Por alguna razón, mis objetos entran en el espacio antiguo. Tengo dos sospechosos por los que se trasladan al Viejo espacio:

• Según este artículo: http://chaoticjava.com/posts/gc-tips-and-memory-leaks/ se le informa si tiene grandes objetos asignados, que van directamente al espacio antiguo. ¿Es esto cierto, y si lo es, hay un parámetro de opción de JVM que pueda establecer el umbral de tamaño de objeto para el espacio Joven?

• Si entendí el proceso correctamente, los objetos cambian entre las secciones de supervivencia de To-From antes de moverlas a la sección anterior. ¿Hay algún parámetro que pueda establecer cuántos conmutadores entre To y From deben realizarse antes de pasar al espacio antiguo?

¿Algún otro consejo?

Gracias, Amar

Answer 1

¿Hay algún parámetro que pueda establecer cuántos conmutadores entre To y From deben realizarse antes de pasar al espacio antiguo?

Sí, -XX:MaxTenuringThreshold

Este modificador determina cuántas veces los objetos saltan entre los espacios de Superviviente "De" y "Hasta" antes de ser promovidos a la generación anterior. El valor más grande es 15 para Java 6 y 31 para JDK anteriores. El valor predeterminado es 15 para el colector paralelo y 4 para los recopiladores CMS .

De los documentos Sun JVM GC,

Use -XX: MaxTenuringThreshold = 0 para mover un objeto que sobrevive a una colección de generación joven de inmediato a la generación permanente.

Como quiere hacer lo opuesto a eso, si no ha establecido este valor, estaría en el valor predeterminado, que es suficiente para decidir si el objeto debe entrar en Viejo, siempre y cuando @Peter diga, los sobrevivientes son lo suficientemente grande como para contener esos objetos.

¿En qué consiste su SurvivorRatio? ¿Y cuál es tu Heap total?

Answer 2

¿Estás seguro de que el crecimiento de la generación anterior simplemente no está en los objetos en la memoria caché? A menos que su caché esté fija y nunca cambie, continuamente la agregará. A medida que los objetos que han llegado a la generación anterior caducan desde ese caché, se mantendrán en la memoria hasta el siguiente GC completo.

He tenido mucha mejor suerte con el colector concurrente de barrido de marcas para eliminar completamente las pausas largas de los GC completos. Requiere un poco de ajuste y puede variar según la aplicación. Esto es lo que usamos para ejecutar una JVM de 24GB de 64 bits con pausas GC menores de un segundo, mientras que brindamos más de 100 solicitudes de página por segundo con cachés grandes:

-Xms24g -Xmx24g -XX:+UseCompressedOops -XX:NewRatio=4 -XX:SurvivorRatio=8
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+DisableExplicitGC
-XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled
-XX:+CMSScavengeBeforeRemark -XX:CMSInitiatingOccupancyFraction=68

Answer 3

Las características del tiempo de vida de los objetos juegan un papel crítico aquí. Las perillas de ajuste importantes son el tamaño del espacio del sobreviviente, el umbral de ocupación y el tamaño de la generación joven. Estratégicamente queremos que los objetos mueran jóvenes, por lo que si hay suficiente espacio entre colecciones menores, muchos objetos morirán en la generación joven. Además, podemos configurar el umbral de permanencia para que los objetos permanezcan en el espacio del superviviente para el número deseado de colecciones.

Como mantenemos una gran cantidad de objetos vivos en el espacio del sobreviviente y seguimos copiándolos de un espacio a otro para un número de GC menor, aumenta el costo del GC menor.

Mantener una gran generación joven naturalmente aumenta la brecha entre colecciones secundarias consecutivas y da más tiempo a los objetos para morir.

Uno puede alcanzar un equilibrio correcto experimentando con estas variables para reducir las promociones de objeto a la generación anterior con una visión aceptable en las pausas de generación joven

Answer 4

Parece que los espacios de tu sobreviviente no son lo suficientemente grandes. Debe hacerlos lo suficientemente grandes como para que no se necesiten objetos. Un objeto solo se conecta y sale del espacio de superviviente una vez.

Si está asignando objetos grandes, puede usar un grupo de objetos para ellos evitando la necesidad de GC. ¿Ha considerado utilizar un conjunto de objetos para su solicitud / proceso / respuesta de datos también? por ejemplo, uno simple es usar un ThreadLocal.

¿Has probado el colector G1 que está diseñado para recolectar progresivamente toda tu memoria y reducir el gran éxito de un GC completo.