# LWLock:buffer\$1content (BufferContent)
O evento `LWLock:buffer_content` ocorre quando uma sessão aguarda para ler ou gravar uma página de dados na memória enquanto outra sessão fica com a página bloqueada para gravação. No Aurora PostgreSQL 13 e versões superiores, esse evento de espera é chamado de `BufferContent`.
**Topics**
+ [Versões compatíveis do mecanismo](#apg-waits.lockbuffercontent.context.supported)
+ [Contexto](#apg-waits.lockbuffercontent.context)
+ [Possíveis causas do maior número de esperas](#apg-waits.lockbuffercontent.causes)
+ [Ações](#apg-waits.lockbuffercontent.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera têm suporte para todas as versões do Aurora PostgreSQL.
## Contexto
Para ler ou manipular dados, o PostgreSQL os acessa por meio de buffers de memória compartilhada. Para ler a partir do buffer, um processo obtém um bloqueio leve (LWLock) no conteúdo do buffer no modo compartilhado. Para gravar no buffer, ele adquire esse bloqueio no modo exclusivo. Bloqueios compartilhados permitem que outros processos adquiram bloqueios compartilhados simultaneamente nesse conteúdo. Bloqueios exclusivos impedem que outros processos obtenham qualquer tipo de bloqueio nele.
O evento `LWLock:buffer_content` (`BufferContent`) indica que vários processos estão tentando obter bloqueios leves (LWLocks) no conteúdo de um buffer específico.
## Possíveis causas do maior número de esperas
Quando o evento `LWLock:buffer_content` (`BufferContent`) aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:
**Maior número de atualizações simultâneas para os mesmos dados**
Pode haver um aumento no número de sessões simultâneas com consultas que atualizam o mesmo conteúdo do buffer. Essa contenção pode ser mais evidente em tabelas com vários índices.
**Os dados da workload não estão na memória**
Quando os dados que a workload ativa está processando não estão na memória, esses eventos de espera podem aumentar. Esse efeito ocorre porque os processos que mantêm bloqueios podem fazer isso por mais tempo enquanto executam operações de E/S de disco.
**Uso excessivo de restrições de chaves externas**
Restrições de chave externas podem aumentar o tempo durante o qual um processo mantém um bloqueio de conteúdo de buffer. Esse efeito ocorre porque operações de leitura exigem um bloqueio de conteúdo de buffer compartilhado na chave referenciada enquanto esta está sendo atualizada.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera. Você pode identificar eventos `LWLock:buffer_content` (`BufferContent`) utilizando o Amazon RDS Performance Insights ou consultando a visualização `pg_stat_activity`.
**Topics**
+ [Melhorar a eficiência na memória](#apg-waits.lockbuffercontent.actions.in-memory)
+ [Reduzir o uso de restrições de chaves externas](#apg-waits.lockbuffercontent.actions.foreignkey)
+ [Remover índices não utilizados](#apg-waits.lockbuffercontent.actions.indexes)
+ [Remover índices duplicados](#apg-waits.lockbuffercontent.actions.duplicate-indexes)
+ [Excluir ou REINDEXAR índices inválidos](#apg-waits.lockbuffercontent.actions.invalid-indexes)
+ [Usar índices parciais](#apg-waits.lockbuffercontent.actions.partial-indexes)
+ [Remover o inchaço de tabelas e índices](#apg-waits.lockbuffercontent.actions.bloat)
### Melhorar a eficiência na memória
Para aumentar as chances de que os dados da workload ativa estejam na memória, particione tabelas ou aumente a escala da sua classe de instância na vertical. Para obter informações sobre classes de instância de banco de dados, consulte [Classes de instâncias de banco de dados do Amazon Aurora](Concepts.DBInstanceClass.md).
Monitore a métrica `BufferCacheHitRatio`, que mede a porcentagem de solicitações atendidas pelo cache do buffer de uma instância de banco de dados em seu cluster de banco de dados. Essa métrica fornece insights sobre a quantidade de dados que estão sendo obtidos da memória. Uma alta taxa de acerto indica que a instância de banco de dados tem memória suficiente disponível para seu conjunto de dados de trabalho, enquanto uma taxa baixa sugere que suas consultas acessam dados do armazenamento com frequência.
O acerto de leitura do cache por tabela e o acerto de leitura do cache por índice na seção de configuração de memória do relatório do [PG Collector](https://github.com/awslabs/pg-collector) podem fornecer insights sobre a taxa de acerto do cache de tabelas e índices.
### Reduzir o uso de restrições de chaves externas
Investigue workloads com um número elevado de eventos de espera `LWLock:buffer_content` (`BufferContent`) quanto ao uso de restrições de chaves externas. Remova restrições desnecessárias de chaves externas.
### Remover índices não utilizados
Para workloads com um número elevado de eventos de espera `LWLock:buffer_content` (`BufferContent`), identifique índices não utilizados e remova-os.
A seção de índices não utilizados do relatório do [PG Collector](https://github.com/awslabs/pg-collector) pode fornecer insights sobre os índices não utilizados no banco de dados.
### Remover índices duplicados
Identifique índices duplicados e remova-os.
A seção de índices duplicados do relatório do [PG Collector](https://github.com/awslabs/pg-collector) pode fornecer insights sobre os índices duplicados no banco de dados.
### Excluir ou REINDEXAR índices inválidos
Os índices inválidos geralmente se apresentam ao usar `CREATE INDEX CONCURRENTLY` ou `REINDEX CONCURRENTLY` e quando o comando falha ou é cancelado.
Embora esses índices não possam ser usados para consultas, eles serão atualizados e ocuparão espaço em disco.
A seção de índices inválidos do relatório do [PG Collector](https://github.com/awslabs/pg-collector) pode fornecer insights sobre os índices inválidos no banco de dados.
### Usar índices parciais
Os índices parciais podem ser aproveitados para aprimorar o desempenho da consulta e reduzir o tamanho do índice. Um índice parcial é um índice criado sobre um subconjunto de uma tabela definido por uma expressão condicional. Conforme detalhado na documentação do [índice parcial](https://www.postgresql.org/docs/current/indexes-partial.html), os índices parciais podem reduzir os custos indiretos de manutenção de índices, pois o PostgreSQL não precisa atualizar o índice em todos os casos.
### Remover o inchaço de tabelas e índices
O inchaço de tabelas e índices pode afetar negativamente o desempenho do banco de dados. Tabelas e índices grandes demais aumentam o tamanho do conjunto de trabalho ativo, degradando a eficiência na memória. Além disso, o inchaço aumenta os custos de armazenamento e causa lentidão na execução de consultas. Para diagnosticar inchaços, consulte [Diagnosticar a sobrecarga na tabela e no índice](AuroraPostgreSQL.diag-table-ind-bloat.md). Além disso, a seção de fragmentação (inchaço) do relatório do [PG Collector](https://github.com/awslabs/pg-collector) pode fornecer insights sobre o inchaço de tabelas e índices.
Para lidar com o inchaço de tabelas e índices, há algumas opções:
**VACUUM FULL**
`VACUUM FULL` cria uma cópia da tabela, copiando somente as tuplas ativas e, em seguida, substitui a tabela antiga pela nova enquanto mantém um bloqueio `ACCESS EXCLUSIVE`. Isso evita qualquer leitura ou gravação na tabela, o que pode causar uma interrupção. Além disso, `VACUUM FULL` levará mais tempo se a tabela for grande.
** pg\$1repack **
O `pg_repack` é útil em situações em que `VACUUM FULL` talvez não seja adequado. Ele cria uma tabela que contém os dados da tabela inchada, monitora as alterações na tabela original e, em seguida, substitui a tabela original pela nova. Ele não bloqueia a tabela original para operações de leitura ou gravação enquanto está criando a outra tabela. Para ter mais informações sobre como usar `pg_repack`, consulte [Removing bloat with pg\$1repack](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/pg-repack.html) e [pg\$1repack](https://reorg.github.io/pg_repack/).
**REINDEX**
O comando `REINDEX` pode ser usado para lidar com o inchaço do índice. `REINDEX` grava uma nova versão do índice sem as páginas inativas ou as páginas vazias ou quase vazias, reduzindo assim o consumo de espaço do índice. Para ter informações detalhadas sobre o comando [https://www.postgresql.org/docs/current/sql-reindex.html](https://www.postgresql.org/docs/current/sql-reindex.html), consulte a documentação do REINDEX.
Depois de remover o inchaço das tabelas e índices, pode ser necessário aumentar a frequência de autovacuum nessas tabelas. A implementação de configurações agressivas de autovacuum em nível de tabela pode ajudar a evitar a ocorrência de futuros inchaços. Para ter mais informações, consulte a documentação em [https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html).