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 dans la mémoire tampon, un processus obtient un lock 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 d'obtenir des verrous légers (LWLocks) sur le contenu d'une mémoire tampon spécifique.

Causes probables de l'allongement des temps 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 verrouillés peuvent les conserver plus longtemps lorsqu'ils effectuent des I/O opérations sur le 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 Amazon RDS Performance Insights ou en interrogeant la vue pg_stat_activity.

Rubriques

• Améliorez l'efficacité en mémoire

• Réduisez l'utilisation des contraintes de clé étrangère

• Supprimez les index inutilisés

• Supprimer les index dupliqués

• Supprimer ou RÉINDEXER les index non valides

• Utiliser des index partiels

• Supprimer le gonflement de la table et de l'index

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'instances de base de données, consultez Classes d'instances de base de données Amazon Aurora.

Surveillez la BufferCacheHitRatio métrique, qui mesure le pourcentage de demandes traitées par le cache tampon d'une instance de base de données dans votre cluster de base de données. Cette métrique donne un aperçu de la quantité de données servies depuis la mémoire. Un taux de réussite élevé indique que votre instance de base de données dispose de suffisamment de mémoire disponible pour votre ensemble de données de travail, tandis qu'un faible ratio indique que vos requêtes accèdent fréquemment à des données depuis le stockage.

Les résultats de lecture du cache par table et de lecture du cache par index dans la section Paramètres de la mémoire du rapport PG Collector peuvent fournir des informations sur le taux de réussite du cache des tables et des index.

Réduisez 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 de la base de données.

Supprimer les 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 de la base de données.

Supprimer ou RÉINDEXER les index non valides

Les index non valides apparaissent généralement lors de l'utilisation de CREATE INDEX CONCURRENTLY ou REINDEX CONCURRENTLY et la commande échoue ou est abandonnée.

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

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

Utiliser des index partiels

Les index partiels peuvent être utilisés pour améliorer les performances des requêtes et réduire la taille de l'index. Un index partiel est un index construit sur un sous-ensemble d'une table, le sous-ensemble étant défini par une expression conditionnelle. Comme indiqué dans la documentation sur les index partiels, les index partiels 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.

Supprimer le gonflement de la table et de l'index

Une surcharge excessive 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 surchargés augmentent la taille de l'ensemble de travail actif, dégradant ainsi l'efficacité de la mémoire. En outre, la surcharge augmente les coûts de stockage et ralentit l'exécution des requêtes. Pour diagnostiquer le ballonnement, reportez-vous auDiagnostic du gonflement de la table et de l'index. En outre, la section Fragmentation (bloat) du rapport PG Collector peut fournir des informations sur le gonflement des tables et des index.

Pour remédier à l'engorgement des tables et des index, plusieurs options s'offrent à vous :

VACUUM FULL

VACUUM FULLcrée une nouvelle copie de la table, en copiant uniquement les tuples dynamiques, puis remplace l'ancienne table par la nouvelle tout en maintenant un ACCESS EXCLUSIVE verrou enfoncé. Cela empêche toute lecture ou écriture dans la table, ce qui peut provoquer une panne. De plus, VACUUM FULL cela prendra plus de temps si la table est grande.

pg_repack

pg_repackC'est utile dans les situations où VACUUM FULL cela pourrait ne pas convenir. Il crée une nouvelle table qui contient les données de la table surchargé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 plus d'informations et pour savoir comment l'utiliserpg_repack, consultez Supprimer le bloat avec pg_repack et pg_repack.

REINDEX

La REINDEX commande peut être utilisée pour remédier au gonflement de l'index. REINDEXécrit une nouvelle version de l'index sans les pages mortes ou les pages vides ou presque vides, réduisant ainsi la consommation d'espace de l'index. Pour des informations détaillées sur la REINDEXcommande, 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 d'aspiration automatique sur ces tables. La mise en œuvre de réglages d'aspiration automatique agressifs au niveau de la table peut aider à prévenir de futurs gonflements. Pour plus d'informations, consultez la documentation sur Vacuuming and analyzing tables automatically.