Comment puis-je résoudre les problèmes de pics de latence de recherche dans mon cluster Amazon OpenSearch Service ?

Date de la dernière mise à jour : 05/08/2021

Je rencontre des problèmes de pics de latence de recherche dans mon cluster Amazon OpenSearch Service. Comment puis-je dépanner et résoudre les problèmes de pics de latence de recherche ?

Brève description

Pour les requêtes de recherche, le temps de transmission aller-retour est calculé comme suit :

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

La métrique SearchLatency sur Amazon CloudWatch vous indique le temps passé par la requête dans la phase de requête.

Il existe plusieurs étapes de dépannage à suivre pour résoudre les problèmes de recherche de pics de latence dans votre cluster OpenSearch Service, notamment :

  • Vérifier si les ressources allouées sur le cluster sont insuffisantes
  • Rechercher les rejets de recherche à l'aide de la métrique ThreadpoolSearchRejected dans CloudWatch
  • Utiliser les journaux lents de recherche et l'API de profil
  • Résoudre les erreurs d'expiration de délai de passerelle 504

Résolution

Vérifier si les ressources allouées sur le cluster sont insuffisantes

Vous pouvez rencontrer des problèmes de pics de latence de recherche si les ressources allouées sur votre cluster sont insuffisantes. Utilisez les bonnes pratiques suivantes pour vous assurer que vous disposez de ressources suffisantes allouées.

1.    Examinez la métrique CPUUtilization et la pression JVMMemory du cluster à l'aide d'Amazon CloudWatch pour vérifier qu'elles se situent dans les seuils recommandés. Pour plus d'informations, veuillez consulter la rubrique Alarmes CloudWatch recommandées.

2.    Utilisez l'API Node Stats pour obtenir des statistiques au niveau du nœud sur votre cluster :

GET /_nodes/stats

Dans la sortie, vérifiez les sections suivantes : caches, fielddata et jvm. Exécutez cette API plusieurs fois avec un certain délai pour comparer les sorties.

3.    OpenSearch Service utilise le cache du système de fichiers pour accélérer les requêtes de recherche. Vérifiez la sortie de l'API NodeStats 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 requête. Dans ce cas, envisagez d'utiliser des nœuds plus grands avec plus de mémoire.

4.    L'exécution d'agrégations sur des champs contenant des valeurs hautement uniques peut entraîner une augmentation de l'utilisation du heap. Si des requêtes d'agrégation sont déjà utilisées, les opérations de recherche utilisent FieldData. FieldData permet également de trier et d'accéder aux valeurs de champ dans le script. Les expulsions FieldData dépendent de la taille du fichier indices.fielddata.cache.size, qui représente 20 % de l'espace de heap JVM. Les expulsions démarrent lorsque la taille du cache est dépassée.

Pour plus d'informations sur le dépannage de la mémoire JVM élevée, veuillez consulter la rubrique Comment puis-je résoudre les problèmes liés à une forte sollicitation de la mémoire JVM dans un cluster Amazon OpenSearch Service ?

Pour résoudre les problèmes d'utilisation élevée du CPU, veuillez consulter la rubrique Comment résoudre les problèmes d'utilisation élevée du processeur sur mon cluster Amazon OpenSearch Service ?

Rechercher les rejets de recherche à l'aide de la métrique ThreadpoolSearchRejected dans CloudWatch

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

Utilisez Rechercher des journaux lents pour identifier les requêtes longues

Utilisez les journaux lents pour identifier à la fois les requêtes longues et le temps passé par une requête sur une partition spécifique. 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 lents, consultez Viewing Amazon Elasticsearch Service Slow Logs. Veillez à définir "profile":true pour que votre requête de recherche obtienne une répartition détaillée du temps passé par votre requête dans la phase de requête.

Remarque : si vous définissez le seuil de journalisation sur une valeur très faible, la pression de la mémoire JVM peut augmenter. Cela peut entraîner un nettoyage plus fréquent de la mémoire, ce qui augmente ensuite l'utilisation du CPU ainsi que la latence au niveau du cluster. La journalisation d'un plus grand nombre de requêtes peut également augmenter vos coûts. La sortie de l'API de profil peut être longue et ajouter ainsi une surcharge importante à l'exécution des requêtes de recherche.

Résoudre les erreurs 504 Expiration de la passerelle

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 HTTP 504 d'expiration de la passerelle, veuillez consulter la rubrique Comment puis-je éviter des erreurs de dépassement de délai de passerelle HTTP 504 dans Amazon OpenSearch Service ?

Remarque : vous devez activer les journaux d'erreurs pour identifier des codes d'erreur HTTP spécifiques. Pour plus d'informations sur les codes d'erreur HTTP, veuillez consulter la rubrique Affichage des journaux d'erreurs Amazon ES.

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

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

  • Une activité de nettoyage de mémoire fréquente ou longue peut entraîner des problèmes de performances de recherche. Une activité de récupération de la mémoire peut interrompre les threads et augmenter la latence de recherche. Pour plus d'informations, veuillez consulter la rubrique Managing Elasticsearch's managed heap (Gestion du heap géré d'Elasticsearch) sur le site Web Elasticsearch.
  • 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 aurez pas besoin. Il est recommandé de tester les performances entre les nœuds i3 et les nœuds r5 avant de passer directement à i3.
  • Un cluster avec trop de partitions peut entraîner une augmentation de l'utilisation des ressources, même lorsque le cluster est inactif. Un trop grand nombre de fragments ralentit les performances des requêtes. Bien que l'augmentation du nombre de partitions de réplica puisse vous aider à effectuer des recherches plus rapides, veillez à ne pas aller au-delà de 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 maximal de partitions sur un nœud doit être heap * 20.
  • Trop de segments ou trop de documents supprimés peuvent affecter les performances de recherche. Dans ce cas, l'utilisation de la fusion forcée sur des index en lecture seule peut aider. Si votre cas d'utilisation le permet, augmentez l'actualisation interne sur les index actifs. Pour plus d'informations, veuillez consulter la rubrique Traitement des documents supprimés par Lucene sur le site Web Elasticsearch.
  • Si votre cluster est dans un VPC, envisagez d'exécuter vos applications dans le même VPC.
  • Pensez à utiliser des nœuds UltraWarm ou des nœuds de données chauds pour les données en lecture seule. Le stockage chaud offre les performances les plus rapides possibles pour l'indexation et la recherche de nouvelles données. Toutefois, les nœuds UltraWarm constituent un moyen économique de stocker de grandes quantités de données en lecture seule sur votre cluster. Pour les index sur lesquels vous n'écrivez pas activement et desquels vous n'attendez pas les mêmes performances, UltraWarm offre des coûts par Gio de données significativement inférieurs.
  • Testez votre charge de travail pour voir si les données que vous recherchez sont disponibles sur tous les nœuds. Certaines applications bénéficient de cette approche, en particulier si votre cluster compte peu d'index. Pour ce faire, augmentez le nombre de partitions de réplica. Gardez à l'esprit que cela peut 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éplicas que vous ajoutez. Cela augmentera vos coûts de volume EBS.
  • Recherchez le moins de champs possible, évitez les scripts et les requêtes génériques. Pour plus d'informations, veuillez consulter la rubrique Réglage de la vitesse de recherche sur le site Web Elasticsearch.
  • Pour les index comportant de nombreuses partitions, vous pouvez utiliser le routage personnalisé pour accélérer les recherches. Le routage personnalisé garantit que seules les partitions contenant vos données sont interrogées, au lieu de diffuser la requête à toutes les partitions de l'index. Pour plus d'informations, consultez Personnalisation du routage de vos documents sur le site Web Elasticsearch.

Amazon OpenSearch Service est le successeur d'Amazon Elasticsearch Service.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?