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

Lecture de 8 minute(s)
0

Des pics de latence de recherche se produisent dans mon cluster Amazon OpenSearch Service.

Brève description

Pour les demandes de recherche, OpenSearch Service calcule le temps d'aller-retour comme suit :

**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 sur Amazon CloudWatch vous indique le temps passé par la requête dans la phase de requête.

Pour résoudre les pics de latence de recherche dans votre cluster OpenSearch Service, procédez comme suit :

  • Vérifiez que les ressources mises à disposition sur le cluster sont suffisantes
  • Vérifiez les rejets de recherche au moyen de la métrique ThreadpoolSearchRejected dans CloudWatch
  • Utilisez l'API Search Slow Logs et l'API Profile
  • Résolvez toutes les erreurs de délai d'expiration de la passerelle 504

Résolution

Vérifiez que les ressources mises à disposition sur le cluster sont suffisantes

Si vous ne disposez pas de ressources suffisantes sur votre cluster, vous risquez d’avoir des pics de latence de recherche. Appliquez les meilleures pratiques suivantes pour vous assurer que vous disposez de ressources suffisantes.

1.Examinez la métrique CPUUtilization et la pression de la JVMMemory du cluster au moyen de CloudWatch. Vérifiez que les seuils recommandés sont respectés. Pour plus d'informations, consultez la section Alarmes CloudWatch recommandée pour Amazon OpenSearch Service.

2.Utilisez l'API node stats pour obtenir des statistiques au niveau des nœuds sur votre cluster :

GET /_nodes/stats

Dans la sortie, consultez les sections suivantes : caches, données de champ et jvm. Pour comparer les sorties, exécutez cette API plusieurs fois avec un certain délai entre chaque sortie.

3.OpenSearch Service utilise plusieurs caches pour améliorer ses performances et le temps de réponse aux requêtes :

  • Le cache du système de fichiers, ou cache de pages, existant 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

Consultez la sortie de l'API Node Stats pour les expulsions de cache. Un nombre élevé d'expulsions de cache dans la sortie signifie que la taille du cache est insuffisante pour répondre à la demande. Pour réduire vos expulsions, utilisez des nœuds plus grands avec davantage de mémoire.

Pour afficher des informations de cache spécifiques à l'aide de l'API node stats, utilisez les requêtes suivantes. La deuxième requête concerne un cache de requêtes au niveau de la partition :

GET /_nodes/stats/indices/request_cache?human

GET /_nodes/stats/indices/query_cache?human

Pour plus d'informations sur les caches OpenSearch, consultez la section consacrée à la mise en cache d'Elasticsearch : Augmenter la vitesse des requêtes, un cache à la fois, sur le site Web d'Elastic.

Pour savoir comment vider les différents caches, consulter Effacer le cache d'index ou de flux de données sur le site Web d'OpenSearch.

4.L'exécution d'agrégations sur des champs contenant des valeurs hautement uniques peut entraîner une augmentation de l'utilisation du segment de mémoire. Si des requêtes d'agrégation sont déjà utilisées, les opérations de recherche utilisent Icefield. Fielddata trie et accède également aux valeurs des champs dans le script. Les expulsions 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. Le dépassement du cache, les expulsions démarrent.

Pour afficher le cache Fielddata, utilisez cette requête :

GET /_nodes/stats/indices/fielddata?human

Pour plus d'informations sur la résolution des problèmes de mémoire JVM élevée, consultez Comment résoudre les problèmes de pression élevée sur la mémoire JVM dans mon cluster Amazon OpenSearch Service ?
Pour résoudre les problèmes d'utilisation élevée du processeur, consultez Comment résoudre les problèmes d'utilisation élevée du processeur dans mon cluster Amazon OpenSearch Service ?

Vérifiez les rejets de recherche au moyen de la métrique ThreadpoolSearchRejected dans CloudWatch

Pour vérifier les rejets de recherche à l'aide de CloudWatch, suivez les étapes décrites dans la section Comment résoudre les refus de recherche ou d'écriture dans Amazon OpenSearch Service ?

Utilisez les journaux de lenteur des recherches 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 plus d'informations sur la configuration des journaux de lenteur, consultez la section Affichage des journaux lents d'Amazon Elasticsearch Service.Pour obtenir une ventilation détaillée du temps consacré à votre requête au cours de la phase de recherche, configurez « profile » :true pour votre requête de recherche.

Remarque : Si vous définissez le seuil de journalisation à une valeur très faible, la pression de la mémoire de votre JVM risque pourrait augmenter. Le récupérateur de déchets peut ainsi être plus fréquent, ce qui augmente l'utilisation du processeur et augmente la latence du cluster. La journalisation d'un nombre croissant de requêtes peut également augmenter vos coûts. Une sortie longue de l'API de profil ajoute également une charge importante à toutes les requêtes de recherche.

Résolvez toutes les erreurs de délai d'expiration de la passerelle 504

Dans les journaux des applications de votre cluster OpenSearch Service, vous pouvez voir des codes d'erreur HTTP spécifiques pour des demandes individuelles. Pour plus d'informations sur la résolution des erreurs de délai d'expiration de la passerelle HTTP 504, consultez Comment éviter les erreurs de délai d'expiration de la passerelle HTTP 504 dans Amazon OpenSearch Service ?

Remarque : Vous devez activer les journaux d'erreurs pour découvrir des codes d'erreur HTTP spécifiques. Pour plus d'informations sur les codes d'erreur HTTP, consultez la section Affichage des journaux d'erreurs d'Amazon OpenSearch Service.

Autres facteurs pouvant entraîner une latence de recherche élevée

Plusieurs autres facteurs peuvent entraîner une latence de recherche élevée. Suivez les conseils suivants pour mieux résoudre les problèmes de latence de recherche élevée :

  • Les activités de collecte des déchets fréquentes ou prolongées peuvent entraîner des problèmes de performances de recherche. Une activité de récupération de mémoire peut interrompre les threads de discussion et étendre la latence des recherches. Pour plus d'informations, consultez Un tas de problèmes : Gestion du segment de mémoire géré d'Amazon OpenSearch Service sur le site Web d'Elastic.
  • Les IOPS provisionnés (ou instances i3) peuvent vous aider à supprimer tout goulot d'étranglement Amazon Elastic Block Store (Amazon EBS). Dans la plupart des cas, vous n'en avez pas besoin. Avant de déplacer une instance vers i3, il est recommandé de tester les performances entre les nœuds i3 et r5.
  • Un cluster comportant trop 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 que l'augmentation du nombre de partitions de réplica puisse vous aider à accélérer les recherches, ne dépassez pas 1 000 partitions sur un nœud donné. Veillez également à ce que les tailles des partitions soient comprises entre 10 Gio et 50 Gio. Idéalement, le nombre maximum de partitions sur un nœud est heap * 20.
  • 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. Si possible, augmentez également le rafraîchissement interne sur les index actifs. Pour plus d'informations, consultez la section sur la gestion des documents supprimés par Lucene sur le site Web d'Elastic.
  • Si votre cluster se trouve dans un Virtual Private Cloud (VPC), alors il est recommandé d'exécuter vos applications au sein du même VPC.
  • Utilisez des nœuds UltraWarm ou des nœuds de données chaudes pour les données en lecture seule. Le stockage à chaud fournit les performances les plus rapides possibles pour l'indexation et la recherche 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 sur lesquels vous n'avez pas besoin d'écrire et n’exigeant pas de hautes performances, UltraWarm offre des coûts par Gio de données nettement inférieurs.
  • Déterminez si votre charge de travail bénéficie de la disponibilité des données que vous recherchez sur tous les nœuds. Certaines applications bénéficient de cette approche, notamment s'il existe peu d'indices sur votre cluster. Pour ce faire, augmentez le nombre de partitions de réplica.
    Remarque : Risque d’augmenter la latence d'indexation. En outre, il se peut que vous ayez besoin d'un espace de stockage Amazon EBS supplémentaire pour accueillir les réplica que vous ajoutez. Cela augmente vos coûts de volume EBS.
  • 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 section Optimisation de la vitesse de recherche sur le site Web d'Elastic.
  • Pour les index comportant de nombreuses partitions, utilisez un routage personnalisé pour accélérer les recherches. Le routage personnalisé vous garantit d’interroger uniquement les partitions contenant vos données au lieu de diffuser la demande à toutes les partitions. Pour plus d'informations, consultez la section Personnalisation du routage de vos documents sur le site Web d'Elastic.

Informations connexes

Alarmes CloudWatch recommandées pour Amazon OpenSearch Service

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an