En utilisant AWS re:Post, vous acceptez les AWS re:Post Conditions d’utilisation

Comment résoudre les problèmes liés à l'utilisation élevée du processeur sur mes instances Amazon DocumentDB ?

Lecture de 8 minute(s)
0

Je constate une utilisation élevée du processeur sur mes instances de base de données Amazon DocumentDB (compatible avec MongoDB).

Brève description

L'utilisation du processeur de vos instances Amazon DocumentDB vous aide à comprendre le fonctionnement des ressources actuellement allouées face à la charge de travail continue.

Vous pouvez observer une augmentation de l'utilisation du processeur pour les raisons suivantes :

  • Charges de travail lourdes initiées par l'utilisateur
  • Requêtes non efficaces
  • Surcharge de l'enregistreur du cluster parce que la charge en lecture n'est pas équilibrée dans le cluster
  • Configuration matérielle du lecteur inférieure à celle de l'enregistreur : impossible de synchroniser le lecteur face à la charge de travail élevée en écriture
  • Tâches internes telles que la récupération des déchets dans le cluster Amazon DocumentDB
  • Trop de connexions à la base de données (inactives)
  • Courtes rafales de connexions

Pour identifier les principales sources d'utilisation du processeur dans votre instance Amazon DocumentDB, passez en revue les aspects suivants :

  • Métriques Amazon CloudWatch
  • Informations sur les performances
  • Requêtes de base de données natives
  • Vérification de l'efficacité des requêtes
  • Paramètres de journalisation agressifs

Après avoir identifié la cause, analysez et optimisez votre charge de travail afin de réduire l'utilisation du processeur. Si le problème persiste, augmentez la taille de votre instance en fonction de la charge de travail.

Résolution

Utiliser les métriques CloudWatch

Amazon DocumentDB s'intègre à CloudWatch pour vous permettre de recueillir et d'analyser les métriques opérationnelles de vos clusters.

Grâce auxmétriques CloudWatch, vous pouvez identifier le processeur et ses modèles métriques proportionnels sur de longues périodes. Passez en revue ces métriques, puis surveillez-les dans la console CloudWatch :

  • Identifiez le nombre de connexions ouvertes selon un calendrier pertinent à l'aide des métriques DatabaseConnections et DatabaseConnectionsMax.
  • Déterminez la charge de travail globale de votre instance Amazon DocumentDB à l'aide des métriques WriteIOPs, ReadIOPs, ReadThroughput et WriteThroughput.
  • Utilisez également les métriques DocumentsDeleted, DocumentsInserted, DocumentsReturned et DocumentsUpdated. Les métriques peuvent vous aider à comprendre la charge de travail des utilisateurs sur votre instance Amazon DocumentDB.
  • Si vous utilisez les classes d'instance T3 ou T4, consultez les métriques CPUCreditBalance et CPUSurplusCreditBalance pour vérifier la limitation du calcul.

Utiliser les métriques de Performance Insights

Identifiez les requêtes qui contribuent à la charge de la base de données et à l'état d'attente à l'aide des métriques Amazon DocumentDB Performance Insights. Dans l'option Gérer les métriques, sélectionnez la moyenne des sessions actives pour examiner la charge et la répartition du processeur (system%, user% ou total%).

Une charge moyenne supérieure au nombre de vCPU indique que l'instance est soumise à une charge importante. Par exemple, la charge moyenne peut être inférieure au nombre de vCPU pour la classe d'instance de base de données. Cela indique que la limitation du processeur n'est peut-être pas à l'origine de la latence des applications. Vérifiez la charge moyenne et analysez les états d'attente pertinents pour comprendre la cause d'une utilisation élevée du processeur, telle que les E/S, les verrous et les loquets.

Utiliser des requêtes de base de données natives

Les requêtes natives peuvent vous aider à analyser la charge de travail et à vérifier l'utilisation du processeur. Utilisez le shell MongoDB pour exécuter la requête suivante. Elle répertorie toutes les opérations actuellement exécutées sur une instance Amazon DocumentDB :

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

Cette requête utilise la commande currentOp pour répertorier toutes les requêtes bloquées ou exécutées 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,
                                        WaitState: 1,
                                        blockedOn: 1,
                                        command: 1}}],
                 cursor: {}
                });

Pour analyser les résultats d'utilisation du système, exécutez cette requête sur l'instance dont vous avez constaté une utilisation élevée du processeur. Cette requête renvoie un agrégat de toutes les requêtes exécutées dans chaque espace de noms. Elle répertorie également toutes les tâches internes du système et le nombre unique d'états d'attente par espace de noms.

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

Remarque : la métrique GARBAGE_COLLECTION figurant dans les tâches internes est l'implémentation MVCC dans le cluster Amazon DocumentDB. Il s'agit d'un outil de nettoyage d'arrière-plan qui supprime les versions mortes des documents et indique le nombre de mises à jour ou de suppressions de votre base de données. Le processus de nettoyage est déclenché en fonction de seuils internes au niveau de la collection. Il entraîne des IOPS en lecture/écriture et l'utilisation du processeur.

Vérifier l'efficacité des requêtes

Vérifier la surcharge des index des requêtes en écriture

Un trop grand nombre d'index ou un grand nombre d'index inutilisés associés à votre base de données peut contribuer à la surcharge de vos écritures. Passez en revue les statistiques d'index afin d'identifier les index et analyser leur utilisation.

Consulter le plan d'exécution de la requête à l'aide de la commande explain

Les requêtes peuvent s'exécuter lentement, car elles nécessitent une analyse complète de la collection pour sélectionner les documents pertinents. Pour accélérer la requête, créez des index appropriés.

Pour identifier les champs sur lesquels vous souhaitez créer des index, exécutez la commande explain. Vous pouvez également utiliser les journaux du profileur pour capturer les requêtes de longue durée et les détails de leurs opérations.

Consulter les statistiques des collections

Consultez les statistiques suivantes pour les collections que vous utilisez :

  • Consultez la section Principales requêtes dans Performance Insights pour identifier les collections qui contribuent le plus à la charge.
  • Pour connaître le nombre d'opérations d'insertion, de mise à jour et de suppression effectuées sur une collection, consultez les statistiques de la collection. Vous pouvez également consulter le nombre d'analyses d'index et de collections complètes effectuées.
  • Divisez vos collections afin de réduire la taille des documents à traiter, en particulier si vous devez effectuer un grand nombre d'opérations de mise à jour.

Vérifier les paramètres de journalisation agressive

L'audit des événements est prioritaire par rapport au trafic de base de données. Si l'audit n'est pas nécessaire, vous pouvez le désactiver. Si vous avez besoin d'un audit, définissez le paramètre audit_logs pour enregistrer uniquement les événements nécessaires. Prévoyez une charge accrue, puis passez à une classe d'instance plus importante si nécessaire.

Afin d'éviter une journalisation agressive, dans les journaux du profileur, assurez-vous d'avoir défini la valeur correcte du paramètre profiler_threshold_ms. Examinez la charge de travail de votre application afin d'identifier le seuil approprié dont vous avez besoin pour classer une requête comme étant de longue durée.

Vérifiez que vous avez activé l'option d'exportation des journaux pour les journaux que vous souhaitez exporter vers CloudWatch.

Adopter les bonnes pratiques

Transférer la charge de travail en lecture au lecteur

Si vous avez plusieurs instances de base de données dans votre cluster Amazon DocumentDB, transférez la charge de travail en lecture vers votre instance de lecteur. Lorsque vous vous connectez en tant que jeu de réplicas, spécifiez le paramètre readPreference pour la connexion. Si vous spécifiez une préférence de lecture de secondaryPreferred, le client tente d'acheminer les requêtes en lecture vers vos réplicas. Le client tente d'acheminer les requêtes en écriture vers votre instance de base de données principale.

Notez que les lecteurs finissent par avoir une certaine cohérence. Si une charge de travail nécessite une plus grande cohérence de lecture après écriture, utilisez la préférence de lecture dynamique et remplacez-la au niveau de la requête. Par exemple, vous pouvez définir la préférence secondaryPreferred par défaut au niveau de la connexion afin d'acheminer les requêtes vers les instances secondaires. Si vous avez des requêtes qui nécessitent une meilleure cohérence de lecture après écriture, vous pouvez remplacer la valeur par défaut. Consultez cet exemple :

db.collection.find().readPref("primary")

Ajouter une ou plusieurs instances de lecteur au cluster

Si vous avez un cluster Amazon DocumentDB avec une seule instance de base de données (lecture seule), ajoutez une ou plusieurs instances de base de données de lecteur au cluster. Utilisez ensuite readPreference=secondaryPreferred pour gérer efficacement la charge.

Utiliser Amazon DocumentDB Profiler pour identifier les requêtes lentes

Utilisez Amazon DocumentDB Profiler pour enregistrer les requêtes lentes. Si une requête apparaît à plusieurs reprises dans les journaux des requêtes lentes, vous aurez peut-être besoin d'un index supplémentaire pour améliorer les performances.

Recherchez les requêtes de longue durée comportant une ou plusieurs étapes et qui exécutent au moins une étape COLLSCAN. Cela indique que l'étape de la requête doit lire tous les documents de la collection pour fournir une réponse à la requête.

Pour plus d'informations, consultez la page Profiler les requêtes lentes dans Amazon DocumentDB (compatible avec MongoDB) (langue française non garantie).

Créer une notification d'alerte avec CloudWatch

[Créez une alerte CloudWatch](https://aws.amazon.com/blogs/database/monitoring-metrics-and-setting-up-alarms-on-your-amazon-documentdb-with-mongodb-compatibility-clusters/) qui vous avertit lorsque la métrique Utilisation du processeur dépasse un certain seuil.

Augmenter la classe de vos instances de base de données

S'il n'existe aucune autre possibilité d'ajuster des requêtes, augmentez la classe des instances du cluster pour gérer la charge de travail.

**Remarque :**l'augmentation de la classe d'instance entraîne une augmentation des coûts. Pour plus d'informations, consultez la tarification d'Amazon DocumentDB.

Informations connexes

Mettre à l'échelle ds clusters Amazon DocumentDB

Performances et utilisation des ressources

Comment indexer sur Amazon DocumentDB (compatible avec MongoDB)

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an