Share Your AWS re:Post Experience - Quick 3 Question Survey
Help us improve AWS re:Post! We're interested in understanding how you use re:Post and its impact on your AWS journey. Please take a moment to complete our brief 3-question survey.
Comment puis-je identifier et résoudre les problèmes de performance et de lenteur d’exécution des requêtes dans mon instance de base de données Amazon RDS for PostgreSQL ou Aurora compatible avec PostgreSQL ?
Mon instance de base de données Amazon Relational Database Service (Amazon RDS) for PostgreSQL ou Amazon Aurora édition compatible avec PostgreSQL. Je souhaite identifier et résoudre les problèmes liés à la lenteur d’exécution des requêtes.
Résolution
Un matériel sous-dimensionné, des modifications de la charge de travail, une augmentation du trafic, des problèmes de mémoire ou des requêtes non optimisées affectent les performances des instances de base de données. Pour résoudre les problèmes de performances, prenez les mesures suivantes.
Identifier la cause
Vérifier les métriques CloudWatch
Pour identifier les goulots d'étranglement des performances dus à des ressources insuffisantes, surveillez les métriques Amazon CloudWatch CPUUtilization, FreaableMemory et SwapUsage.
Lorsque l'utilisation du processeur est élevée, une charge de travail active sur l'instance de base de données nécessite davantage de ressources de processeur. La faible disponibilité de la mémoire pour la charge de travail entraîne des échanges fréquents qui se traduisent par une utilisation élevée de la mémoire et de l'espace d’échange. Des requêtes de longue durée, une augmentation soudaine du trafic ou un grand nombre de connexions inactives peuvent entraîner une utilisation élevée du processeur et des ressources mémoire.
Pour afficher les requêtes actives avec exécution, exécutez la commande suivante :
SELECT pid, usename, age(now(),xact_start) query_time, query FROM pg_stat_activity WHERE state='active';
Pour afficher les connexions inactives dans la base de données, exécutez la commande suivante :
SELECT count(*) FROM pg_stat_activity WHERE state='idle';
Pour mettre fin aux connexions inactives, exécutez la commande suivante :
SELECT pg_terminate_backend(example-pid);
Remarque : Remplacez example-pid par l’ID de processus de la connexion inactive.
Pour vérifier que votre instance de base de données atteint le débit réseau attendu, vérifiez les métriques NetworkReceiveThroughput et NetworkTransmitThroughput. Les classes d'instances Amazon Elastic Block Service (Amazon EBS) sous-dimensionnées ou non optimisées peuvent affecter le débit réseau et ralentir les instances. Un débit réseau faible peut entraîner des réponses lentes pour toutes les requêtes d'application, quelles que soient les performances de la base de données.
Pour évaluer les performances d'I/O, vérifiez les métriques ReadIOPS, WriteIOPS, ReadLatency, WriteLatency, ReadThroughput, WriteThroughput et DiskQueueDepth. Pour plus d'informations, consultez la section Comment puis-je résoudre les problèmes de latence des volumes Amazon EBS causés par un goulot d'étranglement des IOPS dans mon instance Amazon RDS ?
Utiliser la surveillance améliorée
Utilisez la surveillance améliorée pour afficher les métriques au niveau du système d'exploitation (OS) et répertorier les 100 principaux processus qui utilisent une quantité élevée de processeur et de mémoire. Activez la surveillance améliorée avec une granularité définie sur 1 pour identifier les problèmes de performances intermittents sur votre instance de base de données.
Évaluez les métriques de système d'exploitation disponibles pour diagnostiquer les problèmes de performances liés au processeur, à la charge de travail, aux I/O, à la mémoire et au réseau. Dans la liste des processus, identifiez les processus dont les valeurs sont élevées pour CPU% ou Mem%.
Exemple :
NOM | VIRT | RES | %CPU | %MEM | VMLIMIT |
---|---|---|---|---|---|
postgres: postgres postgres 178.2.0.44(42303) SELECT [10322] | 250,66 Mo | 27,7 Mo | 85,93 | 2,21 | illimité |
Connectez-vous à la base de données, puis exécutez la requête suivante pour rechercher la connexion avec un processeur élevé dans la base de données :
SELECT * FROM pg_stat_activity WHERE pid = 10322;
Remarque : Remplacez 10322 par l'ID de processus de la connexion.
Vérifier les métriques de Performance Insights
Utilisez Performance Insights pour évaluer les charges de travail des bases de données en fonction des attentes, du code SQL, de l'hôte ou des utilisateurs. Vous pouvez également obtenir les métriques au niveau de la base de données et SQL.
Utilisez l’onglet SQL maximum du tableau de bord Performance Insights pour afficher les instructions SQL qui contribuent le plus à la charge de la base de données. Si le chargement de la base de données ou le chargement par attente (AAS) est supérieur à Max vCPU, la charge de travail de la classe d'instance de base de données est limitée.
Utilisez la latence moyenne par appel dans Statistiques SQL pour afficher la durée d'exécution moyenne d'une requête. SQL maximum est basé sur la durée d'exécution totale. Par conséquent, le code SQL dont la durée d'exécution est la plus élevée est souvent différent du code SQL qui contribue le plus à la charge de la base de données.
Vérifier les statistiques de base de données
Pour évaluer les performances de bases de données dans PostgreSQL, vérifiez les statistiques de distribution des données, les statistiques étendues et les statistiques de surveillance. Pour plus d'informations sur les statistiques, consultez la section Comprendre les statistiques dans PostgreSQL.
Vérifier les outils de base de données natifs
Pour identifier les requêtes lentes, utilisez l'outil pgbadger natif sur le site Web de GitHub. Pour plus d'informations, consultez la section Optimisation et réglage des requêtes dans Amazon RDS pour PostgreSQL à l'aide d'outils natifs et externes.
Optimiser les performances
Régler les paramètres de la mémoire
Vous pouvez définir le paramètre shared_buffers sur une valeur qui contribue à améliorer les performances des requêtes.
Les paramètres work_mem et maintenance_work_mem définissent la quantité de mémoire utilisée pour les processus backend. Pour plus d'informations, consultez la page 20.4 Consommation de ressources sur le site Web de PostgreSQL. Si vous constatez fréquemment une utilisation élevée de la mémoire sur l'instance de base de données, réduisez les valeurs des paramètres dans le groupe de paramètres personnalisés qui est attaché à votre instance.
Utiliser la gestion des plans de requête Aurora compatible avec PostgreSQL
Utilisez la gestion des plans de requête Aurora compatible avec PostgreSQL pour déterminer comment et quand les plans d'exécution des requêtes changent. Pour plus d'informations, consultez la section Bonnes pratiques de gestion des plans de requête Aurora PostgreSQL.
Résoudre les problèmes liés à la lenteur d’exécution des requêtes
Des problèmes d'infrastructure, une planification de requêtes non optimisée ou une utilisation globale élevée des ressources entraînent une lenteur d’exécution des requêtes. Le planificateur de requêtes PostgreSQL utilise des statistiques de table pour créer des plans de requête. Les modifications de schéma et les anciennes statistiques peuvent affecter les plans. Des tables et des index surchargés peuvent également entraîner une lenteur d’exécution des requêtes.
Lorsqu'une table atteint le seuil de tuples morts, le démon autovacuum crée des processus de travail autovacuum qui suppriment les tuples morts de la table. Le démon autovacuum exécute également l'opération ANALYZE qui actualise les statistiques de la table.
Exécutez la requête suivante pour vérifier la présence de tuples morts et les opérations autovacuum ou vacuum ainsi que les exécutions autoanalyze ou analyze :
SELECT schemaname, relname, n_live_tup,n_dead_tup, last_autoanalyze, last_analyze, last_autovacuum, last_vacuum,autovacuum_count+vacuum_count vacuum_count, analyze_count+autoanalyze_count analyze_count FROM pg_stat_user_tables ORDER BY 5 DESC;
Utilisez la vue pg_stat_activity pour rechercher des données liées aux activités en cours, telles qu'un ID de processus backend ou une requête. Pour rechercher des requêtes de longue durée, exécutez la requête suivante :
SELECT pid, datname, query, extract(epoch from now()) - extract(epoch from xact_start) AS duration, case WHEN wait_event IS NULL THEN 'CPU' ELSE wait_event_type||':'||wait_event end wait FROM pg_stat_activity WHERE query!=current_query() AND xact_start IS NOT NULL ORDER BY 4 DESC;
Les requêtes en attente de verrouillage peuvent être lentes. Pour vérifier si une requête est en attente de verrouillage, exécutez la requête suivante :
SELECT pid, virtualtransaction AS vxid, locktype AS lock_type, mode AS lock_mode, granted,fastpath,CASE WHEN virtualxid IS NOT NULL AND transactionid IS NOT NULL THEN virtualxid || ' ' || transactionid WHEN virtualxid::text IS NOT NULL THEN virtualxid ELSE transactionid::text END AS xid_lock, relname, page, tuple, classid, objid, objsubid FROM pg_locks LEFT OUTER JOIN pg_class ON (pg_locks.relation = pg_class.oid) WHERE -- do not show our view's locks pid != pg_backend_pid() AND virtualtransaction IS DISTINCT FROM virtualxid ORDER BY 1, 2, 5 DESC, 6, 3, 4, 7;
Utilisez pg_stat_statements pour afficher les statistiques des requêtes. Avant de créer l'extension pg_stat_statements, ajoutez l’entrée pg_stat_statements à shared_preload_libraries. Pour créer l'extension pg_stat_statements dans la base de données, exécutez la requête suivante :
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
Remarque : Vous pouvez modifier les paramètres de pg_stats_statements uniquement lorsqu'un groupe de paramètres personnalisés est attaché à votre instance de base de données.
Pour identifier les requêtes SQL qui affectent les performances de votre instance de base de données, exécutez les requêtes suivantes.
PostgreSQL versions 12 et antérieures :
SELECT query, calls, total_time, mean_time FROM pg_stat_statements ORDER BY 3 DESC;
PostgreSQL versions 13 et ultérieures :
SELECT query, calls, total_plan_time+total_exec_time AS total_time, mean_plan_time + mean_exec_time AS mean_time FROM pg_stat_statements ORDER BY 3 DESC;
Pour rechercher des requêtes présentant un taux d'accès au cache de tampons inférieur, exécutez les requêtes suivantes.
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_percentFROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;
PostgreSQL versions 13 et ultérieures :
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 5 ASC LIMIT 10;
Pour rechercher des requêtes ou des plans de requête de longue durée dans les journaux d'erreurs de base de données, configurez le paramètre log_min_duration_statement pour votre instance de base de données, puis utilisez le module the auto_explain.
Vous pouvez également utiliser les commandes explain et explain analyze pour obtenir le plan de requête. Utilisez le module auto_explain ou les commandes explain pour identifier la manière dont vous pouvez ajuster le réglage de vos requêtes. Pour plus d'informations, consultez les pages 14.1 Utilisation d’EXPLAIN et F3. auto_explain - plans d’exécution de journal de requêtes lentes sur le site Web de PostgreSQL.
Si vous avez optimisé votre système et que vous rencontrez toujours des problèmes de performances, il est recommandé de mettre à l’échelle la classe d'instance de base de données. Lorsque vous augmentez l'instance de base de données, vous allouez davantage de ressources de calcul et de mémoire.
Informations connexes
Utilisation des paramètres de votre instance de base de données RDS for PostgreSQL

Contenus pertinents
- demandé il y a un anlg...
- demandé il y a 2 moislg...
- demandé il y a un anlg...
- demandé il y a 3 moislg...
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 2 ans