Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # CPU Cet événement se produit lorsqu'un thread est actif dans l'UC ou qu'il est en attente d'UC. **Topics** + [Versions de moteur prises en charge](#wait-event.cpu.context.supported) + [Contexte](#wait-event.cpu.context) + [Causes probables de l'augmentation du nombre d'événements d'attente](#wait-event.cpu.causes) + [Actions](#wait-event.cpu.actions) ## Versions de moteur prises en charge Ces informations sur les événements d'attente s'appliquent à toutes les versions de RDS for PostgreSQL. ## 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. **Topics** + [Comment savoir quand cette attente se produit](#wait-event.cpu.when-it-occurs) + [DBLoadMétrique du processeur](#wait-event.cpu.context.dbloadcpu) + [Métriques os.cpuUtilization](#wait-event.cpu.context.osmetrics) + [Cause probable de la planification du temps UC](#wait-event.cpu.context.scheduling) ### 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; ``` ### DBLoadMétrique du processeur La métrique Performance Insights de l'UC est `DBLoadCPU`. La valeur de `DBLoadCPU` peut être différente de celle de la CloudWatch métrique Amazon`CPUUtilization`. Cette dernière métrique est collectée à partir de HyperVisor 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 Le noyau du système d'exploitation (SE) gère la planification pour le processeur. Quand le processeur est *actif*, il se peut qu'un processus doive attendre avant d'être planifié. Le processeur est actif pendant qu'il effectue des calculs. Il est également actif lorsqu'il possède un thread inactif qu'il n'exécute pas, c'est-à-dire qu'un thread inactif en attente de mémoire I/O. This type of I/O domine la charge de travail typique 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 CloudWatch `CPUUtilization` métrique est proche de 100 %. + La charge moyenne est supérieure au nombre de vCPUs, ce qui indique une charge lourde. 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. **Topics** + [Causes probables des pics soudains](#wait-event.cpu.causes.spikes) + [Causes probables d'une fréquence élevée sur le long terme](#wait-event.cpu.causes.long-term) + [Cas particuliers](#wait-event.cpu.causes.corner-cases) ### 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 processeur est peut-être en train de gérer les entrées des tables de pages si la fonctionnalité *huge pages* (grandes pages) a été désactivée. Cette fonctionnalité de gestion de la mémoire est activée par défaut pour toutes les classes d'instances de base de données autres que les classes micro, petites et moyennes. Pour de plus amples informations, veuillez consulter [Grandes pages pour RDS pour PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md). ## 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. **Topics** + [Vérifiez que la base de données n'est pas à l'origine de l'augmentation du nombre d'événements d'attente UC](#wait-event.cpu.actions.db-CPU) + [Déterminez si le nombre de connexions a augmenté](#wait-event.cpu.actions.connections) + [Réagissez aux changements de charge de travail](#wait-event.cpu.actions.workload) ### 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 `DatabaseConnections` métrique sur 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 principaux consommant du processeur au nombre de v. CPUs Les scénarios suivants sont possibles : + Le nombre de processus principaux consommant le processeur est inférieur au nombre de v. CPUs 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 principaux consommant du processeur est supérieur au nombre de v. CPUs 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, veuillez consulter la section [Proxy Amazon RDS ](rds-proxy.md). + Améliorez la taille de votre instance pour obtenir un nombre plus élevé de CPUs v. + 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 de plus amples informations, veuillez consulter [https://github.com/darold/pgbadger](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 `os.cpuUtilization` métriques Performance Insights ou dans la CloudWatch `CPUUtilization` métrique. 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/](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`.