LWLock:buffer_mapping - Amazon Aurora
Versions de moteur prises en chargeContexteCausesActions

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_mapping

Cet événement se produit lorsqu'une session attend d'associer un bloc de données à une mémoire tampon dans le groupe de mémoires tampons partagées.

Note

Cet événement apparaît sous la forme LWLock:buffer_mapping dans Aurora PostgreSQL 12 et versions antérieures, et sous la forme LWLock:BufferMapping dans Aurora PostgreSQL 13 et versions ultérieures.

Versions de moteur prises en charge

Ces informations sur les événements d'attente s'appliquent à Aurora PostgreSQL 9.6 et versions ultérieures.

Contexte

Le groupe de mémoires tampons partagées est une zone de mémoire d'Aurora PostgreSQL qui contient toutes les pages actuellement ou précédemment utilisées par les processus. Lorsqu'un processus a besoin d'une page, il la lit dans le groupe de mémoires tampons partagées. Le paramètre shared_buffers définit la taille de la mémoire tampon partagée et réserve une zone de mémoire pour stocker la table et les pages d'index. Si vous modifiez ce paramètre, veillez à redémarrer la base de données. Pour plus d'informations, consultez Mémoires tampons partagées.

L'événement d'attente LWLock:buffer_mapping se produit dans les scénarios suivants :

  • Un processus recherche une page dans la table des mémoires tampons et acquiert un verrou de mappage de mémoire tampon partagée.

  • Un processus charge une page dans le groupe de mémoires tampons et acquiert un verrou exclusif de mappage de mémoire tampon.

  • Un processus supprime une page du groupe et acquiert un verrou exclusif de mappage de mémoire tampon.

Causes

Lorsque cet événement se produit plus souvent qu'à l'accoutumée, indiquant un possible problème de performances, la base de données effectue une pagination dans et hors du groupe de mémoires tampons partagées. Les causes sont généralement les suivantes :

  • Requêtes volumineuses

  • Index et tables gonflés

  • Analyses de tables complètes

  • Taille de groupe partagé inférieure à celle de l'ensemble de travail

Actions

Nous vous recommandons différentes actions en fonction de l'origine de votre événement d'attente.

Surveillez les métriques liées à la mémoire tampon

Lorsque les événements d'attente LWLock:buffer_mapping atteignent un pic, examinez le taux d'accès à la mémoire tampon. Vous pouvez utiliser ces métriques pour mieux comprendre ce qui se passe dans le cache de mémoire tampon. Examinez les métriques suivantes :

BufferCacheHitRatio

Cette métrique Amazon CloudWatch mesure le pourcentage de requêtes qui sont traitées par le cache de mémoire tampon d'une instance de base de données dans votre cluster de bases de données. Vous verrez peut-être cette métrique diminuer dans la période précédant l'événement d'attente LWLock:buffer_mapping.

blks_hit

Cette métrique de compteur Performance Insights indique le nombre de blocs qui ont été récupérés à partir du groupe de mémoires tampons partagées. Après l'apparition de l'événement d'attente LWLock:buffer_mapping, vous pouvez observer un pic dans blks_hit.

blks_read

Cette mesure de compteur Performance Insights indique le nombre de blocs pour lesquels une lecture des I/O a été nécessaire dans le groupe de mémoires tampons partagées. Vous observerez peut-être un pic de blks_read dans la période précédant l'événement d'attente LWLock:buffer_mapping.

Évaluez votre stratégie d'indexation

Pour vous assurer que votre stratégie d'indexation ne nuit pas aux performances, vérifiez les éléments suivants :

Gonflement des index

Assurez-vous que le gonflement des index et des tables n'entraîne pas la lecture de pages inutiles dans la mémoire tampon partagée. Si vos tables contiennent des lignes inutilisées, archivez les données et supprimez les lignes des tables. Vous pouvez ensuite reconstruire les index des tables redimensionnées.

Index pour les requêtes fréquemment utilisées

Pour déterminer si vos index sont optimaux, surveillez les métriques du moteur de base de données dans Performance Insights. La métrique tup_returned indique le nombre de lignes lues. La métrique tup_fetched indique le nombre de lignes renvoyées au client. Si la métrique tup_returned est nettement supérieure à la métrique tup_fetched, les données risquent de ne pas être correctement indexées. De plus, les statistiques de votre table ne sont peut-être pas à jour.

Réduisez le nombre de mémoires tampons qui doivent être allouées rapidement

Pour réduire le nombre d'événements d'attente LWLock:buffer_mapping, essayez de réduire le nombre de mémoires tampons qui doivent être allouées rapidement. Une stratégie consiste à effectuer des opérations par lots de plus petite taille. Vous pouvez obtenir des lots plus petits en partitionnant vos tables.