View a markdown version of this page

Requêtes de longue durée - Amazon DocumentDB

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.

Requêtes de longue durée

Présentation de

Long-running les requêtes peuvent entraîner des problèmes de performances à l'échelle du cluster. Ces requêtes peuvent interférer avec le processus de collecte des déchets MVCC ( Multi-Version Concurrency Control) d'Amazon DocumentDB, entraînant l'accumulation d'anciens documents versionnés et une dégradation des performances au sein du cluster. Amazon DocumentDB implémente un délai d'attente de 2 heures côté serveur comme mécanisme de sécurité pour empêcher les requêtes intempestives de consommer des ressources indéfiniment.

Que sont les requêtes de longue durée :

  • Requêtes exécutées pendant de longues périodes (généralement plus de 30 minutes)

  • Ouvrez les curseurs qui restent actifs pendant des heures (un délai de 2 heures ne sera pas applicable si le curseur est actif)

Impact sur le cluster

Les requêtes de longue durée peuvent interférer avec le processus de collecte des déchets

  • Les anciennes versions s'accumulent : le ramasse-miettes ne peut pas récupérer les anciennes versions des documents

  • Expansion des collections et des index : les entrées des collections et des index s'accumulent au fil du temps, ce qui augmente le volume de données, ce qui peut entraîner une augmentation des coûts de stockage.

  • Pression du processeur et de la mémoire : la pression du processeur et de la mémoire augmente en raison du traitement inefficace d'un nombre accru d'anciennes versions de documents, d'entrées d'index et d'identifiants de transaction.

Requête longue → Blocs GC → Croissance du stockage → Pression du processeur et de la mémoire → Requêtes plus longues

Surveiller et détecter

1. Pour rechercher des requêtes de longue durée, utilisez la commande CurrentOp.

// To find a query running for more than 30 mins db.adminCommand({ aggregate: 1, pipeline: [ {$currentOp: {}}, {$match: {$or: [{secs_running: {$gt: 1800}}, {WaitState: {$exists: true}}]}}], cursor: {} });

2. Pour rechercher les curseurs actifs depuis plus de 30 minutes

// To find cursor which is running more than 30 mins db.adminCommand({ "currentOp": true, "active": true, "$all": true }).inprog.filter(function(op) { return op.desc == "Cursor" && op.secs_running > 1800 && op.active == true; }).sort((a, b) => b.microsecs_running - a.microsecs_running)

3. Surveillance de la progression du ramasse-miettes via CloudWatch

LongestRunningGCProcess— Durée en secondes du processus de collecte des déchets actif le plus long. 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.

AvailableMVCCIds-Un compteur qui indique le nombre d'opérations d'écriture restantes disponibles avant d'atteindre zéro. Lorsque ce compteur atteint zéro, votre cluster passe en mode lecture seule jusqu'à ce que les identifiants soient récupérés et recyclés. Le compteur diminue à chaque opération d'écriture et augmente à mesure que la collecte des déchets recycle les anciens identifiants MVCC.

Note

Les identifiants MVCC inférieurs et la durée prolongée de la collecte des déchets ne sont pas exclusivement attribués aux requêtes de longue durée. Write-intensive les charges de travail sur les instances aux ressources limitées peuvent également entraîner une réduction de la disponibilité des identifiants MVCC et des cycles de collecte des déchets prolongés.

Stratégies de remédiation

  • Implémenter les délais d'attente des requêtes dans l'application

  • Ne laissez pas les curseurs actifs pendant de longues durées

  • Optimisez les requêtes pour de meilleures performances.

  • Préférez le traitement par lots des opérations d'écriture