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

Descripción corta

Para las solicitudes de búsqueda, OpenSearch Service calcula el tiempo de ida y vuelta con la siguiente fórmula:

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

La métrica SearchLatency de OpenSearch Service en Amazon CloudWatch muestra el tiempo que la consulta pasó en la fase de consulta.

Para solucionar los picos de latencia de búsqueda en tu clúster de OpenSearch Service, toma las siguientes medidas:

• Comprueba las métricas de la infraestructura, como el uso de la CPU, el uso del disco y la memoria, tanto para la presión de la memoria de la máquina virtual Java (JVM) como para la recopilación de elementos no utilizados.
• Comprobación de si hay picos en la métrica SearchRate.
• Utiliza la métrica ThreadpoolSearchRejected para comprobar si hay rechazos de búsqueda.
• Utiliza registros lentos para identificar consultas de larga duración.
• Resuelve los errores «504 gateway timeout».
• Optimiza la configuración para reducir la latencia.

Resolución

Comprobación de las métricas de infraestructura

La recopilación de elementos no utilizados frecuente y prolongada en los nodos de datos del sistema operativo (SO) se produce cuando el uso de recursos es elevado. Si no aprovisionas suficientes recursos en tu clúster, es posible que experimentes picos de latencia de búsqueda.

Solución de problemas de uso elevado de recursos

Asegúrate de que las métricas CPUUtilization y JVMMemoryPressure para tu clúster estén por debajo del 80 %. Si los valores de las métricas en CloudWatch superan el 80 %, soluciona el problema del uso elevado de la CPU o la alta presión de la memoria de la JVM.

Para supervisar de forma proactiva el uso de los recursos, configura las alarmas de CloudWatch para OpenSearch Service.

Para obtener estadísticas a nivel de nodo de tu clúster, ejecuta la siguiente consulta a intervalos de 5 minutos:

GET /_nodes/stats

En el resultado, busca cambios significativos en el uso de la caché, la memoria de datos de campo y los valores de montón de JVM entre ejecuciones. Los valores consistentes muestran un funcionamiento normal. Pueden producirse picos o caídas repentinos cuando hay problemas.

Comprobación de la configuración de la caché

OpenSearch Service utiliza las siguientes cachés para mejorar su rendimiento y el tiempo de respuesta de las solicitudes:

• La 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 partición que existen en el nivel de OpenSearch Service

Para ver la información de la memoria caché del sistema de archivos, ejecuta la siguiente consulta:

GET /_nodes/stats/indices/request_cache?human

Para ver la información de una caché de solicitudes a nivel de partición, ejecuta la siguiente consulta:

GET /_nodes/stats/indices/query_cache?human

En el resultado, comprueba si hay expulsiones de caché. Un número elevado de expulsiones de caché significa que la caché es demasiado pequeña para atender la solicitud. Para reducir las expulsiones, utiliza nodos más grandes con más memoria. Para obtener más información sobre los precios de los tamaños de los nodos, consulta Precios de Amazon OpenSearch Service. Para obtener más información sobre las cachés de OpenSearch, consulta Análisis a fondo del almacenamiento en caché en Elasticsearch: impulsar la velocidad de búsqueda, una memoria caché a la vez en el sitio web de Elastic.

Para borrar la caché, consulta Clear cache API (API Clear cache) en el sitio web de OpenSearch.

Las agregaciones en campos que contienen valores altamente exclusivos puede provocar un aumento en el uso del montón. Las operaciones de búsqueda para las consultas de agregación utilizan datos de campo. Los datos de campo también ordenan y acceden a los valores de campo del script. Las expulsiones de los datos de campo dependen del tamaño del archivo indices.fielddata.cache.size y esto representa el 20 % del montón de JVM.

Para comprobar la cantidad de memoria que usan los datos de campo en todos los nodos del clúster, ejecuta la siguiente consulta:

GET /_nodes/stats/indices/fielddata?human

Comprobación de si hay picos en la métrica SearchRate

Varias solicitudes de búsqueda en un periodo corto pueden agotar los recursos de un clúster y provocar retrasos en el procesamiento de las consultas y tiempos de respuesta más lentos para las búsquedas individuales. La alta tasa de búsqueda en OpenSearch Service puede provocar un aumento de la latencia de búsqueda. Si la métrica SearchRate aumenta, comprueba si los picos se producen al mismo tiempo que los picos de latencia de búsqueda. Si los picos se producen al mismo tiempo, debes agregar más recursos a tu clúster u optimizar las consultas para administrar la carga de búsqueda.

Comprobación de si hay rechazos de búsqueda

Utiliza la métrica ThreadpoolSearchRejected para identificar y resolver los rechazos de búsqueda.

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

Para identificar las consultas de larga duración y el tiempo que una consulta dedica a una partición determinada, utiliza registros lentos. Puedes establecer umbrales para la fase de consulta y, a continuación, obtener la fase de cada índice.

Para obtener un resumen detallado del tiempo que tu consulta pasa en la fase de consulta, define el perfil como true en la consulta de búsqueda.

Ejemplo de consulta:

GET /my_index/_search
{
  "profile": true,
  "query": {
    "match": {
      "field": "value"
    }
  }
}

Nota: Si estableces un umbral de registro demasiado bajo, es posible que la presión de la memoria de la JVM y la latencia del clúster aumenten. Cuando registras más consultas, también aumentas tus costes. Un resultado grande para una consulta con el perfil establecido en true agrega sobrecarga a otras consultas de búsqueda. Como resultado, otras búsquedas se ralentizan temporalmente.

Resolución de los errores 504 gateway timeout

Requisito previo: Activa los registros de errores para identificar códigos de error HTTP específicos.

En los registros de aplicaciones de tu clúster de OpenSearch Service, puedes ver códigos de error HTTP específicos para solicitudes individuales. Para resolver los errores HTTP 504 gateway timeout, consulta ¿Cómo puedo evitar los errores HTTP 504 gateway timeout en Amazon OpenSearch Service?

Optimización de la configuración

Administra tu actividad de recopilación de elementos no utilizados

La actividad de recopilación de elementos no utilizados frecuente o prolongada puede provocar problemas de rendimiento de búsqueda, pausar subprocesos o aumentar la latencia de búsqueda. Para conocer las prácticas recomendadas para reducir el tiempo de recopilación de elementos no utilizados, consulta A heap of trouble: Managing Elasticsearch's managed heap (Un motón de problemas: administración del montón administrado de Elasticsearch) en el sitio web de Elastic.

Optimización del almacenamiento de las instancias

Tu tipo de instancia de Amazon Elastic Compute Cloud (Amazon EC2) puede usar volúmenes de almacenamiento optimizado de Amazon Elastic Block Store (Amazon EBS) o de almacén de instancias. Los volúmenes de almacén de instancias pueden ayudar a abordar los cuellos de botella de E/S, ya que ofrecen almacenamiento conectado directamente y mayores capacidades de IOPS. Sin embargo, las instancias optimizadas para Amazon EBS ofrecen almacenamiento persistente con un rendimiento uniforme. Elige un tipo de almacenamiento que se alinee con tus requisitos de configuración en función de la E/S, la persistencia de los datos y los costes.

Antes de cambiar el tipo de instancia, se recomienda probar el rendimiento entre los distintos tipos de instancias para comprobar que cumplen los requisitos de carga de trabajo. Para obtener una lista de los tipos de instancias de OpenSearch Service disponibles, consulta Nivel gratuito y Precios de instancias bajo demanda en Precios de Amazon OpenSearch Service.

Nota: Si el clúster está en una nube virtual privada (VPC), se recomienda ejecutar las aplicaciones dentro de la misma VPC.

Simplificación de la configuración de particiones y segmentos

Un clúster con demasiadas particiones puede aumentar la utilización de los recursos, incluso cuando el clúster está inactivo. Demasiadas particiones ralentizan el rendimiento de las consultas. Si bien un número mayor de particiones de réplicas permite realizar búsquedas más rápidas, no utilices más de 1000 particiones en un solo nodo. Además, asegúrate de que los tamaños de las particiones estén entre 10 GiB y 50 GiB. Se recomienda establecer el número máximo de particiones de un nodo en 20 veces el tamaño del montón. Para obtener información sobre cómo volver a indexar y cambiar la estrategia de particiones, consulta Optimize OpenSearch index shard sizes (Optimización del tamaño de las particiones del índice de OpenSearch) en el sitio web de OpenSearch.

Demasiados segmentos o demasiados documentos eliminados también pueden afectar al rendimiento de la búsqueda. Para mejorar el rendimiento, utiliza la combinación forzada en los índices de solo lectura y aumenta el intervalo de actualización en los índices activos. Para obtener más información, consulta Force merge API (API Force merge) y Optimize OpenSearch refresh interval (Optimización del intervalo de actualización de OpenSearch) en el sitio web de OpenSearch.

Antes de agregar particiones de réplica a todos los nodos, evalúa los requisitos de la aplicación. Si tu aplicación debe buscar todos los datos de cualquier nodo, aumenta la cantidad de particiones de réplica para aumentar la disponibilidad de los datos. De lo contrario, es posible que no necesites particiones de réplica en todos los nodos.

Nota: Las particiones de réplica permiten a los clústeres utilizar el procesamiento paralelo y distribuir las solicitudes de búsqueda en varias copias de los datos. Como resultado, el rendimiento de búsqueda mejora. Sin embargo, las operaciones de indexación se vuelven más lentas y se necesita almacenamiento adicional para cada copia de datos completa.

En el caso de los índices con muchas particiones, usa el enrutamiento personalizado para mejorar el rendimiento de la búsqueda. Con el enrutamiento personalizado, solo consultas las particiones que contienen tus datos en lugar de todas las particiones. Para configurar el enrutamiento personalizado, consulta Customizing your document routing (Personalización del enrutamiento de los documentos) en el sitio web de Elastic.

Uso del almacenamiento de UltraWarm para datos de solo lectura

El almacenamiento activo proporciona el rendimiento más rápido para indexar y buscar datos nuevos. Sin embargo, los nodos UltraWarm ofrecen una forma rentable de almacenar grandes cantidades de datos de solo lectura en tu clúster. Para los índices de solo lectura que no requieren un alto rendimiento, utiliza UltraWarm en lugar del almacenamiento activo de datos.

Aumento de la velocidad de búsqueda

Busca el menor número de campos posible y evita los scripts y las consultas con caracteres comodín. Para obtener más información, consulta Tune for search speed (Ajustar la velocidad de búsqueda) en el sitio web de Elastic.