Java CMS GC Behaviors

Question

Tengo una aplicación que causa la creación de gran cantidad de basura. El primer (y casi uno) criterio es el bajo tiempo de pausa del GC. Intento diferentes parámetros de GC usando la herramienta visualgc (y registros de gc). Los mejores parámetros están debajo.

-XX: + UseConcMarkSweepGC

-Xmx1172M

-Xms600M

-XX: + UseParNewGC

-XX: NewSize = 150M de

Mi solicitud ejecutar en SunOS 10 con Java 1.6.0_21. El hardware es 2 x CPU quad core (el resultado de uname -X es numCPU = 8).

Las preguntas son

Observar comportamientos GC, creando nuevos objetos en el espacio hasta eden eden está lleno. Cuando eden space full GC se ejecuta, borre la basura, si el objeto no está copiado a Old-gen (descarto 'de' & 'a' espacios), Similarmente Old-Gen está lleno, GC se ejecuta con CMS-concurrent phase y clear Old -gen espacio Alguna parte de CMS es Stop-the-world (tiempo de pausa). Este es un bucle.

1. ¿Es el escenerio anterior cierto?
2. Después de limpiar el espacio GC de la vieja generación, no hay suficiente espacio para expandir el espacio de la vieja generación (los valores XMS y XMS son diferentes)?
3. ¿Cuándo se inicia el funcionamiento completo del GC? ¿Cómo lo decidió?
4. CMS: la duración de la fase concurrente depende del tamaño del espacio Eden, de hecho mi expectativa es que el espacio Eden no afecte la duración de la fase concurrente CMS. ¿Qué está pasando con GC relacionado con eden space en CMS-concurrent phase?
5. ¿Qué otra cosa me sugiere para minimizar el tiempo de pausa? De hecho, más valiosa respuesta para mí :)

Gracias

Answer 1

no puede simplemente ignorar los espacios de sobrevivientes al usar CMS. CMS no es un recopilador de compactación, lo que significa que si usted (o la JVM) obtiene el umbral de permanencia incorrecto, se purgarán lentamente los objetos para que aumenten la velocidad a la que se forzarán los fragmentos permanentes que obligarán al CMS a forzarlo. no tiene suficiente espacio libre contiguo para manejar las promociones desde los espacios de sobrevivientes hasta la tenencia, lo que forzará un ciclo de gc completo sin advertencia previa y, por lo tanto, es lo máximo en 1 pausa de STW. El tiempo que esto tome dependerá del tamaño de su pila, pero una cosa es muy probable, será de órdenes de magnitud más largos que una colección de eden normal.

Hay algunas otras cosas a tener en cuenta aquí;

1. pausas STW no solamente provienen de la CMS, que provienen de la generación joven coleccionista demasiado
2. CMS tiene 2 fases STW (marca y comente) y 3-4 fases simultáneas, la primera fase de STW (Mark) está estrictamente singlethreaded que puede causar problemas (discusión de la muestra en este here)
3. puede controlar el no de hilos que manejarán las fases simultáneas
4. es necesario comprender cuánto tiempo los objetos tienden a vivir, esto puede significar el uso de -XX:+PrintTenuringDistribution o solo puede verlo con visualgc como lo hizo
5. A continuación, puede sintonizar esto con -XX:SurvivorRatio para controlar el tamaño de los espacios de supervivencia relativas a eden y -XX:MaxTenuringThreshold para controlar la frecuencia con la que un objeto puede sobrevivir una colección joven antes de que se tenured
6. -XX:CMSInitiatingOccupancyFraction se puede utilizar para guiar la CMS en cuanto a cómo completa tiene que ser antes de que comience la fase de CMS (consigue este mal y se le pausa mal)

en última instancia es necesario entender lo que está haciendo una pausa colector, con qué frecuencia, por cuánto tiempo y si hay algún anormal causas de esa pausa. Luego debe comparar esto con el tamaño de cada generación para ver si puede ajustar los parámetros para minimizar el número (y/o la duración) de las pausas.

Tenga en cuenta que esto puede deberse al tiempo limitado debido a la necesidad de pruebas prolongadas para ver si se deteriora con el tiempo. Además, sin una carga de trabajo repetible y automatizada, es casi imposible sacar conclusiones firmes sobre si realmente ha mejorado las cosas.

Una buena fuente de información resumida sobre las partes internas es Jon Masamitsu's blog. Otra buena presentación sobre esto es GC Tuning in the HotSpot Java VM.

Answer 2

La mejor manera de minimizar el impacto de GC es minise el número de objetos objeto creado. Esto no siempre es fácil de hacer o la mejor solución en general, pero minimizará las pausas del GC.

Si no puede producir menos objetos, intente que sean lo suficientemente efímeros y que el espacio de eden sea lo suficientemente grande como para que no salgan del espacio de eden. (O hacer el muy largo vivió y re-utilizado)

1. Hay tres espacios que preocuparse por aquí, eden -> superviviente -> titular http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

2. La GC trata de asegurar que haya suficiente gratuita espacio después de un GC completa y los -ms y -mx opciones de hacer control de lo grandes que sean (antigua conocida como -Xms y -Xmx)

3. un GC fondo en el arranque cuando el espacio titular está llena, o el espacio suvivor se exhaused (por ejemplo, hay para o muchos objetos copiados del espacio eden) o los diseños CMS ahora son un buen mosaico para tratar de realizar una limpieza simultánea.

4. El CMS solo limpia el espacio ocupado.

5. Ver mis respuestas anteriores.