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

Brève description

Plusieurs facteurs peuvent contribuer à l’augmentation de l’utilisation du processeur, tels que des charges de travail volumineuses lancées par l’utilisateur, plusieurs requêtes simultanées ou des 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 à la 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. Pour éviter les faux positifs lors du diagnostic de la cause d’utilisation du processeur, vérifiez la charge moyenne.

Par exemple, vous disposez d’une instance de base de données qui utilise une classe d’instance db.m5.2xlarge et qui atteint la limite du processeur. La classe d'instance est associée à 8 processeurs virtuels. 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 qui sont exécutées sur l’instance de base de données. Pour hiérarchiser les tâches liées à la gestion, les tâches de la charge de travail ont une valeur Nice différente. Par conséquent, dans le cadre de la surveillance améliorée, Nice (%) représente la quantité de processeur utilisée par votre charge de travail par rapport à 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. La surveillance améliorée indique un maximum de 100 processus. Cette liste peut vous aider à identifier les processus qui affectent le plus les performances du processeur et de la mémoire.

Dans la section Liste de processus du système d'exploitation de la surveillance améliorée, examinez les processus du système d’exploitation et les processus RDS. Ces métriques peuvent vous aider à vérifier si le système d'exploitation ou les processus RDS augmentent l'utilisation du processeur. Vous pouvez également utiliser ces métriques pour surveiller le pourcentage de processeur utilisé par les processus mysqld ou aurora. Si le démon de stockage Aurora indique une utilisation élevée du processeur sur une instance Aurora, cela signifie que la charge de travail en lecture/écriture de l'instance est importante. Cette utilisation élevée du processeur peut également indiquer que la taille de l'instance est trop petite pour le volume de stockage et la charge de travail actuels. Ou bien, des opérations complexes se déroulent en arrière-plan.

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 le schéma de performance, vous pouvez mapper l'ID de thread du système d'exploitation à l'ID du processus uniquement pour votre instance de base de données RDS MySQL. Vous ne pouvez pas mapper l'ID de thread du système d'exploitation à l'ID de processus de votre instance de base de données Aurora MySQL. 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 d’une mémoire suffisante ?

Utiliser Database Insights

Important : Performance Insights atteindra sa fin de vie le 30 juin 2026. Vous pouvez effectuer une mise à niveau vers le mode Avancé de Database Insights avant le 30 juin 2026. Si vous n'effectuez pas de mise à niveau, les clusters de base de données qui utilisent Performance Insights passeront par défaut au mode Standard de Database Insights. Seul le mode Avancé de Database Insights prendra en charge les plans d'exécution et l’analyse à la demande. Si vos clusters passent par défaut en mode Standard, il est possible que vous ne puissiez pas utiliser ces fonctionnalités sur la console. Pour activer le mode Avancé, consultez la section Activation du mode Avancé de Database Insights pour Amazon RDS. Consultez également la section Activation du mode Avancé de Database Insights pour Amazon Aurora.

Vous pouvez utiliser Database Insights pour identifier les requêtes qui s'exécutent sur l'instance de base de données et qui entraînent une utilisation élevée du processeur.

Activez d'abord Database Insights sur votre instance MySQL. Puis, utilisez Database Insights pour optimiser votre charge de travail. Vous pouvez également contacter votre administrateur de base de données pour identifier la cause racine du problème.

Pour plus d'informations sur la prise en charge du moteur, des régions AWS et des classes d'instance, consultez la section Prise en charge du moteur, des régions et des classes d'instance Aurora DB pour Database Insights. Consultez également la section Prise en charge du moteur de base de données, des régions et des classes d'instance Amazon RDS pour Database 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ématique. Pour identifier la cause racine de l’utilisation du processeur, exécutez les requêtes suivantes lorsqu’un problème de processeur surchargé se produit.

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. Vous devez disposer des autorisations d'administration du serveur MySQL PROCESS pour voir tous les threads qui s'exécutent sur une instance MySQL. Sans autorisations d’administration, SHOW PROCESSLIST n’affiche que les threads qui sont associés au compte MySQL utilisé.

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 Instruction SHOW PROCESSLIST sur le site Web de MySQL.

La table INNODB_TRX fournit des informations sur toutes les transactions InnoDB qui sont exécutées et 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 demandés mais non reçus par une transaction InnoDB. Pour afficher la table INNODB_LOCKS, exécutez la requête suivante :

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 la section La table INFORMATION_SCHEMA.INNODB_LOCKS de MySQL 5.7 et la section La table data_locks de MySQL 8.0 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.

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 :

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 interpréter le résultat de cette requête, consultez la section Utilisation des informations de transaction et de verrouillage d'InnoDB de MySQL 8.0 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 Instruction SHOW ENGINE de MySQL 8.0 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 l’instruction SHOW STATUS de MySQL 8.0 sur le site Web de MySQL.

Pour vérifier la longueur de la liste historique (HLL), exécutez la commande suivante :

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

Si votre charge de travail nécessite plusieurs transactions ouvertes ou de longue durée, il se peut que votre base de données ait une HLL élevée. De plus, si les threads de purge ne peuvent pas accompagner les modifications de la base de données, il se peut que la HLL soit élevée. Une HLL élevée entraîne une utilisation accrue des ressources et des performances lentes et incohérentes de l'instruction SELECT.

Sur une instance d'écriture Aurora MySQL, utilisez la métrique CloudWatch RollbackSegmentHistoryListLength pour surveiller votre HLL.

Si la HLL de l'instance est élevée, examinez votre instruction SQL. Ce problème se produit lors de l’application de START TRANSACTION et en l’absence d’opération COMMIT. Étant donné que le thread est passé à l’état SLEEP, l'instruction SQL précédente n’est pas visible.

Pour résoudre ce problème, exécutez la commande suivante.

SELECT event_id, current_schema, sql_text, lock_time
 FROM performance_schema.events_statements_history
 WHERE thread_id=<thread_id>  
 ORDER BY event_id DESC;

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 qui sont exécutées 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 Le journal de requêtes générales sur le site Web de MySQL.

Important : Lorsque vous activez le journal de 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 journaux de requêtes lentes MySQL 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 de requêtes lentes ou le journal de requêtes générales, il est recommandé de définir le paramètre log_output sur FILE.

Utilisez le plug-in Audit de MariaDB pour contrôler l'activité de base de données sur Amazon RDS for MySQL ou Amazon RDS for MariaDB. 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 compatible avec MySQL, vous pouvez utiliser l’audit avancé. L’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, exécutez la commande suivante pour mettre fin à la connexion :

CALL mysql.rds_kill(processID);

Important : Lorsque vous mettez fin aux écritures DML (Data Manipulation Language, langage de manipulation des données) sur une instance, la transaction interrompue est restaurée. La restauration des mises à jour peut prendre un certain temps. Si votre requête est exécutée pendant une longue période, contactez votre administrateur de base de données pour vérifier si vous pouvez arrêter la requête.

Pour trouver l’ID 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 Optimisation de 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 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 Instruction ANALYZE TABLE sur le site Web de MySQL.

Informations connexes

Réglage d'Aurora MySQL avec des événements d'attente

Comment puis-je activer et surveiller les journaux d’une instance de base de données Amazon RDS for MySQL ?

Amazon CloudWatch Database Insights appliqué à des scénarios réels