CPU

Cet événement se produit lorsqu'un thread est actif dans l'UC ou qu'il est en attente d'UC.

Versions de moteur prises en charge

Ces informations sur les événements d'attente s'appliquent à Aurora PostgreSQL 9.6 et versions ultérieures.

Contexte

L'unité centrale (UC) est le composant d'un ordinateur qui exécute les instructions. Par exemple, les instructions de l'UC effectuent des opérations arithmétiques et échangent des données en mémoire. Si une requête augmente le nombre d'instructions qu'elle exécute par le biais du moteur de base de données, le temps passé à exécuter la requête augmente. La planification du temps UC consiste à accorder du temps UC à un processus. La planification est orchestrée par le noyau du système d'exploitation.

Rubriques

• Comment savoir quand cette attente se produit
• Métrique DBLoadCPU
• Métriques os.cpuUtilization
• Cause probable de la planification du temps UC

Comment savoir quand cette attente se produit

Cet événement d'attente CPU indique qu'un processus backend est actif dans l'UC ou qu'il est en attente d'UC. Cela se produit lorsqu'une requête contient les informations suivantes :

• La colonne pg_stat_activity.state indique la valeur active.

• Les colonnes wait_event_type et wait_event de pg_stat_activity indiquent toutes les deux null.

Pour voir les processus backend qui utilisent l'UC ou sont en attente de celle-ci, exécutez la requête suivante.

SELECT * 
FROM   pg_stat_activity
WHERE  state = 'active'
AND    wait_event_type IS NULL
AND    wait_event IS NULL;

Métrique DBLoadCPU

La métrique Performance Insights de l'UC est DBLoadCPU. La valeur de DBLoadCPU peut être différente de la valeur de la métrique Amazon CloudWatch CPUUtilization. Cette dernière est collectée à partir de l'hyperviseur pour une instance de base de données.

Métriques os.cpuUtilization

Les métriques du système d'exploitation Performance Insights fournissent des informations détaillées sur l'utilisation de l'UC. 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 présente l'utilisation du processeur par le moteur de base de données sous la forme os.cpuUtilization.nice.avg.

Cause probable de la planification du temps UC

Du point de vue du système d'exploitation, l'UC est active lorsqu'elle n'exécute pas de thread inactif. L'UC est active lorsqu'elle effectue un calcul, mais elle est également active lorsqu'elle attend des I/O mémoire. Ce type d'I/O domine la charge de travail standard d'une base de données.

Les processus sont susceptibles d'attendre d'être planifiés sur une UC lorsque les conditions suivantes sont réunies :

• La métrique CloudWatch CPUUtilization est proche de 100 %.

• La charge moyenne est supérieure au nombre de vCPU, ce qui indique une charge importante. Vous trouverez la métrique loadAverageMinute dans la section relative aux métriques du système d'exploitation de Performance Insights.

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

Un événement d'attente UC trop fréquent peut révéler un problème de performances dont les principales causes sont les suivantes.

Rubriques

• Causes probables des pics soudains
• Causes probables d'une fréquence élevée sur le long terme
• Cas particuliers

Causes probables des pics soudains

Les causes les plus probables des pics soudains sont les suivantes :

• Votre application a ouvert un trop grand nombre de connexions simultanées à la base de données. Ce scénario est connu sous le nom de « connection storm » (tempête de connexions).

• La charge de travail de votre application a connu l'un des changements suivants :

  • Nouvelles requêtes

  • Augmentation de la taille du jeu de données

  • Maintenance ou création d'index

  • Nouvelles fonctions

  • Nouveaux opérateurs

  • Augmentation des exécutions de requêtes parallèles

• Vos plans d'exécution des requêtes ont changé. Dans certains cas, un changement peut entraîner une augmentation des mémoires tampons. Par exemple, la requête utilise désormais une analyse séquentielle alors qu'elle utilisait auparavant un index. Dans ce cas, les requêtes ont besoin de plus d'UC pour atteindre le même objectif.

Causes probables d'une fréquence élevée sur le long terme

Causes les plus probables de la répétition des événements sur une longue période :

• Un trop grand nombre de processus backend s'exécutent simultanément sur l'UC. Ces processus peuvent être des employés parallèles.

• Les performances des requêtes ne sont pas optimales car elles nécessitent un grand nombre de mémoires tampons.

Cas particuliers

Si aucune des causes probables ne s'avère être la bonne, les situations suivantes peuvent se produire :

• L'UC échange des processus en entrée et en sortie.

• Le changement de contexte d'UC a augmenté.

• Il manque des événements d'attente dans le code Aurora PostgreSQL.

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.

Rubriques

• Vérifiez que la base de données n'est pas à l'origine de l'augmentation du nombre d'événements d'attente UC
• Déterminez si le nombre de connexions a augmenté
• Réagissez aux changements de charge de travail

Vérifiez que la base de données n'est pas à l'origine de l'augmentation du nombre d'événements d'attente UC

Examinez la métrique os.cpuUtilization.nice.avg dans Performance Insights. Si cette valeur est bien inférieure à l'utilisation de l'UC, cela signifie que des processus non liés à la base de données contribuent majoritairement aux événements d'attente UC.

Déterminez si le nombre de connexions a augmenté

Examinez la métrique DatabaseConnections dans Amazon CloudWatch. L'action à entreprendre varie selon que ce nombre augmente ou diminue pendant la période d'augmentation des événements d'attente UC.

Les connexions ont augmenté

Si le nombre de connexions a augmenté, comparez le nombre de processus backend utilisant l'UC au nombre de vCPU. Les scénarios possibles sont les suivants :

• Le nombre de processus backend utilisant l'UC est inférieur au nombre de vCPU.

  Dans ce cas, le nombre de connexions n'est pas un problème. Cependant, vous pouvez toujours essayer de réduire l'utilisation de l'UC.

• Le nombre de processus backend utilisant l'UC est supérieur au nombre de vCPU.

  Dans ce cas, procédez comme suit :

  • Réduisez le nombre de processus backend connectés à votre base de données. Par exemple, implémentez une solution de regroupement des connexions telle que RDS Proxy. Pour en savoir plus, consultez Utilisation d'Amazon RDS Proxy pour Aurora.

  • Augmentez la taille de votre instance pour bénéficier d'un plus grand nombre de vCPU.

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

Les connexions n'ont pas augmenté

Examinez les métriques blks_hit dans Performance Insights. Recherchez une corrélation entre une augmentation de blks_hit et l'utilisation de l'UC. Les scénarios possibles sont les suivants :

• L'utilisation de l'UC et blks_hit sont corrélés.

  Dans ce cas, recherchez les principales instructions SQL liées à l'utilisation de l'UC ainsi que les modifications apportées au plan. Vous pouvez utiliser l'une des techniques suivantes :

  • Décrivez les plans manuellement et comparez-les au plan d'exécution attendu.

  • Recherchez une augmentation des accès en bloc par seconde et des accès en bloc locaux par seconde. Dans la section Top SQL (Principaux éléments SQL) du tableau de bord Performance Insights, choisissez Preferences (Préférences).

• L'utilisation de l'UC et blks_hit ne sont pas corrélés.

  Dans ce cas, déterminez si l'une des situations suivantes se produit :

  • L'application se connecte et se déconnecte rapidement de la base de données.

    Diagnostiquez ce comportement en activant log_connections et log_disconnections, puis en analysant les journaux PostgreSQL. Pensez à utiliser l'analyseur de journaux pgbadger. Pour plus d'informations, consultez https://github.com/darold/pgbadger.

  • Le système d'exploitation est surchargé.

    Dans ce cas, Performance Insights montre que les processus backend utilisent l'UC plus longtemps que d'habitude. Recherchez des preuves dans les métriques Performance Insights os.cpuUtilization ou dans la métrique CloudWatch CPUUtilization. Si le système d'exploitation est surchargé, consultez les métriques de surveillance améliorée pour approfondir le diagnostic. Plus précisément, examinez la liste des processus et le pourcentage d'UC utilisé par chaque processus.

  • Les principales instructions SQL utilisent trop d'UC.

    Examinez les instructions liées à l'utilisation de l'UC pour voir si elles peuvent en utiliser moins. Exécutez une commande EXPLAIN et concentrez-vous sur les nœuds du plan qui ont le plus d'impact. Utilisez un visualiseur de plan d'exécution PostgreSQL. Pour essayer cet outil, consultez http://explain.dalibo.com/.

Réagissez aux changements de charge de travail

Si votre charge de travail a changé, recherchez les types de changements suivants :

Nouvelles requêtes

Déterminez si les nouvelles requêtes sont attendues. Si oui, assurez-vous que leur plan d'exécution et le nombre d'exécutions par seconde sont attendus.

Augmentation de la taille du jeu de données

Déterminez si un partitionnement, s'il n'est pas déjà implémenté, peut être utile. Cette stratégie peut réduire le nombre de pages qu'une requête doit récupérer.

Maintenance ou création d'index

Vérifiez si le calendrier de maintenance est attendu. Une bonne pratique consiste à planifier des activités de maintenance en dehors des périodes de pointe.

Nouvelles fonctions

Déterminez si ces fonctions s'exécutent comme prévu lors des tests. Plus précisément, déterminez si le nombre d'exécutions par seconde est attendu.

Nouveaux opérateurs

Déterminez s'ils fonctionnent comme prévu lors des tests.

Augmentation du nombre de requêtes exécutées en parallèle

Déterminez si l'une des situations suivantes s'est produite :

• Les relations ou index impliqués ont soudainement augmenté en termes de taille, de sorte qu'ils sont considérablement différents de min_parallel_table_scan_size ou min_parallel_index_scan_size.

• Des modifications récentes ont été apportées à parallel_setup_cost ou parallel_tuple_cost.

• Des modifications récentes ont été apportées à max_parallel_workers ou max_parallel_workers_per_gather.