Comment puis-je résoudre les problèmes de taux d'utilisation élevé du processeur sur mon cluster Amazon OpenSearch Service ?

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

Mes nœuds de données affichent un taux d'utilisation élevé du processeur sur mon cluster Amazon OpenSearch Service (successeur d'Amazon Elasticsearch Service). Comment puis-je y remédier ?

Brève description

Une bonne pratique consiste à maintenir l'utilisation de votre processeur afin de s'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 requête d'expiration.

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

  • Utilisez l'API des threads chauds des nœuds. (Pour plus d'informations, consultez API des threads chauds des nœuds sur le site Web Elasticsearch.)
  • Vérifiez l'opération d'écriture ou le groupe de threads d'API en bloc. (Pour plus d'informations, consultez API en bloc sur le site Web Elasticsearch.)
  • Vérifiez le groupe de threads de recherche. (Pour plus d'informations, consultez Groupes de threads sur le site Web Elasticsearch.)
  • Vérifiez le groupe de threads de fusion Apache Lucene. (Pour plus d'informations, consultez Fusion sur le site Web Elasticsearch.)

Solution

Utiliser l'API des threads chauds des nœuds

Si vous observez des pics constants d'utilisation du CPU dans votre cluster OpenSearch Service, utilisez l'API Threads chauds des nœuds. L'API des threads chauds des nœuds agit comme gestionnaire de tâches, vous montrant la distribution de tous les threads gourmands en ressources qui s'exécutent sur votre cluster.

Voici un exemple de sortie de l'API des threads chauds des 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 chauds des nœuds répertorie les informations pour chaque nœud. La longueur de votre sortie dépend du nombre de nœuds exécutés dans votre cluster OpenSearch Service.

De plus, utilisez l'API cat nodes pour afficher la distribution actuelle de l'utilisation des ressources. Vous pouvez restreindre le sous-ensemble de nœuds avec l'utilisation de l'UC la plus élevée avec 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 API des nœuds cat sur le site Web d'Elasticsearch.

Ensuite, transmettez le nom de nœud pertinent à votre API de threads chauds :

GET _nodes/<node-name>/hot_threads

Pour plus d'informations, consultez API des threads chauds sur le site Web Elasticsearch.

La sortie des threads chauds des nœuds ressemble à ce qui suit :

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

Le nom du thread indique quels processus OpenSearch Service consomment beaucoup de ressources de CPU.

Vérifiez l'opération d'écriture ou le groupe de threads d'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 CPU dans votre cluster, OpenSearch Service rejette les demandes d'indexation groupées.

Le groupe de threads en écriture gère les demandes d'indexation, qui incluent les opérations d'API groupées. Pour vérifier si votre cluster gère trop de requêtes d'indexation groupées, contrôlez la métrique IndexingRate dans Amazon CloudWatch.

Si votre cluster gère trop de demandes d'indexation groupées, envisagez les approches suivantes :

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

Vérifier le groupe de threads de recherche

Un groupe de threads de recherche qui consomme beaucoup de ressources de CPU indique que les requêtes de recherche dominent votre cluster OpenSearch Service. Votre cluster peut être dominé par une seule requête de longue durée. Une augmentation du nombre de requêtes exécuté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 récupère toutes les requêtes de recherche actives exécutées sur votre cluster. Pour plus d'informations, consultez API de gestion des tâches sur le site web d'Elasticsearch.

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

Cochez le champ de description pour identifier quelle requête particulière est en cours d'exécution. Le champ running_time_in_nanos indique la durée pendant laquelle une requête a été exécutée. Pour réduire votre utilisation de l'UC, annulez la requête de recherche qui consomme beaucoup de processeur. L'API de gestion des tâches prend également en charge un appel _cancel.

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

Voici un 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 toutes les ressources AWS dépendantes. Si plusieurs requêtes sont exécutées sur votre cluster, utilisez l'appel POST pour annuler les requêtes une à la fois. Annulez chaque requête jusqu'à ce que votre cluster retrouve un état normal. Une bonne pratique consiste également à définir une valeur de délai d'expiration appropriée dans le corps de la requête, afin d'éviter des pics de consommation des ressources du CPU. (Pour plus d'informations, consultez Demander des paramètres de recherche de corps sur le site Web Elasticsearch.) Pour vérifier si le nombre de requêtes actives a diminué, vérifiez 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 entraîner des erreurs du côté de l'application cliente.

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 pour réduire le nombre effectif de segments nécessaires pour chaque partition et pour effacer tous 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 thread de fusion Apache Lucene a un impact sur l'utilisation du processeur, augmentez le paramètre 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 migre des index vers un stockage UltraWarm peut augmenter votre utilisation du CPU. Une migration UltraWarm implique généralement une opération d'API de fusion forcée qui peut nécessiter une utilisation intensive du CPU.

Pour rechercher des migrations UltraWarm, utilisez la commande suivante :

GET _ultrawarm/migration/_status?v