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:BufferIO (IPC:BufferIO)
L'événement LWLock:BufferIO se produit lorsqu'Aurora PostgreSQL ou RDS for PostgreSQL attend que d'autres processus terminent leurs opérations d'entrée/sortie (I/O) en cas de tentative simultanée d'accès à une page. Le but est que la même page soit lue dans la mémoire tampon partagée.
Versions de moteur pertinentes
Ces informations sur les événements d'attente s'appliquent à toutes les versions d'Aurora PostgreSQL. Pour Aurora PostgreSQL 12 et versions antérieures, cet événement d'attente est nommé lwlock:buffer_io, tandis qu'il est nommé lwlock:bufferio dans la version Aurora PostgreSQL 13. Depuis la version Aurora PostgreSQL 14, l'événement d'attente BufferIO est passé du type d'événement d'attente (IPC:Bufferio) LWLock à IPC.
Contexte
Chaque mémoire tampon partagée possède un verrou I/O qui est associé à l'événement d'attente LWLock:BufferIO, chaque fois qu'un bloc (ou une page) doit être récupéré en dehors du groupe de mémoires tampons partagées.
Ce verrou est utilisé pour gérer plusieurs sessions qui ont toutes besoin d'accéder au même bloc. Ce bloc doit être lu en dehors du groupe de mémoires tampons partagées, défini par le paramètre shared_buffers.
Dès que la page est lue dans le groupe de mémoires tampons partagées, le verrou LWLock:BufferIO est libéré.
Note
L'événement d'attente LWLock:BufferIO précède l'événement d'attente IO : DataFileRead. L'événement d'attente IO:DataFileRead se produit lorsque les données sont lues à partir du stockage.
Pour en savoir plus sur les verrous légers, consultez Présentation du verrouillage
Causes
Les principales causes de l'événement d'attente LWLock:BufferIO sont les suivantes :
-
Plusieurs backends ou connexions tentant d'accéder à la même page qui est également en attente d'une opération I/O
-
Rapport entre la taille du groupe de mémoires tampons partagées (défini par le paramètre
shared_buffers) et le nombre de mémoires tampons nécessaires à la charge de travail actuelle -
La taille du groupe de mémoires tampons partagées n'est pas bien équilibrée par rapport au nombre de pages expulsées par d'autres opérations
-
Index volumineux ou gonflés qui obligent le moteur à lire plus de pages que nécessaire dans le groupe de mémoires tampons partagées
-
Absence d'index qui oblige le moteur de base de données à lire plus de pages que nécessaire dans les tables
-
Pics soudains de connexions à la base de données tentant d'effectuer des opérations sur la même page
Actions
Nous vous recommandons différentes actions en fonction de l'origine de votre événement d'attente :
-
Observez les métriques Amazon CloudWatch pour établir une corrélation entre les fortes diminutions de
BufferCacheHitRatioet les événements d'attenteLWLock:BufferIO. Cet effet peut indiquer que vous disposez d'un petit paramètre de mémoires tampons partagées. Il peut être nécessaire de l'augmenter ou de procéder à une augmentation d'échelle de votre classe d'instance de base de données. Vous pouvez décomposer votre charge de travail en plusieurs nœuds de lecture. -
Réglez
max_wal_sizeetcheckpoint_timeouten fonction de l'heure de pointe de votre charge de travail si vous constatez queLWLock:BufferIOcoïncide avec des baisses de la métriqueBufferCacheHitRatio. Identifiez ensuite la requête qui pourrait en être la cause. -
Recherchez les index inutilisés et supprimez-les.
-
Utilisez des tables partitionnées (qui comportent également des index partitionnés). Cela permet de limiter la réorganisation des index et de réduire son impact.
-
Évitez d'indexer inutilement des colonnes.
-
Empêchez les pics soudains de connexions à la base de données en utilisant un groupe de connexions.
-
En guise de bonne pratique, limitez le nombre maximal de connexions à la base de données.
