Operaciones de Elasticsearch múltiples o concurrentes

Las operaciones de Elasticsearch múltiples o concurrentes pueden reducir el rendimiento. Debe buscar la causa con atención y planificación.

La detección y determinación de la causa principal de que Elasticsearch funcione con lentitud cuando se ejecutan operaciones simultáneas es compleja, y se debe realizar con mucho cuidado y preparación. Puede anticiparse mediante la realización de pruebas embientales en las siguientes situaciones:

Conforme a lo previsto para la temporada alta, es decir, cuando la carga de trabajo de producción está al límite de su capacidad o en su punto álgido.
Todas las operaciones relacionadas con la indexación y que se espera que se ejecuten durante la carga de trabajo máxima (compilación del índice, actualizaciones NRT en el índice, actualizaciones del índice de inventario, etc.).
Hay otras operaciones que no afectan directamente a la indexación o a los datos de búsqueda, pero que pueden afectar a las operaciones generales (por ejemplo, borrar la memoria caché al completo después tras una reindexación, etc.).

Congestión del flujo

Algunas situaciones suceden con frecuencia al ejecutar una carga de trabajo mixta, como la congestión del embudo y la disminución del rendimiento. A diferencia del tipo único de la operación, este es un ejercicio de ajuste más complicado que observa y ajusta los recursos insuficientes y equilibra dichos recursos de acuerdo con alguna prioridad. Por ejemplo, la solicitud de búsqueda de producción debe preceder a las operaciones de compilación de índice.

En caso de que la lentitud de Elasticsearch se deba a una combinación de cargas de trabajo en la que el clúster de búsqueda indexa y atiende a datos de solicitudes activas, el ajuste resulta más complicado y requiere que se tomen por adelantado decisiones relacionadas con las prioridades de los tipos de combinación de las cargas de trabajo.

En la mayoría de los casos, deberá priorizar un tipo de operación sobre otro. En este ejemplo, sería necesario seleccionar una prioridad más alta para las búsquedas activas y una prioridad más baja para la creación del índice del entorno de creación.

Cambio de los subprocesos de escriturra:

Al cambiar los subprocesos de escritura y búsqueda en Elasticsearch, el clúster puede ajustarse de forma eficaz para obtener un mayor rendimiento y priorizar las operaciones de escritura (compilación de índices de autoría) activas (solicitudes de subprocesos de búsqueda).

Elasticsearch cuenta con un grupo de subprocesos de escritura para gestionar las solicitudes de indexación. De forma predeterminada, este grupo tiene el siguiente tamaño: (número de núcleos de CPU * 2) + 1. Puede aumentar o disminuir el tamaño del grupo según la carga de trabajo del clúster.

Para cambiar el tamaño del grupo de subprocesos de escritura, puede utilizar el valor thread_pool.write.size en el archivo de configuración de Elasticsearch. Por ejemplo, para aumentar el tamaño de escritura de la agrupación de subprocesos a 16, añada la siguiente línea en archivo de configuración:

thread_pool.write.size : 16.

Cambio de los subprocesos de búsqueda

Elasticsearch también dispone de un grupo de subprocesos de búsqueda que gestiona las solicitudes de búsqueda. De forma predeterminada, este grupo tiene un tamaño de (número de núcleos de CPU * 3) / 2. Puede aumentar o disminuir el tamaño de este grupo según la carga de trabajo del clúster.

Para cambiar el tamaño del grupo de subprocesos de búsqueda, puede utilizar el valor thread_pool.search.size en el archivo de configuración de Elasticsearch. Por ejemplo, para aumentar el tamaño del grupo de subprocesos de búsqueda a 24, añada la siguiente línea al archivo de configuración:

thread_pool.search.size: 24 .

Important: El cambio de los tamaños de los grupos de subprocesos debe realizarse con precaución; además, tras el cambio deberán realizarse pruebas exhaustivas. Si el tamaño de un grupo de subprocesos se aumenta demasiado, los recursos podrían agotarse y podría haber problemas en el rendimiento. Se recomienda supervisar el uso de los recursos del clúster después de cambiar los tamaños de los grupos de subprocesos, además de ajustarlos como corresponde para que el rendimiento sea óptimo.

El ajuste de los valores de índice también puede servir para ajustar de forma eficaz Elasticsearch, lo que permite mejorar el rendimiento. Es posible cambiar los siguientes parámetros para mejorar el rendimiento de la indexación:

Intervalo de renovación

De forma predeterminada, Elasticsearch refresca el índice de búsqueda cada segundo. Esto significa que cuando se indexa un documento, este estará disponible inmediatamente y podrá buscarse en el siguiente intervalo de refresco. Si dispone de un gran volumen de solicitudes de indexación, considere la posibilidad de aumentar el intervalo de refresco, de manera que se reduzca la frecuencia de refresco del índice y mejore el rendimiento de la indexación. Por el contrario, si necesita que la indexación sea en tiempo real, puede reducir el intervalo de refresco.

Para ajustar el intervalo de refresco, utilice el valor index.refresh_interval . Por ejemplo, para establecer el intervalo de renovación en 5 segundos, puede ejecutar el siguiente comando:

PUT /my_index/_settings
{
  "index" : {
    "refresh_interval" : "5s"
  }
}

Número de fragmentos

El número de fragmentos de un índice también puede afectar al rendimiento de la indexación. Si dispone de un índice extenso con muchos fragmentos, el rendimiento de la indexación puede ser más lento debido a la sobrecarga que se produce al coordinar escrituras entre varios fragmentos. En general, se recomienda mantener el número de fragmentos por índice entre 1 y 5.

Para ajustar el número de fragmentos, puede utilizar el valor index.number_of_shards. Por ejemplo, para establecer el número de fragmentos en 3, puede ejecutar el siguiente comando:

PUT /my_index/_settings
{
  "index" : {
    "number_of_shards" : 3
  }
}