Comment résoudre les pics de latence de recherche dans mon cluster OpenSearch Service ?

Brève description

Pour les demandes de recherche, OpenSearch Service calcule le temps d'aller-retour à l'aide de la formule suivante :

Aller-retour = Temps passé par la requête dans la phase de requête + Temps passé dans la phase de récupération + Temps passé dans la file d'attente + Latence réseau

La métrique SearchLatency d’OpenSearch Service dans Amazon CloudWatch indique le temps passé par la requête au cours de la phase de requête.

Pour résoudre les problèmes liés aux pics de latence de recherche dans votre cluster OpenSearch Service, effectuez les actions suivantes :

• Vérifiez les métriques d'infrastructure, telles que l'utilisation du processeur, de l'utilisation du disque et de la mémoire, à la fois pour ce qui est de la pression de la mémoire de la machine virtuelle Java (JVM) et de la récupération de mémoire.
• Vérifiez la présence de pics dans la métrique SearchRate.
• Utilisez la métrique ThreadpoolSearchRejected pour vérifier les rejets de recherche.
• Utilisez des journaux lents pour trouver les requêtes longue durée.
• Résolvez les erreurs « 504 gateway timeout ».
• Optimisez votre configuration pour réduire la latence.

Résolution

Vérifier les métriques d'infrastructure

Le récupérateur de mémoire sur les nœuds de données du système d'exploitation (OS) est fréquent et long lorsque votre utilisation des ressources est élevée. Si vous ne provisionnez pas suffisamment de ressources sur votre cluster, vous risquez de rencontrer des pics de latence de recherche.

Résoudre les problèmes liés à l'utilisation élevée des ressources

Assurez-vous que les métriques CPUUtilization et JVMMemoryPressure pour votre cluster sont inférieures à 80 %. Si les valeurs des métriques dans CloudWatch sont supérieures à 80 %, résolvez les problèmes liés à l'utilisation élevée du processeur ou à la forte sollicitation de la mémoire JVM.

Pour surveiller de manière proactive l'utilisation des ressources, configurez des alarmes CloudWatch pour OpenSearch Service.

Pour obtenir des statistiques au niveau des nœuds sur votre cluster, exécutez la requête suivante plusieurs fois à des intervalles de 5 minutes :

GET /_nodes/stats

Dans la sortie, recherchez les changements significatifs dans l'utilisation du cache, la mémoire fieldata et les valeurs de tas JVM entre les exécutions. Des valeurs constantes indiquent un fonctionnement normal. Des pics ou des baisses soudains peuvent survenir en cas de problème.

Vérifier les paramètres de votre cache

OpenSearch Service utilise les caches suivants pour améliorer ses performances et son temps de réponse aux requêtes :

• Le cache du système de fichiers, ou cache de pages, qui existe au niveau du système d'exploitation
• Le cache de requêtes au niveau de la partition et le cache de requêtes, existant tous deux au niveau du service OpenSearch

Pour afficher les informations relatives au cache du système de fichiers, exécutez la requête suivante :

GET /_nodes/stats/indices/request_cache?human

Pour afficher les informations relatives à un cache de requêtes au niveau de la partition, exécutez la requête suivante :

GET /_nodes/stats/indices/query_cache?human

Dans la sortie, vérifiez l’existence d’évictions de cache. Un nombre élevé d'évictions de cache signifie que le cache est trop petit pour répondre à la requête. Pour réduire vos évictions, utilisez des nœuds de plus grande taille avec davantage de mémoire. Pour plus d'informations sur la tarification de la taille des nœuds, consultez la section Tarification d’OpenSearch Service. Pour plus d'informations sur les caches OpenSearch, consultez la page Mise en cache d'Elasticsearch : Augmenter la vitesse des requêtes, un cache à la fois sur le site Web d'Elastic.

Pour vider votre cache, consultez la page API d’effacement du cache sur le site Web d'OpenSearch.

L'exécution d'agrégations sur des champs contenant des valeurs hautement uniques peut entraîner une augmentation de l'utilisation du tas. Les opérations de recherche pour les requêtes d'agrégation utilisent fielddata. Fielddata trie et accède également aux valeurs des champs dans le script. Les évictions de fielddata dépendent de la taille du fichier indices.fielddata.cache.size, qui représente 20 % de l'espace de mémoire de la JVM.

Pour vérifier la quantité de mémoire utilisée par fielddata sur tous les nœuds du cluster, exécutez la requête suivante :

GET /_nodes/stats/indices/fielddata?human

Vérifier la présence de pics dans la métrique SearchRate

Plusieurs demandes de recherche sur une courte période peuvent épuiser les ressources d'un cluster et entraîner des retards dans le traitement des requêtes et des temps de réponse plus lents pour les recherches individuelles. Un taux de recherche élevé dans OpenSearch Service peut entraîner une augmentation de la latence de recherche. Si la métrique SearchRate augmente, vérifiez si les pics se produisent en même temps que les pics de latence de recherche. Si les pics se produisent simultanément, vous devez ajouter des ressources supplémentaires à votre cluster ou optimiser les requêtes pour gérer la charge de recherche.

Vérifier les rejets de recherche

Utilisez la métrique ThreadpoolSearchRejected pour identifier et résoudre les rejets de recherche.

Utiliser des journaux lents pour trouver les requêtes longue durée

Pour trouver à la fois les requêtes longue durée et le temps consacré par une requête à une partition particulière, utilisez des journaux lents. Vous pouvez définir des seuils pour la phase de requête, puis récupérer la phase pour chaque index.

Pour obtenir un résumé détaillé du temps que passe votre requête pendant la phase de recherche, définissez profile sur vrai dans votre requête de recherche.

Exemple de requête :

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

Remarque : Si vous définissez un seuil de journalisation trop bas, la pression de mémoire de votre JVM et la latence de votre cluster peuvent augmenter. Lorsque vous enregistrez un plus grand nombre de requêtes, vous augmentez également vos coûts. Une sortie importante pour une requête avec profile défini sur vrai augmente la charge des autres requêtes de recherche. Par conséquent, les autres recherches ralentissent temporairement.

Résoudre les erreurs de délai d’expiration de la passerelle 504

Prérequis : Activez les journaux d'erreurs pour découvrir des codes d'erreur HTTP spécifiques.

Dans les journaux des applications de votre cluster OpenSearch Service, vous pouvez voir des codes d'erreur HTTP spécifiques pour des requêtes individuelles. Pour résoudre les erreurs de délai d’expiration de la passerelle HTTP 504, consultez la section Comment puis-je empêcher les erreurs de délai d’expiration de la passerelle HTTP 504 dans OpenSearch Service ?

Optimiser votre configuration

Gérer votre activité de récupération de mémoire

Une activité de récupération de mémoire fréquente ou prolongée peut entraîner des problèmes de performances de recherche, suspendre les fils de discussion ou augmenter la latence de recherche. Pour connaître les bonnes pratiques visant à réduire le temps de récupération de mémoire, consultez la page Un tas d’ennuis : Gestion du tas géré d'Elasticsearch sur le site Web d'Elastic.

Optimiser votre stockage d’instance

Votre type d'instance Amazon Elastic Compute Cloud (Amazon EC2) peut utiliser un stockage optimisé pour Amazon Elastic Block Store (Amazon EBS) ou des volumes de stockage d'instance. Les volumes de stockage d'instance peuvent contribuer à remédier aux goulots d'étranglement en matière d'E/S, car ils offrent un stockage directement connecté et des capacités IOPS supérieures. Cependant, les instances optimisées pour Amazon EBS offrent un stockage permanent avec des performances constantes. Choisissez un type de stockage adapté à vos exigences de configuration en fonction des E/S, de la persistance des données et des coûts.

Avant de modifier votre type d'instance, il est recommandé de tester les performances entre les différents types d'instances afin de vérifier qu'ils répondent à vos exigences en matière de charge de travail. Pour obtenir la liste des types d'instances d'OpenSearch Service disponibles, consultez la section Tarification des instances de niveau gratuit et Tarification des instances à la demande sur la page Tarification du service OpenSearch.

Remarque : Si votre cluster se trouve dans un cloud privé virtuel (VPC), il est recommandé d'exécuter vos applications au sein du même VPC.

Simplifier la configuration de vos partitions et de vos segments

Un cluster comportant un trop grand nombre de partitions peut augmenter l'utilisation des ressources, y compris si le cluster est inactif. Un trop grand nombre de partitions ralentit les performances des requêtes. Bien qu'un plus grand nombre de fragments de répliques permette d'accélérer les recherches, n'utilisez pas plus de 1 000 fragments sur un seul nœud. Veillez également à ce que les tailles des partitions soient comprises entre 10 Gio et 50 Gio. Il est recommandé de définir le nombre maximum de fragments sur un nœud à 20 fois la taille du tas. Pour plus d'informations sur la manière de réindexer et de modifier votre stratégie de partition, consultez la page Optimiser la taille des partitions d'index OpenSearch sur le site Web d'OpenSearch.

Un trop grand nombre de segments ou de documents supprimés peut compromettre les performances de recherche. Pour améliorer les performances, utilisez la fusion forcée sur les index en lecture seule et augmentez l'intervalle d'actualisation sur les index actifs. Pour plus d'informations, consultez les pages API de fusion forcée et Optimiser l'intervalle d’actualisation d'OpenSearch sur le site Web d'OpenSearch.

Avant d'ajouter des fragments de réplicas à tous les nœuds, évaluez les exigences de votre application. Si votre application doit rechercher toutes les données provenant d’un nœud quelconque, augmentez le nombre de fragments de réplicas pour améliorer la disponibilité des données. Sinon, vous n'aurez peut-être pas besoin de réplicas de fragments sur chaque nœud.

Remarque : Les réplicas de fragments permettent aux clusters d'utiliser un traitement parallèle et de répartir les demandes de recherche sur plusieurs copies des données. Par conséquent, les performances de recherche s'améliorent. Cependant, les opérations d'indexation deviennent plus lentes et vous avez besoin d'espace de stockage supplémentaire pour chaque copie complète des données.

Pour les index contenant de nombreux fragments, utilisez un routage personnalisé pour améliorer les performances de recherche. Avec le routage personnalisé, vous interrogez uniquement les partitions qui contiennent vos données au lieu de toutes les partitions. Pour configurer le routage personnalisé, consultez la page Personnalisation du routage de vos documents sur le site Web d'Elastic.

Utiliser le stockage UltraWarm pour les données en lecture seule

Le stockage à chaud offre les performances les plus rapides pour indexer et rechercher de nouvelles données. Les nœuds UltraWarm offrent toutefois un moyen rentable de stocker de grandes quantités de données en lecture seule sur votre cluster. Pour les index en lecture seule qui ne nécessitent pas de hautes performances, utilisez UltraWarm au lieu d'un stockage de données à chaud.

Augmenter votre vitesse de recherche

Effectuez des recherches dans le moins de champs possible, et évitez les scripts et les requêtes contenant des caractères génériques. Pour plus d'informations, consultez la page Optimisation de la vitesse de recherche sur le site Web d'Elastic.