Comment résoudre les problèmes d'utilisation élevée du processeur sur mon cluster OpenSearch Service ?

Brève description

Pour résoudre les problèmes d'utilisation élevée du processeur sur votre cluster, effectuez les actions suivantes :

• Utilisez un dossier d'exploitation automatique pour identifier la cause d'une utilisation élevée du processeur.
• Utilisez la détection d’anomalies pour identifier des modèles.
• Utilisez l'API threads actifs de nœuds pour comprendre l'utilisation de vos ressources.
• Vérifiez l’opération d’écriture ou le groupe de threads d'API en bloc.
• Consultez le groupe de threads de recherche.
• Vérifiez le groupe de threads de fusion Apache Lucene.
• Vérifiez la sollicitation de la mémoire de la machine virtuelle Java (JVM).
• Examinez votre stratégie de partition.
• Mettez votre cluster à l’échelle.
• Optimisez vos requêtes.

Il est recommandé de limiter l'utilisation de votre processeur à un niveau suffisant pour qu'OpenSearch Service puisse effectuer ses tâches. Un cluster dont l'utilisation du processeur est en permanence élevée peut subir des problèmes de performance. OpenSearch Service ne répond pas aux clusters surchargés et vous recevez une demande de délai d'attente.

Résolution

Utiliser un dossier d’exploitation automatique

Prérequis : Assurez-vous que vous disposez des autorisations Gestion des identités et des accès AWS (AWS IAM) requises pour exécuter le dossier d’exploitation. Pour plus d'informations, consultez la section Autorisations IAM requises de la rubrique AWSSupport-TroubleshootOpenSearchHighCPU.

Exécutez le dossier d’exploitation d’automatisation AWSSupport-TroubleshootOpenSearchHighCPU AWS Systems Manager pour résoudre les problèmes liés à l'utilisation élevée du processeur dans OpenSearch Service.

La sortie affiche les informations suivantes :

• Threads actifs.
• Tâches en cours d’exécution
• Statistiques du groupe de threads pour chaque nœud du domaine
• Informations sur les nœuds du domaine triées en fonction de leur utilisation de processeur
• Allocation de partitions à chaque nœud de données et à son espace disque
• Statut de l’état et informations sur l'état du domaine OpenSearch Service

Utilisez la sortie du dossier d’exploitation pour identifier la cause de l'utilisation élevée du processeur.

Utiliser la détection d’anomalies pour identifier des modèles

Pour identifier des problèmes potentiels avant qu'ils ne provoquent des pannes, utilisez la détection d’anomalies dans OpenSearch Service pour détecter automatiquement des modèles inhabituels dans des métriques telles que l'utilisation du processeur. Pour plus d'informations, consultez la section Didacticiel : Détecter une utilisation élevée du processeur grâce à la détection d’anomalies.

Utiliser l'API threads actifs de nœuds

Si votre cluster OpenSearch Service présente des pics d’utilisation de processeur constants, exécutez la commande suivante pour afficher les informations relatives à tous les nœuds du cluster :

GET/_nodes/hot_threads

La longueur de votre sortie dépend du nombre de nœuds exécutés dans votre cluster OpenSearch Service. Pour plus d'informations sur l'API threads actifs de nœud, consultez la page API threads actifs de nœud sur le site Web d’OpenSearch.

Exemple de sortie :

GET _nodes/hot_threads
100.0% (131ms out of 500ms) cpu usage by thread 'opensearch[abc][search][T#62]'
10/10 snapshots sharing following 10
elements sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:737)

java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:647)

java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1269)

org.opensearch.common.util.concurrent.SizeBlockingQueue.take(SizeBlockingQueue.java:162)

java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)

En outre, utilisez l'API nœuds cat pour consulter la répartition actuelle de l'utilisation des ressources. Pour consulter les nœuds dont l'utilisation du processeur est la plus élevée, exécutez la commande suivante :

GET _cat/nodes?v&s=cpu:desc

La dernière colonne de la sortie affiche le nom du nœud. Pour plus d'informations sur l'API nœuds cat, consultez la page API nœuds CAT sur le site Web d'OpenSearch.

Exécutez ensuite la commande suivante pour les nœuds dont l'utilisation du processeur est élevée :

GET _nodes/node_id/hot_threads

Remarque : Remplacez node_id par l'ID du nœud.

La sortie indique les processus OpenSearch Service du nœud qui utilisent le plus le processeur. Si la sortie affiche un thread de fusion Apache Lucene, consultez la section Vérifier le groupe de threads de fusion Apache Lucene à des fins de résolution de problèmes.

Exemple de sortie :

percentage of cpu usage by thread 'opensearch[nodeName][thread-name]'

Vérifier l'opération d'écriture ou le groupe de threads de l'API en bloc

Si vous recevez un message d'erreur « 429 », cela signifie que le cluster contient peut-être un trop grand nombre de requêtes d'index en bloc. Lorsque votre cluster présente des pics constants d’utilisation du processeur, OpenSearch Service rejette les requêtes d'index en bloc.

Le groupe de threads d’écriture gère les requêtes d'index et inclut les opérations d'API en bloc. Pour vérifier si votre domaine est sous pression en raison d'un trop grand nombre de requêtes d'index en bloc, consultez la métrique IndexingRate Amazon CloudWatch.

Si votre cluster contient un trop grand nombre de requêtes d'index en bloc, procédez comme suit :

• Réduisez le nombre de requêtes en bloc sur votre cluster.
• Réduisez la taille de chaque requête en bloc pour que vos nœuds puissent les traiter plus efficacement.
• Si vous utilisez Logstash pour charger des données vers votre cluster OpenSearch Service, réduisez la taille du lot ou le nombre d’agents.
• Si le taux d'ingestion de votre cluster ralentit, effectuez une mise à l’échelle horizontale ou verticale de votre cluster.

Vérifier le groupe de threads de recherche

Un groupe de threads de recherche qui utilise un processeur élevé indique que les requêtes de recherche surchargent votre cluster OpenSearch Service. Une seule requête de longue durée peut surcharger votre cluster. Une augmentation du nombre de requêtes effectuées par votre cluster peut également affecter votre groupe de threads de recherche.

Pour vérifier si une seule requête augmente l'utilisation de votre processeur, exécutez la commande suivante :

GET _tasks?actions=*search&detailed

L'API de gestion des tâches affiche toutes les requêtes de recherche actives qui s'exécutent sur votre cluster. Pour plus d'informations, consultez la page API d’énumération des tâches sur le site Web d'OpenSearch.

Dans la sortie, vérifiez le champ de description pour identifier la requête en cours d'exécution. Le champ running_time_in_nanos indique la durée d'exécution d'une requête.

Exemple de sortie :

{    "nodes": {
        "U4M_p_x2Rg6YqLujeInPOw": {
            "name": "U4M_p_x",
            "roles": [
                "data",
                "ingest"
            ],
            "tasks": {
                "U4M_p_x2Rg6YqLujeInPOw:53506997": {
                    "node": "U4M_p_x2Rg6YqLujeInPOw",
                    "id": 53506997,
                    "type": "transport",
                    "action": "indices:data/read/search",
                    "description": """indices[*], types[], search_type[QUERY_THEN_FETCH], source[{"size":10000,"query":{"match_all":{"boost":1.0}}}]""",
                    "start_time_in_millis": 1541423217801,
                    "running_time_in_nanos": 1549433628,
                    "cancellable": true,
                    "headers": {}
                }
            }
        }
    }
}

Remarque : Pour les tâches de recherche, la sortie de l’API de gestion des tâches inclut uniquement le champ de description.

Pour réduire l'utilisation de votre processeur, exécutez la commande suivante pour annuler la requête de recherche dont l’utilisation de processeur est élevée :

POST _tasks/U4M_p_x2Rg6YqLujeInPOw:53506997/_cancel

Remarque : Remplacez U4M_p_x2Rg6YqLujeInPOw:53506997 par votre ID de tâche.

La requête précédente marque la tâche comme étant annulée, puis libère les ressources AWS dépendantes. Si plusieurs requêtes s’exécutent sur votre cluster, utilisez la commande POST pour annuler chaque requête jusqu'à ce que votre cluster revienne à un état normal.

Pour éviter les pics d’utilisation du processeur, il est recommandé de définir une valeur de délai d'expiration dans le corps de la requête. Pour plus d'informations, consultez la page Paramètres de recherche sur le site Web d’OpenSearch. Pour vérifier que le nombre de requêtes actives a diminué, vérifiez la métrique CloudWatch SearchRate.

Remarque : Lorsque vous annulez toutes les requêtes de recherche actives dans votre cluster OpenSearch Service, des erreurs pourraient se produire du côté application client.

Vérifier le groupe de threads de fusion Apache Lucene

OpenSearch Service utilise Apache Lucene pour indexer et rechercher des documents sur votre cluster. Lorsque vous créez de nouveaux segments de partition, Apache Lucene exécute des opérations de fusion afin de réduire le nombre effectif de segments pour chaque partition et de supprimer les documents supprimés. Pour plus d'informations, consultez la page Paramètres de fusion sur le site Web d'Elastic.

Si un thread de fusion Apache Lucene affecte l'utilisation de votre processeur, exécutez la commande suivante pour augmenter le paramètre refresh_interval de vos index :

PUT /your-index-name/_settings
{
  "index": {
    "refresh_interval": "value"
  }
}

Remarque : Remplacez value par votre nouvel intervalle de requête. Cette mise à jour ralentit la création de segments de cluster. Pour plus d'informations, consultez la page API d’actualisation d’index sur le site Web d’OpenSearch.

Lorsqu'un cluster migre des index vers le stockage UltraWarm, l'utilisation de votre processeur pourrait augmenter. La migration UltraWarm utilise généralement une opération d’API de fusion forcée qui peut exiger une quantité importante de ressources du processeur. Pour plus d'informations, consultez la page API de fusion forcée sur le site Web d'OpenSearch.

Pour vérifier les migrations UltraWarm, utilisez la commande suivante :

GET _ultrawarm/migration/_status?v

Vérifier la sollicitation de la mémoire JVM

Vérifiez le pourcentage de sollicitation de la mémoire JVM par rapport au tas Java dans un nœud de cluster. Dans l'exemple de journal suivant, la JVM se situe à l’emplacement recommandé, mais le cluster est affecté par la longue durée du récupérateur de mémoire :

[2022-06-28T10:08:12,066][WARN ][o.o.m.j.JvmGcMonitorService] [515f8f06f23327e6df3aad7b2863bb1f] [gc][6447732] overhead, spent [9.3s]collecting in the last [10.2s]

Pour résoudre les problèmes de forte sollicitation de la mémoire JVM, consultez la section Comment résoudre les problèmes de forte sollicitation de la mémoire JVM sur mon cluster Amazon OpenSearch Service ?

Examiner votre stratégie de partition

En fonction de la taille du cluster, les performances de votre cluster peuvent être réduites en raison d'un trop grand nombre de partitions. Il est recommandé de n’utiliser qu’un maximum de 25 partitions par Gio de tas Java.

Par défaut, OpenSearch Service a une stratégie de partition de 5:1, où chaque index comporte cinq partitions principales. Au sein de chaque index, chaque partition principale utilise son propre réplica. OpenSearch Service attribue automatiquement les partitions principales et les partitions de réplicas à des nœuds de données distincts, puis met une sauvegarde en place en cas de défaillance.

Pour redistribuer vos partitions, consultez la section Comment puis-je rééquilibrer la distribution inégale des partitions dans mon cluster OpenSearch Service ?

Mettre le cluster à l’échelle

Assurez-vous que le cluster dispose d’une capacité de processeur, d’une mémoire et d'un espace disque suffisants pour répondre à vos besoins. Si votre application effectue des requêtes volumineuses ou des écritures fréquentes, redimensionnez votre cluster ou vos nœuds pour répondre aux exigences de performance.

Utilisez également des nœuds principaux dédiés pour améliorer la stabilité et la résilience du cluster, en particulier dans les déploiements plus vastes. Cette configuration supprime les responsabilités de gestion du cluster à partir des nœuds de données.

Optimiser vos requêtes

Les agrégations complexes, les requêtes contenant des caractères génériques, telles que les caractères génériques principaux et les requêtes d’expression régulière (regex) peuvent entraîner des pics d'utilisation du processeur. Pour diagnostiquer ces requêtes, consultez vos journaux lents d'OpenSearch.

Informations connexes

Comment améliorer les performances d'indexation sur mon cluster OpenSearch Service ?

Comment puis-je résoudre les refus de recherche ou d'écriture dans OpenSearch Service ?

Dimensionnement des domaines d'OpenSearch Service