# LWLock:BufferMapping (LWLock:buffer\$1mapping)
<a name="wait-event.lwl-buffer-mapping"></a>

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

**Topics**
+ [Versões compatíveis do mecanismo](#wait-event.lwl-buffer-mapping.context.supported)
+ [Contexto](#wait-event.lwl-buffer-mapping.context)
+ [Causas](#wait-event.lwl-buffer-mapping.causes)
+ [Ações](#wait-event.lwl-buffer-mapping.actions)

## Versões compatíveis do mecanismo
<a name="wait-event.lwl-buffer-mapping.context.supported"></a>

As informações de eventos de espera são relevantes para o RDS para PostgreSQL versão 9.6 e posteriores.

## Contexto
<a name="wait-event.lwl-buffer-mapping.context"></a>

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
<a name="wait-event.lwl-buffer-mapping.causes"></a>

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
<a name="wait-event.lwl-buffer-mapping.actions"></a>

Recomenda-se ações distintas, dependendo dos motivos do evento de espera.

**Topics**
+ [Monitorar métricas relacionadas ao buffer](#wait-event.lwl-buffer-mapping.actions.monitor-metrics)
+ [Avaliar sua estratégia de indexação](#wait-event.lwl-buffer-mapping.actions.indexes)
+ [Diminuir o número de buffers que devem ser alocados rapidamente](#wait-event.lwl-buffer-mapping.actions.buffers)

### Monitorar métricas relacionadas ao buffer
<a name="wait-event.lwl-buffer-mapping.actions.monitor-metrics"></a>

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 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
<a name="wait-event.lwl-buffer-mapping.actions.indexes"></a>

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
<a name="wait-event.lwl-buffer-mapping.actions.buffers"></a>

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.