cpu

L'événement d'attente cpu se produit lorsqu'un thread est actif dans le processeur ou attend le processeur.

Versions de moteur prises en charge

Ces informations relatives aux événements d'attente sont prises en charge pour les versions de moteur suivantes :

• Aurora MySQL versions 2 et 3

Contexte

Pour chaque vCPU, une connexion peut exécuter des tâches sur ce processeur. Dans certains cas, le nombre de connexions actives prêtes à être exécutées est supérieur au nombre de vCPU. Ce déséquilibre entraîne des connexions en attente de ressources de processeur. Si le nombre de connexions actives est constamment supérieur au nombre de vCPU, votre instance est confrontée à une contention de processeur. En cas de contention, l'événement d'attente cpu se produit.

Note

La métrique Performance Insights pour le processeur est DBLoadCPU. La valeur de DBLoadCPU peut être différente de la valeur de la CloudWatch métriqueCPUUtilization. Cette dernière métrique est collectée à partir de HyperVisor pour une instance de base de données.

Les métriques du système d'exploitation Performance Insights fournissent des informations détaillées sur l'utilisation du processeur. Par exemple, vous pouvez afficher les métriques suivantes :

• os.cpuUtilization.nice.avg

• os.cpuUtilization.total.avg

• os.cpuUtilization.wait.avg

• os.cpuUtilization.idle.avg

Performance Insights signale l'utilisation du processeur par le moteur de base de données sous la forme os.cpuUtilization.nice.avg.

Causes probables de l'augmentation du nombre d'événements d'attente

Lorsque cet événement se produit plus que la normale, indiquant un possible problème de performances, les causes types sont les suivantes :

• Requêtes analytiques

• Transactions hautement simultanées

• Transactions de longue durée

• Augmentation soudaine du nombre de connexions (tempête de connexions)

• Augmentation du changement de contexte

Actions

Si l'événement d'attente cpu domine l'activité de la base de données, cela n'indique pas nécessairement un problème de performance. Ne réagissez à cet événement qu'en cas de dégradation des performances.

Selon la cause de l'augmentation de l'utilisation du processeur, envisagez les stratégies suivantes :

• Augmentez la capacité du processeur de l'hôte. En règle générale, une telle approche n'apporte qu'un soulagement temporaire.

• Identifiez les requêtes les plus importantes à des fins d'optimisation potentielle.

• Redirigez certaines charges de travail en lecture seule vers les nœuds de lecture, le cas échéant.

Rubriques

• Identifiez les sessions ou les requêtes à l'origine du problème.
• Analyser et optimiser une charge de travail élevée de l'UC

Identifiez les sessions ou les requêtes à l'origine du problème.

Pour trouver les sessions et les requêtes, consultez la table Top SQL (Principaux éléments SQL) dans Performance Insights et découvrez les instructions SQL dotées de la charge d'UC la plus élevée. Pour plus d'informations, consultez Analyse des métriques à l'aide du tableau de bord de Performance Insights.

En règle générale, une ou deux instructions SQL consomment la majorité des cycles d'UC. Concentrez vos efforts sur ces instructions. Supposons que votre instance de base de données dispose de 2 vCPU avec une charge de base de données de 3,1 sessions actives en moyenne (AAS), le tout dans l'état d'UC. Dans ce cas, votre instance est liée à l'UC. Envisagez les stratégies suivantes :

• Procédez à un niveau vers une plus grande classe d'instance avec plus de vCPU.

• Réglez vos requêtes pour réduire la charge de l'UC.

Dans cet exemple, les principales requêtes SQL présentent une charge de base de données de 1,5 AAS, toutes à l'état d'UC. Une autre instruction SQL présente une charge de 0,1 à l'état d'UC. Dans cet exemple, si vous arrêtez l'instruction SQL de la charge la plus faible, vous ne réduisez pas la charge de la base de données de manière significative. Toutefois, si vous optimisez les deux requêtes à charge élevée pour qu'elles soient deux fois plus efficaces, vous éliminez le goulet d'étranglement de l'UC. Si vous réduisez la charge de l'UC de 1,5 AAS à hauteur de 50 %, l'AAS de chaque instruction diminue de 0,75. La charge de base de données totale dépensée sur l'UC est désormais de 1,6 AAS. Cette valeur est inférieure à la ligne de vCPU maximale de 2.0.

Pour une présentation de la résolution des problèmes à l'aide de Performance Insights, consultez le billet de blog Analyze Amazon Aurora MySQL Workloads with Performance Insights. Consultez également l'AWSarticle de supportHow can I troubleshoot and resolve high CPU utilization on my Amazon RDS for MySQL instances?.

Analyser et optimiser une charge de travail élevée de l'UC

Après avoir identifié la ou les requêtes augmentant l'utilisation de l'UC, vous pouvez les optimiser ou mettre fin à la connexion. L'exemple suivant montre comment mettre fin à une connexion.

CALL mysql.rds_kill(processID);

Pour plus d'informations, consultez mysql.rds_kill.

Si vous mettez fin à une session, l'action peut déclencher une longue restauration.

Suivre les recommandations relatives à l'optimisation des requêtes

Pour optimiser les requêtes, suivez les recommandations ci-dessous :

• Exécutez l'instruction EXPLAIN.

  Cette commande affiche les étapes individuelles associées à l'exécution d'une requête. Pour en savoir plus, consultez Optimizing Queries with EXPLAIN dans la documentation MySQL.

• Exécutez l'instruction SHOW PROFILE.

  Utilisez cette instruction pour consulter les détails du profil pouvant indiquer l'utilisation des ressources pour les instructions exécutées lors de la session en cours. Pour en savoir plus, consultez SHOW PROFILE Statement dans la documentation MySQL.

• Exécutez l'instruction ANALYZE TABLE.

  Utilisez cette instruction pour actualiser les statistiques d'index des tables accessibles par la requête sollicitant considérablement l'UC. En analysant l'instruction, vous pouvez aider l'optimiseur à choisir un plan d'exécution approprié. Pour en savoir plus, consultez ANALYZE TABLE Statement dans la documentation MySQL.

Suivez les recommandations pour améliorer l'utilisation de l'UC

Pour améliorer l'utilisation de l'UC dans une instance de base de données, suivez ces recommandations :

• Assurez-vous que toutes les requêtes utilisent des index appropriés.

• Voyez si vous pouvez utiliser des requêtes parallèles Aurora. Vous pouvez utiliser cette technique pour réduire l'utilisation de l'UC au niveau du nœud principal grâce au traitement de la fonction « pushdown », au filtrage des lignes et à la projection des colonnes pour la clause WHERE.

• Déterminez si le nombre d'exécutions SQL par seconde atteint les seuils attendus.

• Déterminez si la maintenance de l'index ou la création d'un nouvel index prend en charge les cycles d'UC nécessaires à votre charge de travail de production. Planifiez les activités de maintenance en dehors des heures de pointe.

• Déterminez si vous pouvez utiliser le partitionnement pour réduire l'ensemble de données de requête. Pour plus d'informations, consultez le billet de blog.How to plan and optimize Amazon Aurora with MySQL compatibility for consolidated workloads.

Vérifier la présence de tempêtes de connexions

Si la métrique DBLoadCPU n'est pas très élevée, mais que la métrique CPUUtilization l'est, la cause de l'utilisation élevée de l'UC se situe en dehors du moteur de base de données. La tempête de connexions en est l'illustration type.

Vérifiez si les conditions suivantes sont vraies :

• Il y a une augmentation à la fois de la CPUUtilization métrique Performance Insights et de la CloudWatch DatabaseConnections métrique Amazon.

• Le nombre de threads de l'UC est supérieur au nombre de vCPU.

Si les conditions précédentes sont vraies, envisagez de diminuer le nombre de connexions à la base de données. Par exemple, vous pouvez utiliser un groupe de connexions tel que RDS Proxy. Pour connaître les bonnes pratiques en matière de gestion et de mise à l'échelle efficaces des connexions, consultez le livre blanc Manuel d'administrateur de base de données Amazon Aurora MySQL pour la gestion des connexions.