# LWLock:BufferIO (IPC:BufferIO)
O evento `LWLock:BufferIO` ocorre quando o RDS para PostgreSQL aguarda outros processos terminarem suas operações de entrada/saída (E/S) ao tentarem acessar simultaneamente uma página. Sua finalidade é fazer com que a mesma página seja lida no buffer compartilhado.
**Topics**
+ [Versões de mecanismos relevantes](#wait-event.lwlockbufferio.context.supported)
+ [Contexto](#wait-event.lwlockbufferio.context)
+ [Causas](#wait-event.lwlockbufferio.causes)
+ [Ações](#wait-event.lwlockbufferio.actions)
## Versões de mecanismos relevantes
Essas informações de evento de espera são relevantes para todas as versões do RDS para PostgreSQL. Para o RDS para PostgreSQL 12 e versões anteriores, esse evento de espera é denominado lwlock:buffer\$1io, ao passo que, no RDS para PostgreSQL 13, ele é denominado lwlock:bufferio. A partir do RDS para PostgreSQL 14, o evento de espera BufferIO mudou do tipo de evento de espera `LWLock` para `IPC` (IPC:BufferIO).
## Contexto
Cada buffer compartilhado tem um bloqueio de E/S associado ao evento de espera `LWLock:BufferIO`, todas as vezes que um bloqueio (ou uma página) precisa ser recuperado fora do grupo de buffer compartilhado.
Esse bloqueio é utilizado para lidar com várias sessões que requerem acesso ao mesmo bloco. Esse bloco precisa ser lido de fora do grupo de buffer compartilhado, definido pelo parâmetro `shared_buffers`.
Assim que a página for lida dentro do grupo de buffer compartilhado, o bloqueio de `LWLock:BufferIO` será liberado.
**nota**
O evento de espera `LWLock:BufferIO` precede o evento de espera [IO:DataFileRead](wait-event.iodatafileread.md). O evento de espera `IO:DataFileRead` ocorre enquanto os dados estão sendo lidos do armazenamento.
Para obter mais informações sobre bloqueios leves, consulte [Visão geral de bloqueios](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).
## Causas
Causas comuns do surgimento do evento `LWLock:BufferIO` nas principais esperas incluem:
+ Vários backends ou conexões tentando acessar a mesma página para a qual também há uma operação de E/S pendente
+ A proporção entre o tamanho do grupo de buffer compartilhado (definido pelo parâmetro `shared_buffers`) e o número de buffers necessários para a workload atual
+ O tamanho do grupo de buffer compartilhado não está bem equilibrado com o número de páginas que estão sendo despejadas por outras operações
+ Índices grandes ou inchados que exigem que o mecanismo leia mais páginas que o necessário no grupo de buffer compartilhado
+ Ausência índices, o que força o mecanismo de banco de dados a ler mais páginas das tabelas que o necessário
+ Pontos de verificação ocorrendo com muita frequência ou que precisam liberar muitas páginas modificadas
+ Picos repentinos de conexões de banco de dados tentando realizar operações na mesma página
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera:
+ Observe as métricas do Amazon CloudWatch para encontrar uma correlação entre reduções acentuadas nos eventos de espera `BufferCacheHitRatio` e `LWLock:BufferIO`. Esse efeito pode significar que existe uma pequena configuração de buffers compartilhados. Talvez seja necessário aumentá-lo ou aumentar a escala da classe de instância de banco de dados na vertical. Você pode dividir sua workload em mais nós de leitura.
+ Ajuste `max_wal_size` e `checkpoint_timeout` com base no horário de pico da workload, se você vir `LWLock:BufferIO` correspondendo a quedas da métrica `BufferCacheHitRatio`. Em seguida, identifique qual consulta pode estar causando isso.
+ Verifique se existem índices não utilizados e remova-os.
+ Use tabelas particionadas (que também tenham índices particionados). Fazer isso ajuda a manter a reordenação do índice baixo e reduz seu impacto.
+ Evite indexar colunas desnecessariamente.
+ Evite picos repentinos de conexão de banco de dados utilizando um grupo de conexões.
+ Restrinja o número máximo de conexões com o banco de dados como prática recomendada.