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:mappage\$1tampon
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.
**Topics**
+ [Versions de moteur prises en charge](#apg-waits.lwl-buffer-mapping.context.supported)
+ [Contexte](#apg-waits.lwl-buffer-mapping.context)
+ [Causes](#apg-waits.lwl-buffer-mapping.causes)
+ [Actions](#apg-waits.lwl-buffer-mapping.actions)
## 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 de plus amples informations, veuillez consulter [Mémoires tampons partagées](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.buffer-pool).
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 des causes de votre événement d’attente.
**Topics**
+ [Surveillez les métriques liées à la mémoire tampon](#apg-waits.lwl-buffer-mapping.actions.monitor-metrics)
+ [Évaluez votre stratégie d'indexation](#apg-waits.lwl-buffer-mapping.actions.indexes)
+ [Réduisez le nombre de mémoires tampons qui doivent être allouées rapidement](#apg-waits.lwl-buffer-mapping.actions.buffers)
### 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 CloudWatch métrique Amazon 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. 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`
Ce compteur Performance Insights indique le nombre de blocs devant I/O être lus dans le pool de mémoire tampon partagé. 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.