A medida que los usuarios de Elasticsearch están superando los límites de la cantidad de datos que pueden almacenar en un nodo de Elasticsearch, a veces se quedan sin memoria de almacenamiento dinámico antes de quedarse sin espacio en disco. Este es un problema frustrante para estos usuarios, ya que a menudo es importante ajustar tantos datos por nodo como sea posible para reducir los costos.

Pero, ¿por qué Elasticsearch necesita memoria de almacenamiento dinámico para almacenar datos? ¿Por qué no solo necesita espacio en disco? Hay algunas razones, pero la principal es que Lucene necesita almacenar información en la memoria para saber dónde buscar en el disco. Por ejemplo, el índice invertido de Lucene comprende un diccionario de términos que agrupa términos en bloques en el disco en orden ordenado, y un índice de términos para una búsqueda rápida en el diccionario de términos. Este índice de términos asigna prefijos de términos con el desplazamiento en el disco donde comienza el bloque que contiene los términos que tienen este prefijo. El diccionario de términos está en el disco, pero el índice de términos estaba en el montón hasta hace poco.

¿Cuánta memoria requieren los índices? Típicamente en el orden de unos pocos MB por GB de índice. Esto no es mucho, pero a medida que vemos que los usuarios conectan más y más terabytes de disco en sus nodos, los índices rápidamente comienzan a requerir 10-20 GB de memoria de almacenamiento dinámico para almacenar estos terabytes de índices. Dada la recomendación de Elastic de no superar los 30 GB de almacenamiento dinámico, esto no deja mucho espacio para otros consumidores de memoria de almacenamiento dinámico, como las agregaciones, y abre la puerta a problemas de estabilidad si la JVM no tiene suficiente espacio para las operaciones de administración de clúster.

Veamos algunos números prácticos. Elastic ejecuta puntos de referencia nocturnos en múltiples conjuntos de datos y rastrea varias métricas a lo largo del tiempo, en particular el uso de memoria de los segmentos. El conjunto de datos Geonames es interesante porque muestra claramente el impacto de varios cambios que ocurrieron en Elasticsearch 7.x :

Este índice toma aproximadamente 3 GB en el disco y solía requerir ~ 5.2 MB de memoria hace 6 meses, esta es una relación montón: almacenamiento de ~ 1: 600. Entonces, si tuviera un total de 10 TB conectado a cada nodo, necesitaría 10 TB / 600 = 17 GB de almacenamiento dinámico, solo para poder mantener abiertos los índices que almacenan datos similares a geonames. Pero como puede ver, mejoramos las cosas con el tiempo: los puntos (azul oscuro) comenzaron a requerir menos memoria, luego los términos (rosa), luego los campos almacenados (verde) y finalmente los términos nuevamente por un factor importante. La relación montón: almacenamiento es ahora de ~ 1: 4000, una mejora de casi 7 veces en comparación con 6.xy versiones anteriores de 7.x. Ahora solo necesitaría 2,5 GB de memoria de almacenamiento dinámico para mantener abiertos 10 TB de índices.

Los números varían MUCHO entre los conjuntos de datos, y la buena noticia es que Geonames es uno de los conjuntos de datos que exhibió la menor reducción del uso del montón: mientras que el uso del montón disminuyó en ~ 7 veces en Geonames, disminuyó en más de 100 veces en los taxis de Nueva York y Conjuntos de datos de registros HTTP . Nuevamente, este cambio ayudará a reducir los costos al almacenar muchos más datos por nodo que las versiones anteriores de Elasticsearch podrían soportar.

¿Cómo funciona y cuáles son las trampas? La misma receta se ha aplicado a múltiples componentes de los índices de Lucene a lo largo del tiempo: mover estructuras de datos del montón JVM al disco y confiar en la memoria caché del sistema de archivos (a menudo llamada memoria caché de página o memoria caché del sistema operativo) para mantener los bits calientes en la memoria. Esto podría leerse ya que esta memoria todavía se usa y solo se asigna a otro lugar, pero la realidad es que una parte significativa de esta memoria simplemente nunca se usó dependiendo de su caso de uso. Por ejemplo, la última caída para Termsse debió a mover el índice de términos del _idcampo en el disco, lo cual solo es útil cuando se usa la API GET o cuando se indexan documentos con ID explícitos. La gran mayoría de los usuarios que indexan registros y métricas en Elasticsearch nunca realizan ninguna de estas operaciones, por lo que esta será una ganancia neta de recursos para ellos.

¡Reduce tu montón de Elasticsearch con 7.7!

Estamos muy entusiasmados con estas mejoras que estarán disponibles en Elasticsearch 7.7, y esperamos que usted también lo esté. Esté atento al próximo anuncio de lanzamiento y luego pruébelo usted mismo. Pruébelo en su implementación actual o inicie una prueba gratuita del servicio Elasticsearch en Elastic Cloud (que siempre tiene la última versión de Elasticsearch). Esperamos sus comentarios, así que háganos saber lo que piensa en Discusión .