Je constate une utilisation intensive du processeur sur mes instances Amazon Relational Database Service (Amazon RDS) pour MySQL, MariaDB ou Amazon Aurora pour MySQL. Comment puis-je identifier et résoudre une utilisation intensive du processeur ?

Plusieurs facteurs peuvent entraîner une utilisation intensive du processeur. Par exemple, des charges de travail lourdes lancées par l'utilisateur, des requêtes analytiques, des interblocages et attentes de verrouillage prolongés, des transactions simultanées multiples, des transactions à exécution longue ou d’autres processus utilisant les ressources du processeur.

Tout d'abord, vous pouvez identifier la source d'utilisation du processeur via ces processus :

  • Utilisation d’Enhanced Monitoring
  • Utilisation de Performance Insights
  • Utilisation de requêtes afin de détecter ce qui provoque l’utilisation intensive du processeur lors d’une charge de travail
  • Analyse des journaux et activation de la surveillance

Une fois la source identifiée, vous pouvez analyser et optimiser votre charge de travail afin de réduire l'utilisation du processeur.

Utilisation d’Enhanced Monitoring

Enhanced Monitoring fournit des métriques en temps réel granulaires que vous pouvez consulter, ainsi que des métriques Amazon CloudWatch, qui fournissent des statistiques toutes les minutes. Pour plus d'informations, consultez la rubrique Différences entre les métriques de CloudWatch et d’Enhanced Monitoring.

Dans la section Liste de processus du système d'exploitation d’Enhanced Monitoring, examinez les processus du système d'exploitation et RDS pour consulter le pourcentage d'utilisation du processeur lors d’un processus mysqld ou Aurora. Ces métriques peuvent vous aider à déterminer si la hausse de l’utilisation du processeur est causée par des processus du système d’exploitation ou RDS. Vous pouvez également les utiliser pour vérifier si l'augmentation est causée par mysqld ou Aurora. Le cas échéant, cela signifie qu’une charge de travail initiée par un utilisateur fait appel au processeur. Pour plus d’informations, consultez la section Affichage d’Enhanced Monitoring. Vous pouvez également voir les différentes utilisations du processeur en consultant les métriques de cpuUtilization. Pour plus d'informations, consultez la rubrique Métriques disponibles sur le système d'exploitation.

Vous pouvez également vérifier le nombre de tâches interrompues (en veille). Ces tâches peuvent entraîner une consommation accrue des ressources de mémoire (RAM, cache et processeur), ralentissant ainsi le serveur. Il est recommandé d’ajuster votre application pour fermer tranquillement les sessions non utilisées. Vous pouvez également modifier les valeurs des paramètres wait_timeout et interactive_timeout pour fermer la session en fonction de la valeur définie. Pour plus d'informations, consultez la documentation MySQL sur wait_timeout et interactive_timeout.

Utilisation de Performance Insights

Vous pouvez utiliser Performance Insights pour identifier les requêtes exactes qui s'exécutent sur l'instance et qui entraînent une utilisation intensive du processeur. Tout d’abord, activez Performance Insights pour MySQL. Vous pouvez ensuite utiliser Performance Insights pour optimiser votre charge de travail après avoir consulté votre administrateur de base de données (DBA).

Pour voir les moteurs de base de données disponibles avec Performance Insights, consultez la rubrique Utilisation d'Amazon RDS Performance Insights.

Utilisation de requêtes afin de détecter ce qui provoque l’utilisation intensive du processeur lors d’une charge de travail

Avant de pouvoir optimiser votre charge de travail, vous devez identifier la requête problématique. Vous pouvez exécuter les requêtes suivantes en cas de problème de consommation élevée du processeur afin d’identifier la cause première de cette surutilisation. Ensuite, vous pouvez optimiser votre charge de travail afin de moins utiliser le processeur.

La commande SHOW PROCESSLIST vous indique les threads en cours d'exécution sur votre instance MySQL. Parfois, un ensemble d'instructions s’exécute, sans prendre fin. Dans ce cas, les instructions suivantes doivent attendre la fin du premier ensemble d'instructions, car il est fort possible qu’InnoDB active le verrouillage pour mettre à jour les lignes. Pour plus d'informations, reportez-vous à la documentation MySQL sur SHOW PROCESSLIST Syntax.

SHOW FULL PROCESSLIST;

Remarque : exécutez la requête SHOW PROCESSLIST en tant qu'utilisateur principal. Si vous n'êtes pas l'utilisateur principal, l'utilisateur MySQL qui exécute la commande doit disposer des privilèges d'administrateur du serveur MySQL PROCESS pour voir tous les threads s'exécuter sur une instance MySQL. Sans les privilèges d'administrateur, SHOW PROCESSLIST affiche uniquement les threads associés au compte MySQL que vous utilisez.

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 plus d'informations, consultez la documentation MySQL concernant la Table INFORMATION_SCHEMA INNODB_TRX.

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

La table INNODB_LOCKS fournit des informations sur les verrous demandés par une transaction InnoDB, mais non reçus. Pour plus d'informations, consultez la documentation MySQL concernant la Table INFORMATION_SCHEMA INNODB_LOCKS.

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

La table INNODB_LOCK_WAITS fournit une ou plusieurs lignes pour chaque transaction InnoDB bloquée. Pour plus d'informations, consultez la documentation MySQL pour la Table INFORMATION_SCHEMA INNODB_LOCK_WAITS.

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

Vous pouvez exécuter une requête semblable à celle-ci afin d’identifier les transactions en attente et celles qui bloquent les transactions en attente. Pour plus d'informations, reportez-vous à la documentation MySQL concernant l’utilisation des informations de verrouillage et des transactions InnoDB.

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;

La requête SHOW ENGINE INNODB STATUS fournit des informations provenant du moniteur InnoDB standard sur l'état du moteur de stockage InnoDB. Pour plus d'informations, reportez-vous à la documentation MySQL sur SHOW ENGINE Syntax.

SHOW ENGINE INNODB STATUS;

SHOW GLOBAL SESSION STATUS fournit des informations sur l’état du serveur. Pour plus d'informations, reportez-vous à la documentation MySQL sur SHOW STATUS Syntax.

SHOW GLOBAL STATUS;

Remarque : ces requêtes ont été testées sur Aurora 2.02.5 (MySQL 5.7) ; Aurora 1.17.8 (MySQL 5.6) ; MySQL 5.6.x et 5.7.x et MariaDB 10.0.x, 10.1.x, 10.2.x.

Analyse des journaux et activation de la surveillance

Vous pouvez analyser le journal de requêtes générales MySQL pour connaître l’activité de mysqld à un moment spécifique. Vous pouvez également afficher les requêtes en cours d'exécution sur votre instance à une heure spécifique, y compris des informations sur les connexions/déconnexions des clients. Pour plus d'informations, reportez-vous à la documentation MySQL sur le Journal de requêtes générales.

Remarque : lorsque vous activez le journal de requêtes générales sur de longues périodes, les journaux consomment du stockage et peuvent contribuer à la saturation des performances.

Analysez les journaux de requêtes lentes de MySQL afin d’y trouver les requêtes dont l’exécution dépasse le nombre de secondes défini pour long_query_time. Vous pouvez également examiner votre charge de travail et analyser vos requêtes pour améliorer les performances et la consommation de la mémoire. Pour plus d'informations, reportez-vous à la documentation MySQL sur le Journal de requêtes lentes.

Conseil : lorsque vous utilisez le journal de requêtes lentes ou le journal de requêtes générales, définissez le paramètre log_output sur FILE.

Vous pouvez également utiliser MariaDB Audit Plugin pour auditer l'activité de la base de données, par exemple pour avoir un aperçu des utilisateurs qui s’y connectent ou des requêtes exécutées sur cette dernière. Pour plus d'informations, consultez la section Prise en charge de MariaDB Audit Plugin.

Si vous utilisez Aurora pour MySQL, vous pouvez également faire appel à la fonction Advanced Auditing (audit avancé). L'audit vous donne plus de contrôle sur les types de requêtes que vous souhaitez enregistrer et limite la saturation des performances due à l’enregistrement.

Vous pouvez utiliser le paramètre innodb_print_all_deadlocks pour vérifier les blocages et le verrouillage des ressources. Vous pouvez utiliser ce paramètre afin d’enregistrer des informations sur les blocages au niveau des transactions utilisateur InnoDB dans le journal des erreurs MySQL. Pour plus d'informations, reportez-vous à la documentation MySQL sur innodb_print_all_deadlocks.

Analyse et optimisation de la charge de travail élevée du processeur

Une fois la requête responsable de l’utilisation élevée du processeur identifiée, vous pouvez optimiser votre charge de travail afin de réduire cette consommation.

Si vous voyez une requête qui n'est pas nécessaire à votre charge de travail, vous pouvez mettre fin à la session (annuler la requête) à l'aide de la commande suivante :

CALL mysql.rds_kill(processID);

Vous pouvez identifier le processID de la requête en exécutant la commande SHOW FULL PROCESSLIST.

Si vous ne souhaitez pas arrêter la requête, vous pouvez l’optimiser à l'aide de EXPLAIN. Cette commande montre les étapes individuelles impliquées dans l'exécution de la requête. Pour plus d'informations, reportez-vous à la documentation MySQL sur l’optimisation des requêtes avec EXPLAIN.

Activez PROFILING afin d’examiner les informations du profil pouvant indiquer l’utilisation des ressources pour les instructions exécutées au cours de la session actuelle. Pour de plus amples informations, reportez-vous à la documentation MySQL sur PROFILING Syntax.

Utilisez ANALYZE TABLE afin d’actualiser les statistiques d'index pour les tables. Cette action peut aider l'optimiseur à choisir un plan d'exécution approprié. Pour plus d'informations, reportez-vous à la documentation MySQL surANALYZE TABLE Syntax.


Cette page vous a-t-elle été utile ? Oui | Non

Retour au Centre de connaissances AWS Support

Vous avez besoin d'aide ? Consultez le site du Centre AWS Support.

Date de publication : 26/02/2019