Fundamentos de JVM para Elasticsearch: métricas, memoria y monitoreo

Elasticsearch es un motor de analítica y búsqueda basado en Java y una base de datos vectorial construida sobre Apache Lucene, y es el núcleo de Elasticsearch Platform. Para ejecutar Elasticsearch en sus plataformas compatibles, necesitas una máquina virtual Java (JVM). La JVM proporciona un entorno de ejecución independiente de la Platform, y puedes ejecutar Elasticsearch en un entorno virtual sobre el sistema operativo existente. La JVM abstrae el sistema operativo y el hardware subyacentes, por lo que las aplicaciones Java pueden ejecutarse en cualquier Platform.

Comprender la gestión de memoria de la JVM y la recolección de objetos mediante la recolección de basura (GC) es la clave para solucionar problemas como java.lang.OutOfMemoryError (código de salida 127). Estos problemas ocurren cuando la JVM se ejecuta sin memoria o cuando hay un código de salida 137, lo que normalmente indica que el killer de memoria insuficiente (OOM) del host terminó el proceso de la JVM debido a un uso excesivo de memoria. Este blog te guiará sobre cómo examinar los patrones de uso de memoria y solucionar estos problemas de JVM.

También explicaré el papel de la JVM y cómo correlacionar esto con la ayuda de las API de Elasticsearch existentes, proporcionando información valiosa sobre el estado de la JVM de Elasticsearch y ayudándote a decidir si quieres ajustarla aún más según tu propio caso de uso. 

Como se menciona en la documentación de JVM de Elasticsearch, los valores predeterminados de las opciones de JVM que se envían con el producto funcionan de manera eficiente en todos los entornos de producción compatibles; estos valores predeterminados pueden manejar la mayoría de los casos de uso para operaciones de búsqueda e indexación. No se recomienda cambiar ningún valor ni agregar valores personalizados para las opciones o configuraciones de JVM.

Una máquina virtual de Java es una parte integral del Java Runtime Environment (JRE), que viene incluido en un Java Development Kit (JDK).

La JVM es similar a un programa informático que ayuda a ejecutar aplicaciones Java. No existe como una máquina física, pero actúa como tal al traducir el código Java en instrucciones que su sistema operativo compatible puede entender. La JVM también se encarga de tareas importantes como la gestión de memoria, el manejo de la recolección de basura y mantener sus aplicaciones seguras.

A continuación, centrémonos en la gestión de memoria de JVM y la recolección de basura —un punto importante en Elasticsearch que verificamos con frecuencia al solucionar cualquier problema de rendimiento de memoria o relacionado con OOM.

Para entender la gestión de memoria y la recolección de basura, primero debes entender la representación lógica del área heap (o memoria heap) donde residen todos los objetos cuando se inicia una JVM.

Área/región de young generation
Cuando cualquier aplicación de Java se inicia, crea nuevos objetos y los asigna al área llamada memoria heap. El espacio Eden de la young generation es el primer lugar donde la aplicación asigna los objetos recién creados. Esta área está reservada para la asignación de nuevos objetos. Y cuando se llena, los objetos elegibles serán eliminados (garbage collected) o promovidos a otras regiones.

Cuando ocurre una recolección de basura menor, los objetos referenciados se moverán a otra subsección que es la región Survivor S0. Y los objetos no referenciados se eliminarán para liberar espacio en Eden. Esta región contiene los objetos que sobrevivieron al proceso de recolección de basura, de ahí el nombre región Survivor. 

El mismo ciclo se repite cuando el espacio Eden vuelve a estar lleno. Esta vez, los objetos que sobrevivieron tanto a Eden como a S0 se moverán a la región S1, y este proceso continúa. 

Los objetos que sobrevivieron a las recolecciones de basura en Eden, S0 y S1 serán promovidos a la generación antigua según el calculador de antigüedad.

Área/región de old generation
La old generation (también conocida como tenured generation) es una colección de objetos de larga duración que sobrevivieron a los múltiples eventos de recolección de basura en la young generation (GC menores). Los objetos que han sobrevivido a un cierto número de ciclos en el survivor space son movidos por el algoritmo a la old generation, también conocida como promoción de objetos.

El patrón de GC en diente de sierra anterior del monitoreo de pilas muestra que, cuando ocurre una recolección de basura menor, la memoria heap de la JVM se reduce porque el GC elimina los objetos no deseados de la memoria. Después de algunos ciclos, los objetos se acumulan y el GC entra en acción de nuevo para limpiar los objetos. 

El G1GC tiene un objetivo de tiempo de pausa (-XX:MaxGCPauseMillis=200) que intenta cumplir durante la recolección de basura. Esto significa que, durante la recolección de basura, se asegura de que la JVM no experimente una pausa mayor a este valor, lo que lo hace mejor que CMS u otros recolectores donde esta no es una opción. En general, se recomienda mantener la configuración de GC con los valores predeterminados, lo que mantendrá la pausa de GC dentro de los límites para un rendimiento mejorado. 

Esta API proporcionará los detalles de la configuración de Node, incluidos los argumentos de entrada de JVM, los pools de memoria y el tamaño del heap. 

Además, si quieres verificar las métricas de la JVM de Elasticsearch para el tiempo de actividad de un nodo en particular, el heap utilizado en todos los pools de memoria o estadísticas sobre la recolección de basura, puedes usar la API de estadísticas de Node. Proporcionará métricas detalladas sobre cada una de las métricas mencionadas.

Si eres un usuario avanzado y quieres verificar estadísticas en tiempo real sobre una JVM en ejecución sin usar las API de Elasticsearch, puedes usar el Java agrupado y ejecutar jstat para verificar las estadísticas en vivo. Para hacer esto, primero encuentra el directorio de inicio de Java o el directorio bin y el PID del proceso de Elasticsearch. Desde el directorio bin, usa la herramienta jstat:

Aquí, 2000 es el intervalo en milisegundos después del cual se recuperarán e imprimirán las estadísticas en la CLI. Este comando es útil para identificar con qué frecuencia ocurre GC en todas las áreas y qué tan rápido se llenan los pools de memoria con los objetos (tasas de creación y promoción de objetos). 

Esto no es una alternativa a las API mencionadas arriba, sino que es más para depuración a nivel de desarrollador.

El momento del lanzamiento de cualquiera de las características o funcionalidades descritas en esta publicación queda a exclusivo criterio de Elastic. Es posible que algunas características o funcionalidades que no estén disponibles en este momento no se lancen a tiempo o no se lancen en absoluto.