Comment puis-je résoudre les problèmes causés par un événement d'attente LWLock:pg_stat_statements dans Amazon RDS pour PostgreSQL ou Aurora compatible avec PostgreSQL ?

Résolution

Le module pg_stat_statements suit les statistiques relatives aux instructions SQL. Pour les instances de base de données PostgreSQL compatibles avec PostgreSQL 11 ou version ultérieure, la bibliothèque pg_stat_statements se charge par défaut. Pour plus d'informations, consultez la page pg_stat_statements sur le site Web de PostgreSQL.

Lorsque le nombre d'instructions uniques suivies dépasse la valeur de pg_stat_statements.max, PostgreSQL désalloue les statistiques pour les requêtes les moins fréquemment exécutées à partir de la table de hachage de la mémoire partagée. La désallocation crée de l'espace pour les nouvelles entrées.

Lors de la désallocation, PostgreSQL utilise LWLock pour la table de hachage afin d'empêcher tout accès simultané. Cela peut bloquer les processus dorsaux simultanés et l'événement d’attente LWLock:pg_stat_statements peut apparaître dans Performance Insights.

Remarque : Si la table de hachage alloue fréquemment des entrées, les performances globales de la charge de travail peuvent se dégrader.

Augmenter le module pg_stat_statements.max

Pour réduire les événements d'attente LWLock:pg_stat_statements, augmentez la valeur de pg_stat_statements.max dans le groupe de paramètres. Pour plus d'informations, consultez la page pg_stat_statements.max sur le site Web de PostgreSQL.

Remarque : Lorsque vous augmentez la valeur de pg_stat_statements.max, la table de hachage consomme de la mémoire partagée supplémentaire pour stocker davantage d'informations sur les instructions SQL.

Pour Amazon RDS pour PostgreSQL, vous pouvez modifier pg_stat_statements.max dans le groupe de paramètres de base de données.

Pour qu'Aurora soit compatible avec PostgreSQL, vous pouvez modifier la valeur dans le groupe de paramètres du cluster de base de données ou le groupe de paramètres de base de données.

Après avoir modifié pg_stat_statements.max dans le groupe de paramètres, redémarrez l'instance de base de données pour appliquer la modification. Pendant le redémarrage, vous pouvez subir une brève panne. Pour plus d'informations, consultez les sections Redémarrage d’une instance de base de données : étapes de base et Redémarrage d'une instance de base de données au sein d'un cluster Aurora.

Vous ne pouvez pas modifier les paramètres du groupe de paramètres de base de données par défaut ou du groupe de paramètres de cluster de base de données par défaut. Pour modifier les paramètres des groupes par défaut, créez un groupe de paramètres de base de données personnalisé ou un groupe de paramètres de cluster de base de données personnalisé. Puis, associez-le à votre instance de base de données ou à votre cluster de base de données.

Remarque : Vous pouvez stocker de longs textes de requête dans un fichier disque distinct. Si le fichier devient trop volumineux en raison de la longueur de la requête ou de valeurs de pg_stat_statements.max élevées, tous les textes de la requête peuvent être ignorés. Les champs pg_stat_statements.query peuvent alors devenir vides. Pour plus d'informations, consultez la page pg_stat_statements -- suivre les statistiques de planification et d’exécution de SQL sur le site Web de PostgreSQL.

Réduire le nombre d'entrées pg_stat_statements

Il est recommandé d'utiliser la version 17 de PostgreSQL pour réduire le nombre d'entrées pg_stat_statements. Par exemple, lorsque vous utilisez les versions 17 et ultérieures de PostgreSQL, vous pouvez remplacer les noms SAVEPOINT constants par des espaces réservés. Par exemple, vous pouvez enregistrer SAVEPOINT sp1 et SAVEPOINT sp2 sous la forme de deux entrées pg_stat_statements différentes dans les versions précédentes de PostgreSQL. Cependant, dans les versions 17 et ultérieures de PostgreSQL, ces deux instructions sont stockées sous la forme d'une seule entrée, par exemple SAVEPOINT $1. Pour plus d'informations, consultez la page pg_stat_statements sur le site Web de PostgreSQL.

Si vous ne parvenez pas à effectuer la mise à niveau vers les versions 17 ou ultérieures de PostgreSQL, vérifiez si votre application, les mappeurs d'objets relationnels (ORM) et les pilotes de base de données émettent automatiquement des commandes SQL telles que SAVEPOINT. Ces commandes SAVEPOINT automatiques peuvent augmenter le nombre d'entrées pg_stat_statements.

Vérifier le nombre de délocalisations survenues

PostgreSQL versions 14 et ultérieures

Pour vérifier le nombre total de fois que la désallocation s'est produite, consultez la colonne dealloc de la vue pg_stat_statements_info. Vous pouvez utiliser ces informations pour ajuster correctement votre pg_stat_statements.max. Pour plus d'informations, consultez la vue pg_stat_statements_info sur le site Web de PostgreSQL.

Pour vérifier le nombre de désallocations sur une période donnée, sélectionnez régulièrement la vue pg_stat_statements_info, puis calculez la différence à partir de pg_stat_statements_info.dealloc.

Lorsque vous sélectionnez la vue pg_stat_statements_info, le message d'erreur « ERROR: relation 'pg_stat_statements_info' does not exist » peut s'afficher. Cette erreur se produit lorsque pg_stat_statements se charge uniquement dans la mémoire mais ne s'installe pas sur votre base de données. Pour résoudre cette erreur, installez l'extension pg_stat_statements dans la base de données à laquelle votre application se connecte. Connectez-vous à la base de données, puis exécutez l'instruction SQL suivante pour installer pg_stat_statements dans la base de données :

CREATE EXTENSION pg_stat_statements;

Pour plus d'informations, consultez la page CREATE EXTENSION sur le site Web de PostgreSQL.