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'LWLock:BufferIOévénement se produit lorsqu'Aurora PostgreSQL ou RDS pour PostgreSQL attend que d'autres processus input/output (I/O terminent leurs opérations alors qu'ils tentent simultanément d'accéder à 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 CloudWatch les statistiques d'Amazon pour établir une corrélation entre les fortes baisses du nombre d'événements
BufferCacheHitRatioet lesLWLock:BufferIOpériodes d'attente. 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. -
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.
