Résolution des problèmes de charge de travail pour les SQL bases de données Aurora My - Amazon Aurora
Métriques relatives à l'hôte deMé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 SQL bases de données Aurora My

La charge de travail de la base 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 modifier le plan d'exécution des requêtes. Lorsque vous mettez à niveau des versions de base de données, en particulier 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. Le réglage peut impliquer l'optimisation et la réécriture de 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 dans My SQL 8.0 et Server et variables d'état et options ajoutées, déconseillées ou supprimées dans My SQL 8.0 dans Ma SQL documentation, et. Comparaison entre Aurora My SQL version 2 et Aurora My SQL 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 au schéma ou à la base de données ?

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

Table des matières

Métriques relatives à l'hôte de

Surveillez les métriques de l'hôte de l'instanceCPU, telles que la mémoire et l'activité réseau, afin de déterminer s'il y a eu un changement de charge de travail. Deux concepts principaux permettent de comprendre l'évolution de la charge de travail :

  • Utilisation : utilisation d'un périphérique, tel qu'CPUun disque. Il peut être basé sur le temps ou sur les capacités.

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

    • Basé 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 CPU

Vous pouvez utiliser les outils suivants pour identifier CPU l'utilisation et la saturation :

  • CloudWatch fournit la CPUUtilization métrique. Si ce chiffre atteint 100 %, l'instance est saturée. Cependant, CloudWatch les mesures sont moyennées sur une minute et manquent de granularité.

    Pour plus d'informations sur CloudWatch les métriques, consultezMétriques de niveau instance pour Amazon Aurora.

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

    • Idle (%)= Temps d'inactivité

    • IRQ (%)= Interruptions logicielles

    • Nice (%)= C'est le moment idéal pour les processus avec une bonne priorité.

    • Steal (%)= Temps passé à servir les autres locataires (lié à la virtualisation)

    • System (%)= Heure du système

    • User (%)= Heure de l'utilisateur

    • Wait (%)= Attendre les E/S

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

Utilisation de la mémoire

Si le système est soumis à une pression de mémoire et que la consommation de ressources atteint la saturation, vous devriez observer un degré élevé de numérisation de pages, de pagination, d'échange et out-of-memory d'erreurs.

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

CloudWatch fournit la FreeableMemory métrique, 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 libre actuelle.

Pour plus d'informations sur CloudWatch les métriques, consultezMétriques de niveau instance pour Amazon Aurora.

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

  • Buffers (KB)— Quantité de mémoire utilisée pour mettre en mémoire tampon les demandes d'E/S avant d'écrire sur 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 de la Swap mémoire, 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 de régler votre charge de travail pour utiliser moins de mémoire.

Pour plus d'informations sur les métriques de surveillance améliorée, consultezMé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 sys schéma afin de déterminer les connexions et les composants qui utilisent de la mémoire, consultezRésolution des problèmes d'utilisation de la mémoire pour les SQL bases de données Aurora My.

Débit réseau

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

  • NetworkReceiveThroughput— Le débit réseau reçu des clients par chaque instance du cluster de base de données Aurora.

  • NetworkTransmitThroughput— Le débit réseau envoyé aux clients par chaque instance du cluster de base de données Aurora.

  • NetworkThroughput— Le débit réseau reçu et transmis aux clients par chaque instance du cluster de base de données Aurora.

  • StorageNetworkReceiveThroughput— Le débit réseau reçu du sous-système de stockage Aurora par chaque instance du cluster de base de données.

  • StorageNetworkTransmitThroughput— Le débit réseau envoyé au sous-système de stockage Aurora par chaque instance du cluster de base de données Aurora.

  • StorageNetworkThroughput— Le débit réseau reçu et envoyé au sous-système de stockage Aurora par chaque instance du cluster de base de données Aurora.

Pour plus d'informations sur CloudWatch les métriques, consultezMé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, consultezMétriques de système d'exploitation pour Aurora.

Métriques de base de données

Examinez les CloudWatch mesures suivantes pour connaître les modifications de la charge de travail :

  • BlockedTransactions— Le nombre moyen de transactions bloquées par seconde dans la base de données.

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

  • CommitThroughput— Le nombre moyen d'opérations de validation par seconde.

  • DatabaseConnections— Le nombre de connexions réseau client à l'instance de base de données.

  • Deadlocks— Le nombre moyen de blocages dans la base de données par seconde.

  • DMLThroughput— Nombre moyen d'insertions, de mises à jour et de suppressions par seconde.

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

  • RollbackSegmentHistoryListLength— Les journaux d'annulation qui enregistrent les transactions validées avec des enregistrements marqués de suppression.

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

  • SelectThroughput— Nombre moyen de requêtes de sélection par seconde.

Pour plus d'informations sur CloudWatch les métriques, consultezMé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 la réduction de la taille de l'instance de 8 x large à 4 x large, ou le passage de db.r5 à db.r6 ?

  2. Pouvez-vous créer un clone et reproduire le problème, ou cela ne se produit-il que sur cette seule instance ?

  3. Y a-t-il un épuisement des ressources du serveur, un niveau élevé CPU ou un épuisement de la mémoire ? 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 mesures avant et après la mise à niveau.

  6. Le nombre d'instances de base de données de lecture a-t-il changé ?

  7. Avez-vous activé la journalisation générale, la journalisation d'audit ou la journalisation binaire ? Pour de plus amples informations, veuillez consulter 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 d'InnoDB (HLL) pour des indications de transactions de longue durée.

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

    1. Si un volume important HLL est dû à une transaction d'écriture, cela signifie que les UNDO journaux s'accumulent (ils ne sont pas nettoyés régulièrement). Dans le cas d'une transaction d'écriture importante, cette accumulation peut augmenter rapidement. Dans MySQL, UNDO est stocké dans le SYSTEMtablespace. Le SYSTEM tablespace n'est pas rétrécible. Le UNDO journal peut entraîner une augmentation SYSTEM de l'espace disque logique jusqu'à 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 un volume important HLL est dû à 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 redémarrant. Examinez les métriques de la base de données Performance Insights pour détecter toute modification apportée à la Temp section, telle quecreated_tmp_tables. Pour de plus amples informations, veuillez consulter Surveillance de la charge de base de données avec Performance Insights sur Amazon Aurora.

  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 dans les 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 Locks sectioninnodb_row_lock_time, telles que innodb_row_lock_waits, et innodb_dead_locks. Utilisez des intervalles de 1 minute ou 5 minutes.

  12. Y a-t-il une augmentation des temps d'attente ? Examinez les événements d'attente et les types d'attente de Performance Insights à intervalles d'une 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 dans les bases de données. buf_pool mutexIndique, par exemple, la contention du pool de mémoire tampon. Pour de plus amples informations, veuillez consulter Réglage d'Aurora MySQL avec des événements d'attente.