sintonización JVM y GC: teoría para no GC completo

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.

He cambiado 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 qué se mueven al espacio antigua:

• por este artículo: http://chaoticjava.com/posts/gc-tips-and-memory-leaks/ que ha informado si sufre grandes objetos asignados, los ir 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 se 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

Suena como sus espacios de supervivencia 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? p.ej. 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.

Answer 2

¿Existe parámetro que puede establecer cuántos cambia entre A y desde es que se hecho antes de pasar al espacio de edad?

Sí, -XX:MaxTenuringThreshold

Este interruptor determina cuántas veces saltan los objetos entre el campo "De" y "A" espacios superviviente antes de ser promovido a la generación anterior. El valor más grande es 15 para Java 6 y 31 para JDK anteriores. The default value is 15 for the parallel collector and is 4 for CMS collectors.

A partir de los documentos de Sun JVM GC,

Uso -XX: MaxTenuringThreshold = 0 para mover un objeto que sobrevive a un joven de recogida generación inmediatamente a la generación titular.

Como usted quiere hacer lo contrario de eso, si no se ha establecido este valor sería en el valor predeterminado, que es más que suficiente para decidir si el objeto no tiene que ir a Viejo - proporcionan como dice @Peter, los sobrevivientes son lo suficientemente grandes como para sostener esos objetos.

¿Cuál es su SurvivorRatio establecido en? ¿Y cuál es tu Heap total?

Answer 3

¿Estás seguro de que el crecimiento de la generación anterior no se limita a los objetos en 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 utilizamos para ejecutar un 24 GB JVM de 64 bits con pausas inferiores a un segundo GC mientras servía más de 100 solicitudes de página por segundo con grandes cachés:

-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 4

características del tiempo de vida de objetos juegan un crítico perillas de ajuste de papel here.Important son el tamaño del espacio del sobreviviente, el umbral de tenencia 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 lograr un equilibrio adecuado mediante la experimentación con estas variables para reducir las promociones de objetos para la generación de edad con miras a la generación joven aceptable pausas