Performances et utilisation des ressources - Amazon DocumentDB
Afficher les statistiques d'insertion, de mise à jour et de suppressionAnalyser les performances du cacheRechercher les requêtes de longue durée ou bloquéesAffichage d'un plan de requête et optimisation d'une requêteComment puis-je voir un plan de requête dans des clusters élastiques ?Quelle est la marche à suivre pour répertorier toutes les opérations en cours d'exécution sur une instance ?Savoir quand une requête progresseDéterminer pourquoi un système s'exécute lentement soudainementDétermination de la cause d'une utilisation élevée de l'UCRechercher les curseurs ouverts sur une instanceAfficher la version actuelle du moteur Amazon DocumentDBAnalyser l'utilisation des index et identifier les index inutilisésIdentifier les index manquésRésumé des requêtes utiles

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Performances et utilisation des ressources

Cette section fournit des questions et des solutions aux problèmes de diagnostic courants liés aux déploiements Amazon DocumentDB. Les exemples fournis utilisent le shell mongo et sont limités à une instance individuelle. Pour rechercher un point de terminaison d'instance, consultez Comprendre les points de terminaison Amazon DocumentDB.

Comment puis-je déterminer le nombre d'opérations d'insertion, de mise à jour et de suppression effectuées sur ma collection via l'API Mongo ?

Pour afficher le nombre d'opérations d'insertion, de mise à jour et de suppression effectuées sur une collection donnée, exécutez la commande suivante sur cette collection :

db.collection.stats()

Le résultat de cette commande décrit ce qui suit dans son opCounters champ :

  • numDocsIns- Le nombre de documents insérés dans cette collection. Cela inclut les documents insérés à l'aide insert des insertMany commandes et, ainsi que les documents insérés par un upsert.

  • numDocsUpd- Le nombre de documents mis à jour dans cette collection. Cela inclut les documents mis à jour à l'aide update des findAndModify commandes et.

  • numDocsDel- Le nombre de documents supprimés de cette collection. Cela inclut les documents supprimés à l'aide des findAndModify commandes deleteOne deleteManyremove,, et.

  • LastReset : heure à laquelle ces compteurs ont été réinitialisés pour la dernière fois. Les statistiques fournies par cette commande sont réinitialisées lors du démarrage/arrêt du cluster ou lors de la redimensionnement/réduction de l'instance.

Un exemple de résultat de l'exécution db.collection.stats() est présenté ci-dessous.

{
    "ns" : "db.test",
    "count" : ...,
    "size" : ...,
    "avgObjSize" : ...,
    "storageSize" : ...,
    "capped" : false,
    "nindexes" : ...,
    "totalIndexSize" : ...,
    "indexSizes" : {
        "_id_" : ...,
        "x_1" : ...
    },
    "collScans" : ...,
    "idxScans" : ...,
    "opCounter" : {
        "numDocsIns" : ...,
        "numDocsUpd" : ...,
        "numDocsDel" : ...
    },
    "cacheStats" : {
        "collBlksHit" : ...,
        "collBlksRead" : ..,
        "collHitRatio" : ...,
        "idxBlksHit" : ...,
        "idxBlksRead" : ...,
        "idxHitRatio" : ...
    },
    "lastReset" : "2022-09-02 19:41:40.471473+00",
    "ok" : 1,
    "operationTime" : Timestamp(1662159707, 1)
}

Cette commande de statistiques doit être utilisée lors de l'affichage des compteurs spécifiques à une collection pour les opérations d'insertion, de mise à jour et de suppression via l'API Mongo. Vous pouvez également consulter les compteurs d'opérations spécifiques à une collection en activant l'audit DML. Le nombre d'opérations d'insertion, de mise à jour et de suppression effectuées sur toutes les collections pendant des intervalles d'une minute peut être visualisé dansSurveillance d'Amazon DocumentDB avec CloudWatch.

Comment analyser les performances du cache ?

L'analyse des performances du cache peut donner un aperçu de l'efficacité de la récupération des données et des performances du système. Elle est basée sur la quantité de données lues sur le disque par rapport au cache. Nous fournissons des statistiques sur le cache concernant le nombre d'accès au cache (données lues dans le cache) et de défaillances du cache (données introuvables dans le cache et lues sur le disque) afin de donner un aperçu des performances du cache. Les statistiques de cache d'une collection spécifique peuvent être trouvées en exécutant la commande suivante sur cette collection :

db.collection.stats()

Les valeurs du cacheStats champ en sortie de cette commande fournissent des statistiques de cache pour la collection ainsi que les statistiques de cache totales pour les index créés sur la collection. Ces statistiques sont répertoriées ci-dessous :

  • collBlksHit- Le nombre de blocs lus depuis le cache lors des opérations sur cette collection.

  • collBlksRead- Le nombre de blocs lus sur le disque (cache manquant) lors des opérations sur cette collection.

  • collHitRatio- Le taux de réussite du cache pour cette collection (100 * [collBlksHit / (collBlksHit + collBlksRead)]).

  • idxBlksHit- Le nombre de blocs lus depuis le cache pour tout index créé sur cette collection.

  • idxBlksRead- Le nombre de blocs lus sur le disque (cache manquant) pour tout index créé sur cette collection.

  • idxHitRatio- Le taux de réussite du cache pour les index créés dans cette collection (100 * [idxBlksHit / (idxBlksHit + idxBlksRead)]).

  • lastReset- Heure à laquelle ces statistiques ont été réinitialisées pour la dernière fois. Les statistiques fournies par db.collection.stats() sont réinitialisées lors du démarrage/arrêt du cluster ou lors de la redimensionnement/réduction de l'instance.

Une ventilation des idxBlksRead champs idxBlksHit et pour chaque index peut également être trouvée à l'aide de la indexStats commande. Les statistiques de cache spécifiques à l'index peuvent être trouvées en exécutant la commande suivante : 

db.collection.aggregate([{$indexStats:{}}]).pretty()

Pour chaque index, les statistiques de cache suivantes se trouvent sous le cacheStats champ :

  • blksHit- Le nombre de blocs lus depuis le cache pour cet index.

  • blksRead- Le nombre de blocs lus sur le disque pour cet index.

  • blksHitRatio- Le taux de réussite du cache arrondi à quatre décimales, calculé par100 * [blksHit / (blksHit + blksRead)].

Comment rechercher les requêtes de longue durée ou bloquées et les arrêter ?

Les requêtes utilisateur peuvent s'exécuter lentement en raison d'un plan de requête sous-optimal ou peuvent être bloquées en raison d'un conflit de ressources.

Pour rechercher les requêtes de longue durée qui ralentissent en raison d'un plan de requête sous-optimal ou les requêtes bloquées en raison d'un conflit de ressources, utilisez la commande currentOp. Vous pouvez filtrer la commande afin de réduire la liste des requêtes pertinentes à résilier. Vous devez avoir opid associé à la requête de longue durée pour pouvoir mettre fin à la requête.

La requête suivante utilise la commande currentOp pour répertorier toutes les requêtes qui sont bloquées ou en cours d'exécution pendant plus de 10 secondes.

db.adminCommand({
    aggregate: 1,
    pipeline: [
        {$currentOp: {}},
        {$match: 
            {$or: [
                {secs_running: {$gt: 10}},
                {WaitState: {$exists: true}}]}},
        {$project: {_id:0, opid: 1, secs_running: 1}}],
    cursor: {}
});

Ensuite, vous pouvez affiner la requête pour trouver le opid d'une requête en cours d'exécution pendant plus de 10 secondes et y mettre fin.

Pour rechercher et résilier une requête exécutée depuis plus de 10 secondes

  1. Recherchez l'opid de la requête.

    db.adminCommand({
    aggregate: 1,
    pipeline: [
        {$currentOp: {}},
        {$match: 
            {$or: 
                [{secs_running: {$gt: 10}},
                 {WaitState: {$exists: true}}]}}],
    cursor: {}
});

    La sortie de cette opération ressemble à ceci (format JSON).

    {
    "waitedMS" : NumberLong(0),
    "cursor" : {
        "firstBatch" : [
            {
                "opid" : 24646,
                "secs_running" : 12 
            }
        ],
        "id" : NumberLong(0),
        "ns" : "admin.$cmd"
    },
    "ok" : 1
}

  2. Résiliez la requête à l'aide de l'opération killOp.

    db.adminCommand({killOp: 1, op: 24646});

Comment puis-je consulter un plan de requête et optimiser une requête ?

Si une requête s'exécute lentement, cela peut être dû au fait que l'exécution de la requête nécessite une analyse complète de la collection pour choisir les documents pertinents. Parfois, la création d'index appropriés permet à la requête de s'exécuter plus rapidement. Pour détecter ce scénario et choisir les champs sur lesquels créer les index, utilisez la commande explain.

Note

Amazon DocumentDB émule l'API MongoDB 3.6 sur un moteur de base de données spécialement conçu qui utilise un système de stockage distribué, tolérant aux pannes et autoréparateur. Par conséquent, les plans de requête et le résultat de explain() peuvent différer entre Amazon DocumentDB et MongoDB. Les clients qui souhaitent contrôler leur plan de requête peuvent utiliser l'opérateur $hint pour appliquer la sélection d'un index préféré.

Exécutez la requête que vous souhaitez améliorer sous la commande explain comme suit.

db.runCommand({explain: {<query document>}})

Voici un exemple d'opération.

db.runCommand({explain:{
    aggregate: "sample-document",
    pipeline: [{$match: {x: {$eq: 1}}}],
    cursor: {batchSize: 1}}
});

La sortie de cette opération ressemble à ceci (format JSON).

{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "db.test",
        "winningPlan" : {
            "stage" : "COLLSCAN"
        }
    },
    "serverInfo" : {
        "host" : "...",
        "port" : ...,
        "version" : "..."
    },
    "ok" : 1
}

La sortie ci-dessus indique que l'étape $match exige d'analyser l'ensemble des collections et de vérifier si le champ "x" de chaque document est égal à 1. Si la collection comporte trop de documents, l'analyse de la collection et, donc, les performances globales de la requête seront très lentes. Ainsi, la présence de "COLLSCAN" dans la sortie de la commande explain indique que les performances de requête peuvent être améliorées en créant des index appropriés.

Dans cet exemple, la requête vérifie si le champ "x" est égal à 1 dans tous les documents. Par conséquent, la création d'un index sur le champ "x" permet à la requête d'éviter l'analyse complète de la collection et d'utiliser l'index pour renvoyer les documents pertinents plus rapidement.

Après avoir créé un index sur le champ "x", la sortie d'explain se présente comme suit.

{
    "queryPlanner" : {
         "plannerVersion" : 1,
         "namespace" : "db.test",
         "winningPlan" : {
             "stage" : "IXSCAN",
             "indexName" : "x_1",
             "direction" : "forward"
         }
    },
    "serverInfo" : {
        "host" : "...",
        "port" : ...,
        "version" : "..."
    },
    "ok" : 1
}

Ainsi, la création d'un index sur le champ "x" a permis à l'étape $match d'utiliser une analyse d'index pour réduire le nombre de documents sur lesquels le prédicat "x = 1" doit être évalué.

Pour les petites collections, le processeur de requêtes Amazon DocumentDB peut choisir de ne pas utiliser d'index si les gains de performances sont négligeables.

Comment puis-je voir un plan de requête dans des clusters élastiques ?

Pour examiner un plan de requête dans des clusters élastiques, utilisez la explain commande. Voici un exemple d'explainopération sur une requête de recherche ciblant une collection fragmentée :

db.runCommand(
   {
     explain: { find: "cities", filter: {"name": "Seoul"}}
   }
)
Note

Amazon DocumentDB émule MongoDB sur un moteur de base de données spécialement conçu. Par conséquent, les plans de requête et le résultat de explain() peuvent différer entre Amazon DocumentDB et MongoDB. Vous pouvez contrôler le plan de requête à l'aide de l'$hintopérateur pour imposer la sélection d'un index préféré.

Le résultat de cette opération peut ressembler à ce qui suit (format JSON) :

{
  "queryPlanner" : {
    "elasticPlannerVersion" : 1,
    "winningPlan" : {
      "stage" : "SINGLE_SHARD",
      "shards" : [
        {
          "plannerVersion" : 1,
          "namespace" : "population.cities",
          "winningPlan" : {
            "stage" : "SHARD_MERGE",
            "shards" : [
              {
                "shardName" : "f2cf5cfd-fe9c-40ca-b4e5-298ca0d11111",
                "plannerVersion" : 1,
                "namespace" : "population.cities",
                "winningPlan" : {
                  "stage" : "PARTITION_MERGE",
                  "inputStages" : [
                    {
                      "stage" : "COLLSCAN",
                      "partitionCount" : 21
                    }
                  ]
                }
              },
              {
                "shardName" : "8f3f80e2-f96c-446e-8e9d-aab8c7f22222",
                "plannerVersion" : 1,
                "namespace" : "population.cities",
                "winningPlan" : {
                  "stage" : "PARTITION_MERGE",
                  "inputStages" : [
                    {
                      "stage" : "COLLSCAN",
                      "partitionCount" : 21
                    }
                  ]
                }
              },
              {
                "shardName" : "32c5a06f-1b2b-4af1-8849-d7c4a033333",
                "plannerVersion" : 1,
                "namespace" : "population.cities",
                "winningPlan" : {
                  "stage" : "PARTITION_MERGE",
                  "inputStages" : [
                    {
                      "stage" : "COLLSCAN",
                      "partitionCount" : 22
                    }
                  ]
                }
              }
            ]
          },
          "shardName" : "32c5a06f-1b2b-4af1-8849-d7c4a0f3fb58"
        }
      ]
    }
  },
  "serverInfo" : {
    "host" : "example-4788267630.us-east-1.docdb-elastic.amazonaws.com:27017",
    "version" : "5.0.0"
  },
  "ok" : 1,
  "operationTime" : Timestamp(1695097923, 1)
}

La sortie précédente montre le plan de requête pour la find requête sur un cluster à trois partitions. Chaque partition possède plusieurs partitions de données qui peuvent avoir différents étages d'entrée. Dans cet exemple, un « COLLSCAN » (une analyse de collection) est exécuté sur toutes les partitions avant que les résultats ne soient fusionnés à l'étape « PARTITION_MERGE » au sein de chaque partition. Les résultats des partitions sont ensuite fusionnés à l'étape « SHARD_MERGE » avant d'être renvoyés au client.

Quelle est la marche à suivre pour répertorier toutes les opérations en cours d'exécution sur une instance ?

En tant qu'utilisateur ou utilisateur principal, vous souhaitez souvent répertorier toutes les opérations en cours d'exécution sur une instance à des fins de diagnostic et de dépannage. (Pour de plus amples informations sur la gestion des utilisateurs, veuillez consulter Gestion des utilisateurs Amazon DocumentDB.)

Avec le mongo shell, vous pouvez utiliser la requête suivante pour répertorier toutes les opérations en cours sur une instance Amazon DocumentDB.

db.adminCommand({currentOp: 1, $all: 1});

La requête renvoie la liste complète de toutes les demandes d'utilisateur et des tâches système internes en cours d'exécution sur l'instance.

La sortie de cette opération ressemble à ceci (format JSON).

{
    "inprog" : [
        {
            "desc" : "INTERNAL"
        },
        {
            "desc" : "TTLMonitor",
            "active" : false
        },
        {
            "client" : ...,
            "desc" : "Conn",
            "active" : true,
            "killPending" : false,
            "opid" : 195,
            "ns" : "admin.$cmd",
            "command" : {
                "currentOp" : 1,
                "$all" : 1
            },
            "op" : "command",
            "$db" : "admin",
            "secs_running" : 0,
            "microsecs_running" : NumberLong(68),
            "clientMetaData" : {
            "application" : {
                "name" : "MongoDB Shell"
            },
            "driver" : {
                ...
            },
            "os" : {
                ...
            }
          }
       },
       {
          "desc": "GARBAGE_COLLECTION",
          "garbageCollection": {
             "databaseName": "testdb",
             "collectionName": "testCollectionA"
          },
          "secs_running": 3,
          "microsecs_running": NumberLong(3123456)
       },
       {
          "desc": "GARBAGE_COLLECTION",
          "garbageCollection": {
             "databaseName": "testdb",
             "collectionName": "testCollectionB"
          },
          "secs_running": 4,
          "microsecs_running": NumberLong(4123456)
       }
    ],
    "ok" : 1
}

Les valeurs suivantes sont valides pour le champ "desc" :

  • INTERNAL— Tâches internes au système, telles que le nettoyage du curseur ou les tâches de nettoyage des utilisateurs obsolètes.

  • TTLMonitor— Le fil de surveillance Time to Live (TTL). Son statut d'exécution est reflété dans le champ "active".

  • GARBAGE_COLLECTION— Le fil interne du ramasse-miettes.

  • CONN— La requête de l'utilisateur.

  • CURSOR— L'opération est un curseur inactif qui attend que l'utilisateur appelle la commande « GetMore » pour obtenir le prochain lot de résultats. Dans cet état, le curseur consomme de la mémoire, mais ne consomme aucun calcul.

La sortie précédente répertorie également toutes les requêtes utilisateur en cours d'exécution dans le système. Chaque requête utilisateur s'exécute dans le contexte d'une base de données et d'une collection, et l'union de ces deux éléments représente un espace de noms. L'espace de noms de chaque requête utilisateur est disponible dans le champ "ns".

Parfois, vous devez répertorier toutes les requêtes utilisateur qui sont en cours d'exécution dans un espace de noms particulier. Par conséquent, la sortie précédente doit être filtrée sur le champ "ns". Voici un exemple de requête pour obtenir la sortie à filtrer. La requête répertorie toutes les requêtes utilisateur en cours d'exécution dans la base de données "db" et la collection "test" (c'est-à-dire, l'espace de noms "db.test").

db.adminCommand({aggregate: 1,
    pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
               {$match: {ns: {$eq: "db.test"}}}],
    cursor: {}
});

En tant qu'utilisateur principal du système, vous pouvez voir les requêtes de tous les utilisateurs ainsi que toutes les tâches internes du système. Tous les autres utilisateurs peuvent uniquement voir leurs propres requêtes.

Si le nombre total de requêtes et de tâches système internes dépasse la taille du curseur de traitement par lots par défaut, le shell mongo génère automatiquement un objet itérateur 'it' pour afficher le reste des résultats. Il continue d'exécuter la commande 'it' jusqu'à ce que tous les résultats aient été affichés.

Comment savoir si une requête progresse ?

Les requêtes utilisateurs peuvent s'exécuter lentement en raison d'un plan de requête mal adapté ou être bloquées en raison d'un conflit de ressource. Le débogage de telles requêtes est un processus en plusieurs étapes qui nécessite parfois d'exécuter la même étape plusieurs fois.

La première étape de débogage consiste à répertorier toutes les requêtes de longue durée ou bloquées. La requête suivante répertorie toutes les requêtes utilisateur qui ont été exécutées depuis plus de 10 secondes ou qui attendent des ressources.

db.adminCommand({aggregate: 1,
                 pipeline: [{$currentOp: {}},
                            {$match: {$or: [{secs_running: {$gt: 10}},
                                            {WaitState: {$exists: true}}]}},
                            {$project: {_id:0,
                                        opid: 1,
                                        secs_running: 1,
                                        WaitState: 1,
                                        blockedOn: 1,
                                        command: 1}}],
                 cursor: {}
                });

Répétez régulièrement la requête précédente pour déterminer si la liste des requêtes change et pour identifier les requêtes de longue durée ou bloquées.

Si le document de sortie pour la requête pertinente a un champ WaitState, cela indique que la requête s'exécute lentement ou est bloquée à cause d'un conflit de ressource. Le conflit de ressource peut être dû à des E/S, des tâches système internes ou d'autres requêtes utilisateur.

La sortie de cette opération ressemble à ceci (format JSON).

{
    "waitedMS" : NumberLong(0),
    "cursor" : {
        "firstBatch" : [
            {
                "opid" : 201,
                "command" : {
                    "aggregate" : ...
                },
                "secs_running" : 208,
                "WaitState" : "IO"
            }
        ],
        "id" : NumberLong(0),
        "ns" : "admin.$cmd"
    },
    "ok" : 1
}

Les E/S peuvent constituer un goulot d'étranglement si un trop grand nombre de requêtes s'exécutent simultanément dans différentes collections sur la même instance, ou si la taille d'instance est trop petite pour l'ensemble de données sur lequel la requête s'exécute. Si les requêtes sont en lecture seule, vous pouvez atténuer la première situation en séparant les requêtes de chaque collection entre des réplicas distincts. Pour les mises à jour simultanées dans différentes collections ou quand la taille d'instance est trop petite pour l'ensemble de données, la solution consiste à faire monter l'instance en puissance.

Si le conflit de ressource est dû à d'autres requêtes utilisateur, le champ "blockedOn" dans le document de sortie comporte la valeur "opid" de la requête qui affecte cette requête. À l'aide de la valeur "opid", suivez la chaîne des champs "WaitState" et "blockedOn" de toutes les requêtes pour trouver la requête en tête de la chaîne.

Si la tâche en tête de la chaîne est une tâche interne, la seule solution consiste à arrêter la requête et à la réexécuter après un certain temps.

Voici un exemple de sortie dans lequel la requête de recherche est bloquée sur un verrou de collection détenu par une autre tâche.

{
    "inprog" : [
        {
            "client" : "...",
            "desc" : "Conn",
            "active" : true,
            "killPending" : false,
            "opid" : 75,
            "ns" : "...",
            "command" : {
                "find" : "...",
                "filter" : {

                }
            },
            "op" : "query",
            "$db" : "test",
            "secs_running" : 9,
            "microsecs_running" : NumberLong(9449440),
            "threadId" : 24773,
            "clientMetaData" : {
                "application" : {
                   "name" : "MongoDB Shell"
                },
                "driver" : {
                    ...
                },
                "os" : {
                    ...
                }
            },
            "WaitState" : "CollectionLock",
            "blockedOn" : "INTERNAL"
        },
        {
            "desc" : "INTERNAL"
        },
        {
            "client" : "...",
            ...
            "command" : {
                "currentOp" : 1
            },
            ...
        }
    ],
    "ok" : 1
}

Si "WaitState" a les valeurs "Latch", "SystemLock", "BufferLock", "BackgroundActivity" ou "Other", des tâches système internes sont à l'origine du conflit de ressource. Si la situation persiste pendant longtemps, la seule atténuation consiste à mettre fin à la requête et à l'exécuter à nouveau ultérieurement.

Comment puis-je déterminer pourquoi un système fonctionne soudainement lentement ?

Voici quelques raisons courantes du ralentissement d'un système :

  • Contention de ressources excessives entre les requêtes simultanées

  • Nombre de requêtes simultanées actives augmentant au fil du temps

  • Tâches système internes telles que "GARBAGE_COLLECTION"

Pour surveiller l'utilisation du système au fil du temps, exécutez la requête "currentOp" suivante périodiquement et placez les résultats dans un magasin externe. La requête compte le nombre de requêtes et d'opérations dans chaque espace de noms au sein du système. Les résultats de l'utilisation du système peuvent être ensuite analysés pour comprendre la charge du système et prendre les décisions appropriées.

db.adminCommand({aggregate: 1,
                 pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
                            {$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
                 cursor: {}
                });

Cette requête renvoie un agrégat de toutes les requêtes en cours d'exécution dans chaque espace de noms et de toutes les tâches système internes, ainsi que le nombre d'états d'attente par espace de noms, le cas échéant.

La sortie de cette opération ressemble à ceci (format JSON).

{
    "waitedMS" : NumberLong(0),
    "cursor" : {
        "firstBatch" : [
            {
                "_id" : {
                    "desc" : "Conn",
                    "ns" : "db.test",
                    "WaitState" : "CollectionLock"
                },
               "count" : 2
            },
            {
                "_id" : {
                    "desc" : "Conn",
                    "ns" : "admin.$cmd"
                },
                "count" : 1
            },
            {
                "_id" : {
                    "desc" : "TTLMonitor"
                },
                "count" : 1
            }
        ],
        "id" : NumberLong(0),
        "ns" : "admin.$cmd"
    },
    "ok" : 1
}

Dans la sortie précédente, il existe 2 requêtes utilisateur dans l'espace de noms "db.test" qui sont bloquées sur un verrouillage de collecte : 1 requête dans l'espace de noms "admin.$cmd" et une tâche interne "TTLMonitor".

Si la sortie indique de nombreuses requêtes avec des états d'attente bloquants, consultez Comment rechercher les requêtes de longue durée ou bloquées et les arrêter ?

Comment déterminer la cause d'une utilisation élevée du processeur sur une ou plusieurs instances de cluster ?

Les sections suivantes peuvent vous aider à identifier la cause d'une utilisation élevée de l'UC des instances. Vos résultats peuvent varier en fonction de la charge de travail.

En fonction de la raison de votre utilisation élevée de l'UC de l'instance, l'exécution d'une ou de plusieurs des actions suivantes peut vous aider.

  • Si l'instance principale présente une utilisation élevée de l'UC, ce qui n'est pas le cas des instances de réplica, envisagez de répartir le trafic en lecture entre les réplicas via les paramètres de préférence en lecture du client (par exemple, secondaryPreferred). Pour plus d’informations, consultez Connexion à Amazon DocumentDB en tant qu'ensemble de réplicas.

    L'utilisation de réplicas pour les lectures peut mieux utiliser les ressources du cluster en permettant à l'instance principale de traiter plus de trafic d'écriture. Les lectures de réplicas sont cohérentes à terme.

  • Si l'utilisation élevée de l'UC est le résultat de votre charge de travail en écriture, le fait de remplacer la taille des instances du cluster par un type d'instance plus grand augmente le nombre de cœurs d'UC disponibles pour traiter la charge de travail. Pour plus d’informations, consultez instances et Spécifications de la classe d'instance.

  • Si toutes les instances de cluster présentent une utilisation élevée de l'UC et que la charge de travail utilise des réplicas pour les lectures, l'ajout d'autres réplicas au cluster augmente les ressources disponibles pour le trafic en lecture. Pour plus d’informations, consultez Ajouter une instance Amazon DocumentDB à un cluster.

Comment déterminer les curseurs ouverts sur une instance ?

Lorsque vous êtes connecté à une instance Amazon DocumentDB, vous pouvez utiliser la commande db.runCommand("listCursors") pour répertorier les curseurs ouverts sur cette instance. Il existe une limite de 4 560 curseurs actifs ouverts à tout moment sur une instance Amazon DocumentDB donnée, en fonction du type d'instance. Il est généralement conseillé de fermer les curseurs qui ne sont plus utilisés car les curseurs utilisent des ressources sur une instance et ont une limite supérieure. Consultez Quotas et limites Amazon DocumentDB les limites spécifiques.

db.runCommand("listCursors")

Comment puis-je déterminer la version actuelle du moteur Amazon DocumentDB ?

Pour déterminer la version actuelle de votre moteur Amazon DocumentDB, exécutez la commande suivante.

db.runCommand({getEngineVersion: 1})

La sortie de cette opération ressemble à ceci (format JSON).

{ "engineVersion" : "2.x.x", "ok" : 1 }
Note

La version du moteur pour Amazon DocumentDB 3.6 est 1.x.x et la version du moteur pour Amazon DocumentDB 4.0 est 2.x.x.

Comment analyser l'utilisation des index et identifier les index inutilisés ?

Pour identifier les index d'une collection donnée, exécutez la commande suivante :

db.collection.getIndexes()

Pour analyser la quantité d'index utilisés lors des opérations effectuées sur les collections, les indexStats commandes collStats et peuvent être utilisées. Pour afficher le nombre total de scans effectués à l'aide d'index (scans d'index) par rapport au nombre de scans effectués sans index (scans de collection), exécutez la commande suivante : 

db.collection.stats()

La sortie de cette commande inclut les valeurs suivantes :

  • idxScans- Le nombre de scans effectués sur cette collection à l'aide d'un index.

  • collScans- Le nombre de scans effectués sur cette collection sans utiliser d'index. Ces scans auraient impliqué l'examen des documents de la collection un par un.

  • lastReset- L'heure à laquelle ces compteurs ont été réinitialisés pour la dernière fois. Les statistiques fournies par cette commande sont réinitialisées lors du démarrage/arrêt du cluster ou lors de la redimensionnement/réduction de l'instance.

Le détail de l'utilisation de chaque index se trouve dans le résultat de la commande suivante. Il est recommandé d'identifier et de supprimer régulièrement les index inutilisés afin d'améliorer les performances et de réduire les coûts, car cela élimine le calcul, le stockage et les E/S inutiles utilisés pour maintenir les index.

db.collection.aggregate([{$indexStats:{}}]).pretty()

Le résultat de cette commande donne les valeurs suivantes pour chaque index créé dans la collection :

  • ops- Le nombre d'opérations ayant utilisé l'index. Si votre charge de travail est en cours d'exécution depuis suffisamment longtemps et que vous êtes sûr qu’elle est stable, une valeur ops de zéro indique que l'indice n'est pas utilisé du tout.

  • numDocsRead- Le nombre de documents lus lors des opérations utilisant cet indice.

  • since- Le temps écoulé depuis qu'Amazon DocumentDB a commencé à collecter des statistiques sur l'utilisation des index, qui correspond généralement à la valeur écoulée depuis le dernier redémarrage de la base de données ou la dernière action de maintenance.

  • size- La taille de cet index en octets.

L'exemple suivant est un exemple de résultat de l'exécution de la commande ci-dessus :

{
    "name" : "_id_",
    "key" : {
        "_id" : 1
    },
    "host" : "example-host.com:12345",
    "size" : NumberLong(...),
    "accesses" : {
        "ops" : NumberLong(...),
        "docsRead" : NumberLong(...),
        "since" : ISODate("...")
    },
    "cacheStats" : {
        "blksRead" : NumberLong(...),
        "blksHit" : NumberLong(...),
        "hitRatio" : ...
    }
}
{
    "name" : "x_1",
    "key" : {
        "x" : 1
    },
    "host" : "example-host.com:12345",
    "size" : NumberLong(...),
    "accesses" : {
        "ops" : NumberLong(...),
        "docsRead" : NumberLong(...),
        "since" : ISODate("...")
    },
    "cacheStats" : {
        "blksRead" : NumberLong(...),
        "blksHit" : NumberLong(...),
        "hitRatio" : ...
    }
}

Pour déterminer la taille d'index globale d'une collection, exécutez la commande suivante :

db.collection.stats()

Pour supprimer un index non utilisé, exécutez la commande suivante :

db.collection.dropIndex("indexName")

Comment identifier les index manquants ?

Vous pouvez utiliser le profileur Amazon DocumentDB pour enregistrer les requêtes lentes. Une requête qui apparaît à plusieurs reprises dans le journal des requêtes lentes peut indiquer qu'un index supplémentaire est nécessaire pour améliorer les performances de cette requête.

Vous pouvez identifier les possibilités d'index utiles en recherchant les requêtes longues dont une ou plusieurs étapes exécutent au moins une étape COLLSCAN, qui signifie que l’étape de requête doit lire chaque document de la collection afin de fournir une réponse à la requête.

L'exemple suivant montre une requête sur une collection de trajets de taxi exécutée sur une collection de taille importante.

db.rides.count({"fare.totalAmount":{$gt:10.0}}))

Pour exécuter cet exemple, la requête devait effectuer une analyse de collection (c'est-à-dire lire chaque document de la collection) car il n’y a pas d’index sur le champ fare.totalAmount. Le résultat du profileur Amazon DocumentDB pour cette requête ressemble à ce qui suit : 

{
    ...
    "cursorExhausted": true,
    "nreturned": 0, 
    "responseLength": 0,
    "protocol": "op_query",
    "millis": 300679,
    "planSummary": "COLLSCAN",
    "execStats": {
        "stage": "COLLSCAN",
        "nReturned": "0",
        "executionTimeMillisEstimate": "300678.042"
    },
    "client": "172.31.5.63:53878",
    "appName": "MongoDB Shell",
    "user": "example"
}

Pour accélérer la requête dans cet exemple, vous souhaitez créer un index sur fare.totalAmount, comme indiqué ci-dessous.

db.rides.createIndex( {"fare.totalAmount": 1}, {background: true} )
Note

Les index créés au premier plan (c'est-à-dire si l'option {background:true} n'a pas été fournie lors de la création de l'index) prennent un verrou d'écriture exclusive, ce qui empêche les applications d'écrire des données dans la collection jusqu'à ce que la génération de l'index soit terminée. Soyez conscient de cet impact potentiel lors de la création d'index sur les clusters de production. Lors de la création d'index, nous vous recommandons de définir {background:true}.

En général, vous souhaitez créer des index sur des champs de cardinalité élevée (par exemple, un grand nombre de valeurs uniques). La création d'un index sur un champ à faible cardinalité peut générer un index de taille importante qui n'est pas utilisé. L'optimiseur de requêtes Amazon DocumentDB prend en compte la taille globale de la collection et la sélectivité des index lors de la création d'un plan de requête. Vous verrez parfois le processeur de requêtes sélectionner un COLLSCAN, même lorsqu'un index est présent. Cela se produit lorsque le processeur de requêtes estime que l'utilisation de l'index n'apportera pas un avantage au niveau des performances par rapport à l'analyse de l'ensemble de la collection. Si vous voulez forcer le processeur de requêtes à utiliser un index particulier, vous pouvez utiliser l'opérateur hint() comme indiqué ci-dessous.

db.collection.find().hint("indexName")

Résumé des requêtes utiles

Les requêtes suivantes peuvent être utiles pour surveiller les performances et l'utilisation des ressources dans Amazon DocumentDB.

  • Utilisez la commande suivante pour afficher les statistiques relatives à une collection spécifique, notamment les compteurs d'opérations, les statistiques de cache, les statistiques d'accès et les statistiques de taille :

    db.collection.stats()

  • Utilisez la commande suivante pour afficher les statistiques relatives à chaque index créé dans une collection, notamment la taille de l'index, les statistiques de cache spécifiques à l'index et les statistiques d'utilisation de l'index :

    db.collection.aggregate([{$indexStats:{}}]).pretty()

  • Utilisez la requête suivante pour répertorier toutes les activités.

    db.adminCommand({currentOp: 1, $all: 1});

  • Le code suivant répertorie toutes les requêtes de longue durée ou bloquées.

    db.adminCommand({aggregate: 1,
                 pipeline: [{$currentOp: {}},
                            {$match: {$or: [{secs_running: {$gt: 10}},
                                            {WaitState: {$exists: true}}]}},
                            {$project: {_id:0,
                                        opid: 1,
                                        secs_running: 1,
                                        WaitState: 1,
                                        blockedOn: 1,
                                        command: 1}}],
                 cursor: {}
                });

  • Le code suivant met fin à une requête.

    db.adminCommand({killOp: 1, op: <opid of running or blocked query>});

  • Utilisez le code suivant pour obtenir une vue agrégée de l'état du système.

    db.adminCommand({aggregate: 1,
                 pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
                            {$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
                 cursor: {}
                });