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.

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

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.