LWLock:buffer_content (BufferContent) - Amazon Aurora
Versions de moteur prises en chargeContexteCauses probables de l’augmentation du nombre d’événements d’attenteActions

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.

LWLock:buffer_content (BufferContent)

L’événement LWLock:buffer_content se produit lorsqu’une session attend de lire ou d’écrire une page de données en mémoire alors que celle-ci est verrouillée en écriture dans une autre session. Dans Aurora PostgreSQL 13 et versions ultérieures, cet événement d’attente est appelé BufferContent.

Versions de moteur prises en charge

Ces informations sur les événements d’attente s’appliquent à toutes les versions d’Aurora PostgreSQL.

Contexte

Pour lire ou manipuler des données, PostgreSQL y accède via des mémoires tampons partagées. Pour lire à partir de la mémoire tampon, un processus obtient un verrou léger (LWLock) sur le contenu de la mémoire tampon en mode partagé. Pour écrire dans la mémoire tampon, il obtient ce verrou en mode exclusif. Les verrous partagés permettent à d’autres processus d’acquérir simultanément des verrous partagés sur ce contenu. Les verrous exclusifs empêchent les autres processus d’obtenir tout type de verrou sur ce contenu.

L’événement LWLock:buffer_content (BufferContent) indique que plusieurs processus tentent de générer des verrous légers (LWLocks) sur le contenu d’une mémoire tampon spécifique.

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

Un événement LWLock:buffer_content (BufferContent) trop fréquent peut révéler un problème de performances dont les causes sont généralement les suivantes :

Augmentation des mises à jour simultanées des mêmes données

Le nombre de sessions simultanées associées à des requêtes de mise à jour du même contenu de mémoire tampon peut augmenter. Ce conflit peut être plus marqué sur les tables contenant beaucoup d’index.

Les données de la charge de travail ne sont pas en mémoire

Lorsque les données traitées par la charge de travail active ne sont pas en mémoire, la fréquence de ces événements d’attente peut augmenter. Cet effet est dû au fait que les processus détenant des verrous peuvent les conserver plus longtemps pendant qu’ils effectuent des opérations d’I/O disque.

Utilisation excessive de contraintes de clé étrangère

Les contraintes de clé étrangère peuvent augmenter la durée pendant laquelle un processus conserve un verrou de contenu de mémoire tampon. Cet effet est dû au fait que les opérations de lecture ont besoin d’un verrou de contenu de mémoire tampon partagée sur la clé référencée pendant la mise à jour de cette clé.

Actions

Nous vous recommandons différentes actions en fonction des causes de votre événement d’attente. Vous pouvez identifier les événements LWLock:buffer_content (BufferContent) en utilisant Analyse des performances d’Amazon RDS ou en interrogeant la vue pg_stat_activity.

Améliorez l’efficacité en mémoire

Pour que les données de la charge de travail active aient plus de chances d’être mises en mémoire, partitionnez les tables ou procédez à une augmentation d’échelle de votre classe d’instance. Pour plus d’informations sur les classes d’instance de base de données, consultez Classes d’instance de base de données Amazon Aurora.

Surveillez la métrique BufferCacheHitRatio, qui mesure le pourcentage de demandes qui sont traitées par le cache des tampons d’une instance de base de données dans votre cluster de bases de données. Cette métrique fournit des informations sur la quantité de données traitées par la mémoire. Un taux de réussite élevé indique que votre instance de base de données dispose de suffisamment de mémoire pour votre ensemble de données de travail, tandis qu’un faible taux indique que vos requêtes accèdent fréquemment aux données à partir du stockage.

Dans la section Paramètres de la mémoire du rapport PG Collector, les résultats de lecture du cache par table et par index peuvent fournir des informations sur le taux d’accès au cache pour les tables et les index.

Réduction de l’utilisation des contraintes de clé étrangère

Examinez les charges de travail qui présentent un nombre élevé d’événements d’attente LWLock:buffer_content (BufferContent) pour déterminer si des contraintes de clé étrangère sont utilisées. Supprimez les contraintes de clé étrangère inutiles.

Supprimez les index inutilisés

Pour les charges de travail qui présentent un nombre élevé d’événements d’attente LWLock:buffer_content (BufferContent), identifiez les index inutilisés et supprimez-les.

La section des index inutilisés du rapport PG Collector peut fournir des informations sur les index inutilisés dans la base de données.

Suppression des index dupliqués

Identifiez les index dupliqués et supprimez-les.

La section des index dupliqués du rapport PG Collector peut fournir des informations sur les index dupliqués dans la base de données.

Suppression ou RÉINDEXATION des index non valides

Les index non valides surviennent généralement lors de l’utilisation de CREATE INDEX CONCURRENTLY ou REINDEX CONCURRENTLY. Dans ce cas, la commande échoue ou est abandonnée.

Les index non valides ne peuvent pas être utilisés pour les requêtes, mais ils sont tout de même mis à jour et occupent de l’espace disque.

La section Indexes non valides du rapport PG Collector peut fournir des informations sur les index non valides dans la base de données.

Utilisation d’index partiels

Des index partiels peuvent être utilisés pour améliorer les performances des requêtes et réduire la taille de l’index. Ils reposent sur un sous-ensemble d’une table, qui est défini par une expression conditionnelle. Comme indiqué dans la documentation sur les index partiels, ils peuvent réduire la charge de travail liée à la maintenance des index, car PostgreSQL n’a pas besoin de mettre à jour l’index dans tous les cas.

Suppression du gonflement des tables et des index

Un gonflement excessif des tables et des index peut avoir un impact négatif sur les performances de la base de données. Les tables et les index gonflés augmentent la taille de l’ensemble de travail actif, dégradant ainsi l’efficacité de la mémoire. En outre, le gonflement augmente les coûts de stockage et ralentit l’exécution des requêtes. Pour diagnostiquer les problèmes de gonflement, consultez Diagnostic du gonflement de la table et de l'index. La section Fragmentation (Bloat) du rapport PG Collector peut fournir des informations sur le gonflement des tables et des index.

Pour remédier au gonflement des tables et des index, plusieurs options s’offrent à vous :

VACUUM FULL

VACUUM FULL crée une copie de la table, en ne gardant que les tuples dynamiques, puis remplace l’ancienne table par la nouvelle tout en appliquant un verrou ACCESS EXCLUSIVE. En empêchant toute lecture ou écriture dans la table, cela peut provoquer une panne. De plus, VACUUM FULL prend plus de temps si la table est volumineuse.

pg_repack

pg_repack est utile dans les situations où VACUUM FULL pourrait ne pas convenir. Il crée une table qui contient les données de la table gonflée, suit les modifications par rapport à la table d’origine, puis remplace la table d’origine par la nouvelle. Il ne verrouille pas la table d’origine pour les opérations de lecture ou d’écriture pendant la création de la nouvelle table. Pour découvrir comment utiliser pg_repack, consultez Suppression du gonflement avec pg_repack et pg_repack.

REINDEX

La commande REINDEX peut être utilisée pour remédier au gonflement de l’index. REINDEX écrit une nouvelle version de l’index sans les pages inactives ni les pages vides ou presque vides, réduisant ainsi sa consommation d’espace. Pour des informations détaillées sur la commande REINDEX, reportez-vous à la documentation de REINDEX.

Après avoir éliminé le gonflement des tables et des index, il peut être nécessaire d’augmenter la fréquence de la fonctionnalité d’autovacuum sur ces tables. La mise en œuvre de paramètres d’autovacuum agressifs au niveau des tables contribue à prévenir les futurs gonflements. Pour plus d’informations, consultez la documentation sur Vacuuming and analyzing tables automatically.