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

Última actualización: 05-08-2021

Estoy experimentando picos de latencia de búsqueda en mi clúster de Amazon OpenSearch Service (posterior a Amazon Elasticsearch Service). ¿Cómo puedo resolver el problema y solucionar los picos de latencia de búsqueda?

Descripción breve

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

Round trip = Time the query spends in the query phase + time in the fetch phase + time spent in the queue + network latency

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.
  • Use API de perfil y registros de consulta lenta.
  • Resuelva todos los errores 504 Gateway Timeout.

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 Amazon 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 NodeStats 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 ya se utilizaron las consultas de agregación, las operaciones de búsqueda utilizarán FieldData. FieldData también se utiliza para ordenar y acceder a los valores de campo de comandos. Las expulsiones de FieldData dependen del tamaño del archivo indices.fielddata.cache.size y esto representa el 20 % del espacio del heap de la JVM. 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 de Amazon 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 Amazon 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 Amazon 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 Amazon Elasticsearch Service Slow Logs (Visualización de registros lentos de Amazon 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

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 gateway HTTP 504, consulte ¿Cómo puedo evitar los errores de tiempo de espera de la gateway HTTP 504 en Amazon 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 Amazon 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 provisionadas (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 las 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 aumentará los costos de volumen de EBS.
  • Busque en la menor cantidad 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.

¿Le resultó útil este artículo?


¿Necesita asistencia técnica o con la facturación?