Résolution des problèmes de charge de travail pour les bases de données Aurora MySQL - Amazon Aurora
Métriques de l’hôte de l’instanceMétriques de base de données

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 de charge de travail pour les bases de données Aurora MySQL

La charge de travail des bases de données peut être considérée sous forme de lectures et d’écritures. En comprenant la charge de travail « normale » des bases de données, vous pouvez ajuster les requêtes et le serveur de base de données en fonction de l’évolution de la demande. Les performances peuvent changer pour différentes raisons. La première étape consiste donc à comprendre ce qui a changé.

  • Y a-t-il eu une mise à niveau de version majeure ou mineure ?

    Une mise à niveau de version majeure inclut des modifications du code du moteur, en particulier dans l’optimiseur, qui peuvent avoir un impact sur le plan d’exécution des requêtes. Lorsque vous mettez à niveau des versions de base de données, notamment des versions majeures, il est très important d’analyser la charge de travail de la base de données et de l’ajuster en conséquence. L’ajustement peut impliquer l’optimisation et la réécriture des requêtes, ou l’ajout et la mise à jour de paramètres, en fonction des résultats des tests. Comprendre la cause de l’impact vous permettra de commencer à vous concentrer sur ce domaine spécifique.

    Pour plus d’informations, consultez Nouveautés de MySQL 8.0 et Ajout, abandon ou suppression des variables et options de serveur et d’état dans MySQL 8.0 dans la documentation MySQL, et Comparaison d’Aurora MySQL version 2 et Aurora MySQL version 3.

  • Y a-t-il eu une augmentation du nombre de données traitées (nombre de lignes) ?

  • D’autres requêtes sont-elles exécutées simultanément ?

  • Y a-t-il des modifications du schéma ou de la base de données ?

  • Y a-t-il eu des défauts ou des corrections de code ?

Table des matières

Métriques de l’hôte de l’instance

Surveillez les métriques de l’hôte de l’instance telles que le processeur, la mémoire et l’activité réseau afin de déterminer si la charge de travail a changé. Deux concepts principaux permettent de comprendre l’évolution de la charge de travail :

  • Utilisation : utilisation d’un périphérique, tel qu’un processeur ou un disque. Elle peut être basée sur le temps ou sur la capacité.

    • Basée sur le temps : durée pendant laquelle une ressource est occupée au cours d’une période d’observation donnée.

    • Basée sur la capacité : débit qu’un système ou un composant peut fournir, en pourcentage de sa capacité.

  • Saturation : mesure dans laquelle une ressource demande plus de travail qu’elle ne peut en traiter. Lorsque l’utilisation basée sur la capacité atteint 100 %, le travail supplémentaire ne peut pas être traité et doit être mis en file d’attente.

Utilisation de l’UC

Vous pouvez utiliser les outils suivants pour identifier l’utilisation et la saturation du processeur :

  • CloudWatch fournit la métrique CPUUtilization. Si ce chiffre atteint 100 %, l’instance est saturée. Cependant, les métriques CloudWatch se basent sur une moyenne calculée sur une minute et manquent donc de granularité.

    Pour plus d’informations sur les métriques CloudWatch, consultez Métriques de niveau instance pour Amazon Aurora.

  • La surveillance améliorée fournit les métriques renvoyées par la commande top du système d’exploitation. Elle affiche les moyennes de charge et les états de processeur suivants, avec une granularité d’une seconde :

    • Idle (%) = délai d’inactivité

    • IRQ (%) = interruptions logicielles

    • Nice (%) = moment parfait pour les processus avec une bonne priorité.

    • Steal (%) = temps passé à desservir les autres locataires (lié à la virtualisation)

    • System (%) = heure du système

    • User (%) = heure de l’utilisateur

    • Wait (%) = attente d’E/S

    Pour plus d’informations sur les métriques de surveillance améliorée, consultez Métriques de système d’exploitation pour Aurora.

Utilisation de la mémoire

Si le système est soumis à une forte charge de mémoire et que la consommation des ressources atteint la saturation, vous devriez observer un taux élevé d’erreurs liées à l’analyse, à la pagination, à l’échange et à l’épuisement de la mémoire.

Vous pouvez utiliser les outils suivants pour identifier l’utilisation et la saturation de la mémoire :

CloudWatch fournit la métrique FreeableMemory qui indique la quantité de mémoire pouvant être récupérée en vidant certains caches du système d’exploitation et la mémoire disponible actuellement.

Pour plus d’informations sur les métriques CloudWatch, consultez Métriques de niveau instance pour Amazon Aurora.

La surveillance améliorée fournit les métriques suivantes qui peuvent vous aider à identifier les problèmes d’utilisation de la mémoire :

  • Buffers (KB) : quantité de mémoire utilisée pour la mise en mémoire tampon des demandes d’E/S avant écriture dans le périphérique de stockage, en kilo-octets.

  • Cached (KB) : quantité de mémoire utilisée pour la mise en cache des E/S basées sur le système de fichiers.

  • Free (KB) : quantité de mémoire non attribuée, en kilo-octets.

  • Swap : en cache, gratuit et total.

Par exemple, si vous constatez que votre instance de base de données utilise la mémoire Swap, la quantité totale de mémoire pour votre charge de travail est supérieure à celle dont dispose actuellement votre instance. Nous vous recommandons d’augmenter la taille de votre instance de base de données ou d’ajuster votre charge de travail pour qu’elle utilise moins de mémoire.

Pour plus d’informations sur les métriques de surveillance améliorée, consultez Métriques de système d’exploitation pour Aurora.

Pour des informations plus détaillées sur l’utilisation du schéma de performance et du schéma sys afin de déterminer les connexions et les composants qui utilisent de la mémoire, consultez Résolution des problèmes d’utilisation de la mémoire pour les bases de données Aurora MySQL.

Débit réseau

CloudWatch fournit les métriques suivantes concernant le débit total du réseau, toutes calculées en moyenne sur une minute :

  • NetworkReceiveThroughput : quantité de débit réseau reçue des clients par chaque instance du cluster de bases de données Aurora.

  • NetworkTransmitThroughput : quantité de débit réseau envoyée aux clients par chaque instance du cluster de bases de données Aurora.

  • NetworkThroughput : quantité de débit réseau reçue des clients et transmise à ces derniers par chaque instance du cluster de bases de données Aurora.

  • StorageNetworkReceiveThroughput : quantité de débit réseau reçue du sous-système de stockage Aurora par chaque instance du cluster de bases de données.

  • StorageNetworkTransmitThroughput : quantité de débit réseau envoyée au sous-système de stockage Aurora par chaque instance du cluster de bases de données Aurora.

  • StorageNetworkThroughput : quantité de débit réseau reçue du sous-système de stockage Aurora et envoyée à celui-ci par chaque instance du cluster de bases de données Aurora.

Pour plus d’informations sur les métriques CloudWatch, consultez Métriques de niveau instance pour Amazon Aurora.

La surveillance améliorée fournit les graphiques network reçus (RX) et transmis (TX), avec une granularité allant jusqu’à une seconde.

Pour plus d’informations sur les métriques de surveillance améliorée, consultez Métriques de système d’exploitation pour Aurora.

Métriques de base de données

Examinez les métriques CloudWatch suivantes pour identifier les modifications de la charge de travail :

  • BlockedTransactions : nombre moyen de transactions de la base de données bloquées par seconde.

  • BufferCacheHitRatio : pourcentage de demandes traitées par le cache de tampon.

  • CommitThroughput : nombre moyen d’opérations de validation par seconde.

  • DatabaseConnections : nombre de connexions réseau client à l’instance de base de données.

  • Deadlocks : nombre moyen de blocages de la base de données par seconde.

  • DMLThroughput : nombre moyen d’insertions, de mises à jour et de suppressions par seconde.

  • ResultSetCacheHitRatio : pourcentage de demandes traitées par le cache de requêtes.

  • RollbackSegmentHistoryListLength : journaux d’annulation qui enregistrent les transactions validées avec des enregistrements marqués pour la suppression.

  • RowLockTime : temps total passé à acquérir des verrous de ligne pour les tables InnoDB.

  • SelectThroughput : nombre moyen de requêtes SELECT par seconde.

Pour plus d’informations sur les métriques CloudWatch, consultez Métriques de niveau instance pour Amazon Aurora.

Lorsque vous examinez la charge de travail, posez-vous les questions suivantes :

  1. Y a-t-il eu des changements récents dans la classe d’instance de base de données, par exemple une réduction de la taille de l’instance qui serait passé de 8xlarge à 4xlarge, ou le passage de db.r5 à db.r6 ?

  2. Peut-on créer un clone et reproduire le problème, ou cela se produit-il uniquement sur cette instance ?

  3. Les ressources du serveur sont-elles épuisées, le processeur est-il trop élevé ou la mémoire est-elle saturée ? Dans l’affirmative, cela peut signifier que du matériel supplémentaire est nécessaire.

  4. Une ou plusieurs requêtes prennent-elles plus de temps ?

  5. Les modifications sont-elles causées par une mise à niveau, en particulier une mise à niveau de version majeure ? Dans l’affirmative, comparez les métriques avant et après la mise à niveau.

  6. Y a-t-il des changements du nombre d’instances de base de données en écriture ?

  7. Avez-vous activé la journalisation générale, la journalisation d’audit ou la journalisation binaire ? Pour plus d’informations, consultez Journalisation pour les bases de données Aurora MySQL.

  8. Avez-vous activé, désactivé ou modifié votre utilisation de la réplication des journaux binaires (binlog) ?

  9. Existe-t-il des transactions de longue durée comportant un grand nombre de verrous de ligne ? Examinez la longueur de la liste d’historique (HLL) d’InnoDB pour obtenir des indications sur les transactions de longue durée.

    Pour plus d’informations, consultez La longueur de la liste d’historique InnoDB a considérablement augmenté et le billet de blog Pourquoi ma requête SELECT s’exécute-t-elle lentement sur mon cluster de bases de données Amazon Aurora MySQL ?.

    1. Si une grande longueur de la liste d’historique est causée par une transaction d’écriture, cela signifie que les journaux UNDO s’accumulent (ils ne sont donc pas nettoyés régulièrement). Dans le cas d’une transaction d’écriture de grande taille, cette accumulation peut augmenter rapidement. Dans MySQL, UNDO est stocké dans l’espace de table SYSTEM. La taille de l’espace de table SYSTEM ne peut pas être réduite. Le journal UNDO peut entraîner une augmentation de l’espace de table SYSTEM pouvant atteindre plusieurs Go, voire plusieurs To. Après la purge, libérez l’espace alloué en effectuant une sauvegarde logique (vidage) des données, puis importez le vidage dans une nouvelle instance de base de données.

    2. Si une grande longueur de la liste d’historique est causée par une transaction de lecture (requête de longue durée), cela peut signifier que la requête utilise une grande quantité d’espace temporaire. Libérez l’espace temporaire en effectuant un redémarrage. Examinez les métriques de la base de données Performance Insights pour détecter toute modification dans la section Temp, telle que created_tmp_tables. Pour plus d’informations, consultez Surveillance de la charge de la base de données avec Performance Insights sur .

  10. Pouvez-vous diviser les transactions de longue durée en transactions plus petites qui modifient moins de lignes ?

  11. Y a-t-il des changements des transactions bloquées ou une augmentation des blocages ? Examinez les métriques de la base de données Performance Insights pour détecter toute modification apportée aux variables d’état dans la section Locks, telles que innodb_row_lock_time, innodb_row_lock_waits et innodb_dead_locks. Utilisez des intervalles de 1 minute ou de 5 minutes.

  12. Y a-t-il une augmentation des temps d’attente ? Examinez les événements et les types d’attente de Performance Insights avec des intervalles de 1 minute ou de 5 minutes. Analysez les principaux événements d’attente et déterminez s’ils sont corrélés à des modifications de la charge de travail ou à des conflits de base de données. Par exemple, buf_pool mutex indique un conflit du pool de tampons. Pour plus d’informations, consultez Réglage d'Aurora MySQL avec des événements d'attente.