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

Descripción breve

Para las solicitudes de búsqueda, OpenSearch Service calcula el tiempo de ida y vuelta de la siguiente manera:

Ida y vuelta = Tiempo que la consulta pasa en la fase de consulta + Tiempo en la fase de búsqueda + Tiempo empleado en la cola + Latencia de red

La métrica de latencia de búsqueda de Amazon CloudWatch indica el tiempo que la consulta pasó en la fase de consulta.

Para solucionar los picos de latencia de búsqueda en su clúster de OpenSearch Service, puede seguir varios pasos:

• Compruebe si los recursos aprovisionados en el clúster son insuficientes
• Compruebe si hay rechazos de búsqueda mediante la métrica ThreadpoolSearchRejected en CloudWatch
• Utilice la API de registros lentos de búsqueda y la API de perfiles
• Resuelva cualquier error de tiempo de espera del gateway 504

Resolución

Compruebe si los recursos aprovisionados en el clúster son insuficientes

Si no tiene suficientes recursos aprovisionados en su clúster, es posible que experimentes picos de latencia de búsqueda. Siga las siguientes prácticas recomendadas para asegurarse de que cuenta con suficientes recursos aprovisionados.

1.    Revise la métrica de uso de la CPU y la presión de memoria JVM del clúster mediante CloudWatch. Confirme que estén dentro de los umbrales recomendados. Para obtener más información, consulte las alarmas recomendadas de CloudWatch para Amazon OpenSearch Service.

2.    Use la API de estadísticas de nodos para obtener estadísticas a nivel de nodo en su clúster:

GET /_nodes/stats

En la salida, compruebe las siguientes secciones: cachés, fielddata y jvm. Para comparar las salidas, ejecute esta API varias veces con cierto retraso entre cada salida.

3.    OpenSearch Service utiliza múltiples cachés para mejorar su rendimiento y el tiempo de respuesta de las solicitudes:

• La memoria caché del sistema de archivos, o caché de páginas, que existe en el nivel del sistema operativo
• La caché de solicitudes y la caché de consultas a nivel de fragmento que existen en el nivel de servicio de OpenSearch

Revise la salida de la API de estadísticas de nodos para ver si hay expulsiones de caché. Un número elevado de expulsiones de memoria caché en la salida significa que el tamaño de la memoria caché no es adecuado para atender la solicitud. Para reducir las expulsiones, utilice nodos más grandes con más memoria.

Para ver información de caché específica con la API de estadísticas de nodos, use las siguientes solicitudes. La segunda solicitud es para una caché de solicitudes a nivel de fragmento:

GET /_nodes/stats/indices/request_cache?human

GET /_nodes/stats/indices/query_cache?human

Para obtener más información sobre las cachés de OpenSearch, consulte el análisis profundo sobre almacenamiento en caché de Elasticsearch: Aumentar la velocidad de las consultas, una caché a la vez, en el sitio web de Elastic.

Para conocer los pasos para borrar las distintas cachés, consulte Borrar la caché de índices o flujos de datos en el sitio web de OpenSearch.

4.    Realizar agregaciones en campos que contienen valores altamente exclusivos puede provocar un aumento en el uso del montón. Si las consultas de agregación ya están en uso, las operaciones de búsqueda utilizan datos de campo. Fielddata también ordena y accede a los valores de campo del script. Las expulsiones de Fielddata dependen del tamaño del archivo indices.fielddata.cache.size, y esto representa el 20 % del espacio de almacenamiento de JVM. Cuando se supera la memoria caché, se inicia la expulsión.

Para ver la caché de datos de campo, utilice esta solicitud:

GET /_nodes/stats/indices/fielddata?human

Para obtener más información sobre cómo solucionar problemas con un alto nivel de memoria JVM, consulte ¿Cómo soluciono los problemas de alta presión de memoria de JVM en mi clúster de Amazon OpenSearch Service?
Para solucionar problemas de uso elevado de la CPU, consulte ¿Cómo se solucionan los problemas de uso elevado de la CPU en mi clúster de Amazon OpenSearch Service?

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

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

Utilice registros lentos de búsqueda para identificar consultas de larga duración

Para identificar tanto las consultas de ejecución prolongada como el tiempo que una consulta dedica a un fragmento determinado, utilice registros lentos. Puede establecer umbrales para la fase de consulta y, a continuación, obtener la fase de cada índice. Para obtener más información sobre la configuración de registros lentos, consulte Visualización de los registros lentos de Amazon Elasticsearch Service. Para obtener un desglose detallado del tiempo que dedica la consulta a la fase de consulta, establezca "profile":true para la consulta de búsqueda.

Nota: Si establece el umbral para el registro en un valor muy bajo, la presión de la memoria de la JVM podría aumentar. Esto podría llevar a una recolección de basura más frecuente, lo que, a su vez, aumentaría la utilización de la CPU y aumentaría la latencia del clúster. Registrar más consultas también puede aumentar sus costes. Un resultado largo de la API de perfil también añade una sobrecarga significativa a cualquier consulta de búsqueda.

Resuelva cualquier error de tiempo de espera del gateway 504

En los registros de aplicaciones de su 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 de enlace HTTP 504, consulte ¿Cómo puedo evitar los errores de tiempo de espera de la puerta de enlace HTTP 504 en Amazon OpenSearch Service?

Nota: Debe activar 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 de Amazon OpenSearch Service.

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

Hay otros factores que pueden provocar una latencia de búsqueda elevada. Siga estos consejos para solucionar más problemas de alta latencia de búsqueda:

• La actividad de recolección de basura frecuente o prolongada puede provocar problemas de rendimiento en las búsquedas. La actividad de recolección de elementos no utilizados puede pausar los hilos y aumentar la latencia de búsqueda. Para obtener más información, consulte Un montón de problemas: Administrar el montón gestionado de Amazon OpenSearch Service en el sitio web de Elastic.
• Las IOPS aprovisionadas (o instancias i3) pueden ayudarlo a eliminar cualquier obstáculo de Amazon Elastic Block Store (Amazon EBS). En la mayoría de los casos, no los necesita. Antes de mover una instancia a i3, se recomienda probar el rendimiento entre los nodos i3 y r5.
• Un clúster con demasiados fragmentos puede aumentar la utilización de los recursos, incluso cuando el clúster está inactivo. Demasiados fragmentos ralentizan el rendimiento de las consultas. Si bien aumentar el número de fragmentos de réplica puede ayudarle a realizar búsquedas más rápidas, no supere los 1000 fragmentos en un nodo determinado. Además, asegúrese de que los tamaños de los fragmentos estén entre 10 GiB y 50 GiB. Lo ideal es que el número máximo de fragmentos en un nodo sea el montón * 20.
• Demasiados segmentos o demasiados documentos eliminados pueden afectar al rendimiento de la búsqueda. Para mejorar el rendimiento, utilice la combinación forzada en los índices de solo lectura. Además, aumente la actualización interna de los índices activos, si es posible. Para obtener más información, consulte la sección Gestión de documentos borrados por parte de Lucene en el sitio web de Elastic.
• Si el clúster está en una nube privada virtual (VPC), se recomienda ejecutar las aplicaciones dentro de la misma VPC.
• Utilice nodos UltraWarm o nodos de datos activos para datos de solo lectura. El almacenamiento en caliente proporciona 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 su clúster. Para los índices en los que no es necesario escribir ni requieren un alto rendimiento, UltraWarm ofrece costes por GiB de datos significativamente más bajos.
• Determine si su carga de trabajo se beneficia de tener los datos que busca disponibles en todos los nodos. Algunas aplicaciones se benefician de este enfoque, especialmente si hay pocos índices en el clúster. Para ello, aumente el número de fragmentos de réplica.
  Nota: Esto podría aumentar la latencia de indexación. Además, es posible que necesite almacenamiento adicional en Amazon EBS para acomodar las réplicas que añada. Esto aumenta sus costes de volumen de EBS.
• Busque el menor número de campos posible y evite los scripts y las consultas con caracteres comodín. Para obtener más información, consulte Ajustar la velocidad de búsqueda en el sitio web de Elastic.
• Para índices con muchos fragmentos, utilice un enrutamiento personalizado para acelerar las búsquedas. El enrutamiento personalizado garantiza que consulte solo los fragmentos que contienen sus datos, en lugar de transmitir la solicitud a todos los fragmentos. Para obtener más información, consulte Personalización del enrutamiento de documentos en el sitio web de Elastic.

Información relacionada

Alarmas de CloudWatch recomendadas para Amazon OpenSearch Service