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

Lecture de 8 minute(s)
0

Mes nœuds de données affichent une utilisation intense du processeur sur mon cluster Amazon OpenSearch Service.

Brève description

Il est recommandé de maintenir l'utilisation de votre processeur pour vous assurer qu'OpenSearch Service dispose de suffisamment de ressources pour effectuer ses tâches. Un cluster qui fonctionne systématiquement avec un taux d'utilisation élevé du processeur risque une dégradation de ses performances. Lorsque votre cluster est surchargé, OpenSearch Service cesse de répondre, ce qui entraîne une demande de délai d'expiration.

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

  • Utilisez l’API des threads actifs de nœuds.
  • Vérifiez l'opération d'écriture ou le groupe de threads d'API en bloc.
  • Consultez le groupe threads de recherche.
  • Consultez le groupe de threads de fusion Apache Lucene.
  • Vérifiez la pression de la mémoire JVM.
  • Révisez votre stratégie de partitionnement.
  • Optimisez vos requêtes.

Résolution

Utiliser l'API des threads actifs de nœuds

Si vous observez des pics constants d’utilisation de processeur dans votre cluster OpenSearch Service, utilisez l'API de threads actifs de nœuds. L'API** de threads actifs** fait office de gestionnaire de tâches et affiche la répartition de tous les threads gourmands en ressources qui s'exécutent sur votre cluster.

Exemple de sortie de l'API de threads actifs de nœuds :

GET _nodes/hot_threads

100.0% (131ms out of 500ms) cpu usage by thread 'opensearch[xxx][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)

Remarque : La sortie des threads actifs de nœuds répertorie les informations relatives à chaque nœud. La longueur de votre sortie dépend du nombre de nœuds exécutés dans votre cluster OpenSearch Service.

En outre, utilisez l'API Cat Nodes pour consulter la répartition actuelle de l'utilisation des ressources. Vous pouvez affiner le sous-ensemble de nœuds présentant le taux d'utilisation du processeur le plus élevé à l'aide de la commande suivante :

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

La dernière colonne de votre sortie affiche le nom de votre nœud. Pour plus d'informations, consultez l'API Cat Nodes sur le site Web d'Elasticsearch.

Transmettez ensuite le nom du nœud correspondant à l’API de vos threads actifs :

GET _nodes/<node-name>/hot_threads

Pour plus d'informations, consultez l'API threads actifs sur le site Web d'Elasticsearch.

Exemple de sortie de threads actifs de nœuds :

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

Le nom du thread indique quels processus OpenSearch Service utilisent intensément le processeur.

Pour plus d'informations, consultez l'API des threads actifs de nœuds sur le site Web d'Elasticsearch.

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

Une erreur 429 dans OpenSearch Service peut indiquer que votre cluster gère trop de demandes d'indexation groupées. Lorsqu'il y a des pics constants de consommation des ressources du processeur dans votre cluster, OpenSearch Service rejette les demandes d'indexation groupées.

Le groupe de threads d'écriture gère les demandes d'indexation incluant les opérations d'API en bloc. Pour vérifier si votre cluster gère trop de demandes d'indexation en bloc, vérifiez la métrique IndexingRate dans Amazon CloudWatch.

Si votre cluster gère un trop grand nombre de demandes d'indexation en bloc, envisagez les approches suivantes :

  • Réduisez le nombre de demandes groupées sur votre cluster.
  • Réduisez la taille de chaque demande groupée pour que vos nœuds puissent les traiter plus efficacement.
  • Si Logstash est utilisé pour transférer des données vers votre cluster OpenSearch Service, réduisez la taille du lot ou le nombre de travailleurs.
  • Si le taux d'ingestion de votre cluster ralentit, redimensionnez-le (soit horizontalement, soit verticalement). Pour augmenter votre cluster, augmentez le nombre de nœuds et le type d'instance pour que OpenSearch Service puisse traiter les demandes entrantes.

Pour plus d'informations, consultez API en bloc sur le site Web d'Elasticsearch.

Vérifiez le groupe de threads de recherche

Un groupe de threads de recherche consommant beaucoup de ressources du processeur indique que les requêtes de recherche submergent votre cluster OpenSearch Service. Votre cluster peut être submergé par une seule requête de longue durée. 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 votre utilisation du processeur, utilisez l'API de gestion des tâches. Par exemple :

GET _tasks?actions=*search&detailed

L'API de gestion des tâches obtient toutes les requêtes de recherche actives qui s'exécutent sur votre cluster. Pour plus d'informations, consultez l'API de gestion des tâches sur le site Web d'Elasticsearch.

**Remarque **: La sortie n’inclut le champ de description que si une tâche de recherche est répertoriée par l'API de gestion des tâches.

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": {}
                }
            }
        }
    }
}

Vérifiez le champ de description pour déterminer la requête exécutée. Le champ running \ _time \ _in \ _nanos indique la durée d’exécution d’une requête. Pour réduire l'utilisation de votre processeur, annulez la requête de recherche qui sollicite intensément le processeur. L'API de gestion des tâchesprend également en charge un appel \ _cancel.

Remarque : Assurez-vous d'enregistrer l'ID de la tâche à partir de votre sortie pour annuler une tâche particulière. Dans cet exemple, l'ID de tâche est « U4M_p_x2Rg6YqLujeInPOw:53506997 ».

Exemple d'appel POST de gestion des tâches :

POST _tasks/U4M_p_x2Rg6YqLujeInPOw:53506997/_cancel

L'appel POST de gestion des tâches marque la tâche comme « annulée », libérant ainsi toutes les ressources AWS dépendantes. Si plusieurs requêtes s'exécutent sur votre cluster, utilisez l'appel POST pour annuler les requêtes une par une. Annulez chaque requête jusqu'à ce que votre cluster revienne à un état normal. Il est également recommandé de définir une valeur de délai d'expiration dans le corps de la requête, afin d'éviter les pics de consommation du processeur. Pour plus d'informations, consultez la section Paramètres de recherche du corps de requête sur le site Web d'Elasticsearch. Pour vérifier si le nombre de requêtes actives a diminué, consultez la métrique SearchRate dans Amazon CloudWatch.

Remarque : L'annulation simultanée de toutes les requêtes de recherche actives dans votre cluster OpenSearch Service peut provoquer des erreurs du côté de l'application cliente.

Pour plus d'informations, consultez la section Groupe de threads sur le site Web d'Elasticsearch.

Vérifiez le groupe de threads de fusion Apache Lucene

OpenSearch Service utilise Apache Lucene pour indexer et rechercher des documents sur votre cluster. Apache Lucene exécute des opérations de fusion afin de réduire le nombre effectif de segments nécessaires pour chaque partition et d’effacer les documents supprimés. Ce processus est exécuté chaque fois que de nouveaux segments sont créés dans une partition.

Si vous constatez qu'une opération de fusion de threads Apache Lucene a un impact sur l'utilisation du processeur, augmentez les paramètres refresh \ _interval de vos index de cluster OpenSearch Service. L'augmentation du paramètre refresh \ _interval ralentit la création de segments de votre cluster.

**Remarque **: Un cluster qui fait migrer des index vers le stockage UltraWarm peut augmenter l'utilisation de votre processeur. La migration UltraWarm implique généralement une opération de fusion forcée de l'API, qui peut solliciter intensément le processeur.

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

GET _ultrawarm/migration/_status?v

Pour plus d'informations, consultez la section Fusionner sur le site Web d'Elasticsearch.

Vérifiez l’utilisation de la mémoire JVM

Vérifiez le pourcentage de pression de votre mémoire JVM par rapport au tas Java d'un nœud de cluster. Si la sollicitation de la mémoire JVM atteint 75 %, Amazon OpenSearch Service déclenche le récupérateur de mémoire Concurrent Mark Sweep (CMS). Si la sollicitation de la mémoire JVM atteint 100 %, la JVM d'OpenSearch Service est configurée pour s’arrêter et redémarrer probablement sur OutOfMemory (OOM).

Dans l'exemple de journal suivant, la JVM se situe à l’emplacement recommandé, mais le cluster est affecté par la longue durée de la collecte des déchets :

[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 plus d'informations, consultez la section Comment résoudre les problèmes de forte sollicitation de mémoire JVM sur mon cluster Amazon OpenSearch Service ?

Révisez votre stratégie de partitionnement

Selon la taille du cluster, ses performances peuvent se dégrader s’il y a un trop grand nombre de partitions. Il est recommandé de ne pas disposer de plus de 25 partitions par GiB de tas Java.

Par défaut, Amazon OpenSearch Service applique une stratégie de partitionnement de 5:1, chaque index est divisé en cinq partitions principales. Au sein de chaque index, chaque partition principale possède sa propre réplication. OpenSearch Service attribue automatiquement les partitions principales et les partitions de réplication à des nœuds de données distincts, puis veille à ce qu'il existe une sauvegarde en cas de panne.

Pour plus d'informations, consultez la section Comment rééquilibrer la distribution inégale des partitions dans mon cluster Amazon OpenSearch Service ?

Optimisez vos requêtes

Les agrégations volumineuses, les requêtes génériques (en particulier les principaux caractères génériques) et les requêtes regex peuvent être coûteuses en ressources informatiques et provoquer des pics d'utilisation du processeur. La recherche et l'indexation des journaux lents peuvent vous aider à diagnostiquer les requêtes coûteuses et problématiques.

Pour plus d'informations, consultez la section Surveillance des journaux OpenSearch avec Amazon CloudWatch Logs.

Informations connexes

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

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

Dimensionnement des domaines Amazon OpenSearch Service

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