LWLock:buffer_mapping - Amazon Aurora
Versões compatíveis do mecanismoContextoCausasAções

LWLock:buffer_mapping

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 aparece como LWLock:buffer_mapping no Aurora PostgreSQL versão 12 e inferiores e como LWLock:BufferMapping na versão 13 e superiores.

Versões compatíveis do mecanismo

As informações sobre eventos de espera são relevantes para o Aurora PostgreSQL versão 9.6 e versões superiores.

Contexto

O grupo de buffer compartilhado é uma área de memória do Aurora 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, assegure-se de reiniciar o banco de dados. Para mais informações, consulte Buffers compartilhados.

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.

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:

BufferCacheHitRatio

Essa métrica do Amazon CloudWatch mede a porcentagem de solicitações atendidas pelo cache de buffer de uma instância de banco de dados no seu cluster de banco de dados. Você pode ver essa métrica diminuir na preparação para o evento de espera LWLock:buffer_mapping.

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 em blks_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_read em preparação para o evento de espera LWLock: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_returned mostra o número de linhas lidas. A métrica tup_fetched mostra o número de linhas retornadas ao cliente. Se tup_returned for significativamente maior que tup_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.