Comment résoudre les problèmes liés à l'utilisation élevée du processeur pour Amazon RDS ou Amazon Aurora PostgreSQL ?

Date de la dernière mise à jour : 09/06/2022

Je veux identifier et résoudre la cause de problèmes d'utilisation intensive du processeur dans Amazon Relational Database Service (Amazon RDS) ou Amazon Aurora édition compatible avec PostgreSQL.

Brève description

Si vous voyez que votre charge entraîne une utilisation intensive du processeur, vous pouvez utiliser une combinaison des outils suivants pour identifier la cause :

Résolution

Métriques Amazon CloudWatch

Vous pouvez utiliser les métriques CloudWatch pour identifier les modèles de processeur pendant des périodes prolongées. Comparez les graphiques WriteIOPs, ReadIOPs, ReadThroughput et WriteThroughput avec l'utilisation du processeur (CPU) pour trouver les moments où la charge de travail a entraîné une utilisation intensive du processeur (CPU).

Après avoir identifié la période, vous pouvez consulter les données Enhanced Monitoring (Surveillance accrue) associées à votre instance de base de données. Vous pouvez paramétrer Enhanced Monitoring (Surveillance améliorée) pour collecter des données à des intervalles de 1, 5, 10, 15, 30 ou 60 secondes. Cela vous permet de collecter des données à un niveau plus détaillé que CloudWatch.

Enhanced Monitoring (Surveillance améliorée)

Enhanced Monitoring (Surveillance améliorée) fournit une vue au niveau du système d'exploitation (OS). Cette vue peut aider à identifier la cause d'une charge CPU élevée à un niveau précis. Par exemple, vous pouvez consulter la charge moyenne, la distribution du CPU (system% ou nice%) et la liste de traitement du système d'exploitation.

En utilisant Enhanced Monitoring (Surveillance améliorée), vous pouvez vérifier les données loadAverageMinute par intervalles de 1, 5 et 15 minutes. Si la charge moyenne est supérieure au nombre de processeurs virtuels, cela indique que la charge de l'instance est élevée. En outre, si la charge moyenne est inférieure au nombre de processeurs virtuels pour la classe d'instance de base de données, la limitation du CPU peut ne pas être la cause de la latence des applications. Vérifiez la charge moyenne pour éviter les fausses erreurs lors du diagnostic de la cause de l'utilisation du processeur.

Par exemple, si vous avez une instance de base de données utilisant une classe d'instance db.m5.2xlarge avec 3000 IOPS provisionnés qui atteint la limite de processeur (CPU), vous pouvez consulter l'exemple de métriques suivant pour identifier la cause profonde de l'utilisation intensive du processeur (CPU). Dans l'exemple suivant, la classe d'instance dispose de huit processeurs virtuels qui lui sont associés. Pour la même classe d'instance, une charge moyenne supérieure à 170 indique que la machine est sous une charge importante au cours de la période mesurée :

Minute de la charge moyenne

Quinze 170,25
Cinq 391,31
Un 596,74

Utilisation du CPU

Utilisateur (%) 0,71
Système (%) 4,9
Nice (%) 93,92
Total (%) 99,97

Remarque : Amazon RDS donne la priorité à votre charge de travail par rapport à d'autres tâches qui sont en cours d'exécution sur l'instance de base de données. Pour hiérarchiser ces tâches, les tâches de la charge de travail possèdent une valeur Nice supérieure. Par conséquent, dans Enhanced Monitoring (Surveillance améliorée), Nice% représente la quantité de CPU utilisée par votre charge de travail par rapport à la base de données.

Après avoir activé Enhanced Monitoring (Surveillance améliorée), vous pouvez également vérifier la liste de traitement du système d'exploitation associé à l'instance de base de données. La surveillance améliorée montre un maximum de 100 processus. Cela peut vous aider à identifier les processus ayant le plus d'impact sur les performances en fonction de l'utilisation du processeur (CPU) et de la mémoire.

Vous pouvez mettre en association les résultats de Enhanced Monitoring (Surveillance améliorée) avec les résultats pg_stat_activity pour vous aider à identifier l'utilisation des ressources des requêtes.

Performance Insights

Vous pouvez utiliser Amazon RDS Performance Insights pour identifier la requête responsable de la charge de la base de données après avoir vérifié l'onglet SQL qui correspond à une période donnée.

Affichage et catalogues PostgreSQL natif

Au niveau du moteur de base de données, si le problème se produit en temps réel, vous pouvez utiliser pg_stat_activity ou pg_stat_statements. Cela peut vous aider à regrouper les machines, les clients, et les adresses IP avec le trafic le plus important. Vous pouvez également utiliser ces données pour voir s'il y a des augmentations au fil du temps, les augmentations des serveurs d'application ou si un serveur d'application a des sessions bloquées ou des problèmes de verrouillage. Pour plus d'informations, consultez la documentation PostgreSQL pour pg_stat_activity et pg_stat_statements.

Pour activer pg_stat_statements, modifiez le groupe de paramètres personnalisés existants et définissez les valeurs suivantes :

  • Ajoutez pg_stat_statements à shared_preload_libraries
  • track_activity_query_size = 4096
  • pg_stat_statements.track = ALL
  • pg_stat_statements.max = 10000

Choisissez Apply Immediately (Appliquer immédiatement), puis redémarrez l'instance de base de données. Ensuite, exécutez une commande semblable à la commande suivante sur la base de données que vous souhaitez surveiller :

Remarque : l'exemple suivant installe l'extension dans la base de données « démo ».

demo=> select current_database();
current_database
------------------
demo
(1 row)
     
demo=> CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Une fois pg_stat_statements configuré, vous pouvez surveiller la sortie en utilisant l'une des méthodes suivantes :

    Répertoriez les requêtes par total_time et voyez quelle requête passe le plus de temps dans la base de données pour les versions 12 et antérieures de PostgreSQL :

      SELECT total_time, query
      FROM pg_stat_statements
      ORDER BY total_time DESC LIMIT 10;

        Pour les versions 13 et ultérieures de PostgreSQL :

        SELECT total_plan_time+total_exec_time as total_time, query
        FROM pg_stat_statements
        ORDER BY 1 DESC LIMIT 10;

        Répertorier les requêtes avec un taux de succès du cache de mémoire tampon inférieur, exécutez la requête suivante pour PostgreSQL versions 12 et antérieures :

          SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit / nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
          FROM pg_stat_statements ORDER BY total_time 
          DESC LIMIT 10;

            Pour les versions 13 et ultérieures de PostgreSQL :

            SELECT query, calls, total_plan_time+total_exec_time as total_time, rows, 100.0 * shared_blks_hit / nullif(shared_blks_hit +
            shared_blks_read, 0) AS hit_percent
            FROM pg_stat_statements ORDER BY 3 DESC LIMIT 10;

            Répertoriez les requêtes par exécution afin d'obtenir des exemples de requêtes au fil du temps pour les versions 12 et antérieures de PostgreSQL :

              SELECT query, calls, total_time/calls as avg_time_ms, rows/calls as avg_rows,
              temp_blks_read/calls as avg_tmp_read, temp_blks_written/calls as avg_temp_written
              FROM pg_stat_statements
              WHERE calls != 0
              ORDER BY total_time DESC LIMIT 10;

              Pour les versions 13 et ultérieures de PostgreSQL :

              SELECT query, calls, (total_plan_time+total_exec_time as total_time)/calls as avg_time_ms, rows/calls as avg_rows,
              temp_blks_read/calls as avg_tmp_read, temp_blks_written/calls as avg_temp_written
              FROM pg_stat_statements
              WHERE calls != 0
              ORDER BY 3 DESC LIMIT 10;

              Connexions inactives dans la base de données

              Les connexions inactives dans la base de données peuvent consommer des ressources de calcul, telles que la mémoire et le processeur. Lorsque l'utilisation du processeur de votre instance est élevée, veillez à vérifier les connexions inactives sur la base de données. Pour plus d'informations, consultez la rubrique Impact sur les performances des connexions PostgreSQL inactives. Vous pouvez vérifier les connexions inactives en consultant la liste des processus du système d'exploitation à l'aide de Enhanced Monitoring (Surveillance améliorée). Toutefois, cette liste indique un maximum de 100 processus.

              Vous pouvez vérifier la présence d'une connexion inactive en exécutant quelques requêtes au niveau de la base de données :

              Exécutez les requêtes suivantes pour afficher les sessions actives et inactives en cours :

              SELECT pid, datname, state, current_timestamp-least(query_start,xact_start) age, application_name, usename, query
              FROM pg_stat_activity
              WHERE query != '<IDLE>'
              AND query NOT ILIKE '%pg_stat_activity%'
              AND usename!='rdsadmin'
              ORDER BY query_start desc;
              
              
              SELECT application_name,pid,wait_event_type,wait_event,current_timestamp-least(query_start,xact_start) AS runtime, query AS current_query
              FROM pg_stat_activity
              WHERE not pid=pg_backend_pid()
              AND query NOT ILIKE '%pg_stat_activity%'
              AND usename!='rdsadmin';

              Exécutez les requêtes suivantes pour obtenir le nombre de connexions par utilisateur et par nom d'application :

              postgres=> SELECT application_name,count(*) FROM pg_stat_activity GROUP BY application_name;
              
                  application_name    | count 
              ------------------------+-------
               psql                   |     1
               PostgreSQL JDBC Driver |     1
                                      |     5
              (3 rows)
              postgres=> SELECT usename,count(*) FROM pg_stat_activity GROUP BY usename;
              
               usename  | count 
              ----------+-------
               master   |     4
               user1    |     1
               rdsadmin |     2
              (3 rows)

              Après avoir identifié les connexions inactives, arrêtez ces connexions en exécutant l'une des requêtes suivantes :

              psql=> SELECT pg_terminate_backend(pid) 
                 FROM pg_stat_activity
                 WHERE usename = 'example-username'
                 AND pid <> pg_backend_pid()
                 AND state in ('idle');

              ou

              SELECT pg_terminate_backend (example-pid);

              Si votre application telle que conçue génère un nombre élevé de connexions, pensez à apporter des modifications afin que votre mémoire et vos ressources processeur ne soient pas gaspillés dans la gestion de ces connexions. Vous pouvez soit modifier l'application pour limiter le nombre de connexions, soit utiliser un regroupement de connexions tel que PGbouncer. Vous pouvez également utiliser Amazon RDS Proxy, un service géré qui vous permet de configurer un regroupement de connexions en quelques clics.

              Commande Analyser

              La commande Analyser collecte des statistiques sur le contenu des tables de la base de données et stocke les résultats dans le catalogue système pg_statistic. Ensuite, le planificateur de requêtes utilise ces statistiques pour déterminer les plans d'exécution les plus efficaces pour les requêtes. Si vous n'exécutez pas Analyze fréquemment sur les tables de votre base de données, les requêtes peuvent consommer davantage de ressources de calcul. Cela est dû aux statistiques obsolètes présentes dans le système pour les relations auxquelles vous accédez. Cette erreur se produit dans les conditions suivantes :

              • Autovacuum n'est pas utilisé fréquemment.
              • Analyze n'a pas été exécuté après la mise à niveau de la version majeure.

              Autovacuum n'est pas en cours d'exécution : Autovacuum est un démon qui automatise l'exécution des commandes VACUUM et ANALYZE. Autovacuum vérifie la présence de tables surdimensionnées dans la base de données et récupère l'espace pour la réutiliser. Le démon autovacuum s'assure que les statistiques de la table sont mises à jour régulièrement en exécutant l'opération Analyser chaque fois que le seuil défini de tuples est mort. Cela permet au planificateur de requêtes d'utiliser le plan de requêtes le plus efficace en fonction des statistiques récentes. Si autovacuum n'est pas en cours d'exécution, le planificateur de requêtes peut créer des plans de requêtes sous-optimaux, ce qui entraîne une consommation de ressources plus élevée par les requêtes. Pour plus d'informations sur le réglage d'autovacuum, consultez les rubriques Comprendre autovacuum dans les environnements Amazon RDS for PostgreSQL environment et Étude de cas du réglage d'autovacuum dans Amazon RDS for PostgreSQL.

              Exécutez la requête suivante pour obtenir des informations sur la date de la dernière exécution d'autovacuum et d'autoanalyze sur les tables :

              SELECT relname, last_autovacuum, last_autoanalyze FROM pg_stat_user_tables;

              Analyze n'a pas été exécuté après la mise à niveau de la version majeure : les bases de données PostgreSQL rencontrent généralement des problèmes de performances après une mise à niveau de version majeure. L'une des raisons courantes de ces problèmes est que l'opération Analyze n'est pas effectuée après la mise à niveau pour actualiser la table pg_statistic. Assurez-vous d'exécuter l'opération Analyze pour chaque base de données de votre instance de base de données RDS pour PostgreSQL. Les statistiques de l'optimiseur ne sont pas transférées pendant une mise à niveau de version majeure. Par conséquent, vous devez régénérer toutes les statistiques pour éviter les problèmes de performances dus à une utilisation plus élevée des ressources.

              Exécutez la commande suivante sans aucun paramètre pour générer des statistiques pour toutes les tables normales de la base de données actuelle après une mise à niveau majeure de la version :

              ANALYZE VERBOSE

              Paramètres de journalisation PostgreSQL

              Activez la journalisation des requêtes à l'aide d'Amazon RDS for PostgreSQL. Ensuite, vérifiez les journaux des erreurs PostgreSQL afin de confirmer que vos paramètres log_min_duration_statement et log_statement sont définis sur les valeurs appropriées. Pour plus d'informations, consultez la documentation PostgreSQL pour Signalement et journalisation des erreurs.

              Réduction de l'utilisation du CPU

              Une fois que vous avez identifié les requêtes entraînant une utilisation élevée du CPU, vous pouvez utiliser les méthodes suivantes pour réduire son utilisation :

              1. S'il y a des opportunités de réglage, utilisez EXPLAIN and EXPLAIN ANALYZE pour identifier les mises en garde. Pour plus d'informations, consultez la documentation PostgreSQL relative à EXPLAIN.
              2. Si une requête est exécutée de manière répétée, envisagez d'utiliser des instructions préparées pour réduire la pression sur votre CPU. L'exécution répétée d'instructions préparées met en cache le plan de requête. Par conséquent, le temps nécessaire à la planification est beaucoup plus court pour les exécutions ultérieures, car le plan est déjà en cache.

              Cet article vous a-t-il été utile ?


              Besoin d'aide pour une question technique ou de facturation ?