LWLock:BufferIO (IPC:BufferIO) - Amazon Aurora
Versiones del motor relevantesContextoCausasAcciones

LWLock:BufferIO (IPC:BufferIO)

El evento LWLock:BufferIO ocurre cuando Aurora PostgreSQL o RDS for 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.

Versiones del motor relevantes

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

Contexto

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. 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.

Causas

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

  • Picos repentinos de conexiones a la base de datos que intentan hacer operaciones en la misma página

Acciones

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.