¿Cómo soluciono los picos de latencia de búsqueda en mi clúster de Amazon OpenSearch Service?

Descripción breve

Para las peticiones de búsqueda, el tiempo de ida y vuelta se calcula de la siguiente manera:

Tiempo de ida y vuelta = Tiempo que la consulta pasa en la fase de consulta + Tiempo en la fase de obtención + Tiempo que pasa en la cola + Latencia de la red

La métrica SearchLatency de Amazon CloudWatch le brinda el tiempo que utiliza la consulta en la fase de consulta.

Hay una serie de pasos de resolución de problemas que puede seguir para solucionar problemas de búsqueda de picos de latencia en el clúster de OpenSearch Service, entre los que se incluyen los siguientes:

• Verifique si hay recursos aprovisionados insuficientes en el clúster.
• Verifique si hay rechazos de búsqueda mediante la métrica ThreadpoolSearchRejected de CloudWatch
• Utilice la API de registros lentos de búsqueda y la API de perfiles
• Resolución de los errores 504 “gateway timeout” (tiempo de espera de puerta de enlace agotado)

Resolución

Verifique si hay recursos aprovisionados insuficientes en el clúster.

Puede experimentar picos de latencia de búsqueda si no tiene suficientes recursos aprovisionados en el clúster. Utilice las siguientes prácticas recomendadas para asegurarse de que dispone de suficientes recursos aprovisionados.

1.    Revise la métrica de CPUUtilization y la presión de la JVMMemory del clúster mediante CloudWatch para confirmar que se encuentran dentro de los límites recomendados. Para obtener más información, consulte Alarmas de CloudWatch recomendadas.

2.    Utilice la API de node stats para obtener las estadísticas de niveles de nodos en el clúster:

GET /_nodes/stats

En el resultado, verifique las siguientes secciones: cachés, fielddata y jvm. Ejecute esta API en varias ocasiones con cierto retraso para comparar los resultados.

3.    OpenSearch Service utiliza la caché del sistema de archivos para realizar peticiones de búsqueda más rápidas. Analice el resultado de la API de node stats para observar si hay expulsiones de caché. Si hay una cantidad elevada de expulsiones de caché en la salida, esto significa que el tamaño de la caché no es adecuado para realizar la solicitud. En este caso, considere utilizar nodos más grandes con más memoria.

4.    Las agregaciones en campos que contienen valores muy únicos pueden provocar un aumento en el uso del heap. Si las consultas de agregación ya están en uso, las operaciones de búsqueda utilizan fielddata. fielddata también se utiliza para ordenar y acceder a los valores de los campos en el script. Las expulsiones de fielddata dependen del tamaño del archivo indices.fielddata.cache.size, y éste representa el 20 % del espacio de la JVM en la pila. Las expulsiones comienzan cuando se excede el límite de la caché.

Para obtener más información sobre la solución de problemas de memoria elevada de la JVM, consulte ¿Cómo se solucionan problemas de alta presión de memoria de la JVM en el clúster OpenSearch Service?

Para solucionar problemas de uso de la CPU elevado, consulte ¿Cómo se solucionan los problemas de uso elevado de la CPU en el clúster de OpenSearch Service?

Verifique si hay rechazos de búsqueda mediante la métrica ThreadpoolSearchRejected de CloudWatch

Para verificar si hay rechazos de búsqueda mediante CloudWatch, siga los pasos descritos en ¿Cómo se resuelven los rechazos de búsqueda o escritura en OpenSearch Service?

Uso de los registros de consultas lentas para identificar consultas de larga duración

Utilice los registros lentos para identificar tanto las consultas de larga duración como el tiempo que una consulta dedica a cada partición. Puede establecer límites para la fase de consulta y, luego, recuperar la fase de cada índice. Para obtener más información sobre la configuración de registros lentos, consulte Viewing OpenSearch Service slow logs (Visualización de registros lentos de OpenSearch Service). Asegúrese de establecer “profile”:true para su consulta de búsqueda para obtener un desglose detallado del tiempo que emplea la consulta en la fase de consulta.

Nota: Si se establece el límite de registro en un valor muy bajo, es posible que la presión de la memoria de la JVM aumente. Esto puede ocasionar que la recolección de basura sea más frecuente, lo que aumenta la utilización de la CPU y la latencia del clúster. El registro de más consultas también puede aumentar los costos. El resultado de la API profile puede ser largo, lo que agrega una sobrecarga significativa a cualquier consulta de búsqueda.

Resolución de los errores 504 “gateway timeout” (tiempo de espera de puerta de enlace agotado)

En los registros de aplicación del clúster de OpenSearch Service, puede ver códigos de error HTTP específicos para solicitudes individuales. Para obtener más información sobre cómo resolver los errores de tiempo de espera de la puerta e enlace HTTP 504, consulte ¿Cómo puedo evitar los errores de tiempo de espera de la puerta de enlace HTTP 504 en OpenSearch Service?

Nota: Es necesario habilitar los registros de errores para identificar códigos de error HTTP específicos. Para obtener más información sobre los códigos de error HTTP, consulte Visualización de los registros de errores en OpenSearch Service.

Otros factores que pueden ocasionar una latencia de búsqueda alta

Existen otros factores que pueden ocasionar una latencia de búsqueda alta. Siga los consejos a continuación para solucionar más problemas de latencia de búsqueda alta:

• La actividad de recolección de basura frecuente o prolongada puede ocasionar problemas de rendimiento de búsqueda. La actividad de recolección de basura puede pausar los subprocesos y aumentar la latencia de búsqueda. Para obtener información adicional, consulte Administración del montón administrado de Elasticsearch en el sitio web de Elasticsearch.
• Las IOPS aprovisionadas (o instancias i3) pueden ayudar a eliminar cualquier obstáculo de Amazon Elastic Block Store (Amazon EBS). En la mayoría de los casos, no los necesitará. Se recomienda probar el rendimiento entre los nodos i3 y los r5 antes de utilizar directamente i3.
• Un clúster con demasiadas particiones puede ocasionar el aumento de la utilización de recursos, incluso cuando el clúster está inactivo. Si hay demasiadas particiones, estas ralentizan el rendimiento de las consultas. Si bien el aumento del recuento de particiones de réplica puede ocasionar búsquedas más rápidas, asegúrese de no superar las 1000 particiones en un nodo determinado. Además, asegúrese de que los tamaños de las particiones oscilen entre 10 GiB y 50 GiB. Idealmente, el número máximo de particiones en un nodo debería ser heap * 20.
• Si hay demasiados segmentos o documentos eliminados, esto puede afectar al rendimiento de la búsqueda. En este caso, el uso de la combinación forzada en índices de solo lectura puede ser de gran ayuda. Si el caso de uso lo permite, aumente la actualización interna de los índices activos. Para obtener más información, consulte Gestión de Lucene de los documentos eliminados en el sitio web de Elasticsearch.
• Si el clúster está en una VPC, considere la posibilidad de ejecutar las aplicaciones dentro de la misma VPC.
• Considere la posibilidad de utilizar nodos UltraWarm o nodos de datos activos para datos de solo lectura. El almacenamiento activo brinda el rendimiento más rápido posible para indexar y buscar datos nuevos. Sin embargo, los nodos UltraWarm son una forma rentable de almacenar grandes cantidades de datos de solo lectura en el clúster. En el caso de los índices que no escribe de forma activa y de los que no necesita el mismo rendimiento, UltraWarm ofrece costos por GiB de datos significativamente más bajos.
• Analice la carga de trabajo para comprobar si es beneficioso tener los datos que busca disponibles en todos los nodos. Algunas aplicaciones se benefician gracias a este método, especialmente si hay pocos índices en el clúster. Para ello, aumente el número de particiones de réplica. Tenga en cuenta que esto puede aumentar la latencia de indexación. Además, es posible que necesite almacenamiento adicional de Amazon EBS para dar lugar a las réplicas agregadas. Esto aumenta los costos de volumen de EBS.
• Busque en el menor número de campos posible, evite los scripts y las consultas con comodines. Para obtener más información, consulte Ajuste de la velocidad de búsqueda en el sitio web de Elasticsearch.
• En el caso de índices con muchas particiones, puede utilizar el enrutamiento personalizado para acelerar las búsquedas. El enrutamiento personalizado garantiza que solo se consulten los particiones que contienen los datos, en lugar de transmitir la solicitud a todas las particiones del índice. Para obtener más información, consulte Personalización del enrutamiento del documento en el sitio web de Elasticsearch.

---

Información relacionada

Alarmas de CloudWatch recomendadas para Amazon OpenSearch Service