¿Cómo puedo resolver los rechazos de búsqueda o escritura en OpenSearch Service?

Descripción corta

Cuando escribe o busca datos en el clúster de OpenSearch Service, es posible que reciba el siguiente error HTTP 429 o es_rejected_execution_exception:

error":"elastic: Error 429 (Too Many Requests): rejected execution of org.elasticsearch.transport.TransportService$7@b25fff4 on
EsThreadPoolExecutor[bulk, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@768d4a66[Running,
pool size = 2, active threads = 2, queued tasks = 200, completed tasks = 820898]] [type=es_rejected_execution_exception]"

Reason={"type":"es_rejected_execution_exception","reason":"rejected execution of org.elasticsearch.transport.TcpTransport$RequestHandler@3ad6b683 on EsThreadPoolExecutor[search, queue capacity = 1000, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@bef81a5[Running, pool size = 25, active threads = 23, queued tasks = 1000, completed tasks = 440066695]]"

Las siguientes variables pueden contribuir a que se produzca un error HTTP 429 o una excepción de es_rejected_execution_exception:

• Tipos de instancias de nodos de datos y límites de búsqueda o escritura
• Valores altos de métricas de instancias
• Subprocesos activos y en cola
• Alta utilización de la CPU y presión de memoria de JVM

Se pueden producir errores HTTP 429 debido a las solicitudes de búsqueda y escritura en el clúster. Los rechazos también pueden provenir de un solo nodo o de varios nodos del clúster.

Nota: Las diferentes versiones de Elasticsearch usan diferentes grupos de subprocesos para procesar las llamadas a la API _index. Las versiones 1.5 y 2.3 de Elasticsearch usan el grupo de subprocesos de índice. Las versiones 5.x, 6.0 y 6.2 de Elasticsearch utilizan el grupo de subprocesos masivos. Las versiones 6.3 y posteriores de Elasticsearch usan el grupo de subprocesos de escritura. Para obtener más información, consulte grupos de subprocesos en el sitio web de Elasticsearch.

Resolución

Tipos de instancias de nodos de datos y límites de búsqueda o escritura

Un tipo de instancia de nodo de datos tiene CPU virtuales (vCPU) fijas. Introduzca el recuento de vCPU en la fórmula para recuperar las operaciones simultáneas de búsqueda o escritura que el nodo puede realizar antes de que entre en una cola. Si un subproceso activo se llena, pasa a formar una cola y, finalmente, se rechaza. Para obtener más información sobre la relación entre las vCPU y los tipos de nodos, consulte los precios de OpenSearch Service.

Además, hay un límite en el número de búsquedas por nodo o escrituras por nodo que puede realizar. Este límite se basa en la definición del grupo de subprocesos y en el número de versión de Elasticsearch. Para obtener más información, consulte grupos de subprocesos en el sitio web de Elasticsearch.

Por ejemplo, si elige el tipo de nodo R5.2xlarge para cinco nodos del clúster de Elasticsearch (versión 7.4), el nodo tendrá 8 vCPU.

Use la siguiente fórmula para calcular el número máximo de subprocesos activos para las solicitudes de búsqueda:

int ((# of available_processors * 3) / 2) + 1

Utilice la siguiente fórmula para calcular el número máximo de subprocesos activos para las solicitudes de escritura:

int (# of available_processors)

Para un nodo R5.2xlarge, puede realizar un máximo de 13 operaciones de búsqueda:

(8 VCPUs * 3) / 2 + 1 = 13 operations

Para un nodo R5.2xlarge, puede realizar un máximo de 8 operaciones de escritura:

8 VCPUs = 8 operations

Para un clúster de OpenSearch Service con cinco nodos, puede realizar un máximo de 65 operaciones de búsqueda:

5 nodes * 13 = 65 operations

Para un clúster de OpenSearch Service con cinco nodos, puede realizar un máximo de 40 operaciones de escritura:

5 nodes * 8 = 40 operations

Valores altos de métricas de instancias

Para solucionar la excepción 429, compruebe las siguientes métricas de Amazon CloudWatch para su clúster:

• IndexingRate: el número de operaciones de indexación por minuto. Una sola llamada a la API _bulk que agrega dos documentos y actualiza dos cuenta como cuatro operaciones que pueden extenderse entre los nodos. Si ese índice tiene una o más réplicas, los demás nodos del clúster también registran un total de cuatro operaciones de indexación. Las eliminaciones de documentos no cuentan para la métrica IndexingRate.
• SearchRate: el número total de solicitudes de búsqueda por minuto para todas las particiones de un nodo de datos. Una sola llamada a la API _search puede devolver resultados de muchas particiones diferentes. Si hay cinco particiones diferentes en un nodo, el nodo indica «5» para esta métrica, incluso si el cliente solo hizo una solicitud.
• CoordinatingWriteRejected: el número total de rechazos que se produjeron en el nodo coordinador. Estos rechazos se deben a la presión de indexación acumulada desde el inicio de OpenSearch Service.
• PrimaryWriteRejected: el número total de rechazos que se produjeron en las particiones principales. Estos rechazos se deben a la presión de indexación acumulada desde el último inicio de OpenSearch Service.
• ReplicaWriteRejected: el número total de rechazos que se produjeron en las particiones de réplica debido a la presión de indexación. Estos rechazos se deben a la presión de indexación acumulada desde el último inicio de OpenSearch Service.
• ThreadpoolWriteQueue: el número de tareas en cola en el grupo de subprocesos de escritura. Esta métrica le indica si una solicitud se rechaza debido a un uso elevado de la CPU o a una alta concurrencia de indexación.
• ThreadpoolWriteRejected: el número de tareas rechazadas en el grupo de subprocesos de escritura.
  **Nota:**El tamaño predeterminado de la cola de escritura se incrementó de 200 a 10 000 en la versión 7.9 de OpenSearch Service. Como resultado, esta métrica ya no es el único indicador de rechazos de OpenSearch Service. Utilice las métricas CoordinatingWriteRejected, PrimaryWriteRejected y ReplicaWriteRejected para supervisar los rechazos en las versiones 7.9 y posteriores.
• ThreadpoolSearchQueue: el número de tareas en cola en el grupo de subprocesos de búsqueda. Si el tamaño de la cola es constantemente alto, considere la posibilidad de escalar el clúster. El tamaño máximo de la cola de búsqueda es de 1000.
• ThreadpoolSearchRejected: el número de tareas rechazadas en el grupo de subprocesos de búsqueda. Si este número aumenta continuamente, considere la posibilidad de escalar el clúster.
• JVMMemoryPressure: a presión de la memoria de JVM especifica el porcentaje del montón de Java en un nodo de clúster. Si la presión de memoria de JVM alcanza el 75 %, OpenSearch Service inicia el recolector de elementos no utilizados de Concurrent Mark Sweep (CMS). La recopilación de elementos no utilizados es un proceso que consume mucha CPU. Si la presión de la memoria de la JVM se mantiene en este porcentaje durante unos minutos, es posible que surjan problemas de rendimiento del clúster. Para obtener más información, consulte ¿Cómo soluciono los problemas de alta presión de memoria de JVM en mi clúster de Amazon OpenSearch Service?

Nota: Las métricas del grupo de subprocesos que aparecen en la lista ayudan a informarle sobre IndexingRate y SearchRate.

Para obtener más información sobre la supervisión del clúster de OpenSearch Service con CloudWatch, consulte las métricas de instancias.

Subprocesos activos y en cola

Si faltan CPU o hay mucha concurrencia de solicitudes, la cola puede llenarse rápidamente y provocar un error HTTP 429. Para supervisar los subprocesos de cola, compruebe las métricas ThreadpoolSearchQueue y ThreadpoolWriteQueue en CloudWatch.

Para comprobar si hay algún rechazo de búsqueda en los subprocesos activos y en cola, use el siguiente comando:

GET /_cat/thread_pool/search?v&h=id,name,active,queue,rejected,completed

Para comprobar si hay rechazos de escritura en los subprocesos activos y en cola, sustituya «búsqueda» por «escritura». Los valores rechazados y completados de la salida son contadores de nodos acumulativos, que se restablecen cuando se inician nuevos nodos. Para obtener más información, consulte la sección Ejemplo con columnas explícitas de la API cat thread pool en el sitio web de Elasticsearch.

Nota: La cola masiva de cada nodo puede contener entre 50 y 200 solicitudes, según la versión de Elasticsearch que utilice. Cuando la cola está llena, se rechazan las nuevas solicitudes.

Errores en los rechazos de búsqueda y escritura

Rechazos de búsqueda

Un error de rechazo de búsqueda indica que los subprocesos activos están ocupados y que las colas se han llenado hasta el número máximo de tareas. Por lo tanto, es posible que se rechace su solicitud de búsqueda. Puede configurar los registros de OpenSearch Service para que estos mensajes de error aparezcan en los registros de búsquedas lentas.

Nota: Para evitar sobrecargas adicionales, establezca el umbral de registro lento en una cantidad generosa. Por ejemplo, si la mayoría de las consultas tardan 11 segundos y el umbral es «10», OpenSearch Service tardará más tiempo en escribir un registro. Para evitar esta sobrecarga, establezca el umbral de registro lento en 20 segundos. De esta forma, solo se registra un pequeño porcentaje de las consultas más lentas (que tardan más de 11 segundos).

Una vez que el clúster esté configurado para enviar los registros lentos de búsqueda a CloudWatch, establezca un umbral específico para la generación lenta de registros. Puede establecer un umbral específico para la generación lenta de registros con la siguiente llamada HTTP POST:

curl -XPUT http://<your domain’s endpoint>/index/_settings -d '{"index.search.slowlog.threshold.query.<level>":"10s"}'

Rechazos de escritura

Un mensaje de error 429 como rechazo de escritura indica un error de cola masiva. es_rejected_execution_exception[bulk] indica que la cola está llena y que se ha rechazado cualquier solicitud nueva. Este error de cola masiva se produce cuando el número de solicitudes al clúster supera el tamaño de la cola masiva (threadpool.bulk.queue_size). Una cola masiva en cada nodo puede contener entre 50 y 200 solicitudes, según la versión de Elasticsearch que utilice.

Puede configurar los registros de OpenSearch Service para que estos mensajes de error aparezcan en los registros lentos de su índice.

Nota: Para evitar sobrecargas adicionales, establezca el umbral de registro lento en una cantidad generosa. Por ejemplo, si la mayoría de las consultas tardan 11 segundos y el umbral es «10», OpenSearch Service tardará más tiempo en escribir un registro. Para evitar esta sobrecarga, establezca el umbral de registro lento en 20 segundos. De esta forma, solo se registra un pequeño porcentaje de las consultas más lentas (que tardan más de 11 segundos).

Una vez que el clúster esté configurado para enviar los registros lentos de búsqueda a CloudWatch, establezca un umbral específico para la generación lenta de registros. Para establecer un umbral específico para la generación lenta de registros, utilice la siguiente llamada HTTP POST:

curl -XPUT http://<your domain’s endpoint>/index/_settings -d '{"index.indexing.slowlog.threshold.query.<level>":"10s"}'

Prácticas recomendadas de rechazos de escritura

Estas son algunas de las prácticas recomendadas que mitigan los rechazos de escritura:

• Cuando los documentos se indexan más rápido, es menos probable que la cola de escritura alcance su capacidad máxima.
• Ajuste el tamaño masivo de acuerdo con su carga de trabajo y el rendimiento deseado. Para obtener más información, consulte Ajustar la velocidad de indexación en el sitio web de Elasticsearch.
• Agregue una lógica de reintento exponencial a la lógica de la aplicación. La lógica de reintento exponencial garantiza que las solicitudes fallidas se reintenten automáticamente.
  Nota: Si el clúster recibe continuamente un alto número de solicitudes simultáneas, la lógica de reintentos exponenciales no ayudará a resolver el error 429. Utilice esta práctica recomendada cuando haya un aumento repentino u ocasional de tráfico.
• Si está ingiriendo datos de Logstash, ajuste el recuento de trabajadores y el tamaño del lote. Se recomienda establecer el tamaño de la unidad entre 3 y 5 MB.

Para obtener más información sobre el ajuste del rendimiento de la indexación, consulte ¿Cómo puedo mejorar el rendimiento de indexación en mi clúster de OpenSearch Service?

Prácticas recomendadas de rechazos de búsqueda

Estas son algunas de las prácticas recomendadas que mitigan los rechazos de búsqueda:

• Cambie a un tipo de instancia más grande. OpenSearch Service depende en gran medida de la memoria caché del sistema de archivos para obtener resultados de búsqueda más rápidos. El número de subprocesos del grupo de subprocesos de cada nodo para las solicitudes de búsqueda es igual al siguiente: int((# of available_processors * 3) / 2) + 1. Cambie a una instancia con más vCPU para obtener más subprocesos para procesar las solicitudes de búsqueda.
• Active los registros de búsqueda lenta para un índice determinado o para todos los índices con un valor de umbral razonable. Compruebe qué consultas tardan más en ejecutarse e implemente estrategias de rendimiento de búsqueda para las consultas. Para obtener más información, consulte Solución de problemas en las búsquedas de Elasticsearch para principiantes o Ajustes avanzados: encontrar y resolver búsquedas lentas en Elasticsearch en el sitio web de Elasticsearch.