java performance garbage-collection g1gc concurrent-mark-sweep

java - UseConcMarkSweepGC vs UseParallelGC



performance garbage-collection (4)

Actualmente estoy teniendo problemas con tiempos de recolección de basura muy largos. por favor vea el seguimiento. Mi configuración actual es que estoy usando un -Xms1g y -Xmx3g. Mi aplicación está utilizando Java 1.4.2. No tengo ningún conjunto de banderas de recolección de basura. por lo que parece, 3gb no es suficiente y realmente tengo muchos objetos para recolectar basura.

pregunta:

¿Debo cambiar mi algoritmo de recolección de basura? ¿Qué debo usar? es mejor usar -XX:+UseParallelGC or -XX:+UseConcMarkSweepGC

o debo usar esta combinación

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC

Los que ocupan la memoria son en gran parte informes de datos y no datos de caché. Además, la máquina tiene 16 GB de memoria y planeo aumentar el montón a 8 GB.

¿Cuál es la diferencia entre las dos opciones ya que todavía me resulta difícil de entender? La máquina tiene múltiples procesadores. Puedo recibir golpes de hasta 5 segundos, pero de 30 a 70 segundos es muy difícil.

Gracias por la ayuda.

Line 151493: [14/Jan/2012:11:47:48] WARNING ( 8710): CORE3283: stderr: [GC 1632936K->1020739K(2050552K), 1.2462436 secs] Line 157710: [14/Jan/2012:11:53:38] WARNING ( 8710): CORE3283: stderr: [GC 1670531K->1058755K(2050552K), 1.1555375 secs] Line 163840: [14/Jan/2012:12:00:42] WARNING ( 8710): CORE3283: stderr: [GC 1708547K->1097282K(2050552K), 1.1503118 secs] Line 169811: [14/Jan/2012:12:08:02] WARNING ( 8710): CORE3283: stderr: [GC 1747074K->1133764K(2050552K), 1.1017273 secs] Line 175879: [14/Jan/2012:12:14:18] WARNING ( 8710): CORE3283: stderr: [GC 1783556K->1173103K(2050552K), 1.2060946 secs] Line 176606: [14/Jan/2012:12:15:42] WARNING ( 8710): CORE3283: stderr: [Full GC 1265571K->1124875K(2050552K), 25.0670316 secs] Line 184755: [14/Jan/2012:12:25:53] WARNING ( 8710): CORE3283: stderr: [GC 2007435K->1176457K(2784880K), 1.2483770 secs] Line 193087: [14/Jan/2012:12:37:09] WARNING ( 8710): CORE3283: stderr: [GC 2059017K->1224285K(2784880K), 1.4739291 secs] Line 201377: [14/Jan/2012:12:51:08] WARNING ( 8710): CORE3283: stderr: [Full GC 2106845K->1215242K(2784880K), 30.4016208 secs] xaa:1: [11/Oct/2011:16:00:28] WARNING (17125): CORE3283: stderr: [Full GC 3114936K->2985477K(3114944K), 53.0468651 secs] --> garbage collection occurring too often as noticed in the time. garbage being collected is quite low and if you would notice is quite close the the heap size. during the 53 seconds, this is equivalent to a pause. xaa:2087: [11/Oct/2011:16:01:35] WARNING (17125): CORE3283: stderr: [Full GC 3114943K->2991338K(3114944K), 58.3776291 secs] xaa:3897: [11/Oct/2011:16:02:33] WARNING (17125): CORE3283: stderr: [Full GC 3114940K->2997077K(3114944K), 55.3197974 secs] xaa:5597: [11/Oct/2011:16:03:00] WARNING (17125): CORE3283: stderr: [Full GC[Unloading class sun.reflect.GeneratedConstructorAccessor119] xaa:7936: [11/Oct/2011:16:04:36] WARNING (17125): CORE3283: stderr: [Full GC 3114938K->3004947K(3114944K), 55.5269911 secs] xaa:9070: [11/Oct/2011:16:05:53] WARNING (17125): CORE3283: stderr: [Full GC 3114937K->3012793K(3114944K), 70.6993328 secs]

Si tiene una alta tasa de supervivencia, su montón puede ser demasiado grande. Cuanto más grande es el montón, más tiempo puede ir la JVM sin GC''ing, así que una vez que golpea, tiene mucho más para moverse.

Tu montón es demasiado pequeño. La pausa es tan grande porque está ocupada explorando repetidamente todo el montón buscando desesperadamente algo que recopilar.

Necesita hacer 1 o posiblemente más de lo siguiente;

  • encontrar y reparar una pérdida de memoria
  • ajuste la aplicación para usar menos memoria
  • configurar la JVM es utilizar un montón más grande

¿Estás atado a 1.4.2 por alguna razón? Las implementaciones de GC realmente han avanzado desde entonces, por lo que debería considerar la actualización si es posible. Me doy cuenta de que esto puede ser una tarea no trivial, pero vale la pena considerarlo de todos modos.

Paso 1:

  1. Asegúrese de haber configurado suficiente memoria para su aplicación.
  2. Asegúrese de que no haya pérdidas de memoria en su aplicación. Eclipse Memory Analyzer Tool o visualvm lo ayudará a identificar fugas en su aplicación.

Paso 2:

Si no tiene problemas con el Paso 1 con respecto a las fugas de memoria, consulte la page documentación de Oracle sobre casos de uso para el algoritmo específico de recolección de basura en la sección "Recolectores de basura de Java" y el artículo de gctuning .

Dado que ha decidido configurar montones más grandes (> = 8 GB), G1GC debería funcionar bien para usted. Consulte esta pregunta relacionada con la SE sobre parámetros clave de ajuste fino:

Recolección de basura Java 7 (JDK 7) y documentación sobre G1