Esse evento ocorre quando uma sessão está aguardando para associar um bloco de dados a um buffer no grupo de buffer compartilhado.
nota
Esse evento é denominado LWLock:BufferMapping para o RDS para PostgreSQL versão 13 e posteriores. No caso do RDS para PostgreSQL versão 12 e posteriores, esse evento é denominado LWLock:buffer_mapping.
Versões compatíveis do mecanismo
As informações de eventos de espera são relevantes para o RDS para PostgreSQL versão 9.6 e posteriores.
Contexto
O grupo de buffer compartilhado é uma área de memória do PostgreSQL que contém todas as páginas que estão ou estavam sendo utilizadas por processos. Quando um processo precisa de uma página, ele lê a página no grupo de buffer compartilhado. O parâmetro shared_buffers define o tamanho do buffer compartilhado e reserva uma área de memória para armazenar a tabela e as páginas de índice. Se você alterar esse parâmetro, reinicie o banco de dados.
O evento de espera LWLock:buffer_mapping ocorre nos seguintes cenários:
-
Um processo pesquisa a tabela de buffer em busca de uma página e adquire um bloqueio de mapeamento de buffer compartilhado.
-
Um processo carrega uma página no grupo de buffer e adquire um bloqueio exclusivo de mapeamento de buffer.
-
Um processo remove uma página do grupo e adquire um bloqueio exclusivo de mapeamento de buffer.
Causas
Quando esse evento aparece mais do que o normal, possivelmente indicando um problema de performance, o banco de dados está paginando dentro e fora do grupo de buffer compartilhado. As causas típicas incluem:
-
Consultas grandes
-
Índices e tabelas inchados
-
Varreduras completas de tabelas
-
Um tamanho de grupo compartilhado menor que o conjunto de trabalho
Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
Tópicos
Monitorar métricas relacionadas ao buffer
Quando as esperas LWLock:buffer_mapping atingirem picos, investigue a taxa de acertos de buffer. É possível utilizar essas métricas para entender melhor o que está acontecendo no cache de buffer. Examine as métricas a seguir:
blks_hit-
Essa métrica de contador do Performance Insights indica o número de bloqueios que foram recuperados do grupo de buffer compartilhado. Após o surgimento do evento de espera
LWLock:buffer_mapping, é possível observar um pico emblks_hit. blks_read-
Essa métrica de contador do Performance Insights indica o número de bloqueios que exigiram a leitura da E/S no grupo de buffer compartilhado. Você pode observar um pico em
blks_readem preparação para o evento de esperaLWLock:buffer_mapping.
Avaliar sua estratégia de indexação
Para confirmar que sua estratégia de indexação não está diminuindo a performance, verifique o seguinte:
- Inchaço de índice
-
Assegure-se de que o índice e o inchaço da tabela não estejam fazendo com que páginas desnecessárias sejam lidas no buffer compartilhado. Se as suas tabelas contiverem linhas não utilizadas, considere arquivar os dados e remover as linhas das tabelas. Em seguida, você poderá reconstruir os índices para as tabelas redimensionadas.
- Índices para consultas utilizadas com frequência
-
Para determinar se você tem os índices ideais, monitore as métricas do mecanismo de banco de dados no Performance Insights. A métrica
tup_returnedmostra o número de linhas lidas. A métricatup_fetchedmostra o número de linhas retornadas ao cliente. Setup_returnedfor significativamente maior quetup_fetched, talvez os dados não estejam devidamente indexados. Além disso, as estatísticas da tabela podem não estar atualizadas.
Diminuir o número de buffers que devem ser alocados rapidamente
Para diminuir os eventos de espera LWLock:buffer_mapping, tente reduzir o número de buffers que devem ser alocados rapidamente. Uma estratégia é realizar operações em lote menores. Talvez seja possível obter lotes menores particionando tabelas.
