Comment puis-je résoudre les problèmes liés à l’utilisation élevée du processeur sur mon instance de base de données Amazon RDS for MySQL ou Aurora compatible avec MySQL ?

Lecture de 10 minute(s)

Je constate une utilisation élevée du processeur sur mon Amazon Relational Database Service (Amazon RDS) pour des instances de base de données MySQL ou sur mes instances Amazon Aurora édition compatible avec MySQL.

Brève description

L’augmentation de l’utilisation du processeur peut être due à plusieurs facteurs : charges de travail volumineuses lancées par l’utilisateur, multiples requêtes simultanées ou transactions de longue durée.

Pour identifier la source de l'utilisation du processeur dans votre instance de base de données, vérifiez les ressources suivantes :

Surveillance améliorée
Performance Insights
Requêtes détectant la cause de l’utilisation du processeur dans la charge de travail
Journaux avec surveillance activée

Après avoir identifié la cause, analysez et optimisez votre charge de travail afin de réduire l'utilisation du processeur.

Résolution

Utiliser la surveillance améliorée

La surveillance améliorée fournit une vue au niveau du système d'exploitation (OS) afin d'identifier la cause d'une charge de processeur élevée. Par exemple, vous pouvez consulter la charge moyenne, la distribution du processeur (system% ou nice%) et la liste des processus du système d’exploitation.

Grâce à Surveillance améliorée, vous pouvez consulter les données loadAverageMinute à des intervalles de 1, 5 et 15 minutes. Une charge moyenne supérieure au nombre de processeurs virtuels indique que l’instance est soumise à une charge importante. Si la charge moyenne est inférieure au nombre de processeurs virtuels pour la classe d’instance de base de données, il est possible que la limitation du processeur ne soit pas à l’origine de la latence de l’application. Lors du diagnostic de la cause d’utilisation du processeur, vérifiez la charge moyenne pour éviter les faux positifs.

Par exemple, supposons que vous ayez une instance de base de données utilisant une classe d’instance db.m5.2xlarge de 3000 IOPS provisionnées qui atteint la limite du processeur. Huit vCPU sont associés à la classe d'instance. Une charge moyenne supérieure à 170 indique que la machine est soumise à une charge importante pendant la période mesurée :

Charge moyenne en minutes


Quinze	170,25
Cinq	391,31
Un	596,74

Utilisation du processeur


Utilisateur (%)	0,71
Système (%)	4,9
Nice (%)	93,92
Total (%)	99,97

Remarque : Amazon RDS donne à votre charge de travail une priorité supérieure aux autres tâches exécutées sur l’instance de base de données. Pour hiérarchiser ces tâches, les tâches liées à la charge de travail ont une valeur Nice supérieure. Par conséquent, dans Surveillance améliorée, Nice (%) représente la part du processeur utilisée par votre charge de travail vis-à-vis de la base de données.

Une fois que la surveillance améliorée est activée, consultez également la liste des processus du système d’exploitation associée à l’instance de base de données. Surveillance améliorée indique un maximum de 100 processus. Cela peut vous aider à identifier les processus ayant le plus d’impact sur les performances selon l’utilisation du processeur et de la mémoire.

Dans la section Liste des processus du système d'exploitation de la Surveillance améliorée, examinez les processus du système d’exploitation et les processus RDS. Vérifiez le pourcentage d’utilisation du processeur d’un processus mysqld ou aurora. Ces métriques peuvent vous aider à confirmer si l’augmentation de l’utilisation du processeur est due au système d’exploitation ou aux processus de RDS. Vous pouvez également utiliser ces métriques pour surveiller toute augmentation de l’utilisation du processeur due à mysqld ou Aurora. Pour voir la répartition de l'utilisation du processeur, consultez les métriques de cpuUtilization. Pour plus d’informations, consultez la section Surveillance des métriques du système d’exploitation avec Surveillance améliorée.

Remarque : Si vous activez Schéma des performances, vous pouvez mapper l’identifiant de thread du système d’exploitation à celui du processus de votre base de données. Pour plus d’informations, consultez la section Pourquoi mon instance de base de données Amazon RDS utilise-t-elle de la mémoire d’échange quand je dispose de suffisamment de mémoire ?

Utiliser Performance Insights

Vous pouvez utiliser Performance Insights pour identifier les requêtes exécutées sur l'instance de base de données qui entraînent une utilisation élevée du processeur. Tout d’abord, activez Performance Insights for MySQL. Puis, utilisez Performance Insights pour optimiser votre charge de travail. Si nécessaire, contactez votre administrateur de base de données pour identifier la cause racine du problème.

Pour voir les moteurs de base de données que vous pouvez utiliser avec Performance Insights, consultez la section Prise en charge du moteur de base de données Amazon RDS, des régions AWS et des classes d'instances pour Performance Insights.

Utiliser des requêtes pour détecter la cause de l’utilisation du processeur dans la charge de travail

Avant de pouvoir optimiser votre charge de travail, vous devez identifier la requête à problème. Pour identifier la cause racine de l’utilisation du processeur, exécutez les requêtes suivantes en cas de problème de processeurs surchargés.

Pour afficher les threads qui s'exécutent sur votre instance MySQL, exécutez la commande SHOW FULL PROCESSLIST :

SHOW FULL PROCESSLIST;

Remarque : Exécutez la requête SHOW PROCESSLIST en tant qu’utilisateur principal du système. Si vous n’êtes pas l’utilisateur principal du système, vous devez disposer d’autorisations d’administration de serveur MySQL PROCESS pour voir tous les threads exécutés sur une instance MySQL. Sans autorisations d’administration, SHOW PROCESSLIST n’affiche que les threads associés au compte MySQL que vous êtes en train d’utiliser.

Parfois, un même ensemble d’instructions peut se poursuivre sans prendre fin. Dans ce cas, les instructions suivantes doivent attendre la fin de la première série d’instructions. Cela est dû au fait que le verrouillage au niveau des lignes d’InnoDB peut mettre à jour les mêmes lignes. Pour plus d’informations, consultez la page 13.7.5.29 Instruction SHOW PROCESSLIST sur le site Web de MySQL.

La table INNODB_TRX fournit des informations sur toutes les transactions InnoDB en cours d’exécution qui ne sont pas des transactions en lecture seule. Pour afficher la table INNODB_TRX, exécutez la requête suivante :

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

La table INNODB_LOCKS fournit des informations sur les verrous qu’une transaction InnoDB a demandés, mais pas reçus. Pour afficher la table INNODB_LOCKS, exécutez la requête suivante :

Pour MySQL 5.7 ou version antérieure :

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

MySQL 8.0 :

SELECT * FROM performance_schema.data_locks;

Pour plus d'informations, consultez les pages 24.4.14 La table INFORMATION_SCHEMA.INNODB_LOCKS et 10.13.1 La table data_locks sur le site Web de MySQL.

La table INNODB_LOCK_WAITS fournit une ou plusieurs lignes pour chaque transaction InnoDB bloquée. Pour afficher la table INNODB_LOCKS_WAITS, exécutez la requête suivante.

Pour MySQL 5.7 ou version antérieure :

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

MySQL 8.0 :

SELECT * FROM performance_schema.data_lock_waits;

Pour voir les transactions en attente et les transactions qui bloquent les transactions en attente, vous pouvez exécuter une requête similaire à la suivante :

Pour MySQL 5.7 ou version antérieure :

SELECT  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,
  r.trx_query waiting_query,
  b.trx_id blocking_trx_id,
  b.trx_mysql_thread_id blocking_thread,
  b.trx_query blocking_query
FROM       information_schema.innodb_lock_waits w
INNER JOIN information_schema.innodb_trx b
  ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.innodb_trx r
  ON r.trx_id = w.requesting_trx_id;

MySQL 8.0 :

SELECT  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,
  r.trx_query waiting_query,
  b.trx_id blocking_trx_id,
  b.trx_mysql_thread_id blocking_thread,
  b.trx_query blocking_query
FROM       performance_schema.data_lock_waits w
INNER JOIN information_schema.innodb_trx b
  ON b.trx_id = w.blocking_engine_transaction_id
INNER JOIN information_schema.innodb_trx r
  ON r.trx_id = w.requesting_engine_transaction_id;

Pour plus d'informations sur la façon d'interpréter le résultat de cette requête, consultez la page 17.15.2.1 Utilisation des informations de transaction et de verrouillage d'InnoDB sur le site Web de MySQL.

Pour obtenir des informations à partir du moniteur InnoDB standard sur l'état du moteur de stockage InnoDB, exécutez la requête suivante :

SHOW ENGINE INNODB STATUS;

Pour plus d’informations, consultez la page 13.7.5.15 Instruction SHOW ENGINE sur le site Web de MySQL.

Pour afficher le statut du serveur, exécutez la commande suivante.

SHOW GLOBAL STATUS;

Pour plus d’informations, consultez la page 15.7.7.37 Instruction SHOW STATUS sur le site Web de MySQL.

Analyser les journaux et activer la surveillance

Analysez le journal des requêtes générales de MySQL pour voir ce que fait mysqld à un moment précis. Vous pouvez également visualiser les requêtes en cours d’exécution sur votre instance à un moment précis, telles que des informations sur les heures de connexion ou de déconnexion de clients. Pour plus d’informations, consultez la page 7.4.3 Le journal des requêtes générales sur le site Web de MySQL.

Important : Lorsque vous activez le journal des requêtes générales pendant de longues périodes, les journaux consomment de l’espace de stockage et peuvent alourdir les performances.

Analysez les MySQL Slow Query Logs pour trouver les requêtes dont l’exécution prend plus de temps que les secondes que vous avez définies pour long_query_time. Vous pouvez également examiner votre charge de travail et analyser vos requêtes pour améliorer les performances et la charge de mémoire. Pour plus d’informations, consultez la page 7.4.5 Le journal des requêtes générales sur le site Web de MySQL.

Remarque : Lorsque vous utilisez le journal des requêtes lentes ou le journal des requêtes générales, il est recommandé de définir le paramètre log_output sur FILE.

Utilisez le plugin Audit MariaDB pour consulter l’activité des bases de données. Par exemple, suivez les utilisateurs qui se connectent à la base de données ou les requêtes exécutées sur la base de données.

Si vous utilisez Aurora pour MySQL, vous pouvez également utiliser Audit avancé. Audit avancé permet de mieux contrôler les types de requêtes que vous souhaitez enregistrer et de réduire les frais liés à la journalisation.

Utilisez le paramètre innodb_print_all_deadlocks pour vérifier les blocages et le verrouillage des ressources. Vous pouvez utiliser ce paramètre pour enregistrer des informations sur les blocages des transactions utilisateur d’InnoDB dans le journal d’erreurs de MySQL. Pour plus d’informations, consultez la page innodb_print_all_deadlocks sur le site Web de MySQL.

Analyser et optimiser la charge de travail élevée du processeur

Après avoir identifié la requête qui augmente l’utilisation du processeur, optimisez votre charge de travail pour réduire son utilisation.

Si vous voyez une requête superflue pour votre charge de travail, vous pouvez résilier la connexion à l’aide de la commande suivante :

CALL mysql.rds_kill(processID);

Pour trouver l’identifiant de processus d’une requête, exécutez la commande SHOW FULL PROCESSLIST.

Si vous ne souhaitez pas terminer la requête, utilisez la commande EXPLAIN pour l’optimiser. EXPLAIN montre les différentes étapes à suivre lorsque vous exécutez une requête. Pour plus d’informations, consultez la page 10.8.1 Optimisation des requêtes avec EXPLAIN sur le site Web de MySQL.

Pour consulter les détails du profil, activez le profilage. La commande SHOW PROFILE indique l'utilisation des ressources pour les instructions qui s'exécutent pendant la session en cours. Pour plus d’informations, consultez la page 15.7.7.30 Instruction SHOW PROFILE sur le site Web de MySQL.

Pour afficher et optimiser les statistiques de la table, utilisez la requête ANALYZE TABLE. Pour plus d’informations, consultez la page 15.7.3.1 Instruction ANALYZE TABLE sur le site Web de MySQL.