¿Por qué los tiempos de GC aumentan constantemente en una aplicación Java de alto volumen y larga ejecución?

Question

Tengo una aplicación de alto volumen de Java que maneja una carga constante de 50000msgs/seg. Se está sintonizado para un alto rendimiento usando los siguientes ajustes:

-Xmx3g -Xms3g -XX: NewSize = 2g -Xss128k -XX: SurvivorRatio = 6 -XX: TargetSurvivorRatio = 90 -XX: + UseParallelGC -XX: ParallelGCThreads = 12 -XX: + UseParallelOldGC -XX: + HeapDumpOnOutOfMemoryError

Estoy descubriendo que los tiempos de los jóvenes GC constantemente aumentan de 50 ms cuando comienza a 200 ms para el final del día, aunque la frecuencia de carreras de GC sigue siendo la misma.

Si pruebo la misma ejecución con el colector ParNewGC, los tiempos de GC aumentan mucho más rápido. ¿Alguien tiene alguna idea sobre este problema?

Answer 1

Si tiene una pérdida de memoria o una memoria caché en memoria que está usando gradualmente más y más memoria, esto tendría el efecto de hacer que el GC haga más trabajo rastreando los objetos alcanzables.

Otras posibilidades son:

• que tiene una fuga de memoria no montón, y que se traduce en el aumento de paginación; es decir, copia de páginas de memoria física en el disco y viceversa.

• Algunos procesos externos consumen cantidades cada vez mayores de memoria, lo que aumenta la búsqueda.

• La naturaleza de los objetos generados en la generación joven está cambiando con el tiempo, por lo que se necesita más trabajo para rastrear los objetos alcanzables. Puede ser simplemente que una mayor proporción de ellos sobrevivan después de la primera colección.

Answer 2

Puede ser una combinación de varios factores:

• una pérdida de memoria real. (Todavía se hace referencia a los objetos por accidente)
• Más objetos, o tal vez una distribución diferente de los objetos entre los pools de gc.
• El montón es más grande. Trace el tiempo-gc y el tamaño del montón.
• Fragmentación de la memoria. En el nivel del sistema operativo y/o el montón de Java, dependiendo de la jvm.

¿Por qué no trazas el número de objetos, el tamaño del montón y el tiempo de gc? (usando una herramienta, o cuestionando MBeans) Una gráfica debería indicar la tendencia; aumentar, disminuir o lineal, y lo ayudará a determinar si hay una fuga. Si es posible, también descargue algunas estadísticas de su programa, como el número de mensajes procesados ​​o sesiones activas, etc.

¿Es un problema real ya que sus mensajes no se procesan durante gc ?. Pruebe la marca concurrente y barrer gc ...

* -XX:+UseConcMarkSweepGC -XX:+UseParNewGC