# LWLock:BufferIO (IPC:BufferIO)
<a name="wait-event.lwlockbufferio"></a>

El evento `LWLock:BufferIO` ocurre cuando RDS para PostgreSQL espera que otros procesos terminen sus operaciones de entrada/salida (E/S) cuando intentan acceder a una página de forma simultánea. Su propósito es que la misma página se lea en el búfer compartido.

**Topics**
+ [Versiones del motor relevantes](#wait-event.lwlockbufferio.context.supported)
+ [Context](#wait-event.lwlockbufferio.context)
+ [Causas](#wait-event.lwlockbufferio.causes)
+ [Acciones](#wait-event.lwlockbufferio.actions)

## Versiones del motor relevantes
<a name="wait-event.lwlockbufferio.context.supported"></a>

Esta información de eventos de espera es relevante para todas las versiones de RDS para PostgreSQL. Para RDS para PostgreSQL 12 y versiones anteriores, este evento de espera se denomina lwlock:buffer\$1io, mientras que en la versión 13 de RDS para PostgreSQL se denomina lwlock:bufferio. A partir de la versión 14 de RDS para PostgreSQL, el evento de espera BufferIO se movió de tipo de evento de espera `LWLock` a `IPC` (IPC:bufferIO). 

## Context
<a name="wait-event.lwlockbufferio.context"></a>

Cada búfer compartido tiene un bloqueo de E/S que está asociado con el evento de espera `LWLock:BufferIO`, cada vez que un bloque (o una página) se tiene que recuperar fuera del grupo de búferes compartidos.

Este bloqueo se utiliza para manejar múltiples sesiones que requieren acceso al mismo bloque. Este bloque se tiene que leer desde fuera del grupo de búferes compartidos, que se define con el parámetro `shared_buffers`.

Tan pronto como la página se lee dentro del grupo de búferes compartidos, el bloqueo `LWLock:BufferIO` se libera.

**nota**  
El evento de espera `LWLock:BufferIO` precede al evento de espera [IO:DataFileRead](wait-event.iodatafileread.md). El evento de espera `IO:DataFileRead` se produce mientras se leen datos del almacenamiento.

Para obtener más información sobre los bloqueos ligeros, consulte [Información general sobre los bloqueos](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).

## Causas
<a name="wait-event.lwlockbufferio.causes"></a>

Las causas más comunes para que el evento `LWLock:BufferIO` aparezca en el máximo de esperas son las siguientes:
+ Varios backends o conexiones que intentan acceder a la misma página que también tiene pendiente una operación de E/S
+ La relación entre el tamaño del grupo de búferes compartidos (definido por el parámetro `shared_buffers`) y el número de búferes que necesita la carga de trabajo actual
+ El tamaño del grupo de búferes compartidos no está bien equilibrado con el número de páginas que se desalojan por otras operaciones
+ Índices grandes o sobrecargados que requieren que el motor lea más páginas de las necesarias en el grupo de búferes compartidos
+ La falta de índices obliga al motor de la base de datos a leer más páginas de las necesarias en las tablas
+ Puntos de control que se producen con demasiada frecuencia o que necesitan vaciar demasiadas páginas modificadas
+ Picos repentinos de conexiones a la base de datos que intentan hacer operaciones en la misma página

## Acciones
<a name="wait-event.lwlockbufferio.actions"></a>

Recomendamos diferentes acciones en función de las causas del evento de espera:
+ Observe las métricas de Amazon CloudWatch en busca de una correlación entre los descensos bruscos de los eventos de espera `BufferCacheHitRatio` y `LWLock:BufferIO`. Este efecto a veces significa que tiene una configuración de búferes compartidos pequeña. Puede que tenga que aumentarla o escalar verticalmente la clase de instancia de base de datos. Puede dividir su carga de trabajo en más nodos de lectura.
+ Ajuste `max_wal_size` y `checkpoint_timeout` en función del tiempo de pico de su carga de trabajo si ve que `LWLock:BufferIO` coincide con las caídas de la métrica `BufferCacheHitRatio`. A continuación, identifique qué consulta puede ser la causa.
+ Verifique si tiene índices sin utilizar y elimínelos.
+ Utilice tablas particionadas (que también tengan índices particionados). Esto ayuda a mantener un bajo nivel de reordenación de índices y reduce su impacto.
+ Evite indexar columnas innecesariamente.
+ Evite los picos repentinos de conexión a la base de datos, utilice un grupo de conexiones.
+ Limite el número máximo de conexiones a la base de datos como práctica recomendada.