¿Por qué se está elevando el tiempo de recolección de basura en el servidor de región de HBASE?
Tengo un servidor Cloudera HBASE que muestra un aumento repentino en el tiempo de GC (20s), lo que provoca que mis tareas del Executor de Spark Streaming fallen debido a que las consultas de Phoenix tardan más que el límite de tiempo (60s).
No soy un experto en GC y me resulta bastante difícil entender los parámetros de ajuste del GC. Pero ¿hay alguna razón por la que el tiempo de GC aumenta en el servidor de la región de HBASE? ¿O hay un parámetro específico que necesite aplicar para que el GC se ejecute a intervalos en lugar de activarse cuando el montón de memoria está lleno?
Mi aplicación de Spark Streaming se ejecuta las 24 horas del día, los 7 días de la semana y ha funcionado bien en producción durante años, hasta ahora.
Aquí está el gráfico del tiempo de GC, uso de CPU y uso de memoria.
El servidor de la región de HBASE se ejecuta en Centos con Java 1.7_67; está gestionado por Cloudera CDH 5.10.
Tres servidores de la región se ejecutan en AWS m5.xlarge (4 vCPU, 16GB de RAM).
Aquí están las opciones de Java que se están ejecutando en el HBASE RegionServer:
-Xms2147483648 -Xmx2147483648 -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/tmp/hbase_hbase-REGIONSERVER-a79693382d05d90e92d12135c6a45fc1_pid{{PID}}.hprof
-XX:OnOutOfMemoryError={{AGENT_COMMON_DIR}}/killparent.sh
davy.ai
Según la información proporcionada, parece que el tiempo de recolección de basura (GC) está causando que las consultas de Phoenix demoren más que el límite de tiempo de espera, lo que a su vez provoca el fallo de las tareas del executor de Spark Streaming. Para entender por qué el tiempo de GC está aumentando, es necesario analizar el comportamiento y la carga de trabajo de la aplicación.
Una posible razón para el aumento en el tiempo de GC podría ser la asignación frecuente de objetos y su recolección de basura. Sería útil identificar los objetos que se crean y destruyen con frecuencia y optimizar el código para reducir el número de asignaciones de objetos o utilizar agrupación de objetos para reutilizarlos.
Otra posible razón podría ser una utilización ineficiente de la memoria, donde algunos objetos están utilizando más memoria de la necesaria, lo que provoca que el recolector de basura se active con más frecuencia. Sería conveniente analizar el uso de memoria de la aplicación e identificar los objetos que están consumiendo más memoria de la necesaria y optimizarlos.
En cuanto a los parámetros de ajuste de GC, se recomienda consultar a un experto en JVM o utilizar herramientas como GCViewer o GCeasy para analizar los registros de GC y ajustar los parámetros en consecuencia. Sin embargo, las opciones actuales de Java para el HBASE RegionServer parecen haber habilitado la recolección de basura paralela y concurrente, y establecido el tamaño inicial y máximo del montón en 2 GB.
Para ejecutar el GC en intervalos en lugar de activarlo cuando el montón se llena, es necesario utilizar un algoritmo de recolección de basura diferente como G1GC, que está diseñado para ejecutar la recolección de basura de forma concurrente e incremental, reduciendo así los tiempos de pausa. Sin embargo, es esencial probar exhaustivamente la aplicación con el nuevo algoritmo de GC antes de implementarlo en producción, ya que G1GC puede tener características y comportamiento diferentes al algoritmo de GC actual.
En resumen, para resolver el problema del tiempo de GC elevado, es necesario analizar el comportamiento y la carga de trabajo de la aplicación, reducir el número de asignaciones frecuentes de objetos, optimizar la utilización de la memoria y ajustar los parámetros de GC en consecuencia, o considerar el uso de un algoritmo de GC diferente.