LWLock:BufferIO (IPC:BufferIO) - Amazon Aurora
Versões de mecanismos relevantesContextoCausasAções

LWLock:BufferIO (IPC:BufferIO)

O evento LWLock:BufferIO ocorre quando o Aurora PostgreSQL ou o RDS for 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 Aurora PostgreSQL. Para o Aurora PostgreSQL 12 e versões anteriores, esse evento de espera é denominado lwlock:buffer_io, ao passo que, no Aurora PostgreSQL versão 13, é denominado lwlock:bufferio. A partir do Aurora PostgreSQL versão 14, o evento de espera BufferIO foi movido 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

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