Dépanner une utilisation élevée du processeur sur une instance ApsaraDB for MongoDB - ApsaraDB for MongoDB

Une utilisation élevée du processeur sur une instance ApsaraDB for MongoDB, atteignant parfois 100 %, ralentit les opérations de lecture et d'écriture et perturbe vos activités. Suivez les étapes de diagnostic ci-dessous pour identifier et résoudre la cause première du problème.

Vérifier les opérations en cours

Connectez-vous à l'instance via le shell mongo. La procédure de connexion varie selon l'architecture de l'instance :

Se connecter à une instance autonome à l'aide du shell mongo

Exécutez db.currentOp() pour lister toutes les opérations en cours sur l'instance :

db.currentOp()

Exemple de sortie :

{
    "desc" : "conn632530",
    "threadId" : "140298196924160",
    "connectionId" : 632530,
    "client" : "11.xxx.xxx.236:57052",
    "active" : true,
    "opid" : 1008837885,
    "secs_running" : 0,
    "microsecs_running" : NumberLong(70),
    "op" : "update",
    "ns" : "mygame.players",
    "query" : {
        "uid" : NumberLong(31577677)
    },
    "numYields" : 0,
    "locks" : {
        "Global" : "w",
        "Database" : "w",
        "Collection" : "w"
    },
    ....
}

Examinez les champs suivants pour identifier les opérations problématiques :

Champ

Description

Quand agir

client

Client ayant envoyé la requête

Utilisez cette information pour retrouver la source de la requête

opid

ID unique de l'opération

Exécutez db.killOp(opid) pour arrêter l'opération si nécessaire

secs_running

Durée d'exécution de l'opération, en secondes

Examinez les opérations dont la valeur est anormalement élevée

microsecs_running

Durée d'exécution de l'opération, en microsecondes

Examinez les opérations dont la valeur est anormalement élevée

ns

Namespace (collection) analysé

Croisez ces données avec les journaux de requêtes lentes pour identifier les collections sollicitées

op

Type d'opération : query, insert, update ou delete

—

locks

Informations sur les verrous associés à l'opération

Consultez la FAQ : Concurrence

Pour plus d'informations sur db.currentOp(), consultez la documentation db.currentOp().

Les pics d'utilisation du processeur sont souvent causés par des opérations de maintenance, telles qu'une analyse complète d'une collection, qui s'exécutent simultanément à votre charge de travail habituelle. Si db.currentOp() affiche une opération avec une valeur secs_running anormalement élevée et inattendue, arrêtez-la :

db.killOp(<opid>)

Remplacez <opid> par la valeur du champ opid issue de la sortie de db.currentOp(). Pour plus d'informations, consultez la documentation db.killOp().

Analyser les journaux de requêtes lentes

Si l'utilisation du processeur augmente dès le démarrage de votre application et reste élevée, mais que db.currentOp() ne montre aucune opération manifestement problématique, la cause réside probablement dans un motif de requêtes lentes qui s'accumulent au fil du temps.

Consultez les journaux de requêtes lentes dans la console ApsaraDB for MongoDB. Pour plus d'informations, consultez Afficher les journaux de requêtes lentes.

Voici un exemple d'entrée de journal de requête lente :

{
  "atype": "slowOp",
  "param": {
    "op": "query",
    "ns": "abbott_analysis.uaidScanInfo",
    "query": {
      "find": "uaidScanInfo",
      "filter": {
        "dateType": 2,
        "companyCode": "GMP"
      },
      "ntoreturn": -1,
      "sort": {
        "scanDateTime": -1
      }
    },
    "keysExamined": 0,
    "docsExamined": 2181021,
    "hasSortStage": true,
    "cursorExhausted": true,
    "numYield": 17059,
    "locks": { ... },
    "nreturned": 0,
    "responseLength": 20,
    "millis": 4878,
    "planSummary": "COLLSCAN"
  },
  "result": "OK"
}

Recherchez les motifs suivants dans les journaux de requêtes lentes :

Analyses complètes de collection (`COLLSCAN`, `docsExamined`)

La mention planSummary: COLLSCAN indique que la requête a analysé l'intégralité de la collection sans utiliser d'index. Le champ docsExamined révèle le nombre de documents examinés : plus ce chiffre est élevé, plus la requête consomme de ressources processeur.

Créez un index sur les champs interrogés pour corriger ce problème :

db.<collection>.createIndex({ <field>: 1 })

Index inefficaces (`IXSCAN`, `keysExamined`)

Lorsqu'une requête utilise un index, le champ planSummary affiche IXSCAN. Le champ keysExamined indique le nombre de clés d'index examinées. Plus cette valeur est importante, plus la requête mobilise de ressources processeur.

Exemple de sélectivité d'index

Prenons une collection où le champ x ne peut prendre que deux valeurs (1 ou 2), tandis que le champ y couvre une plage beaucoup plus large (1 à 100000). Pour la requête { x: 1, y: 2 } :

{ x: 1, y: 1 }
{ x: 1, y: 2 }
...
{ x: 1, y: 100000 }
{ x: 2, y: 1 }
...

Index

Sélectivité

Raison

db.createIndex({ x: 1 })

Faible

La moitié de la collection partage la même valeur x

db.createIndex({ x: 1, y: 1 })

Faible

Le premier champ x présente toujours une faible sélectivité

db.createIndex({ y: 1 })

Bonne

y couvre une large plage — peu de documents partagent la même valeur

db.createIndex({ y: 1, x: 1 })

Bonne

Le premier champ y élimine immédiatement la majorité des documents

Indexez en priorité le champ offrant la meilleure sélectivité. Pour plus d'informations, consultez la documentation Index composés.

Un nombre excessif d'index nuit aux performances d'écriture et de mise à jour. Si votre application génère un volume important d'opérations d'écriture et utilise des index, ses performances peuvent se dégrader. Auditez et supprimez les index inutilisés si vous constatez également une baisse des performances en écriture.

Tri en mémoire (`SORT`, `hasSortStage`)

La mention hasSortStage: true signifie que l'instance a trié les résultats de la requête en mémoire, car aucun index ne pouvait satisfaire l'ordre de tri demandé. Les tris en mémoire appliqués à de grands ensembles de résultats consomment considérablement le processeur.

Si les journaux de requêtes lentes contiennent le mot-clé SORT, créez un index sur les champs utilisés dans la clause de tri :

db.<collection>.createIndex({ <sort-field>: 1 })

Autres opérations gourmandes en processeur

La création d'index et les pipelines aggregation (qui combinent parcours, filtrage, mises à jour et tri) peuvent également entraîner une forte utilisation du processeur. Appliquez la même approche diagnostique : vérifiez les champs docsExamined, keysExamined, hasSortStage et planSummary dans les journaux de requêtes lentes.

Évaluer la capacité du service

Si toutes les requêtes utilisent des index appropriés et que l'utilisation du processeur reste élevée, il est possible que l'instance ait atteint sa limite de capacité.

Examinez les données de surveillance pour comprendre vos schémas d'utilisation des ressources. Pour plus d'informations, consultez Afficher les données de surveillance et Surveillance des nœuds (précédemment surveillance de base).
Testez votre base de données MongoDB afin de déterminer si l'instance actuelle offre les performances et la capacité de service nécessaires à votre charge de travail.

Si vous devez mettre à niveau l'instance, consultez Modifier la configuration d'une instance ou Modifier le nombre de nœuds d'un replica set.

Référence rapide

Commande

Objectif

db.currentOp()

Lister toutes les opérations en cours sur l'instance

db.killOp(<opid>)

Arrêter une opération spécifique via son ID

Afficher les journaux de requêtes lentes dans la console

Identifier les requêtes lentes sans se connecter à l'instance