Optimización avanzada de Spark GC

• En el espacio del montón de Java, se dividirá en dos áreas, Joven y Viejo. La parte Joven almacena principalmente objetos de corta duración; mientras que la parte Vieja almacena principalmente objetos de vida más larga.

• La parte Joven se puede subdividir en tres partes, a saber, Edén, Superviviente1 y Superviviente2.

• Describe brevemente el proceso de gc: cuando la parte de Eden está llena, se activa un pequeño GC en Eden, los objetos en Eden y Survivor1 se copian en Surviv2, y el área de Survivor se cambia. Si un objeto ha existido durante suficiente tiempo o el espacio de Survivor2 está lleno, mueva el objeto al área Antigua. Al final, el GC completo se activa cuando el área Vieja está casi agotada, lo que consumirá más rendimiento.

  • El objetivo de optimización de gc de Spark es garantizar que los RDD reservados durante mucho tiempo se almacenen en el área Antigua y que haya suficiente espacio en el área Joven para almacenar los objetos almacenados durante un breve período de tiempo. Intente evitar que los objetos temporales generados en la ejecución de la tarea activen la GC completa, puede utilizar los siguientes pasos para optimizar

  1: Al observar las estadísticas del GC, verifique si hay varios GC completos antes de que finalice la tarea. Si se encuentra muchas veces, significa que la memoria es insuficiente cuando se ejecuta la tarea.
  2: En las estadísticas del GC, si el Se encuentra que la GC pequeña se activa con más frecuencia. Es necesario aumentar el tamaño del área de Edén para optimizar. Puede establecer la cantidad de memoria más de la que requiere la tarea para establecer el tamaño de la parte Eden. Suponiendo que el valor estimado es E, puede establecer el tamaño del área de Young -Xmn = 4/3 E (expandido a 4/3 porque la parte Superviviente debe tenerse en cuenta)
  3: Al verificar las estadísticas de gc, es descubrió que el espacio de la parte OldGen está cerca Después del consumo, reduzca la cantidad total de memoria caché spark.memory.fraction; reduzca la velocidad de ejecución de la tarea almacenando en caché menos objetos. O considere reducir el tamaño del área de Young. Si hay un valor de -Xmn establecido anteriormente, reduzca el valor de manera apropiada. Si no cambia el valor de -Xmn, intente modificar el parámetro NewRatio de la JVM. El valor predeterminado establecido en la mayoría de las JVM es 2, lo que significa que la parte antigua representa 2/3 de todo el montón, y debe ser lo suficientemente grande para exceder la chispa. El valor de memory.fraction
  4: Encienda G1GC. A través de la opción -XX: + UseG1GC, el rendimiento se puede mejorar significativamente cuando gc se convierte en un cuello de botella. Tenga en cuenta que cuando necesita realizar tareas que consumen demasiada memoria, aumentar el tamaño de la región G1 es muy importante: XX: G1HeapRegionSize
  5: Por ejemplo, cuando su tarea lee datos de HDFS, la cantidad de memoria que necesita consumir una tarea puede ser El tamaño del bloque HDFS aprobado es estimado. Tenga en cuenta que el tamaño del bloque descomprimido generalmente aumentará 23 veces. Esperamos que pueda haber 34 tareas en el mismo proceso de trabajo, y el tamaño del bloque de HDFS es de 128 MB, por lo que el valor estimado E se puede obtener el valor de Eden (34 * 128 MB)
  6: Después de la configuración, controle si la información de las estadísticas de gc ha cambiado

PS：监控gc的情况  -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps to the Java options.

Para una línea de registros recopilados por la generación joven, el contenido básico es el siguiente:

2014-07-18T16: 02: 17.606 + 0800: 611.633: [GC 611.633: [DefNew: 843458K-> 2K (948864K), 0.0059180 segundos] 2186589K-> 1343132K (3057292K), 0.0059490 segundos] [Tiempos: usuario = 0.00 sys = 0.00, real = 0.00 segundos]

Su significado es aproximadamente el siguiente:

2014-07-18T16: 02: 17.606 + 0800 (marca de tiempo actual): 611.633 (marca de tiempo): [GC (para GC joven) 611.633: [DefNew (GC de generación joven serial de un solo subproceso): 843458K (antes del tamaño de la recolección de basura de la generación joven) ) -> 2K (el tamaño después de la colección de la generación joven) (948864K (tamaño total de la generación joven)), 0.0059180 segundos (el tiempo de esta colección)] 2186589K (el tamaño antes de la colección de todo el montón) - > 1343132K (la colección de todo el montón) Después del tamaño) (3057292K (tamaño total del montón)), 0.0059490 segundos (tiempo de recuperación)] [Tiempos: usuario = 0.00 (tiempo del usuario) sys = 0.00 (tiempo del sistema), real = 0.00 segundos (tiempo real)]

Los registros recuperados en la generación anterior son los siguientes:

2014-07-18T16: 19: 16.794 + 0800: 1630.821: [GC 1630.821: [DefNew: 1005567K-> 111679K (1005568K), 0.9152360 segundos] 1631.736: [Titular:
2573912K-> 1340650K (2574068K), 1.8511050 segundos] 3122548K > 1340650K (3579636K), [Perm: 17882K-> 17882K (21248K)], 2.7854350 s] [Times: user = 2.57 sys = 0.22, real = 2.79 secs]

El último en el registro de gc parece una instantánea antes de que se complete el sistema:

Heap
 def new generation total 1005568K, used 111158K [0x00000006fae00000, 0x000000073f110000, 0x0000000750350000)
  eden space 893888K, 12% used [0x00000006fae00000, 0x0000000701710e90, 0x00000000007316f0000)
  desde el espacio 1116400000K, 0x70000
  a 1100000, 0x7000% 1100000, 0x7000 al espacio usado utilizado [0x00000007316f0000, 0x00000007316f0000, 0x0000000738400000)
 tenured total de generación 2234420K, utilizó 1347671K [0x0000000750350000, 0x00000007d895d000, 0x00000007fae00000)
   el espacio 2234420K, 60% utilizó [0x0000000750350000, 0x00000007a2765cb8, 0x00000007a2765e00, 0x00000007d895d000)
 perm compactación gen total de 21248K, utilizó 17994K [0x00000007fae00000, 0x00000007fc2c0000 , 0x0000000800000000)
   el espacio 21248K, 84% usado [0x00000007fae00000, 0x00000007fbf92a50, 0x00000007fbf92c00, 0x00000007fc2c0000)
No se han configurado espacios compartidos.