UseConcMarkSweepGC vs UseParallelGC

Actualmente estoy teniendo problemas con los tiempos de recolección de basura muy largos. por favor mira el followig. Mi configuración actual es que estoy usando un -Xms1g y -Xmx3g. mi aplicación está usando Java 1.4.2. No tengo ningún conjunto de indicadores de recolección de basura. por lo que parece, 3GB no es suficiente y realmente tengo muchos objetos para recolectar basura.UseConcMarkSweepGC vs UseParallelGC

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 los informes de datos de la caché de datos y no. 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 realmente 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]

Fuente

2012-01-25 grassbl8d

Aquí es el enlace que puede ser útil para usted http://www.oracle.com/technetwork/java/gc-tuning-5-138395 .html. Los colectores son específicos de 1.5, el concepto para parllel y el barrido simultáneo podría ser el mismo en 1.4. – kosa

Dado que tiene pausas de GC extremadamente largas, no creo que cambiar el algoritmo de GC ayude.

Tenga en cuenta que es muy sospechoso que solo tenga colecciones completas. Quizás necesite aumentar el tamaño de la generación joven y/o el espacio de supervivencia.

Consulte también:

Tuning Garbage Collection with the 1.4.2 Java[tm] Virtual Machine

Fuente

2012-01-25 16:01:10 axtavt

ya, solo ocurre cuando se generan informes. estos son objetos que provienen de la base de datos y tienen valores realmente grandes. Me preguntaba si de todos modos podría salir adelante con esto. en el escenario 2, creo que el tamaño del montón realmente no existe, es por eso que planeamos aumentarlo, para el escenario 1, el montón todavía está disponible. gc es alrededor de 25 a 30 segundos. – grassbl8d

siento que no pude incluir el otro gc en él. incluido ahora para el primer escenario. – grassbl8d

su montón es demasiado pequeño. La pausa es tan grande porque está ocupada escaneando todo el montón buscando desesperadamente algo para recolectar.

Tiene que hacer 1 o posiblemente más de lo siguiente;

encontrar y corregir una pérdida de memoria
sintonizar la aplicación a usar menos memoria
configurar la JVM es utilizar un montón grande

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

Fuente

2012-01-25 16:19:35 Matt

en realidad, solo ocurre cuando los usuarios están comenzando a generar grandes informes y realmente no podemos controlarlos. los informes son realmente grandes actualmente, 1.4.2 es el servidor en el que estamos, el proceso para migrar está ahí, pero tenemos que hacer lo que podamos por el momento. – grassbl8d

para el escenario 1, todavía tengo un montón disponible, ya que mi montón máximo es de 3 GB pero la recolección de basura es demasiado larga. – grassbl8d

Si la generación de grandes informes es parte del funcionamiento normal, entonces su montón es simplemente demasiado pequeño. Sin embargo, debe hacer una evaluación comparativa apropiada para sintonizar esto y la salida de ese esfuerzo será, al menos parcialmente, redundante si se mueve a java6 o java7 jvm. No querrás hacer el mismo trabajo dos veces si puedes evitarlo. – Matt

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 pasar la JVM sin GC, por lo que una vez que llega, tiene mucho más para moverse.

Fuente

2012-03-05 21:38:04 nilskp

Paso 1:

Asegúrese de que ha establecido suficiente memoria para su aplicación.
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 usted no tiene ningún problema con el Paso 1 con respecto a las pérdidas de memoria, consulte la documentación de Oracle page en casos de uso para el algoritmo de recolección de basura específico en "Java Recolectores de basura "sección y artículo gctuning.

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

Java 7 (JDK 7) garbage collection and documentation on G1

Fuente

2015-12-09 18:02:21

UseConcMarkSweepGC vs UseParallelGC

Respuesta

Cuestiones relacionadas