Passer au contenu

Comment résoudre le problème d'utilisation élevée du processeur et de lenteur des requêtes après la mise à niveau de mon instance de base de données Amazon RDS for MySQL ou Aurora compatible avec MySQL ?

Lecture de 4 minute(s)
0

Une mise à niveau majeure a été effectuée sur mon instance de base de données Amazon Relational Database Service (Amazon RDS) for MySQL ou Amazon Aurora compatible avec MySQL. À présent, je constate des performances de requête lentes et une utilisation élevée du processeur.

Résolution

Prérequis :

Pour éviter les erreurs de diagnostic, structurez correctement votre flux de travail de dépannage et utilisez les outils et services AWS. Pour plus d'informations, consultez les articles suivants :

Vérifier les problèmes spécifiques à la mise à niveau

Lorsque vous mettez à niveau une instance, par exemple d’Aurora compatible avec MySQL 5.7 vers Aurora compatible avec MySQL 8.0, la mise à niveau peut supprimer certaines fonctionnalités de l'instance.

Si votre instance utilise des fonctionnalités obsolètes, elle peut rencontrer des problèmes de performance. Pour vérifier si la version de votre instance utilise des fonctionnalités obsolètes qui affectent votre charge de travail, consultez la section Notes de version d’Amazon Aurora édition compatible avec MySQL. Vous pouvez également consulter la page Notes de mise à jour de MySQL 8.0 sur le site Web de MySQL.

Dans l'exemple de scénario suivant, vous mettez à niveau un cluster Aurora compatible avec MySQL 5.7 vers Aurora compatible avec MySQL 8.0. Après la mise à niveau, le processeur de l'instance en écriture double, même si les requêtes, les plans d'exécution et les modèles de charge de travail sont les mêmes.

Pour résoudre ce problème, vous pouvez consulter les métriques de votre cluster Amazon RDS for MySQL ou Aurora compatible avec MySQL. En fonction du problème, comparez les métriques associées au cluster entre la version précédente et la version mise à niveau.

Exemples de métriques d’Aurora compatible avec MySQL 5.7 :

SHOW GLOBAL STATUS LIKE 'Qcache%';

Exemples de métriques d’Aurora compatible avec MySQL 8.0 :

`mysql> SHOW STATUS LIKE 'Qcache%';`  
`+-------------------------+--------+`  
`| Variable_name | Value |`  
`+-------------------------+--------+`  
`| Qcache_free_blocks | 36 |`  
`| Qcache_free_memory | 138488 |`  
`| Qcache_hits | 79570 |`  
`| Qcache_inserts | 27087 |`  
`| Qcache_lowmem_prunes | 3114 |`  
`| Qcache_not_cached | 22989 |`  
`| Qcache_queries_in_cache | 415 |`  
`| Qcache_total_blocks | 912 |`  
`+-------------------------+--------+`

Dans cet exemple, Aurora compatible avec MySQL 8.0 a supprimé une fonctionnalité qui diffusait des requêtes depuis le cache afin d'éviter les exécutions complètes. Sans cette fonctionnalité, Aurora MySQL exécute intégralement toutes les requêtes et double la charge de travail.

Si vous constatez des pics dans le processeur de l'instance, examinez les métriques suivantes :

  • Requêtes
  • Com_select
  • Innodb_rows_read

Pour résoudre les problèmes liés à ces métriques, effectuez les tâches suivantes :

Étapes de dépannage supplémentaires

Vous pouvez comparer la version précédente des plans d'exécution aux plans d'exécution des versions mises à jour afin de mieux résoudre les problèmes. Pour comparer les réglages des groupes de paramètres, utilisez la requête EXPLAIN FORMAT=JSON. Les configurations critiques, telles que innodb_buffer_pool_size doivent être identiques dans les deux versions. Pour plus d'informations, consultez les pages Configuration de la taille du pool de mémoire tampon InnoDB et Instruction EXPLAIN sur le site Web de MySQL.

Il est recommandé d'utiliser la fonctionnalité de clonage d'Aurora pour tester les mises à niveau dans un environnement intermédiaire. Vous pouvez utiliser des outils tels que Sysbench pour simuler des charges de travail dans l'environnement intermédiaire. Puis, utilisez des outils AWS tels que AWS Database Insights et Surveillance améliorée pour surveiller les métriques clés.

AWS OFFICIELA mis à jour il y a 3 mois