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.
# Résolution des problèmes liés à Amazon DocumentDB
Les sections suivantes fournissent des informations sur la manière de résoudre les problèmes que vous pourriez rencontrer lors de l'utilisation d'Amazon DocumentDB (avec compatibilité avec MongoDB).
**Topics**
+ [Problèmes de connexion](troubleshooting.connecting.md)
+ [Index](troubleshooting.index-creation.md)
+ [Performances et utilisation des ressources](user_diagnostics.md)
+ [Collecte des ordures](garbage-collection.md)
# Dépannage des problèmes de connexion
Vous rencontrez des difficultés pour vous connecter ? Voici quelques scénarios courants et la façon de les résoudre.
**Rubriques**
+ [Impossible de se connecter à un point de terminaison Amazon DocumentDB](#troubleshooting-connecting)
+ [Test d'une connexion à une instance Amazon DocumentDB](#troubleshooting.testing-connection)
+ [Connexion à un point de terminaison non valide](#troubleshooting.invalid-endpoint)
+ [La configuration du pilote a un impact sur le nombre de connexions](#troubleshooting.driver.config)
## Impossible de se connecter à un point de terminaison Amazon DocumentDB
Lorsque vous essayez de vous connecter à Amazon DocumentDB, voici l'un des messages d'erreur les plus courants que vous pouvez recevoir.
```
connecting to: mongodb://docdb-2018-11-08-21-47-27.cluster-ccuszbx3pn5e.us-east-
1.docdb.amazonaws.com:27017/
2018-11-14T14:33:46.451-0800 W NETWORK [thread1] Failed to connect to
172.31.91.193:27017 after 5000ms milliseconds, giving up.
2018-11-14T14:33:46.452-0800 E QUERY [thread1] Error: couldn't connect to server
docdb-2018-11-08-21-47-27.cluster-ccuszbx3pn5e.us-east-1.docdb.amazonaws.com:27017,
connection attempt failed :
connect@src/mongo/shell/mongo.js:237:13
@(connect):1:6
exception: connect failed
```
Ce message d'erreur signifie généralement que votre client (le shell mongo dans cet exemple) ne peut pas accéder au point de terminaison Amazon DocumentDB. Cela peut être le cas pour plusieurs raisons :
**Topics**
+ [Connexion à partir de points de terminaison publics](#troubleshooting.cannot-connect.public-endpoints)
+ [Connexions interrégionales](#troubleshooting.cannot-connect.different-regions)
+ [Connexion depuis différents Amazon VPCs](#troubleshooting.cannot-connect.different-vpcs)
+ [Le groupe de sécurité bloque les connexions entrantes](#troubleshooting.cannot-connect.inbound-not-allowed)
+ [Problème de préférence de lecture du pilote Java Mongo](#troubleshooting-cannot-connect-java-mongo-issue)
### Connexion à partir de points de terminaison publics
**Vous essayez de vous connecter à un cluster Amazon DocumentDB directement depuis votre ordinateur portable ou votre machine de développement locale.**
Toute tentative de connexion à un cluster Amazon DocumentDB directement depuis un point de terminaison public, tel que votre ordinateur portable ou votre machine de développement locale, échouera. Amazon DocumentDB est uniquement destiné au cloud privé virtuel (VPC) et ne prend actuellement pas en charge les points de terminaison publics. Ainsi, vous ne pouvez pas vous connecter directement à votre cluster Amazon DocumentDB depuis votre ordinateur portable ou depuis un environnement de développement local en dehors de votre VPC.
Pour vous connecter à un cluster Amazon DocumentDB depuis l'extérieur d'un Amazon VPC, vous pouvez utiliser un tunnel SSH. Pour de plus amples informations, veuillez consulter [Connexion à un cluster Amazon DocumentDB depuis l'extérieur d'un Amazon VPC](connect-from-outside-a-vpc.md). En outre, si votre environnement de développement se trouve dans un autre Amazon VPC, vous pouvez également utiliser VPC Peering et vous connecter à votre cluster Amazon DocumentDB depuis un autre Amazon VPC de la même région ou d'une région différente.
### Connexions interrégionales
**Vous essayez de vous connecter à un cluster Amazon DocumentDB dans une autre région.**
Si vous essayez de vous connecter à un cluster Amazon DocumentDB depuis une instance Amazon EC2 située dans une région autre que celle du cluster, par exemple en essayant de vous connecter à un cluster situé dans la région USA Est (Virginie du Nord) (us-east-1) depuis la région USA Ouest (Oregon) (us-west-2), la connexion échouera.
Pour vérifier la région de votre cluster Amazon DocumentDB, exécutez la commande suivante. La région est dans le point de terminaison.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].Endpoint'
```
Le résultat de cette opération ressemble à ceci.
```
[
"sample-cluster.node.us-east-1.docdb.amazonaws.com"
]
```
Pour vérifier la région de votre instance EC2, exécutez la commande suivante :
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].Placement.AvailabilityZone'
```
Le résultat de cette opération ressemble à ceci.
```
[
[
"us-east-1a"
]
]
```
### Connexion depuis différents Amazon VPCs
**Vous essayez de vous connecter à un cluster Amazon DocumentDB à partir d'un VPC différent de celui sur lequel votre cluster est déployé.**
Si votre cluster Amazon DocumentDB et votre instance Amazon EC2 se trouvent dans le Région AWS même Amazon, mais pas dans le même Amazon VPC, vous ne pouvez pas vous connecter directement à votre cluster Amazon DocumentDB à moins que le peering VPC ne soit activé entre les deux Amazon. VPCs
Pour vérifier le VPC Amazon de votre instance Amazon DocumentDB, exécutez la commande suivante.
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].DBSubnetGroup.VpcId'
```
Pour vérifier le VPC Amazon de votre instance Amazon EC2, exécutez la commande suivante.
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].VpcId'
```
### Le groupe de sécurité bloque les connexions entrantes
**Vous essayez de vous connecter à un cluster Amazon DocumentDB et le groupe de sécurité du cluster n'autorise pas les connexions entrantes sur le port du cluster (port par défaut : 27017).**
Supposons que votre cluster Amazon DocumentDB et votre instance Amazon EC2 se trouvent tous deux dans la même région et dans le même Amazon VPC et qu'ils utilisent le même groupe de sécurité Amazon VPC. Si vous ne parvenez pas à vous connecter à votre cluster Amazon DocumentDB, cela est probablement dû au fait que le groupe de sécurité (c'est-à-dire le pare-feu) de votre cluster n'autorise pas les connexions entrantes sur le port que vous avez choisi pour votre cluster Amazon DocumentDB (le port par défaut est 27017).
Pour vérifier le port de votre cluster Amazon DocumentDB, exécutez la commande suivante.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[DBClusterIdentifier,Port]'
```
Pour obtenir le groupe de sécurité Amazon DocumentDB pour votre cluster, exécutez la commande suivante.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[VpcSecurityGroups[*],VpcSecurityGroupId]'
```
Pour vérifier les règles relatives au trafic entrant pour votre groupe de sécurité, consultez les rubriques suivantes de la documentation Amazon EC2 :
+ [Autorisation du trafic entrant pour vos instances Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html)
+ [Autorisation du trafic entrant pour vos instances Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/authorizing-access-to-an-instance.html)
### Problème de préférence de lecture du pilote Java Mongo
**Les préférences de lecture des clients ne sont pas respectées et certains clients ne peuvent pas écrire sur Amazon DocumentDB après un basculement, sauf s'ils redémarrent.**
Ce problème, découvert pour la première fois dans Java Mongo Driver 3.7.x, se produit lorsqu'un client établit une connexion à Amazon DocumentDB à l'aide de la méthode `MongoClientSettings` et, en particulier, lors du chaînage. `applyToClusterSettings` Les paramètres du MongoClient cluster peuvent être définis à l'aide de différentes méthodes, telles que `hosts()``requiredReplicaSetName()`, et`mode()`.
Lorsque le client ne spécifie qu'un seul hôte dans la `hosts()` méthode, le mode est défini sur au `ClusterConnectionMode.SINGLE` lieu de `ClusterConnectionMode.MULTIPLE` Cela amène le client à ignorer la préférence de lecture et à se connecter uniquement au serveur configuré dans`hosts()`. Ainsi, même si les paramètres du client sont initialisés comme ci-dessous, toutes les lectures seront toujours dirigées vers le primaire plutôt que vers le secondaire.
```
final ServerAddress serverAddress0 = new ServerAddress("cluster-endpoint", 27317));
final MongoCredential credential = MongoCredential.createCredential("xxx",
"admin", "xxxx".toCharArray());
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.readPreference(ReadPreference.secondaryPreferred())
.retryWrites(false)
.applyToSslSettings(builder -> builder
.enabled(false))
.applyToClusterSettings(builder -> builder.hosts(
Arrays.asList(serverAddress0
))
.requiredReplicaSetName("rs0"))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
**Étui Failover**
En utilisant les paramètres de connexion client ci-dessus, en cas de basculement et de mise à jour différée de l'enregistrement DNS pour le point de terminaison du rédacteur du cluster, le client essaiera toujours d'envoyer des écritures à l'ancien enregistreur (devenu lecteur après le basculement). Cela entraîne une erreur côté serveur (non principale) qui n'est pas gérée correctement par le pilote Java (cela fait toujours l'objet d'une enquête). Ainsi, le client peut être laissé dans un mauvais état jusqu'au redémarrage du serveur d'applications, par exemple.
Il existe deux solutions pour contourner ce problème :
+ Les clients qui se connectent à Amazon DocumentDB via une chaîne de connexion ne rencontreront pas ce problème, car cette valeur `ClusterConnectionMode` sera définie `MULTIPLE` lors de la définition des préférences de lecture.
```
MongoClientURI mongoClientURI = new MongoClientURI("mongodb://usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred");
MongoClient mongoClient = MongoClients.create(mongoClientURI.getURI());
```
Ou en utilisant `MongoClientSettings` Builder avec la `applyConnectionString` méthode.
```
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.applyConnectionString(new ConnectionString("usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred"))
.retryWrites(false)
.applyToSslSettings(builder → builder
.enabled(false))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
+ Paramétré de manière explicite `ClusterConnectionMode` sur`MULTIPLE`. Cela n'est nécessaire que lors de l'utilisation `applyToClusterSettings` de et`hosts().size() == 1`.
```
final ServerAddress serverAddress0 = new ServerAddress("cluster-endpoint", 27317));
final MongoCredential credential = MongoCredential.createCredential("xxx","admin", "xxxx".toCharArray());
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.readPreference(ReadPreference.secondaryPreferred())
.retryWrites(false)
.applyToSslSettings(builder → builder
.enabled(false))
.applyToClusterSettings(builder → builder
.hosts(Arrays.asList(serverAddress0))
.requiredReplicaSetName("rs0"))
.mode(ClusterConnectionMode.MULTIPLE))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
## Test d'une connexion à une instance Amazon DocumentDB
Vous pouvez tester votre connexion à un cluster à l'aide des outils courants Linux ou Windows.
Depuis un terminal Linux ou Unix, testez la connexion en saisissant les informations suivantes (remplacez `cluster-endpoint` par le point de terminaison et `port` par le port de votre instance) :
```
nc -zv cluster-endpoint port
```
Voici un exemple d'opération et la valeur de retour :
```
nc -zv docdbTest.d4c7nm7stsfc0.us-west-2.docdb.amazonaws.com 27017
Connection to docdbTest.d4c7nm7stsfc0.us-west-2.docdb.amazonaws.com 27017 port [tcp/*] succeeded!
```
## Connexion à un point de terminaison non valide
Lorsque vous vous connectez à un cluster Amazon DocumentDB et que vous utilisez un point de terminaison de cluster non valide, une erreur similaire à la suivante apparaît.
```
mongo --ssl \
--host sample-cluster.node.us-east-1.docdb.amazonaws.com:27017 \
--sslCAFile global-bundle.pem \
--username \
--password
```
Le résultat se présente comme suit :
```
MongoDB shell version v3.6
connecting to: mongodb://sample-cluster.node.us-east-1.docdb.amazonaws.com:27017/
2018-11-14T17:21:18.516-0800 I NETWORK [thread1] getaddrinfo("sample-cluster.node.us-east-1.docdb.amazonaws.com") failed:
nodename nor servname provided, or not known 2018-11-14T17:21:18.537-0800 E QUERY [thread1] Error: couldn't initialize
connection to host sample-cluster.node.us-east-1.docdb.amazonaws.com, address is invalid :
connect@src/mongo/shell/mongo.js:237:13@(connect):1:6
exception: connect failed
```
Pour connaître le point de terminaison valide pour un cluster, exécutez la commande suivante :
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[Endpoint,Port]'
```
Pour connaître le point de terminaison valide pour une instance, exécutez la commande suivante :
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].[Endpoint.Address,Endpoint.Port]'
```
Pour de plus amples informations, veuillez consulter [Comprendre les points de terminaison Amazon DocumentDB](endpoints.md).
## La configuration du pilote a un impact sur le nombre de connexions
Lorsque vous utilisez le pilote client pour vous connecter à un cluster Amazon DocumentDB, il est important de prendre en compte le paramètre de `maxPoolSize` configuration. Le `maxPoolSize` paramètre détermine le nombre maximum de connexions que le pilote client conservera dans son pool de connexions.
# Index de résolution des problèmes
Les rubriques suivantes expliquent la procédure à suivre en cas d'échec de la génération de votre index ou de votre index d'arrière-plan.
**Topics**
+ [La création de l'index échoue](#troubleshooting.index-build-fails)
+ [Problèmes et échecs de latence lors de la création de l'index d'arrière-plan](#troubleshooting.background-index-build-fails)
+ [Surcharge de l'index de base de données](#troubleshooting-database-bloat)
## La création de l'index échoue
Amazon DocumentDB utilise le stockage local sur une instance dans le cadre du processus de création d'index. Vous pouvez surveiller cette utilisation du disque à l'aide de la **FreeLocalStorage** CloudWatch métrique (`CloudWatch -> Metrics -> DocDB -> Instance Metrics`). Lorsque la génération d'un index utilise l'ensemble du disque local et échoue, vous recevez une erreur. Lorsque vous migrez des données vers Amazon DocumentDB, nous vous encourageons à créer d'abord des index, puis à insérer les données. Pour plus d'informations sur les stratégies de migration et la création d'index, consultez [Migration vers Amazon DocumentDB](docdb-migration.md) la documentation Amazon DocumentDB et le blog [: Migrer de MongoDB vers Amazon DocumentDB en utilisant](https://aws.amazon.com/blogs/database/migrate-from-mongodb-to-amazon-documentdb-using-the-offline-method/) la méthode hors ligne.
Lorsque vous créez des index sur un cluster existant, si la création de l'index prend plus de temps que prévu ou échoue, nous vous recommandons de redimensionner l'instance pour créer l'index, puis de la réduire une fois l'index créé. Amazon DocumentDB vous permet de redimensionner rapidement la taille des instances en quelques minutes à l'aide du AWS Management Console ou du. AWS CLI Pour de plus amples informations, veuillez consulter [Gestion des classes d'instances](db-instance-classes.md). Avec la tarification des instances à la seconde, vous payez seulement pour les ressources que vous utilisez à la seconde près.
## Problèmes et échecs de latence lors de la création de l'index d'arrière-plan
Les compilations d'index en arrière-plan dans Amazon DocumentDB ne démarrent que lorsque toutes les requêtes sur l'instance principale lancées avant le lancement de la génération d'index ne sont terminées. Si la requête est longue, les compilations d'index en arrière-plan seront bloquées jusqu'à la fin de la requête et peuvent donc prendre plus de temps que prévu. Cela est vrai même si les collections sont vides.
Les constructions d'index de premier plan ne présentent pas le même comportement de blocage. Au lieu de cela, les constructions d'index de premier plan bloquent exclusivement la collection jusqu'à ce que la création de l'index soit terminée. Ainsi, pour créer des index sur une collection vide et éviter de bloquer les requêtes de longue durée, nous vous suggérons d'utiliser des versions d'index de premier plan.
**Note**
Amazon DocumentDB autorise la création d'un seul index d'arrière-plan sur une collection à la fois. Si les opérations DDL (langage de définition de données) telles que `createIndex()` ou `dropIndex()` se produisent pendant la génération d'un index d'arrière-plan, celle-ci échoue.
## Surcharge de l'index de base de données
Amazon DocumentDB utilise le contrôle de concurrence multiversion (MVCC) pour gérer les transactions simultanées. Lorsque des documents sont supprimés ou mis à jour, leurs versions précédentes restent dans les collections et les index en tant que versions « mortes ». Le processus de collecte des déchets permet de récupérer automatiquement de l'espace dans ces versions mortes pour les opérations futures.
Le gonflement des index se produit lorsque les index d'une collection augmentent en raison de l'accumulation d'entrées d'index mortes ou obsolètes ou de la fragmentation des pages. Le pourcentage indiqué représente la quantité d'espace d'index qui peut être utilisée par les futures entrées d'index. Cette surcharge consomme de l'espace à la fois dans le cache tampon et dans le stockage. Si vous souhaitez supprimer le surmenage, vous devez reconstruire les index.
**Example Exemple**
Exécutez la commande suivante pour déterminer le stockage inutilisé pour votre index :
```
db.coll.aggregate({$indexStats:{}});
```
Le résultat ressemble à ceci :
```
{
"name" : "_id_",
"key" : {
"_id" : 1
},
"host" : "devbox-test.localhost.a2z.com:27317",
"size" : NumberLong(827392),
"accesses" : {
"ops" : NumberLong(40000),
"docsRead" : NumberLong(46049),
"since" : ISODate("2025-04-03T21:44:51.251Z")
},
"cacheStats" : {
"blksRead" : NumberLong(264),
"blksHit" : NumberLong(140190),
"hitRatio" : 99.8121
},
"unusedStorageSize" : {
"unusedSizeBytes" : 409600,
"unusedSizePercent" : 49.51
}
}
```
Vous pouvez reconstruire les index sans interruption à l'aide de la `reIndex` commande, qui nécessite une analyse de l'ensemble de la collection. Consultez [Maintenance de l'index en utilisant `reIndex`](managing-indexes.md#reIndex).
# Résolution des problèmes de performances et d'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](endpoints.md).
**Topics**
+ [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 ?](#user-diag-performed-operations)
+ [Comment analyser les performances du cache ?](#user-diag-cache-perf)
+ [Comment rechercher les requêtes de longue durée ou bloquées et les arrêter ?](#user_diagnostics-query_terminating)
+ [Comment puis-je consulter un plan de requête et optimiser une requête ?](#user_diagnostics-query_plan)
+ [Comment puis-je voir un plan de requête dans des clusters élastiques ?](#user-diagnostics-ec-query-plan)
+ [Quelle est la marche à suivre pour répertorier toutes les opérations en cours d'exécution sur une instance ?](#user_diagnostics-list_queries)
+ [Comment savoir si une requête progresse ?](#user_diagnostics-query_progressing)
+ [Comment puis-je déterminer pourquoi un système fonctionne soudainement lentement ?](#user_diagnostics-speed_change)
+ [Comment déterminer la cause d'une utilisation élevée du processeur sur une ou plusieurs instances de cluster ?](#user_diagnostics-cpu_utilization)
+ [Comment déterminer les curseurs ouverts sur une instance ?](#user_diagnostics-open_cursors)
+ [Comment puis-je déterminer la version actuelle du moteur Amazon DocumentDB ?](#user_diagnostics-engine_version)
+ [Comment analyser l'utilisation des index et identifier les index inutilisés ?](#user-diag-index-usage)
+ [Comment identifier les index manquants ?](#user_diagnostics-identify_missing_indexes)
+ [Comment puis-je déterminer le surcroît de collecte de données ?](#performance-collection-bloat)
+ [Résumé des requêtes utiles](#user_diagnostics-useful_queries)
## 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 mises à jour de documents 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` `deleteMany``remove`,, 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 starting/stopping du cluster ou du dimensionnement up/down 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é dans[Surveillance d'Amazon DocumentDB avec CloudWatch](cloud_watch.md).
## 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`**- L'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 starting/stopping du cluster ou du dimensionnement up/down 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é par`100 * [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
}
```
1. 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: {}})
```
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'`explain`opé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'`$hint`opé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\$1MERGE » au sein de chaque partition. Les résultats des partitions sont ensuite fusionnés à l'étape « SHARD\$1MERGE » 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 d'Amazon DocumentDB](security.managing-users.md).)
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\$1COLLECTION**— 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 ?](#user_diagnostics-query_terminating)
## 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.
+ Pour déterminer pourquoi une instance s'exécute lentement soudainement, consultez [Comment puis-je déterminer pourquoi un système fonctionne soudainement lentement ?](#user_diagnostics-speed_change)
+ Pour identifier et mettre fin aux requêtes de longue durée sur une instance particulière, consultez [Comment rechercher les requêtes de longue durée ou bloquées et les arrêter ?](#user_diagnostics-query_terminating)
+ Pour comprendre si une requête progresse, consultez [Comment savoir si une requête progresse ?](#user_diagnostics-query_progressing)
+ Pour déterminer pourquoi l'exécution d'une requête prend beaucoup de temps, consultez [Comment puis-je consulter un plan de requête et optimiser une requête ?](#user_diagnostics-query_plan)
+ Pour suivre les requêtes de longue durée au fil du temps, consultez [Profilage des opérations Amazon DocumentDB](profiling.md).
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 de plus amples informations, veuillez consulter [Connexion à Amazon DocumentDB en tant que jeu de répliques](connect-to-replica-set.md).
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](what-is.md#what-is-db-instances) et [Spécifications des classes d'instances](db-instance-classes.md#db-instance-class-specs).
+ 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 de plus amples informations, veuillez consulter [Ajouter une instance Amazon DocumentDB à un cluster](db-instance-add.md).
## 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. Voir [Quotas et limites Amazon DocumentDB](limits.md) pour connaître 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, la version du moteur pour Amazon DocumentDB 4.0 est 2.x.x, la version du moteur pour Amazon DocumentDB 5.0 est 3.x.x et la version du moteur pour Amazon DocumentDB 8.0 est 4.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 starting/stopping du cluster ou du dimensionnement up/down 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 l' I/Os utilisation inutiles 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 de l'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 obtenu suite à 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](https://docs.aws.amazon.com//documentdb/latest/developerguide/profiling.html). 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 opportunités d'indexation utiles en recherchant des requêtes de longue durée comportant une ou plusieurs étapes comportant au moins une `COLLSCAN` étape, ce qui signifie que l'étape de requête doit lire tous les documents 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")
```
## Comment puis-je déterminer le surcroît de collecte de données ?
Le gonflement des collections se produit lorsque la taille d'une collection augmente en raison de l'accumulation de documents morts ou obsolètes ou de la fragmentation des pages de la base de données. Le pourcentage indiqué représente la quantité d'espace de document qui pourra être utilisée par les futurs documents. Cette surcharge consomme de l'espace à la fois dans le cache tampon et dans le stockage. Pour supprimer cette surcharge, les collections doivent être rechargées via dump/restore ou à l'aide d'une boucle de migration et d'un basculement pendant une fenêtre de maintenance.
**Example Exemple**
Exécutez la commande suivante pour déterminer l'espace de stockage inutilisé pour votre collection :
```
db.runCommand({collStats:'coll'})
```
Le résultat ressemble à ceci :
```
{
"ns" : "test.coll",
"count" : 7500,
"size" : 23250,
"avgObjSize" : 31,
"storageSize" : 106496,
"unusedStorageSize" : {
"unusedBytes" : 16384,
"unusedPercent" : 25.12
},
"compression" : {
"enable" : false
},
"capped" : false,
"nindexes" : 1,
"totalIndexSize" : 57344,
"indexSizes" : {
"_id_" : 57344
},
"collScans" : 4,
"idxScans" : 10000,
"opCounter" : {
"numDocsIns" : 1000,
"numDocsUpd" : 0,
"numDocsDel" : 250
},
"cacheStats" : {
"collBlksHit" : 3570,
"collBlksRead" : 8,
"collHitRatio" : 99.7765,
"idxBlksHit" : 12293,
"idxBlksRead" : 6,
"idxHitRatio" : 99.9513
},
"lastReset" : "2024-12-18 00:30:21.552019+00",
"ok" : 1,
"operationTime" : Timestamp(1734632375, 1)
}
```
## 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: });
```
+ 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: {}
});
```
# Collecte des déchets dans Amazon DocumentDB
Amazon DocumentDB implémente une architecture de base de données MVCC (Multiversion Concurrency Control) qui crée de nouvelles versions des entrées de document et d'index pour chaque opération de mise à jour. Cette architecture permet d'isoler les transactions, empêchant ainsi les modifications d'une transaction d'apparaître dans une autre.
**Topics**
+ [Comprendre la collecte des déchets dans Amazon DocumentDB](#understanding-garbage-collection)
+ [Processus de collecte des ordures](#garbage-collection-process)
+ [Architecture de stockage et stockage étendu](#storage-architecture)
+ [Surveillance de la collecte des déchets](#monitoring-garbage-collection)
+ [Exemple de sortie CollStats](#example-collstats-output)
+ [Questions fréquentes (FAQ)](#garbage-collection-faq)
## Comprendre la collecte des déchets dans Amazon DocumentDB
La collecte des déchets (GC) est un processus d'arrière-plan automatisé qui garantit des performances et une disponibilité optimales du système dans Amazon DocumentDB. Comme de nombreuses bases de données modernes, l'architecture MVCC d'Amazon DocumentDB crée de nouvelles versions de documents et d'index à chaque mise à jour. Chaque opération d'écriture consomme un identifiant MVCC unique provenant d'un compteur fini. Ils IDs identifient à quelle transaction appartient une version du document et si elle a été validée ou annulée. Au fil du temps, ces anciennes versions et leur MVCC IDs s'accumulent, ce qui nécessite un nettoyage pour éviter toute dégradation des performances.
### Fonctions de collecte des ordures
Le collecteur de déchets remplit trois fonctions essentielles :
+ **Récupère de l'espace de stockage** : il supprime les versions de documents et d'index obsolètes dont les requêtes actives n'ont plus besoin, libérant ainsi de l'espace pour les futures opérations d'écriture.
+ **Empêche le dépassement d'ID MVCC** — Il empêche le débordement d'ID MVCC en gérant le compteur fini de MVCC. IDs Sans cette gestion, le compteur finirait par atteindre ses limites, forçant la base de données à passer en mode lecture seule temporaire jusqu'à ce IDs qu'elle soit recyclée.
+ **Maintient les performances des requêtes** : il permet de maintenir des performances de requête optimales en éliminant les versions de documents obsolètes qui, autrement, s'accumuleraient et ralentiraient le traitement des requêtes.
## Processus de collecte des ordures
Le processus GC fonctionne par collection et peut comporter plusieurs processus exécutés simultanément sur différentes collections. Le processus comprend quatre phases séquentielles :
1. **Identification** — Le système identifie les versions des documents et des index qui ne sont plus référencées par les transactions ou requêtes actives.
1. **Chargement de la mémoire** — Les anciens documents et entrées d'index sont chargés en mémoire s'ils ne sont pas déjà présents.
1. **Suppression** — Les versions obsolètes sont définitivement supprimées pour récupérer de l'espace de stockage.
1. **Recyclage des identifiants MVCC** — Le système recycle le MVCC à IDs partir des versions supprimées pour de nouvelles opérations.
Lorsque la collecte des déchets termine le traitement des anciennes versions de documents, elle supprime le MVCC le plus ancien IDs du système. Ce nettoyage est crucial pour empêcher le débordement des identifiants MVCC en recyclant les MVCC IDs et en les rendant disponibles pour de nouvelles opérations d'écriture dans le cluster. Sans ce processus de recyclage, le système finirait par épuiser son compteur d'identifiants MVCC limité et passer en mode lecture seule.
### Planification de la collecte des ordures
La collecte des déchets s'exécute automatiquement en arrière-plan à intervalles réguliers. La synchronisation et la fréquence s'ajustent dynamiquement en fonction de la charge du système, des ressources disponibles, du volume d'écriture et des niveaux de consommation des identifiants MVCC. En cas d'activité d'écriture intense, le processus GC s'exécute plus fréquemment pour gérer le nombre accru de versions de documents.
## Architecture de stockage et stockage étendu
Amazon DocumentDB utilise une architecture de stockage sophistiquée qui sépare le stockage des documents en deux segments distincts :
### Segment de stockage de base
Le segment de stockage de base contient les données et métadonnées du document principal. Ce segment stocke :
+ Contenu du document adapté à la taille de page standard (8 Ko).
+ Informations sur les métadonnées et les structures des documents.
+ Les index principaux et leurs entrées.
+ Statistiques et configuration au niveau de la collection.
### Segment de stockage étendu
Le segment de stockage étendu utilise un magasin d'objets de grande taille spécialisé conçu pour traiter les documents dont la taille de page de stockage standard est supérieure à la taille de page de stockage standard. Ce segment fournit :
+ **Gestion efficace des documents volumineux** — Les documents dont la taille est supérieure au seuil de stockage de base sont automatiquement déplacés vers le segment de stockage étendu.
+ **Disposition de stockage optimisée** : le segment utilise un format de stockage différent optimisé pour les objets volumineux, ce qui réduit la fragmentation et améliore les modèles d'accès.
+ **Collecte indépendante des déchets** — Le segment du stockage étendu possède son propre processus de collecte des déchets qui peut être exécuté indépendamment du nettoyage du stockage de base.
+ **Accès transparent** : les applications accèdent facilement à des documents volumineux sans avoir besoin de savoir quel segment de stockage contient les données.
Le segment du stockage étendu est particulièrement avantageux pour :
+ Collections contenant des documents contenant de grands tableaux intégrés.
+ Documents dotés de structures imbriquées étendues.
+ Collections stockant des données binaires ou de grands champs de texte.
+ Applications avec des tailles de documents mixtes où certains documents dépassent largement la taille moyenne.
## Surveillance de la collecte des déchets
### Métriques au niveau du cluster
**`AvailableMVCCIds`**
+ **Emplacement** — Amazon CloudWatch
+ **Description** — Un compteur qui indique le nombre d'opérations d'écriture restantes disponibles à partir d'une limite maximale de 1,8 milliard. Lorsque ce compteur atteint zéro, votre cluster passe en mode lecture seule jusqu'à ce IDs qu'il soit récupéré et recyclé. Le compteur diminue à chaque opération d'écriture et augmente à mesure que la collecte des déchets recycle l'ancien IDs MVCC.
+ **Recommandation** — Réglez une alarme lorsque la valeur tombe en dessous de 1,3 milliard. Cette alerte précoce vous permet de prendre les mesures recommandées dont il sera question ultérieurement.
**`LongestActiveGCRuntime`**
+ **Emplacement** — Amazon CloudWatch
+ **Description** — Durée en secondes du plus long processus actif de collecte des déchets. Il est mis à jour toutes les minutes et suit uniquement les opérations actives, à l'exception des processus terminés dans le délai d'une minute.
+ **Recommandation** — Comparez les données avec les données `gcRuntimeStats` historiques pour identifier les comportements anormaux de collecte des déchets, tels que les durées d'exécution prolongées lors de suppressions groupées.
### Mesures au niveau de la collecte
**`MVCCIDStats: MVCCIdScale`**
+ **Emplacement — Commande** CollStats de base de données
+ **Description** — Mesure l'âge de l'identifiant MVCC sur une échelle de 0 à 1, où 1 indique l'âge maximum avant qu'un cluster ne passe en mode lecture seule. Utilisez cette métrique en parallèle `AvailableMVCCIds` pour identifier les collections contenant les plus anciens MVCC IDs qui vieillissent le cluster.
+ **Recommandation** — Maintenir les valeurs inférieures à 0,3 pour chaque collection.
**`gcRuntimeStats`**
+ **Emplacement — Commande** CollStats de base de données
+ **Description** — Fournit un historique sur deux mois des indicateurs de collecte des déchets, y compris le nombre total de cycles, la durée moyenne et la durée maximale. Inclut uniquement les opérations de collecte des ordures de plus de cinq minutes afin de garantir des statistiques significatives.
**Important**
`gcRuntimeStats``documentFragmentStats`, et la répartition des métriques au niveau de la collection en `storageSegmentBase` et ne `storageSegmentExtended` sont disponibles que pour Amazon DocumentDB 8.0.
**`storageSizeStats`**
+ **Emplacement — Commande** CollStats de base de données
+ **Description** : fournit une ventilation détaillée de l'utilisation du stockage entre les différents segments de stockage :
+ `storageSegmentBase`— Stockage utilisé par le segment de stockage de base pour les documents standard
+ `storageSegmentExtended`— Stockage utilisé par le segment de stockage étendu pour les documents volumineux
+ **Utilisation** : permet d'identifier les collections contenant un volume important de documents et de comprendre les modèles de distribution du stockage.
**`unusedStorageSize`**(niveau de collecte)
+ **Emplacement — Commande** CollStats de base de données
+ **Description** — Estime l'espace de stockage inutilisé dans une collection sur la base de statistiques échantillonnées. Il inclut l'espace réservé aux documents supprimés et aux segments vides. La métrique fournit à la fois des totaux combinés et des ventilations par segment :
+ Combiné `unusedBytes` et `unusedPercent` dans tous les segments de stockage
+ `storageSegmentBase`— Espace inutilisé spécifiquement dans le segment de stockage de base
+ `storageSegmentExtended`— Espace inutilisé, en particulier dans le segment du stockage étendu
**`documentFragmentStats`**
+ **Emplacement — Commande** CollStats de base de données
+ **Description** — Fournit des informations détaillées sur les fragments de documents et les données non utilisées dans les collections. Les fragments de document représentent les unités de stockage internes utilisées par le moteur de base de données, tandis que les fragments morts indiquent des données qui ne sont plus accessibles mais qui n'ont pas encore été récupérées. Cette métrique inclut :
+ `totalDocFragmentsCount`— Nombre total de fragments de documents dans la collection
+ `deadDocFragmentsCount`— Nombre de fragments contenant des données mortes (inaccessibles)
+ `deadDocFragmentsPercent`— Pourcentage de fragments contenant des données inactives
+ `deadDocFragmentBytes`— Estimation du nombre d'octets consommés par les fragments de document morts
+ Répartition par segment pour et `storageSegmentBase` `storageSegmentExtended`
+ **Utilisation** — Surveillez cette métrique pour comprendre l'efficacité de la collecte des déchets et identifier les collectes susceptibles de bénéficier des opérations de maintenance. Des pourcentages élevés de fragments morts indiquent que la collecte des déchets est peut-être en retard ou qu'il serait utile d'optimiser la collecte.
### Mesures au niveau de l'indice
**`unusedStorageSize`**(niveau de l'indice)
+ **Emplacement — Commande** IndexStats de base de données
+ **Description** — Estime l'espace de stockage inutilisé dans un index sur la base de statistiques échantillonnées. Il inclut l'espace réservé aux entrées d'index obsolètes et aux segments vides.
+ **Recommandation** — Utilisez la `reIndex` commande pour reconstruire les index sans interruption et récupérer l'espace inutilisé. Reportez-vous à la section Gestion des index pour plus de détails.
## Exemple de sortie CollStats
L'exemple suivant montre une `collStats` sortie typique avec des métriques de collecte des déchets et de stockage :
```
{
"ns" : "Mvcc_consumption_test_db.mvcc_test_collection",
"MVCCIdStats" : {
"MVCCIdScale" : 0.03
},
"gcRuntimeStats" : {
"numRuns" : 1,
"historicalAvgRuntime" : 3295,
"historicalMaxRuntime" : 3295,
"lastRuntime" : 3295,
"lastRuntimeStart" : ISODate("2025-06-24T08:47:14Z")
},
"documentFragmentStats" : {
"totalDocFragmentsCount" : 45000000,
"deadDocFragmentsCount" : 2250000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 98304000,
"storageSegmentBase" : {
"totalDocFragmentsCount" : 30000000,
"deadDocFragmentsCount" : 1500000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 65536000
},
"storageSegmentExtended" : {
"totalDocFragmentsCount" : 15000000,
"deadDocFragmentsCount" : 750000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 32768000
}
},
"collScans" : 14,
"count" : 30000000,
"size" : 1320000000,
"avgObjSize" : 44,
"storageSize" : 6461497344,
"storageSizeStats" : {
"storageSegmentBase" : 4307664896,
"storageSegmentExtended" : 2153832448
},
"capped" : false,
"nindexes" : 2,
"totalIndexSize" : 9649553408,
"indexSizes" : {
"_id_" : 1910661120,
"c_1" : 7738892288
},
"unusedStorageSize" : {
"unusedBytes" : 4201881600,
"unusedPercent" : 65.05,
"storageSegmentBase" : {
"unusedBytes" : 2801254400,
"unusedPercent" : 65.05
},
"storageSegmentExtended" : {
"unusedBytes" : 1400627200,
"unusedPercent" : 65.05
}
},
"cacheStats" : {
"collBlksHit" : 171659016,
"collBlksRead" : 754061,
"collHitRatio" : 99.5627,
"idxBlksHit" : 692563636,
"idxBlksRead" : 1177921,
"idxHitRatio" : 99.8303
},
"idxScans" : 41823984,
"opCounter" : {
"numDocsIns" : 0,
"numDocsUpd" : 20911992,
"numDocsDel" : 0
},
"lastReset" : "2025-06-24 05:57:08.219711+00",
"ok" : 1,
"operationTime" : Timestamp(1750968826, 1)
}
```
## Questions fréquentes (FAQ)
### Comment savoir si le ramassage des ordures ne fonctionne pas efficacement ?
Surveillez ces panneaux d'avertissement qui indiquent un ramassage inefficace des déchets :
+ **Surcharge excessive des collections** : augmentation constante `unusedStorageSize` des statistiques lors d'écritures intensives ou de suppressions massives, en particulier pour les index volumineux.
+ **Pourcentage élevé de fragments morts** : `documentFragmentStats` affichage constant de `deadDocFragmentsPercent` valeurs élevées (supérieures à 10 à 15 %).
+ Latence **des requêtes dégradée : latence** des requêtes accrue en raison de l'accumulation de documents morts.
+ **Durée prolongée du GC** — Les opérations de collecte des déchets prennent plus de temps que les moyennes historiques en`gcRuntimeStats`.
+ **Traitement GC élevé** — Un niveau élevé `LongestActiveGCRuntime` indique que le ramasse-miettes ne peut pas répondre aux demandes du système.
### Le ramassage des déchets affecte-t-il les performances de ma base de données ?
Dans des conditions normales, le ramassage des déchets a un impact minimal sur les performances. Cependant, lorsque la collecte des ordures prend du retard, vous pouvez rencontrer :
+ Coûts de stockage accrus en raison de l'accumulation de documents morts.
+ Ralentissement des performances des requêtes en raison d'entrées d'index obsolètes.
+ Mode lecture seule temporaire si les MVCC IDs sont épuisés.
+ Utilisation accrue des ressources lors de collectes intensives, en particulier sur les petites instances.
+ Efficacité réduite dans les opérations de segments de stockage étendus pour les documents volumineux.
### Puis-je déclencher manuellement le ramassage des ordures ?
Non, la collecte des déchets dans Amazon DocumentDB ne peut pas être déclenchée manuellement. Le système gère automatiquement la collecte des ordures dans le cadre de ses opérations de maintenance internes.
### Quelles alarmes dois-je configurer en tant que meilleure pratique opérationnelle ?
Nous vous recommandons de configurer la surveillance au niveau du cluster et de la collecte afin de garantir des performances optimales de votre système Amazon DocumentDB.
Pour la surveillance au niveau du cluster, commencez par créer une CloudWatch alarme Amazon pour la `AvailableMVCCIds` métrique avec un seuil de 1,3 milliard. Cela vous laisse suffisamment de temps pour agir avant que la métrique n'atteigne zéro, date à laquelle votre cluster passe en mode lecture seule. N'oubliez pas que cet indicateur peut fluctuer en fonction de vos habitudes d'utilisation spécifiques : certains clients le voient chuter en dessous de 1,3 milliard, puis remonter au-dessus de 1,5 milliard une fois que le ramassage des déchets est terminé.
Il est également important de surveiller la `LongestActiveGCRuntime` métrique via Amazon CloudWatch. Cette métrique, associée à`gcRuntimeStats`, vous aide à comprendre l'efficacité de la collecte des déchets dans votre système.
Pour le suivi au niveau de la collection, concentrez-vous sur ces indicateurs clés :
+ `MVCCIdScale`— Surveillez les valeurs croissantes qui suggèrent que les MVCC IDs vieillissent et peuvent nécessiter une attention particulière.
+ `gcRuntimeStats`— Identifiez les processus de collecte des déchets qui prennent inhabituellement du temps ou s'étendent sur plusieurs jours.
+ `documentFragmentStats`— Surveillez `deadDocFragmentsPercent` les valeurs : des pourcentages constamment élevés (supérieurs à 10 à 15 %) peuvent indiquer que la collecte des déchets est en retard.
+ `storageSizeStats`et `unusedStorageSize` — Suivez les modèles d'utilisation du stockage et identifiez les collections présentant un espace inutilisé important dans l'un ou l'autre des segments de stockage.
Les collections où les opérations d'écriture sont fréquentes nécessitent une attention particulière, car elles génèrent plus de travail pour le ramasse-miettes. Nous vous recommandons de vérifier ces indicateurs plus fréquemment pour les collections présentant une forte activité d'écriture afin de vous assurer que le ramassage des déchets correspond à votre charge de travail.
Notez que ces recommandations de surveillance servent de point de départ. Au fur et à mesure que vous vous familiariserez avec le comportement de votre système, vous souhaiterez peut-être ajuster ces seuils pour mieux correspondre à vos habitudes d'utilisation et à vos exigences spécifiques.
### Que dois-je faire si mon revenu `AvailableMVCCIds` tombe en dessous de 1,3 milliard ?
Si votre `AvailableMVCCIds` indicateur tombe en dessous de 1,3 milliard, nous vous recommandons de prendre des mesures immédiates pour empêcher votre cluster de passer en mode lecture seule. Nous vous recommandons d'abord d'augmenter la taille de votre instance afin de fournir au ramasse-miettes davantage de ressources informatiques. Il s'agit de notre principale recommandation, car elle permet à votre application de continuer à fonctionner normalement tout en donnant au ramasse-miettes la puissance supplémentaire dont il a besoin pour rattraper son retard.
Si la mise à l'échelle à elle seule n'améliore pas la situation, nous vous recommandons d'envisager de réduire vos opérations d'écriture. Utilisez la `MVCCIdScale` métrique pour identifier les collections spécifiques contenant des anciens MVCC IDs qui nécessitent une attention particulière. De plus, surveillez `documentFragmentStats` pour identifier les collections présentant des pourcentages élevés de fragments morts qui peuvent contribuer à l'inefficacité de la collecte des déchets.
Une fois que vous aurez identifié ces collections, vous devrez peut-être réduire temporairement les opérations d'écriture pour permettre à la collecte des déchets de rattraper son retard. Pendant la période de reprise, nous vous recommandons de surveiller de près la `AvailableMVCCIds` métrique pour vous assurer que vos actions ont l'effet escompté. Votre cluster est considéré comme sain une fois que `AvailableMVCCIds` sa valeur revient à 1,5 milliard ou plus.
N'oubliez pas que ces étapes sont des mesures préventives destinées à aider votre système à se rétablir avant qu'il n'atteigne un état critique. Plus vous agissez rapidement après avoir vu le chiffre passer en dessous de 1,3 milliard, plus vous avez de chances d'éviter tout impact sur vos opérations d'écriture.