Ajuste de JVM para el rendimiento de Elasticsearch: Consejos sobre Heap y Recolección de Basura

Elasticsearch se ejecuta en la JVM, por lo que el heap y la recolección de basura importan. Pero el ajuste de JVM no es por donde empezaría si un clúster está lento. Primero verifica el número de shards, la forma de las consultas, la presión de indexación, la latencia del disco y si el nodo simplemente es pequeño. La configuración de JVM es importante porque valores incorrectos pueden desestabilizar un clúster saludable. No son un atajo para un diseño de índices deficiente o hardware sobrecargado.

Esta guía se centra en el ajuste de JVM de Elasticsearch que sigue siendo útil en las operaciones diarias: dimensionamiento del heap, síntomas de recolección de basura, presión de memoria y las comprobaciones prácticas que te indican si Java es realmente el problema.

---

Comprendiendo los requisitos de memoria de Elasticsearch

Elasticsearch requiere memoria para dos áreas principales: Memoria Heap y Memoria Fuera del Heap. Un ajuste adecuado implica configurar el heap correctamente y asegurarse de que el sistema operativo tenga suficiente memoria física restante para los requisitos fuera del heap.

1. Asignación de memoria heap (ES_JAVA_OPTS)

El heap es donde residen los objetos de Elasticsearch, índices, shards y cachés. Es la configuración más crítica.

Configuración del tamaño del heap

Elasticsearch recomienda encarecidamente establecer el tamaño inicial del heap (-Xms) igual al tamaño máximo del heap (-Xmx). Esto evita que la JVM redimensione dinámicamente el heap, lo que puede causar pausas de rendimiento notables.

Mejor práctica: La regla del 50%

Nunca asignes más del 50% de la RAM física al heap de Elasticsearch. La memoria restante es crucial para la caché del sistema de archivos del Sistema Operativo (SO). El SO utiliza esta caché para almacenar datos de índice a los que se accede con frecuencia (índices invertidos, campos almacenados) desde el disco, lo que es significativamente más rápido que leer desde el disco.

Recomendación: Si una máquina tiene 64 GB de RAM, establece -Xms y -Xmx en 31g o menos.

Ubicación de la configuración

Estas configuraciones se definen típicamente en el archivo jvm.options ubicado en el directorio de configuración de Elasticsearch (por ejemplo, $ES_HOME/config/jvm.options) o mediante variables de entorno si prefieres gestionar la configuración externamente (como usando ES_JAVA_OPTS).

Ejemplo de configuración (en jvm.options):

# Tamaño inicial del heap de Java (ej., 30 Gigabytes)
-Xms30g

# Tamaño máximo del heap de Java (debe coincidir con -Xms)
-Xmx30g

Advertencia sobre el tamaño del heap: Evita establecer el tamaño del heap por encima de 31 GB (o aproximadamente 32 GB). Esto se debe a que una JVM de 64 bits utiliza punteros de objeto comprimidos (Compressed Oops) para heaps menores de ~32 GB, lo que resulta en diseños de objetos más eficientes en memoria. Superar este umbral a menudo anula este beneficio de eficiencia.

2. Memoria fuera del heap (Memoria Directa)

Elasticsearch también utiliza memoria fuera del heap de Java. Lucene depende en gran medida de la caché de páginas del sistema operativo, y Elasticsearch puede usar memoria directa para operaciones de red y nativas. En la mayoría de las instalaciones, no debes establecer -XX:MaxDirectMemorySize a menos que la documentación de Elastic o la guía de soporte para tu versión y carga de trabajo exactas te lo indiquen. Un límite manual de memoria directa puede crear un nuevo modo de fallo si es demasiado bajo o se basa en una suposición desactualizada.

Ajuste de la Recolección de Basura (GC)

La recolección de basura es el proceso mediante el cual la JVM recupera memoria utilizada por objetos que ya no están referenciados. En Elasticsearch, una GC mal gestionada puede causar picos de latencia significativos, a menudo denominados pausas "stop-the-world", que pueden provocar tiempos de espera e inestabilidad en los nodos.

Elegir el recolector adecuado

Las versiones modernas de Elasticsearch incluyen valores predeterminados de JVM compatibles y generalmente usan G1GC en versiones recientes comunes de Java. Trata esos valores predeterminados como la línea base. Cambia la configuración del recolector solo cuando los registros y las métricas muestren un problema real de recolección de basura.

Parámetros de ajuste de G1GC

El parámetro principal para la optimización de G1GC es establecer el objetivo de tiempo máximo de pausa. Esto le indica al recolector con qué agresividad debe limpiar la memoria.

Ejemplo de configuración de G1GC:

# Solo ejemplo: no agregues banderas de GC a menos que tu versión las soporte
# y tengas evidencia de que el comportamiento predeterminado es el problema.
-XX:MaxGCPauseMillis=200

Monitoreo de la actividad de GC

Un ajuste efectivo requiere saber cuándo se ejecuta GC y cuánto tiempo toma. Elasticsearch permite registrar eventos de GC directamente en un archivo, lo cual es esencial para solucionar problemas de latencia.

Habilitando el registro de GC:

Agrega estas banderas a tu archivo jvm.options para habilitar el registro detallado de GC:

# Habilitar registro de GC
-Xlog:gc*:file=logs/gc.log:time,level,tags

# Opcional: Especificar tamaño de rotación de registros (ej., rotar después de 10MB)
-Xlog:gc*:file=logs/gc.log:utctime,level,tags:filecount=10,filesize=10m

Analiza el archivo gc.log resultante usando herramientas como GCEasy o scripts específicos para identificar:

1. Frecuencia: Con qué frecuencia se ejecuta GC.
2. Duración: La duración de las pausas (Total time for GC in...).
3. Tasa de promoción: Cuántos datos sobreviven lo suficiente como para moverse a la generación anterior.

Si las pausas de GC superan consistentemente el objetivo de MaxGCPauseMillis (por ejemplo, alcanzando frecuentemente 500 ms o más), indica presión de memoria. Las soluciones incluyen aumentar el tamaño del heap (si la RAM lo permite, respetando la regla del 50%) u optimizar los patrones de indexación/consulta para reducir la rotación de objetos.

Flujo de trabajo práctico de ajuste y mejores prácticas

Sigue este enfoque sistemático para ajustar la configuración de JVM de Elasticsearch:

Paso 1: Determinar la capacidad del nodo

Identifica la RAM física total disponible en la máquina que aloja el nodo de Elasticsearch.

Paso 2: Calcular el tamaño del heap

Calcula el tamaño máximo del heap: Heap Máximo = RAM Física * 0.5 (redondeado hacia abajo a la fracción segura más cercana, típicamente dejando 1-2 GB de búfer libre). Establece -Xms y -Xmx en este valor.

Paso 3: Dejar la memoria directa en paz a menos que tengas una razón

No copies banderas de memoria directa de publicaciones de blog antiguas. Primero verifica la documentación de tu versión de Elasticsearch y los registros de inicio actuales.

Paso 4: Configurar GC

Asegúrate de que -XX:+UseG1GC esté presente y considera establecer un objetivo razonable como -XX:MaxGCPauseMillis=100.

Paso 5: Habilitar y monitorear el registro

Activa el registro de GC y deja que el clúster funcione bajo una carga de producción típica durante varias horas o días. Revisa los registros.

Paso 6: Iterar basándose en los registros

• Si las pausas son demasiado largas: Es posible que necesites reducir la carga de indexación o, si la RAM lo permite, aumentar ligeramente el tamaño del heap y reevaluar la regla del 50%.
• Si GC se ejecuta con mucha frecuencia pero las pausas son cortas: Tu heap podría ser ligeramente demasiado pequeño, causando colecciones menores excesivas, o estás creando demasiados objetos de corta duración.

Consejo sobre el tamaño de los shards: El ajuste de JVM funciona mejor cuando se combina con estrategias de indexación adecuadas. El exceso de sharding (demasiados shards pequeños) obliga a la JVM a gestionar una gran cantidad de objetos en muchas estructuras, aumentando la sobrecarga de GC. Apunta a shards más grandes (por ejemplo, 10 GB a 50 GB) para reducir la sobrecarga por nodo.

Cómo se ve la presión del heap en clústeres reales

La presión del heap rara vez se anuncia como "presión del heap" a la persona de guardia. Se manifiesta como picos de latencia de búsqueda, rechazos de indexación, actualizaciones lentas del estado del clúster, nodos que se van y se reincorporan, o paneles que se ven bien hasta que el tráfico alcanza su punto máximo. La señal útil es si el heap de la JVM aumenta, se ejecuta la recolección de basura y el heap vuelve a un nivel saludable después.

Si el heap aumenta durante un período ocupado y luego baja después de la recolección de basura, es posible que el nodo simplemente esté trabajando duro. Si el heap aumenta y se mantiene alto después de las colecciones de la generación anterior, es posible que tengas presión sostenida. Si las pausas largas de GC coinciden con desconexiones de nodos, elecciones de maestro o tiempos de espera del cliente, es probable que el comportamiento de la JVM sea parte del incidente.

Usa las estadísticas de nodo de Elasticsearch para verificar el comportamiento de la JVM:

curl -s "http://localhost:9200/_nodes/stats/jvm,indices,thread_pool?pretty"

Observa el porcentaje de heap utilizado, el recuento y tiempo de recolección de basura, la memoria de fielddata, la caché de solicitudes, la caché de consultas, la presión de indexación y las tareas rechazadas del pool de hilos. Una sola métrica puede engañarte. Por ejemplo, un heap alto sin tareas rechazadas puede ser menos urgente que un heap moderado con rechazos de búsqueda y pausas largas de la generación anterior.

La regla del 50 por ciento tiene una razón

El consejo común de mantener el heap de Elasticsearch en o por debajo de aproximadamente la mitad de la RAM del sistema no es arbitrario. Lucene lee archivos de índice del disco, y la caché de páginas del sistema operativo hace que las lecturas repetidas sean mucho más rápidas. Si le das casi toda la memoria a la JVM, el heap puede verse generoso mientras que el rendimiento de búsqueda empeora porque el SO no puede almacenar en caché los segmentos activos de manera efectiva.

En un nodo de 64 GB, un heap de alrededor de 30 GB o 31 GB es un límite común. En un nodo de 16 GB, 8 GB puede ser un punto de partida. En un nodo de desarrollo pequeño, Elasticsearch puede ejecutarse con mucho menos. El valor correcto depende de la carga de trabajo, la versión y el rol del nodo. Los nodos dedicados elegibles como maestro generalmente necesitan mucho menos heap que los nodos de datos activos. Los nodos solo de coordinación pueden necesitar un heap significativo si distribuyen búsquedas grandes y fusionan respuestas grandes.

No aumentes el heap solo porque el heap a veces está alto. Primero pregúntate qué lo está usando. Demasiados shards, agregaciones costosas, fielddata grande, solicitudes masivas grandes, ventanas de resultados de búsqueda enormes y un estado de clúster pesado pueden aumentar el heap. Aumentar el heap puede retrasar el síntoma mientras que el diseño subyacente sigue empeorando.

Punteros de objeto comprimidos y la trampa de los 32 GB

Muchas implementaciones de Java evitan heaps por encima de aproximadamente 32 GB porque la JVM puede perder los punteros de objeto ordinarios comprimidos, a menudo llamados compressed oops. Cuando eso sucede, las referencias a objetos pueden ocupar más memoria, y el heap adicional puede no comprar tanto espacio utilizable como se esperaba. El límite exacto puede variar, así que verifica los registros de inicio en lugar de tratar 32 GB como un número mágico.

Elasticsearch registra la ergonomía de la JVM durante el inicio. Si estás cerca del umbral, confirma si compressed oops está habilitado. Un heap de 31g a menudo se elige para mantenerse por debajo de la línea con cierto margen de seguridad. Si un nodo realmente necesita mucha más memoria, puede ser mejor agregar nodos, reducir la presión de los shards o dividir roles en lugar de crear un heap gigante con un comportamiento de GC doloroso.

Los shards, mapeos y consultas pueden crear problemas de JVM

El ajuste de JVM no puede salvar un clúster de recuentos excesivos de shards. Cada shard tiene sobrecarga: estructuras de datos, metadatos de segmentos, cachés, coordinación de búsqueda y trabajo de recuperación. Miles de shards pequeños pueden consumir heap y ralentizar las operaciones del clúster incluso cuando cada shard contiene muy pocos datos. Si tu problema de heap apareció después de agregar muchos índices diarios, la solución puede ser la gestión del ciclo de vida del índice y la consolidación de shards, no una bandera de GC.

Los mapeos también importan. Los campos de texto, campos de palabra clave, valores de documento, fielddata, documentos anidados y campos de tiempo de ejecución tienen diferentes comportamientos de memoria. Habilitar fielddata en campos de texto grandes puede ser especialmente costoso. Si el heap aumenta durante las agregaciones, verifica si los usuarios están agregando en campos que no fueron diseñados para eso.

Las consultas pueden crear ráfagas de uso de memoria. La paginación profunda con valores grandes de from, consultas comodín amplias, agregaciones de alta cardinalidad y tamaños de resultados grandes ejercen presión sobre los nodos coordinadores y de datos. Usa search_after, búsquedas point-in-time, filtros más estrechos y agregaciones bien diseñadas cuando corresponda. Una consulta que parece inofensiva en desarrollo puede doler mucho cuando se ejecuta en cientos de shards.

Indexación masiva y heap

La indexación masiva es otra fuente común de confusión. Las solicitudes masivas más grandes pueden mejorar el rendimiento hasta cierto punto, pero las solicitudes sobredimensionadas consumen memoria, aumentan el tiempo de cola y hacen que los reintentos sean más costosos. Si ves presión de indexación, rechazos del pool de hilos de escritura o picos de GC durante la ingesta, reduce el tamaño de las solicitudes masivas o la concurrencia antes de cambiar las banderas de JVM.

Un enfoque práctico es probar tamaños masivos con documentos similares a los de producción. Comienza modestamente, aumenta hasta que el rendimiento deje de mejorar, luego retrocede. Observa la CPU, el heap, la GC, el E/S del disco, la actividad de fusión y los recuentos de rechazo. Si el nodo pasa la mayor parte del tiempo fusionando segmentos o esperando en el disco, el ajuste del heap no solucionará el cuello de botella de ingesta.

El intervalo de actualización también afecta el comportamiento de indexación. Para ingesta pesada donde no se requiere búsqueda casi en tiempo real, aumentar refresh_interval puede reducir la rotación de segmentos. Esa es una configuración de índice, no un ajuste de JVM, pero a menudo mejora los síntomas que la gente atribuye a la JVM.

Límites de memoria en contenedores

Elasticsearch en contenedores necesita atención especial porque la JVM ve los límites del contenedor de manera diferente según la versión de Java y la configuración. Si el contenedor tiene un límite de memoria de 4 GB y estableces un heap de 4 GB, el proceso aún puede ser eliminado porque la memoria fuera del heap, las pilas de hilos, la memoria nativa y la caché del sistema de archivos también necesitan espacio.

Establece el heap en relación con el límite de memoria del contenedor, no con la memoria del host. Deja espacio para la memoria no heap. Observa los eventos OOMKilled en Kubernetes o los registros de tiempo de ejecución del contenedor. Un pod que desaparece sin un error limpio de Elasticsearch puede haber sido eliminado por la plataforma en lugar de fallar dentro de Java.

Para Kubernetes, las solicitudes y límites deben reflejar el perfil de memoria real. Un límite demasiado cercano al heap invita a muertes por OOM. Una solicitud demasiado baja puede colocar el pod en un nodo donde compite fuertemente con otras cargas de trabajo. Elasticsearch se beneficia más de una memoria predecible y E/S de disco que de una sobreasignación oportunista.

Cuándo cambiar la configuración de GC

La mayoría de los operadores deben evitar experimentos con recolectores. Elasticsearch prueba e incluye configuraciones de JVM compatibles para cada versión. Agregar aleatoriamente banderas antiguas de CMS, objetivos de pausa agresivos o paquetes de ajuste copiados puede impedir el inicio o empeorar el comportamiento.

Cambia la configuración de GC solo después de que puedas describir el problema en los registros: las pausas de GC antiguas son demasiado largas, la GC joven es demasiado frecuente, el heap no se recupera o los eventos de pausa coinciden con la inestabilidad del clúster. Incluso entonces, prefiere cambios pequeños y mantén un camino de reversión. Las banderas de JVM son parte de la configuración de producción y deben pasar por la misma revisión que los cambios de asignación de shards o seguridad.

Si cambias un objetivo de pausa como MaxGCPauseMillis, recuerda que es un objetivo, no una promesa. La JVM puede no cumplirlo bajo presión de asignación pesada. Si la aplicación crea demasiados objetos demasiado rápido, el recolector no puede convertir eso en rendimiento gratuito.

Una lista de verificación breve para incidentes

Cuando la latencia de Elasticsearch aumenta y se sospecha de la JVM, verificaría estos en orden:

1. ¿Uno o dos nodos no están saludables, o todo el clúster está afectado?
2. ¿El uso del heap aumentó al mismo tiempo que la latencia?
3. ¿Ocurrieron pausas de GC de la generación anterior y cuánto duraron?
4. ¿Los pools de hilos de búsqueda o escritura están rechazando trabajo?
5. ¿Cambió la tasa de indexación, el tamaño masivo o el volumen de consultas?
6. ¿Crecieron recientemente el número de shards, el número de segmentos o el tamaño del estado del clúster?
7. ¿Es alta la latencia de E/S del disco?
8. ¿Comenzó una implementación, cambio de mapeo o nueva consulta de panel aproximadamente al mismo tiempo?

Esa lista de verificación mantiene la investigación fundamentada. El ajuste de JVM es una palanca, pero es una palanca entre varias.

La conclusión práctica

La configuración adecuada de JVM ayuda a que Elasticsearch se mantenga estable, pero la mayoría de las ganancias provienen de dimensionar el heap cuidadosamente, dejar espacio para la caché del sistema de archivos, observar el comportamiento real de GC y solucionar problemas de shards o consultas que crean presión de memoria en primer lugar. Mantén -Xms y -Xmx iguales, sé conservador cerca del umbral de compressed-oops, confía en los valores predeterminados de la versión hasta que la evidencia diga lo contrario y trata los registros de GC como evidencia operativa en lugar de decoración.