;
```
Se a desativação do paralelismo produzir resultados melhores ou mais consistentes, desative-o para consultas específicas no nível da sessão usando os comandos SET. Para um impacto mais amplo, você pode querer desabilitar o paralelismo no nível da instância ajustando os parâmetros relevantes em seu grupo de parâmetros do cluster ou instância. Para obter mais informações, consulte [Amazon Aurora PostgreSQL parameters](AuroraPostgreSQL.Reference.ParameterGroups.md).
### Monitorar o uso de consultas paralelas
Use as consultas a seguir para obter visibilidade da atividade e da capacidade de consultas paralelas:
Verifique os processos de operador paralelos ativos:
```
SELECT
COUNT(*)
FROM
pg_stat_activity
WHERE
backend_type = 'parallel worker';
```
Esta consulta mostra o número de processos de operador paralelos ativos. Um valor alto pode indicar que seu `max\$1parallel\$1workers` está configurado com um valor alto e você pode querer reduzi-lo.
Verifique as consultas paralelas simultâneas:
```
SELECT
COUNT(DISTINCT leader_pid)
FROM
pg_stat_activity
WHERE
leader_pid IS NOT NULL;
```
Essa consulta retorna o número de processos líderes distintos que iniciaram consultas paralelas. Um número alto aqui indica que várias sessões estão executando consultas paralelas simultaneamente, o que pode aumentar a demanda de CPU e memória.
### Revisar e ajustar as configurações de consulta paralela
Analise os seguintes parâmetros para garantir que estejam alinhados à sua workload:
+ `max_parallel_workers`: número total de workers paralelos em todas as sessões.
+ `max_parallel_workers_per_gather`: máximo de workers por consulta.
Para workloads OLAP, aumentar esses valores pode melhorar o desempenho. Para workloads OLTP, valores mais baixos geralmente são preferidos.
```
SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
```
### Otimizar a alocação de recursos
Monitore a utilização da CPU e ajuste o número de vCPUs se for consistentemente alto e se seu aplicativo se beneficiar de consultas paralelas. Verifique se há memória adequada disponível para operações paralelas.
+ Use as métricas do Performance Insights para determinar se o sistema está limitado pela CPU.
+ Cada operador paralelo usa o seu próprio `work_mem`. Verifique se o uso total da memória está dentro dos limites da instância.
As consultas paralelas podem consumir substancialmente mais recursos do que as consultas não paralelas, porque cada processo de operador é completamente separado que tem aproximadamente o mesmo impacto no sistema que uma sessão de usuário adicional. Isso deve ser levado em consideração ao escolher um valor para essa configuração, bem como ao definir outras configurações que controlam a utilização de recursos, como `work_mem`. Para obter mais informações, consulte a [Documentação do PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Limites de recursos, como `work_mem`, são aplicados individualmente a cada operador, o que significa que a utilização total pode ser muito maior em todos os processos do que normalmente seria em qualquer processo único.
Aumente as vCPUs ou ajuste os parâmetros de memória se sua workload estiver altamente paralelizada.
### Investigar o gerenciamento de conexão
Se estiver experimentando esgotamento de conexões, revise as estratégias de pool de conexões do aplicativo. Implemente o pool de conexões no nível do aplicativo, se ainda não estiver em uso.
### Revisar e otimizar as operações de manutenção
Coordene a criação de índices e outras tarefas de manutenção para evitar a contenção de recursos. Agende essas operações fora do horário de pico. Evite agendar manutenções pesadas (por exemplo, construções paralelas de índices) durante períodos de alta carga de consultas do usuário. Essas operações podem consumir workers paralelos e impactar o desempenho de consultas regulares.
### Utilize o gerenciamento de planos de consultas (QPM)
No Aurora PostgreSQL, o atributo de gerenciamento de planos de consulta (QPM) foi projetado para garantir a adaptabilidade e a estabilidade do plano, independentemente das alterações no ambiente de banco de dados que poderiam causar a regressão do plano de consulta. Para obter mais informações, consulte [Visão geral do gerenciamento de planos de consulta do Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md). O QPM fornece algum controle sobre o otimizador. Revise os planos aprovados no QPM para garantir que estejam alinhados com as configurações atuais de paralelismo. Atualize ou remova planos desatualizados que possam estar forçando uma execução paralela subótima.
Você também pode corrigir os planos usando pg\$1hint\$1plan. Para obter mais informações, consulte [Corrigir planos usando pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan). Você pode usar a dica chamada `Parallel` para forçar a execução paralela. Para obter mais informações, consulte [Dicas para planos paralelos](https://github.com/ossc-db/pg_hint_plan/blob/master/docs/hint_table.md#hints-for-parallel-plans).
# IPC:ProcArrayGroupUpdate
O evento `IPC:ProcArrayGroupUpdate` ocorre quando uma sessão está aguardando o líder do grupo atualizar o status da transação ao final dessa operação. Embora o PostgreSQL geralmente associe eventos de espera do tipo IPC a operações de consulta paralela, esse evento de espera determinado não é específico de consultas paralelas.
**Topics**
+ [Versões compatíveis do mecanismo](#apg-rpg-ipcprocarraygroup.supported)
+ [Contexto](#apg-rpg-ipcprocarraygroup.context)
+ [Possíveis causas do maior número de esperas](#apg-rpg-ipcprocarraygroup.causes)
+ [Ações](#apg-rpg-ipcprocarraygroup.actions)
## Versões compatíveis do mecanismo
As informações sobre esse evento de espera são aceitas em todas as versões do Aurora PostgreSQL.
## Contexto
**Noções básicas sobre a matriz do processo**: a matriz do processo (proc) é uma estrutura de memória compartilhada no PostgreSQL. Ela contém informações sobre todos os processos em execução, incluindo detalhes da transação. Durante a conclusão da transação (`COMMIT` ou `ROLLBACK`), o ProcArray precisa ser atualizado para refletir a alteração e limpar o ID da transação da matriz. A sessão que tenta concluir sua transação deve adquirir um bloqueio exclusivo no ProcArray. Isso impede que outros processos tenham bloqueios compartilhados ou exclusivos.
**Mecanismo de atualização de grupo**: ao executar um COMMIT ou ROLLBACK, se um processo de backend não conseguir recuperar um ProcArrayLock no modo exclusivo, ele atualizará um campo especial chamado ProcArrayGroupMember. Isso adiciona a transação à lista de sessões que pretendem terminar. Esse processo de backend então é suspenso, e o tempo de suspensão é instrumentado como o evento de espera ProcArrayGroupUpdate. O primeiro processo no ProcArray com o procArrayGroupMember, conhecido como processo líder, adquire o ProcArrayLock no modo exclusivo. Depois, ele limpa a lista de processos que aguardam a limpeza do transactionID do grupo. Quando isso é concluído, o líder libera o ProcArrayLock e, depois, ativa todos os processos dessa lista, notificando-os de que a transação foi concluída.
## Possíveis causas do maior número de esperas
Quanto mais processos estiverem em execução, mais tempo um líder manterá um procArrayLock no modo exclusivo. Consequentemente, quanto mais transações de gravação ocorrerem, maior a chance de entrarem em um cenário de atualização em grupo, causando um possível acúmulo de processos aguardando o evento de espera `ProcArrayGroupUpdate`. Na visualização Top SQL do Database Insights, você verá que COMMIT é a declaração com a maior parte desse evento de espera. Isso é esperado, mas exigirá uma investigação mais profunda do SQL de gravação específico que está sendo executado para determinar qual ação apropriada realizar.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera. Identifique eventos `IPC:ProcArrayGroupUpdate` utilizando o Insights de Performance do Amazon RDS ou consultando a visualização `pg_stat_activity` do sistema PostgreSQL.
**Topics**
+ [Monitorar operações de confirmação e reversão de transações](#apg-rpg-ipcprocarraygroup.actions.monitor)
+ [Reduzir a simultaneidade](#apg-rpg-ipcprocarraygroup.actions.concurrency)
+ [Implementar o agrupamento de conexões](#apg-rpg-ipcprocarraygroup.actions.pooling)
### Monitorar operações de confirmação e reversão de transações
**Monitorar confirmações e reversões**: um número maior de confirmações e reversões pode aumentar a pressão sobre o ProcArray. Por exemplo, se uma instrução SQL começar a falhar devido ao aumento das violações de chaves duplicadas, você poderá observar um aumento nas reversões, o que pode aumentar a contenção do ProcArray e o inchaço da tabela.
O Amazon RDS Database Insights fornece as métricas `xact_commit` e `xact_rollback` do PostgreSQL e relata o número de confirmações e reversões por segundo.
### Reduzir a simultaneidade
**Transações em lote**: sempre que possível, agrupe operações em transações únicas para reduzir as operações de confirmação/reversão.
**Limitar a simultaneidade**: reduza o número de transações ativas simultaneamente para aliviar a contenção de bloqueios no ProcArray. Embora isso exija alguns testes, reduzir o número total de conexões simultâneas pode reduzir a contenção e manter o throughput.
### Implementar o agrupamento de conexões
**Soluções de agrupamento de conexões**: use o grupo de conexões para gerenciar conexões de banco de dados com eficiência, reduzindo o número total de backends e, portanto, a workload no ProcArray. Embora isso exija alguns testes, reduzir o número total de conexões simultâneas pode reduzir a contenção e manter o throughput.
Para acessar mais informações, consulte [Connection pooling for Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.connection_pooling.html).
**Reduzir os surtos de conexão**: da mesma forma, um padrão de criação e encerramento frequentes de conexões causa pressão adicional no ProcArray. Ao reduzir esse padrão, a contenção geral é reduzida.
# Lock:advisory
O evento `Lock:advisory` ocorre quando uma aplicação PostgreSQL utiliza um bloqueio para coordenar as atividades em várias sessões.
**Topics**
+ [Versões de mecanismos relevantes](#apg-waits.lockadvisory.context.supported)
+ [Contexto](#apg-waits.lockadvisory.context)
+ [Causas](#apg-waits.lockadvisory.causes)
+ [Ações](#apg-waits.lockadvisory.actions)
## Versões de mecanismos relevantes
As informações sobre eventos de espera são relevantes para o Aurora PostgreSQL versão 9.6 e versões superiores.
## Contexto
Bloqueios consultivos do PostgreSQL são bloqueios cooperativos em nível de aplicação, feitos explicitamente e desfeitos pelo código da aplicação do usuário. Uma aplicação pode utilizar bloqueios consultivos do PostgreSQL para coordenar atividades em várias sessões. Ao contrário de bloqueios regulares, ou em nível de objeto ou linha, a aplicação tem controle total ao longo da vida útil do bloqueio. Para obter mais informações, consulte o tópico sobre [Bloqueios consultivos](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) na documentação do PostgreSQL.
Bloqueios consultivos podem ser liberados antes que uma transação termine ou podem ser mantidos por uma sessão em todas as transações. Isso não é válido para bloqueios implícitos aplicados pelo sistema, como um bloqueio exclusivo de acesso em uma tabela adquirida por uma instrução `CREATE INDEX`.
Para obter uma descrição das funções utilizadas para adquirir (bloquear) e liberar (desbloquear) bloqueios consultivos, consulte o tópico sobre [Funções de bloqueios consultivos](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS), na documentação do PostgreSQL.
Bloqueios consultivos são implementados sobre o sistema de bloqueio regular do PostgreSQL e ficam visíveis na visualização do sistema `pg_locks`.
## Causas
Esse tipo de bloqueio é controlado exclusivamente por uma aplicação que o utiliza explicitamente. Bloqueios consultivos que são adquiridos para cada linha como parte de uma consulta podem causar um aumento nos bloqueios ou um acúmulo a longo prazo.
Esses efeitos acontecem quando a consulta é executada de uma maneira que adquire bloqueios em mais linhas do que as retornadas pela consulta. A aplicação deve eventualmente liberar todos os bloqueios, mas, se eles forem adquiridos em linhas que não são retornadas, a aplicação não poderá localizar todos os bloqueios.
O exemplo a seguir foi extraído do tópico [Bloqueios consultivos](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) na documentação do PostgreSQL.
```
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100;
```
Nesse exemplo, a cláusula `LIMIT` apenas pode interromper a saída da consulta depois que as linhas já foram selecionadas internamente e seus valores de ID estão bloqueados. Isso pode acontecer repentinamente quando um volume de dados crescente faz com que o planejador escolha um plano de execução diferente que não foi testado durante o desenvolvimento. O acúmulo nesse caso acontece porque a aplicação chama explicitamente `pg_advisory_unlock` para cada valor de ID bloqueado. No entanto, nesse caso, não é possível encontrar o conjunto de bloqueios adquiridos em linhas que não foram retornadas. Como os bloqueios são adquiridos em nível de sessão, eles não são liberados automaticamente no final da transação.
Outra possível causa para picos em tentativas de bloqueio bloqueadas são conflitos não intencionais. Nesses conflitos, partes não relacionadas da aplicação compartilham o mesmo espaço de ID de bloqueio por engano.
## Ações
Revise o uso da aplicação de bloqueios consultivos e detalhe onde e quando no fluxo de aplicação cada tipo de bloqueio consultivo é adquirido e liberado.
Determine se uma sessão está adquirindo muitos bloqueios ou se uma sessão de longa execução não está liberando bloqueios cedo o suficiente, resultando em um acúmulo lento de bloqueios. Você pode corrigir um acúmulo lento de bloqueios em nível de sessão encerrando a sessão com `pg_terminate_backend(pid)`.
Um cliente que aguarda um bloqueio de consultoria aparece em `pg_stat_activity` com `wait_event_type=Lock` e `wait_event=advisory`. É possível obter valores de bloqueio específicos consultando a visualização do sistema `pg_locks` em busca do mesmo `pid`, procurando `locktype=advisory` e `granted=f`.
Em seguida, identifique a sessão de bloqueio consultando `pg_locks` em busca do mesmo bloqueio consultivo que possui `granted=t`, conforme mostrado no exemplo a seguir.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
Todas as funções de API de bloqueio consultivo têm dois conjuntos de argumentos, um argumento `bigint` ou dois argumentos `integer`:
+ Para as funções de API com um único argumento `bigint`, os 32 bits superiores estão em `pg_locks.classid` e os 32 bits inferiores estão em `pg_locks.objid`.
+ Para as funções da API com dois argumentos `integer`, o primeiro argumento é `pg_locks.classid` e o segundo é `pg_locks.objid`.
O valor `pg_locks.objsubid` indica qual formato de API foi utilizado: `1` significa um argumento `bigint`; `2`significa dois argumentos `integer`.
# Lock:extend
O evento `Lock:extend` ocorre quando um processo de backend está aguardando para bloquear uma relação com o objetivo de a estender, enquanto outro processo tem um bloqueio nessa relação para o mesmo objetivo.
**Topics**
+ [Versões compatíveis do mecanismo](#apg-waits.lockextend.context.supported)
+ [Contexto](#apg-waits.lockextend.context)
+ [Possíveis causas do maior número de esperas](#apg-waits.lockextend.causes)
+ [Ações](#apg-waits.lockextend.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
O evento `Lock:extend` indica que um processo de backend está aguardando para estender uma relação na qual outro processo de backend mantém um bloqueio enquanto estende essa relação. Como apenas um processo por vez pode estender uma relação, o sistema gera um evento de espera `Lock:extend`. Operações `INSERT`, `COPY` e `UPDATE` podem gerar esse evento.
## Possíveis causas do maior número de esperas
Quando o evento `Lock:extend` aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:
**Surto de inserções simultâneas ou atualizações na mesma tabela **
Pode haver um aumento no número de sessões simultâneas com consultas que inserem ou atualizam a mesma tabela.
**Largura de banda da rede insuficiente**
É possível que a largura de banda da rede na instância de banco de dados para as necessidades de comunicação de armazenamento da workload atual. Isso pode contribuir para a latência de armazenamento que causa um aumento em eventos `Lock:extend`.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [Reduzir inserções e atualizações simultâneas para a mesma relação](#apg-waits.lockextend.actions.action1)
+ [Aumentar a largura de banda da rede](#apg-waits.lockextend.actions.increase-network-bandwidth)
### Reduzir inserções e atualizações simultâneas para a mesma relação
Primeiro, determine se há um aumento nas métricas `tup_inserted` e `tup_updated` e um aumento acompanhante nesse evento de espera. Em caso afirmativo, verifique quais relações estão em alta disputa por operações de inserção e atualização. Para determinar isso, consulte a visualização `pg_stat_all_tables` para os valores nos campos `n_tup_ins` e `n_tup_upd`. Para obter mais informações sobre a visualização `pg_stat_all_tables`, consulte [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) na documentação do PostgreSQL.
Para obter mais informações sobre bloqueio e consultas bloqueadas, consulte `pg_stat_activity` como no exemplo a seguir:
```
SELECT
blocked.pid,
blocked.usename,
blocked.query,
blocking.pid AS blocking_id,
blocking.query AS blocking_query,
blocking.wait_event AS blocking_wait_event,
blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type
------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
```
Depois de identificar relações que contribuem para o aumento dos eventos `Lock:extend`, utilize as seguintes técnicas para reduzir a contenção:
+ Descubra se é possível utilizar o particionamento para reduzir a contenção para a mesma tabela. Separar tuplas inseridas ou atualizadas em partições diferentes pode reduzir a contenção. Para obter informações sobre particionamento, consulte [Gerenciar partições do PostgreSQL com a extensão pg\$1partman](PostgreSQL_Partitions.md).
+ Se o evento de espera for principalmente devido a atividades de atualização, reduza o valor do fator de preenchimento da relação. Isso pode reduzir as solicitações de novos bloqueios durante a atualização. O fator de preenchimento é um parâmetro de armazenamento de uma tabela que determina o espaço máximo para empacotar uma página de tabela. Ele é expresso como uma porcentagem do espaço total de uma página. Para obter mais informações sobre o parâmetro de fator de preenchimento, consulte [CREATE TABLE](https://www.postgresql.org/docs/13/sql-createtable.html) na documentação do PostgreSQL.
**Importante**
É altamente recomendável testar seu sistema se você alterar o fator de preenchimento, pois isso pode afetar negativamente a performance dependendo da workload.
### Aumentar a largura de banda da rede
Para ver se há um aumento na latência de gravação, verifique a métrica `WriteLatency` no CloudWatch. Se houver, use as métricas `WriteThroughput` e `ReadThroughput` do Amazon CloudWatch para monitorar o tráfego relacionado ao armazenamento no cluster de banco de dados. Essas métricas podem ajudar a determinar se a largura de banda da rede é suficiente para a atividade de armazenamento da sua workload.
Se a largura de banda da rede não suficiente, aumente-a. Se a sua instância de banco de dados estiver atingindo os limites de largura de banda da rede, a única maneira de aumentar a largura de banda será ampliar o tamanho da instância de banco de dados.
Para obter mais informações sobre métricas do CloudWatch, consulte [Métricas do Amazon CloudWatch para o Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). Para obter informações sobre a performance de rede de cada classe de instância de banco de dados, consulte [Especificações de hardware para classes de instância de banco de dadospara o Aurora](Concepts.DBInstanceClass.Summary.md).
# Lock:Relation
O evento `Lock:Relation` ocorre quando uma consulta está aguardando para adquirir um bloqueio em uma tabela ou visualização (relação) que está atualmente bloqueada por outra transação.
**Topics**
+ [Versões compatíveis do mecanismo](#apg-waits.lockrelation.context.supported)
+ [Contexto](#apg-waits.lockrelation.context)
+ [Possíveis causas do maior número de esperas](#apg-waits.lockrelation.causes)
+ [Ações](#apg-waits.lockrelation.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
A maioria dos comandos PostgreSQL utiliza bloqueios implicitamente para controlar o acesso simultâneo aos dados em tabelas. Também é possível utilizar esses bloqueios explicitamente no código da aplicação com o comando `LOCK`. Vários modos de bloqueio não são compatíveis entre si e podem bloquear transações quando tentam acessar o mesmo objeto. Quando isso acontece, o Aurora PostgreSQL gera um evento `Lock:Relation`. Veja a seguir alguns exemplos comuns:
+ Bloqueios exclusivos, como `ACCESS EXCLUSIVE`, podem bloquear todo o acesso simultâneo. Operações de linguagem de definição de dados (DDL), como `DROP TABLE`, `TRUNCATE`, `VACUUM FULL` e `CLUSTER`, adquirem bloqueios `ACCESS EXCLUSIVE` implicitamente. `ACCESS EXCLUSIVE` também é o modo de bloqueio padrão para instruções `LOCK TABLE` que não especificam um modo explicitamente.
+ Usar `CREATE INDEX (without CONCURRENT)` em uma tabela gera conflito com instruções de linguagem de manipulação de dados (DML) `UPDATE`, `DELETE` e `INSERT`, que adquirem bloqueios `ROW EXCLUSIVE`.
Para obter mais informações sobre bloqueios em nível da tabela e modos de bloqueio conflitantes, consulte o tópico sobre [Bloqueio explícito](https://www.postgresql.org/docs/13/explicit-locking.html) na documentação do PostgreSQL.
Normalmente, o bloqueio de consultas e transações é liberado de uma das seguintes maneiras:
+ Consulta de bloqueio: a aplicação pode cancelar a consulta ou o usuário pode encerrar o processo. O mecanismo também pode forçar a finalização da consulta devido a um tempo limite de declaração de uma sessão ou um mecanismo de detecção de deadlock.
+ Transação de bloqueio: uma transação para de bloquear quando executa uma instrução `ROLLBACK` ou `COMMIT`. Reversões também acontecem automaticamente quando as sessões são desconectadas por um cliente ou por problemas de rede, ou quando são encerradas. As sessões podem ser encerradas quando o mecanismo de banco de dados é desligado, quando o sistema está sem memória e assim por diante.
## Possíveis causas do maior número de esperas
Quando o evento `Lock:Relation` ocorre com maior frequência do que o normal, pode indicar um problema de performance. As causas típicas incluem:
**Maior número de sessões simultâneas com bloqueios de tabela conflitantes**
Pode haver um aumento no número de sessões simultâneas com consultas que bloqueiam a mesma tabela com modos de bloqueio conflitantes.
**Operações de manutenção**
Operações de manutenção de integridade, como `VACUUM` e `ANALYZE`, podem aumentar significativamente o número de bloqueios conflitantes. `VACUUM FULL` adquire um bloqueio `ACCESS EXCLUSIVE` e `ANALYZE` adquire um bloqueio `SHARE UPDATE EXCLUSIVE`. Ambos os tipos de bloqueios podem causar um evento de espera `Lock:Relation`. Operações de manutenção de dados de aplicações, como atualizar uma visualização materializada, também podem aumentar as consultas e transações bloqueadas.
**Bloqueios em instâncias de leitor**
Pode haver um conflito entre os bloqueios de relação mantidos pelo gravador e os leitores. No momento, só bloqueios de relação do `ACCESS EXCLUSIVE` são replicados para instâncias do leitor. No entanto, o bloqueio de relação do `ACCESS EXCLUSIVE` entrará em conflito com qualquer bloqueio de relação do `ACCESS SHARE` mantido pelo leitor. Isso pode causar um aumento nos eventos de espera de relação de bloqueio no leitor.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [Reduzir o impacto do bloqueio de instruções SQL](#apg-waits.lockrelation.actions.reduce-blocks)
+ [Minimizar o efeito de operações de manutenção](#apg-waits.lockrelation.actions.maintenance)
+ [Verificar se há bloqueios de leitor](#apg-waits.lockrelation.actions.readerlocks)
### Reduzir o impacto do bloqueio de instruções SQL
Para reduzir o impacto do bloqueio de instruções SQL, modifique o código da aplicação sempre que possível. Veja a seguir duas técnicas comuns para reduzir bloqueios:
+ Usar a opção `NOWAIT`: alguns comandos SQL, como instruções `SELECT` e `LOCK`, oferecem suporte a essa opção. A diretiva `NOWAIT` cancela a consulta de solicitação de bloqueio quando o bloqueio não pode ser adquirido imediatamente. Essa técnica pode evitar que uma sessão de bloqueio cause um empilhamento de sessões bloqueadas por detrás dela.
Por exemplo: suponha que a transação A esteja aguardando um bloqueio mantido pela transação B. Se B solicitar um bloqueio em uma tabela bloqueada pela transação C, a transação A poderá ser bloqueada até a conclusão da transação C. Porém, se a transação B utilizar um `NOWAIT` quando solicitar o bloqueio em C, ela pode falhar rapidamente e garantir que a transação A não precise aguardar indefinidamente.
+ Usar `SET lock_timeout`: defina um valor de `lock_timeout` para limitar o tempo de espera de uma instrução SQL para adquirir um bloqueio em uma relação. Se o bloqueio não for obtido dentro do tempo limite definido, a transação que o está solicitando será cancelada. Defina o valor no nível da sessão.
### Minimizar o efeito de operações de manutenção
Operações de manutenção, como `VACUUM` e `ANALYZE`, são importantes. Recomendamos que você não as desative ao encontrar eventos de espera `Lock:Relation` relacionados a essas operações de manutenção. As abordagens a seguir podem minimizar o efeito dessas operações:
+ Execute operações de manutenção manualmente fora do horário de pico.
+ Para reduzir esperas `Lock:Relation` causadas por tarefas de autovacuum, realize qualquer ajuste de autovacuum necessário. Para obter mais informações sobre ajuste de autovacuum, consulte [Trabalhar com o autovacuum do PostgreSQL no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html), no *Guia do usuário do Amazon RDS*.
### Verificar se há bloqueios de leitor
É possível ver como as sessões simultâneas em um gravador e leitores podem estar mantendo bloqueios que são aplicáveis uns aos outros. Uma maneira de fazer isso é executando consultas que retornem o tipo de bloqueio e a relação. Na tabela, você pode encontrar uma sequência de consultas para duas dessas sessões simultâneas, uma de gravador e uma de leitor.
O processo de repetição aguarda a duração de `max_standby_streaming_delay` antes de cancelar a consulta do leitor. Como mostrado no exemplo, o tempo limite de bloqueio de 100 ms está bem abaixo do `max_standby_streaming_delay` padrão de 30 segundos. O bloqueio esgota-se antes que seja um problema.
| Evento de sequência | Sessão | Comando ou saída |
| --- | --- | --- |
| Define uma variável de ambiente chamada READER com o valor especificado e tenta se conectar à instância de banco de dados com esse endpoint. | Sessão de leitor | Comando da CLI: export READER=aurorapg2.12345678910.us-west-1.rds.amazonaws.com
psql -h $READER
Resultado:
```
psql (15devel, server 10.14)
Type "help" for help.
``` |
| Define uma variável de ambiente chamada WRITER e tenta se conectar à instância de banco de dados com esse endpoint. | Sessão de gravador | Comando da CLI: export WRITER=aurorapg1.12345678910.us-west-1.rds.amazonaws.com
psql -h $WRITER
Resultado:
```
psql (15devel, server 10.14)
Type "help" for help.
``` |
| A sessão do gravador cria a tabela t1 na instância de gravador. | Sessão de gravador | Consulta do PostgreSQL: postgres=> CREATE TABLE t1(b integer);
CREATE TABLE
|
| Se não houver consultas conflitantes no gravador, o bloqueio ACCESS EXCLUSIVE é obtido no gravador imediatamente. | Sessão de gravador | Bloqueio `ACCESS EXCLUSIVE` habilitado |
| A sessão do leitor especifica um intervalo de tempo limite de bloqueio igual a 100 milissegundos. | Sessão de leitor | Consulta do PostgreSQL: postgres=> SET lock_timeout=100;
SET
|
| A sessão do leitor tenta ler dados da tabela t1 na instância de leitor. | Sessão de leitor | Consulta do PostgreSQL: postgres=> SELECT * FROM t1;
Exemplo de resultado:
```
b
---
(0 rows)
``` |
| A sessão do gravador descarta t1. | Sessão de gravador | Consulta do PostgreSQL: postgres=> BEGIN;
BEGIN
postgres=> DROP TABLE t1;
DROP TABLE
postgres=>
|
| A consulta atinge o tempo limite e é cancelada no leitor. | Sessão de leitor | Consulta do PostgreSQL: postgres=> SELECT * FROM t1;
Exemplo de resultado:
```
ERROR: canceling statement due to lock timeout
LINE 1: SELECT * FROM t1;
^
``` |
| Para determinar a causa do erro, a sessão do leitor consulta `pg_locks` e `pg_stat_activity` | Sessão de leitor | Consulta do PostgreSQL: postgres=> SELECT locktype, relation, mode, backend_type
postgres=> FROM pg_locks l, pg_stat_activity t1
postgres=> WHERE l.pid=t1.pid AND relation = 't1'::regclass::oid;
|
| O resultado indica que o processo `aurora wal replay` está mantendo um bloqueio `ACCESS EXCLUSIVE` na tabela t1. | Sessão de leitor | Resultado da consulta: locktype | relation | mode | backend_type
----------+----------+---------------------+-------------------
relation | 68628525 | AccessExclusiveLock | aurora wal replay
(1 row)
|
# Lock:transactionid
O evento `Lock:transactionid` ocorre quando uma transação está aguardando um bloqueio em nível de linha.
**Topics**
+ [Versões compatíveis do mecanismo](#apg-waits.locktransactionid.context.supported)
+ [Contexto](#apg-waits.locktransactionid.context)
+ [Possíveis causas do maior número de esperas](#apg-waits.locktransactionid.causes)
+ [Ações](#apg-waits.locktransactionid.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
O evento `Lock:transactionid` ocorre quando uma transação está tentando adquirir um bloqueio em nível de linha já concedido a uma transação que está sendo executada simultaneamente. A sessão que mostra o evento de espera `Lock:transactionid` está bloqueada devido a esse bloqueio. Depois que a transação de bloqueio terminar em uma instrução `COMMIT` ou `ROLLBACK`, a transação bloqueada pode continuar.
A semântica de controle de simultaneidade de várias versões do Aurora PostgreSQL garante que os leitores não bloqueiem gravadores e que os gravadores não bloqueiem os leitores. Para que ocorram conflitos em nível de linha, transações de bloqueio e bloqueadas devem emitir instruções conflitantes dos seguintes tipos:
+ `UPDATE`
+ `SELECT … FOR UPDATE`
+ `SELECT … FOR KEY SHARE`
A instrução `SELECT … FOR KEY SHARE` é um caso especial. O banco de dados usa a cláusula `FOR KEY SHARE` para otimizar a performance da integridade referencial. Um bloqueio em nível de linha em uma linha pode bloquear comandos `INSERT`, `UPDATE` e `DELETE` em outras tabelas que fazem referência à linha.
## Possíveis causas do maior número de esperas
Quando esse evento aparece mais do que o normal, a causa geralmente envolve instruções `UPDATE`, `SELECT … FOR UPDATE` ou `SELECT … FOR KEY SHARE` combinadas com as seguintes condições.
**Topics**
+ [Alta simultaneidade](#apg-waits.locktransactionid.concurrency)
+ [Ocioso na transação](#apg-waits.locktransactionid.idle)
+ [Transações de longa execução](#apg-waits.locktransactionid.long-running)
### Alta simultaneidade
O Aurora PostgreSQL pode utilizar semântica de bloqueio granular em nível de linha. A probabilidade de conflitos em nível de linha aumenta quando as condições a seguir são atendidas:
+ Uma workload altamente simultânea controla as mesmas linhas.
+ A simultaneidade aumenta.
### Ocioso na transação
Às vezes, a coluna `pg_stat_activity.state` mostra o valor `idle in transaction`. Esse valor aparece para sessões que iniciaram uma transação, mas ainda não emitiram um `COMMIT` ou `ROLLBACK`. Se o valor de `pg_stat_activity.state` não for `active`, a consulta mostrada em `pg_stat_activity` será a mais recente a terminar a execução. A sessão de bloqueio não está processando uma consulta ativamente porque uma transação aberta está mantendo um bloqueio.
Se uma transação ociosa adquiriu um bloqueio em nível de linha, talvez ela esteja impedindo que outras sessões o adquiram. Essa condição leva à ocorrência frequente do evento de espera `Lock:transactionid`. Para diagnosticar o problema, examine a saída proveniente de `pg_stat_activity` e `pg_locks`.
### Transações de longa execução
Transações executadas por um longo tempo recebem bloqueios por um longo tempo. Esses bloqueios de longa duração podem impedir que outras transações sejam executadas.
## Ações
O bloqueio de linhas é um conflito entre instruções `UPDATE`, `SELECT … FOR UPDATE` ou `SELECT … FOR KEY SHARE`. Antes de tentar uma solução, descubra quando essas instruções estão sendo executadas na mesma linha. Use essas informações para escolher uma estratégia descrita nas seguintes seções.
**Topics**
+ [Responder a alta simultaneidade](#apg-waits.locktransactionid.actions.problem)
+ [Responder a transações ociosas](#apg-waits.locktransactionid.actions.find-blocker)
+ [Responder a transações de longa duração](#apg-waits.locktransactionid.actions.concurrency)
### Responder a alta simultaneidade
Se a simultaneidade for o problema, tente uma das seguintes técnicas:
+ Reduza a simultaneidade na aplicação. Por exemplo, reduza o número de sessões ativas.
+ Implemente um pool de conexões. Para saber como agrupar conexões com o RDS Proxy, consulte [Amazon RDS Proxypara Aurora](rds-proxy.md).
+ Projete a aplicação ou o modelo de dados para evitar a contenção de instruções `UPDATE` e `SELECT … FOR UPDATE`. Também é possível diminuir o número de chaves estrangeiras acessadas por instruções `SELECT … FOR KEY SHARE`.
### Responder a transações ociosas
Se `pg_stat_activity.state` mostrar `idle in transaction`, utilize as seguintes estratégias:
+ Ative a confirmação automática sempre que possível. Essa abordagem impede que transações bloqueiem outras transações enquanto aguardam `COMMIT` ou `ROLLBACK`.
+ Procure caminhos de código que não contenham `COMMIT`, `ROLLBACK` ou `END`.
+ Assegure-se de que a lógica de tratamento de exceções na seu aplicação sempre tenha um caminho para um válido `end of transaction`.
+ Assegure-se de que a sua aplicação processe os resultados da consulta depois de encerrar a transação com `COMMIT` ou `ROLLBACK`.
### Responder a transações de longa duração
Se transações de longa duração estiverem causando a ocorrência frequente de `Lock:transactionid`, tente as estratégias a seguir:
+ Mantenha os bloqueios de linha fora de transações de longa execução.
+ Limite o comprimento das consultas implementando a confirmação automática sempre que possível.
# Lock:tuple
O evento `Lock:tuple` ocorre quando um processo de backend está aguardando para adquirir um bloqueio em uma tupla.
**Topics**
+ [Versões compatíveis do mecanismo](#apg-waits.locktuple.context.supported)
+ [Contexto](#apg-waits.locktuple.context)
+ [Possíveis causas do maior número de esperas](#apg-waits.locktuple.causes)
+ [Ações](#apg-waits.locktuple.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
O evento `Lock:tuple` indica que um backend está aguardando para adquirir um bloqueio em uma tupla enquanto outro backend mantém um bloqueio conflitante na mesma tupla. A tabela a seguir ilustra um cenário em que as sessões geram o evento `Lock:tuple`.
| Tempo | Sessão 1 | Sessão 2 | Sessão 3 |
| --- | --- | --- | --- |
| t1 | Inicia uma transação. | | |
| t2 | Atualiza a linha 1. | | |
| t3 | | Atualiza a linha 1. A sessão adquire um bloqueio exclusivo na tupla e aguarda a sessão 1 liberar esse bloqueio via confirmação ou reversão. | |
| t4 | | | Atualiza a linha 1. A sessão aguarda a sessão 2 liberar o bloqueio exclusivo na tupla. |
Outra alternativa é simular esse evento de espera utilizando a ferramenta de benchmarking `pgbench`. Configure um número elevado de sessões simultâneas para atualizar a mesma linha em uma tabela com um arquivo SQL personalizado.
Para saber mais sobre modos de bloqueio conflitantes, consulte o tópico sobre [Bloqueio explícito](https://www.postgresql.org/docs/current/explicit-locking.html), na documentação do PostgreSQL. Para saber mais sobre `pgbench`, consulte [pgbench](https://www.postgresql.org/docs/current/pgbench.html) na documentação do PostgreSQL.
## Possíveis causas do maior número de esperas
Quando esse evento aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:
+ Um número elevado de sessões simultâneas está tentando adquirir um bloqueio conflitante para a mesma tupla executando instruções `UPDATE` ou `DELETE`.
+ Sessões altamente simultâneas estão executando uma instrução `SELECT` utilizando os modos de bloqueio `FOR UPDATE` ou `FOR NO KEY UPDATE`.
+ Diversos fatores fazem com que grupos de aplicações ou conexões abram mais sessões para executar as mesmas operações. À medida que novas sessões estão tentando modificar as mesmas linhas, a carga de banco de dados pode atingir picos e `Lock:tuple` pode surgir.
Para obter mais informações, consulte o tópico sobre [Bloqueios em nível de linha](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS), na documentação do PostgreSQL.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [Investigar a lógica da sua aplicação](#apg-waits.locktuple.actions.problem)
+ [Localizar a sessão bloqueadora](#apg-waits.locktuple.actions.find-blocker)
+ [Reduzir a simultaneidade quando ela estiver elevada](#apg-waits.locktuple.actions.concurrency)
+ [Solucionar problemas de gargalos](#apg-waits.locktuple.actions.bottlenecks)
### Investigar a lógica da sua aplicação
Descubra se uma sessão bloqueadora está no estado `idle in transaction` por muito tempo. Em caso positivo, considere encerrar a sessão bloqueadora como uma solução de curto prazo. Também é possível utilizar a função `pg_terminate_backend`. Para obter mais informações sobre essa função, consulte [Funções de sinalização de servidor](https://www.postgresql.org/docs/13/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL), na documentação do PostgreSQL.
Para uma solução de longo prazo, faça o seguinte:
+ Ajuste a lógica da aplicação.
+ Use o parâmetro `idle_in_transaction_session_timeout`. Esse parâmetro encerra qualquer sessão com uma transação aberta que tenha ficado ociosa por um tempo maior que o especificado. Para obter mais informações, consulte o tópico sobre [Padrões de conexão de clientes](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT), na documentação do PostgreSQL.
+ Use a confirmação automática o máximo possível. Para obter mais informações, consulte [SET AUTOCOMMIT](https://www.postgresql.org/docs/current/ecpg-sql-set-autocommit.html), na documentação do PostgreSQL.
### Localizar a sessão bloqueadora
Enquanto o evento de espera `Lock:tuple` está ocorrendo, identifique a sessão bloqueadora e a sessão bloqueada descobrindo quais bloqueios dependem um do outro. Para obter mais informações, consulte o tópico sobre [Informações de dependências de bloqueios](https://wiki.postgresql.org/wiki/Lock_dependency_information), na wiki do PostgreSQL. Para analisar eventos `Lock:tuple` passados, utilize a função do Aurora `aurora_stat_backend_waits`.
O exemplo a seguir consulta todas as sessões, filtrando em `tuple` e ordenando por `wait_time`.
```
--AURORA_STAT_BACKEND_WAITS
SELECT a.pid,
a.usename,
a.app_name,
a.current_query,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
left(query,80) as current_query,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND usename<>'rdsadmin') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we
WHERE we.event_name = 'tuple'
ORDER BY a.wait_time;
pid | usename | app_name | current_query | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time
-------+---------+----------+------------------------------------------------+-------------------+--------------------+---------------+-----------+------------+-------+-----------
32136 | sys | psql | /*session3*/ update tab set col=1 where col=1; | Lock | tuple | active | Lock | tuple | 1 | 1000018
11999 | sys | psql | /*session4*/ update tab set col=1 where col=1; | Lock | tuple | active | Lock | tuple | 1 | 1000024
```
### Reduzir a simultaneidade quando ela estiver elevada
O evento `Lock:tuple` pode ocorrer constantemente, especialmente em um tempo de workload ocupado. Nessa situação, considere reduzir a simultaneidade elevada para linhas muito ocupadas. Várias vezes, apenas algumas linhas controlam uma fila ou a lógica booleana, o que torna essas linhas muito ocupadas.
Você pode reduzir a simultaneidade utilizando diferentes abordagens com base no seu requisito de negócios, na lógica da aplicação e no tipo de workload. Por exemplo, você pode fazer o seguinte:
+ Reformule sua tabela e a lógica de dados para reduzir a simultaneidade elevada.
+ Altere a lógica da aplicação para reduzir a simultaneidade elevada no nível da linha.
+ Aproveite e reformule consultas com bloqueios em nível de linha.
+ Use a cláusula `NOWAIT` com operações de novas tentativas.
+ Considere utilizar o controle de simultaneidade lógico otimista e bloqueio híbrido.
+ Considere modificar o nível de isolamento do banco de dados.
### Solucionar problemas de gargalos
O `Lock:tuple` pode ocorrer com gargalos, como falta de CPU ou uso máximo da largura de banda do Amazon EBS. Para diminuir gargalos, considere as seguintes abordagens:
+ Aumente a escala do seu tipo de classe de instância na vertical.
+ Otimize consultas que consomem muitos recursos.
+ Altere a lógica da aplicação.
+ Arquive dados acessados raramente.
# 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).
# LWLock:buffer\$1mapping
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.
**Topics**
+ [Versões compatíveis do mecanismo](#apg-waits.lwl-buffer-mapping.context.supported)
+ [Contexto](#apg-waits.lwl-buffer-mapping.context)
+ [Causas](#apg-waits.lwl-buffer-mapping.causes)
+ [Ações](#apg-waits.lwl-buffer-mapping.actions)
## 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 obter mais informações, consulte [Buffers compartilhados](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.buffer-pool).
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.
**Topics**
+ [Monitorar métricas relacionadas ao buffer](#apg-waits.lwl-buffer-mapping.actions.monitor-metrics)
+ [Avaliar sua estratégia de indexação](#apg-waits.lwl-buffer-mapping.actions.indexes)
+ [Diminuir o número de buffers que devem ser alocados rapidamente](#apg-waits.lwl-buffer-mapping.actions.buffers)
### 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.
# 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.
**Topics**
+ [Versões de mecanismos relevantes](#apg-waits.lwlockbufferio.context.supported)
+ [Contexto](#apg-waits.lwlockbufferio.context)
+ [Causas](#apg-waits.lwlockbufferio.causes)
+ [Ações](#apg-waits.lwlockbufferio.actions)
## 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\$1io, 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](apg-waits.iodatafileread.md). 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](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).
## 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.
+ 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.
# LWLock:lock\$1manager
Esse evento ocorre quando o mecanismo Aurora PostgreSQL mantém a área de memória do bloqueio compartilhado para alocar, verificar e desalocar um bloqueio nos casos em que um bloqueio de caminho rápido não é possível.
**Topics**
+ [Versões compatíveis do mecanismo](#apg-waits.lw-lock-manager.context.supported)
+ [Contexto](#apg-waits.lw-lock-manager.context)
+ [Possíveis causas do maior número de esperas](#apg-waits.lw-lock-manager.causes)
+ [Ações](#apg-waits.lw-lock-manager.actions)
## 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
Quando você emite uma instrução SQL, o Aurora PostgreSQL registra bloqueios para proteger a estrutura, os dados e a integridade do banco de dados durante operações simultâneas. O mecanismo pode atingir esse objetivo utilizando um bloqueio de caminho rápido ou um bloqueio de caminho que não é rápido. Um bloqueio de caminho que não é rápido é mais caro e gera mais sobrecarga do que um bloqueio de caminho rápido.
### Bloqueio de caminho rápido
Para reduzir a sobrecarga de bloqueios que são retirados e liberados com frequência, mas que raramente entram em conflito, os processos de backend podem utilizar o bloqueio de caminho rápido. O banco de dados usa esse mecanismo para bloqueios que atendem aos seguintes critérios:
+ Usam o método de bloqueio DEFAULT.
+ Representam um bloqueio em uma relação de banco de dados em vez de uma relação compartilhada.
+ São bloqueios fracos que provavelmente não entrarão em conflito.
+ O mecanismo é capaz de verificar rapidamente se nenhum bloqueio conflitante pode existir.
O mecanismo não pode utilizar o bloqueio rápido de caminho quando uma das seguintes condições é verdadeira:
+ O bloqueio não atende aos critérios anteriores.
+ Não há mais slots disponíveis para o processo de backend.
Para obter mais informações sobre o bloqueio de caminho rápido, consulte o tópico sobre [caminho rápido](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76), no README do gerenciador de bloqueios do PostgreSQL e[pg-locks](https://www.postgresql.org/docs/15/view-pg-locks.html) na documentação do PostgreSQL.
### Exemplo de um problema de escalabilidade para o gerenciador de bloqueios
Neste exemplo, uma tabela chamada `purchases` armazena cinco anos de dados, particionados por dia. Cada partição possui dois índices. A seguinte sequência de eventos ocorre:
1. Você consulta muitos dias de dados, o que exige que o banco de dados leia várias partições.
1. O banco de dados cria uma entrada de bloqueio para cada partição. Se os índices de partição fizerem parte do caminho de acesso do otimizador, o banco de dados também criará uma entrada de bloqueio para eles.
1. Quando o número de entradas de bloqueios solicitadas para o mesmo processo de backend for maior que 16, que é o valor de `FP_LOCK_SLOTS_PER_BACKEND`, o gerenciador de bloqueio usará o método de bloqueio de caminho não rápido.
Aplicações modernas podem ter centenas de sessões. Se sessões simultâneas estiverem consultando o pai sem a devida limpeza da partição, o banco de dados poderá criar centenas ou até milhares de bloqueios de caminho não rápidos. Em geral, quando essa simultaneidade é maior que o número de vCPUs, o evento de espera `LWLock:lock_manager` é exibido.
**nota**
O evento de espera `LWLock:lock_manager` não está relacionado ao número de partições ou índices em um esquema de banco de dados e sim ao número de bloqueios de caminho não rápidos que o banco de dados deve controlar.
## Possíveis causas do maior número de esperas
Quando o evento de espera `LWLock:lock_manager` ocorre mais do que o normal, possivelmente indicando um problema de performance, as causas mais prováveis de picos súbitos são:
+ Sessões ativas simultâneas estão executando consultas que não utilizam bloqueios de caminho rápido. Essas sessões também excedem a vCPU máxima.
+ Um número elevado de sessões ativas simultâneas está acessando uma tabela fortemente particionada. Cada partição possui vários índices.
+ O banco de dados está passando por uma tempestade de conexões. Por padrão, algumas aplicações e softwares de grupo de conexões criam mais conexões quando o banco de dados está lento. Essa prática piora o problema. Ajuste o software do grupo de conexões para que tempestades de conexões não ocorram.
+ Um número elevado de sessões consulta uma tabela pai sem separar partições.
+ Um comando de linguagem de definição de dados (DDL), linguagem de manipulação de dados (DML) ou manutenção bloqueia exclusivamente uma relação ocupada ou tuplas que são frequentemente acessadas ou modificadas.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [Usar a limpeza de partição](#apg-waits.lw-lock-manager.actions.pruning)
+ [Remover índices desnecessários](#apg-waits.lw-lock-manager.actions.indexes)
+ [Ajustar suas consultas para bloqueio de caminho rápido](#apg-waits.lw-lock-manager.actions.tuning)
+ [Fazer ajustes com base em eventos de espera](#apg-waits.lw-lock-manager.actions.other-waits)
+ [Reduzir gargalos de hardware](#apg-waits.lw-lock-manager.actions.hw-bottlenecks)
+ [Usar um agrupador de conexões](#apg-waits.lw-lock-manager.actions.pooler)
+ [Fazer upgrade da versão do Aurora PostgreSQL](#apg-waits.lw-lock-manager.actions.pg-version)
### Usar a limpeza de partição
*Limpeza de partição* é uma estratégia de otimização de consultas que exclui partições desnecessárias das varreduras de tabelas, melhorando assim a performance. Por padrão, a remoção de partição está ativada. Se ela estiver desativada, ative-a da seguinte maneira.
```
SET enable_partition_pruning = on;
```
As consultas podem tirar proveito da limpeza de partição quando suas cláusula `WHERE` contêm a coluna utilizada para o particionamento. Para obter mais informações, consulte o tópico sobre [Limpeza de partição](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING), na documentação do PostgreSQL.
### Remover índices desnecessários
Seu banco de dados pode conter índices não utilizados ou raramente utilizados. Se esse for o caso, considere excluí-los. Realize um dos procedimentos a seguir:
+ Saiba mais sobre como encontrar índices desnecessários lendo o tópico sobre [Índices não utilizados](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes) na wiki do PostgreSQL.
+ Execute o PG Collector. Esse script SQL reúne informações do banco de dados e as apresenta em um relatório HTML consolidado. Confira a seção “Índices não utilizados”. Para obter mais informações, consulte [pg-collector](https://github.com/awslabs/pg-collector) no Repositório AWS Labs GitHub.
### Ajustar suas consultas para bloqueio de caminho rápido
Para descobrir se as suas consultas usam o bloqueio de caminho rápido, consulte a coluna `fastpath` na tabela `pg_locks`. Se as suas consultas não estiverem utilizando o bloqueio de caminho rápido, tente reduzir o número de relações por consulta para menos de 16.
### Fazer ajustes com base em eventos de espera
Se `LWLock:lock_manager` for o primeiro ou o segundo na lista de principais esperas, verifique se os seguintes eventos de espera também aparecem na lista:
+ `Lock:Relation`
+ `Lock:transactionid`
+ `Lock:tuple`
Se os eventos anteriores aparecerem em posição elevada na lista, considere ajustar esses eventos de espera primeiro. Esses eventos podem ser um fator impulsionador para `LWLock:lock_manager`.
### Reduzir gargalos de hardware
É possível que haja um gargalo de hardware, como falta de CPU ou uso máximo da largura de banda do Amazon EBS. Nesses casos, considere reduzir gargalos de hardware. Considere as ações a seguir:
+ Aumente a escala da sua classe de instância na vertical.
+ Otimize consultas que consomem grandes quantidades de CPU e memória.
+ Altere a lógica da aplicação.
+ Arquive os dados.
Para obter mais informações sobre CPU, memória e largura de banda da rede do EBS, consulte [Tipos de instâncias do Amazon RDS](https://aws.amazon.com/rds/instance-types/).
### Usar um agrupador de conexões
Se o número total de conexões ativas exceder o máximo de vCPU, mais processos do SO exigirão CPU do que o tipo de instância pode suportar. Nesse caso, considere utilizar ou ajustar um grupo de conexões. Para obter mais informações sobre as vCPUs para o seu tipo de instância, consulte o tópico sobre [Tipos de instância do Amazon RDS](https://aws.amazon.com/rds/instance-types/).
Para obter mais informações sobre agrupamento de conexões, consulte os seguintes recursos:
+ [Amazon RDS Proxypara Aurora](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ [Grupos conexões e fontes de dados](https://www.postgresql.org/docs/7.4/jdbc-datasource.html), na *Documentação do PostgreSQL*
### Fazer upgrade da versão do Aurora PostgreSQL
Se a versão atual do Aurora PostgreSQL for menor que 12, atualize para a versão 12 ou superior. As versões 12 e 13 do PostgreSQL possuem um mecanismo de partição aprimorado. Para obter mais informações sobre a versão 12, consulte [Notas de release do PostgreSQL 12.0]( https://www.postgresql.org/docs/release/12.0/). Para obter mais informações sobre como fazer upgrade do Aurora PostgreSQL, consulte [Atualizações do mecanismo de banco de dados do Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md).
# LWLock:MultiXact
Os eventos de espera `LWLock:MultiXactMemberBuffer`, `LWLock:MultiXactOffsetBuffer`, `LWLock:MultiXactMemberSLRU` e `LWLock:MultiXactOffsetSLRU` indicam que uma sessão está aguardando para recuperar uma lista de transações que modificam a mesma linha em uma tabela específica.
+ `LWLock:MultiXactMemberBuffer`: um processo está aguardando a E/S em um buffer utilizado com menos frequência (SLRU) para um membro multixact.
+ `LWLock:MultiXactMemberSLRU`: um processo está aguardando para acessar o cache utilizado com menos frequência (SLRU) para um membro multixact.
+ `LWLock:MultiXactOffsetBuffer`: um processo está aguardando a E/S em um buffer utilizado com menos frequência (SLRU) para um desvio multixact.
+ `LWLock:MultiXactOffsetSLRU`: um processo está aguardando para acessar o cache utilizado com menos frequência (SLRU) para um desvio multixact.
**Topics**
+ [Versões compatíveis do mecanismo](#apg-waits.xactsync.context.supported)
+ [Contexto](#apg-waits.lwlockmultixact.context)
+ [Possíveis causas do maior número de esperas](#apg-waits.lwlockmultixact.causes)
+ [Ações](#apg-waits.lwlockmultixact.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
*Multixact* é uma estrutura de dados que armazena uma lista de IDs de transação (XIDs) que modificam a mesma linha da tabela. Quando uma única transação faz referência a uma linha em uma tabela, o ID da transação é armazenado na linha de cabeçalho da tabela. Quando várias transações fazem referência à mesma linha em uma tabela, a lista de IDs de transação é armazenada na estrutura de dados multixact. Os eventos de espera multixact indicam que uma sessão está recuperando da estrutura de dados a lista de transações que se referem a uma determinada linha em uma tabela.
## Possíveis causas do maior número de esperas
Estas são três causas comuns para uso do multixact:
+ **Subtransações de pontos de salvamento explícitos**: a criação explícita de um ponto de salvamento nas transações gera novas transações para a mesma linha. Por exemplo, usando `SELECT FOR UPDATE`, `SAVEPOINT` e, então `UPDATE`.
Alguns drivers, mapeamentos de objetos relacionais (ORMs) e camadas de abstração têm opções de configuração para envolver automaticamente todas as operações com pontos de salvamento. Isso pode gerar muitos eventos de espera multiexact em algumas workloads. A opção `autosave` do driver JDBC do PostgreSQL é um exemplo disso. Para obter mais informações, consulte [pgJDBC](https://jdbc.postgresql.org/) na documentação do JDBC do PostgreSQL. Outro exemplo é o driver ODBC do PostgreSQL e sua opção `protocol`. Para obter mais informações, consulte [psqlODBC Configuration Options](https://odbc.postgresql.org/docs/config.html) (Opções de configuração do psqlODBC) na documentação do driver ODBC do PostgreSQL.
+ **Subtransações de cláusulas EXCEPTION de PL/pgSQL**: cada cláusula `EXCEPTION` que você escreve em funções ou procedimentos de PL/pgSQL cria um `SAVEPOINT` interno.
+ **Chaves externas**: várias transações adquirem um bloqueio compartilhado no registro pai.
Quando uma determinada linha é incluída em uma operação de várias transações, o processamento da linha exige a recuperação de IDs de transação das listas `multixact`. Se as pesquisas não conseguirem obter o multixact do cache de memória, a estrutura de dados deverá ser lida da camada de armazenamento do Aurora. Essa E/S do armazenamento significa que as consultas de SQL podem demorar mais. As falhas no cache de memória podem começar a ocorrer com o uso intenso devido a um grande número de transações múltiplas. Todos esses fatores contribuem para o aumento desse evento de espera.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera. Algumas dessas ações podem ajudar na redução imediata dos eventos de espera. Porém, outras podem precisar de investigação e correção para escalar a workload.
**Topics**
+ [Realizar a operação vacuum freeze nas tabelas com este evento de espera](#apg-waits.lwlockmultixact.actions.vacuumfreeze)
+ [Aumentar a frequência da limpeza automática das tabelas com esse evento de espera](#apg-waits.lwlockmultixact.actions.autovacuum)
+ [Aumentar os parâmetros de memória](#apg-waits.lwlockmultixact.actions.memoryparam)
+ [Reduzir transações de longa execução](#apg-waits.lwlockmultixact.actions.longtransactions)
+ [Ações de longo prazo](#apg-waits.lwlockmultixact.actions.longactions)
### Realizar a operação vacuum freeze nas tabelas com este evento de espera
Se esse evento de espera aumentar repentinamente e afetar o ambiente de produção, você poderá usar qualquer um dos métodos temporários a seguir para reduzir a contagem.
+ Use *VACUUM FREEZE* na tabela ou na partição da tabela afetada para resolver o problema imediatamente. Para ter mais informações, consulte [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html).
+ Use a cláusula VACUUM (FREEZE, INDEX\$1CLEANUP FALSE) para realizar uma limpeza rápida ignorando os índices. Para ter mais informações, consulte [Aspirar uma tabela o mais rápido possível](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing).
### Aumentar a frequência da limpeza automática das tabelas com esse evento de espera
Depois de verificar todas as tabelas em todos os bancos de dados, a operação VACUUM removerá multixacts, e os valores multixact mais antigos avançarão. Para ter mais informações, consulte [Multixacts e Wraparound](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-MULTIXACT-WRAPAROUND). Para reduzir ao mínimo os eventos de espera LWLock:MultiXact, é necessário executar a operação VACUUM sempre que necessário. Para fazer isso, garanta que o VACUUM no cluster de banco de dados do Aurora PostgreSQL esteja configurado de forma ideal.
Se o uso de VACUUM FREEZE na tabela ou na partição da tabela afetada resolver o problema do evento de espera, recomendamos usar um programador, como o `pg_cron`, para realizar o VACUUM em vez de ajustar o autovacuum na instância.
Para que o autovacuum ocorra com maior frequência, é possível reduzir o valor do parâmetro de armazenamento `autovacuum_multixact_freeze_max_age` na tabela afetada. Para ter mais informações, consulte [autovacuum\$1multixact\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MULTIXACT-FREEZE-MAX-AGE).
### Aumentar os parâmetros de memória
Você pode otimizar o uso da memória para caches multixact ajustando os seguintes parâmetros. Essas configurações controlam a quantidade de memória reservada para esses caches, o que pode ajudar a reduzir os eventos de espera multixact na workload. Recomendamos começar com os valores a seguir:
Para o Aurora PostgreSQL 17 e posterior:
+ `multixact_offset_buffers` = 128
+ `multixact_member_buffers` = 256
Para o Aurora PostgreSQL 16 e posterior:
+ `multixact_offsets_cache_size` = 128
+ `multixact_members_cache_size` = 256
**nota**
No Aurora PostgreSQL 17, os nomes dos parâmetros foram alterados de `multixact_offsets_cache_size` para `multixact_offset_buffers` e de `multixact_members_cache_size` para `multixact_member_buffers` para se alinharem à comunidade do PostgreSQL 17.
É possível definir esses parâmetros no nível do cluster para que todas as instâncias do cluster permaneçam consistentes. Recomendamos que você teste e ajuste os valores para melhor atender aos requisitos específicos da workload e à classe de instância. É necessário reinicializar a instância do gravador para que a alteração do parâmetro tenha efeito.
Os parâmetros são expressos em termos de entradas de cache multixact. Cada entrada de cache usa `8 KB` de memória. Para calcular a memória total reservada, multiplique o valor de cada parâmetro por `8 KB`. Por exemplo, se você definir um parâmetro como 128, o total de memória reservada será `128 * 8 KB = 1 MB`.
### Reduzir transações de longa execução
Transações de longa duração fazem com que o vácuo retenha as informações até que a transação seja confirmada ou até que a transação somente leitura seja fechada. Recomendamos que você monitore e gerencie transações de longa duração de maneira proativa. Para obter mais informações, consulte [O banco de dados está inativo há muito tempo na conexão da transação](PostgreSQL.Tuning_proactive_insights.md#proactive-insights.idle-txn). Tente modificar a aplicação para evitar ou minimizar o uso de transações de longa duração.
### Ações de longo prazo
Examine a workload para descobrir a causa do transbordamento de multixact. É necessário corrigir o problema para escalar a workload e reduzir o evento de espera.
+ É necessário analisar a DDL (linguagem de definição de dados) usada para criar tabelas. Verifique se as estruturas e os índices das tabelas estão bem projetados.
+ Quando as tabelas afetadas tiverem chaves externas, determine se elas são necessárias ou se há outra forma de aplicar a integridade referencial.
+ Quando uma tabela tem grandes índices não utilizados, isso pode fazer com que o autovacuum não se ajuste à workload e pode impedir a execução. Para evitar isso, verifique se há índices não utilizados e remova-os completamente. Para ter mais informações, consulte [Gerenciar o autovacuum com grandes índices](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html).
+ Reduza o uso de pontos de salvamento nas transações.
# LWLock:pg\$1stat\$1statements
O evento de espera LWLock:pg\$1stat\$1statements ocorre quando a extensão `pg_stat_statements` obtém um bloqueio exclusivo na tabela de hash que rastreia instruções SQL. Isso acontece nos seguintes cenários:
+ Quando o número de instruções rastreadas atinge o valor configurado do parâmetro `pg_stat_statements.max` e é necessário abrir espaço para mais entradas, a extensão executa uma classificação no número de chamadas, remove 5% das instruções menos executadas e preenche novamente o hash com as entradas restantes.
+ Quando `pg_stat_statements` executa uma operação `garbage collection` no arquivo `pgss_query_texts.stat` no disco e reescreve o arquivo.
**Topics**
+ [Versões compatíveis do mecanismo](#apg-rpg-lwlockpgstat.supported)
+ [Contexto](#apg-rpg-lwlockpgstat.context)
+ [Possíveis causas do maior número de esperas](#apg-rpg-lwlockpgstat.causes)
+ [Ações](#apg-rpg-lwlockpgstat.actions)
## Versões compatíveis do mecanismo
As informações sobre esse evento de espera são aceitas em todas as versões do Aurora PostgreSQL.
## Contexto
**Conceitos básicos sobre a extensão pg\$1stat\$1statements**: essa extensão rastreia as estatísticas de execução de instruções SQL em uma tabela de hash. Ela rastreia as instruções SQL até o limite definido pelo parâmetro `pg_stat_statements.max`. Esse parâmetro determina o número máximo de instruções que podem ser rastreadas, o qual corresponde ao número máximo de linhas na visualização pg\$1stat\$1statements.
**Persistência das estatísticas de instrução**: a extensão mantém as estatísticas da instrução em todas as reinicializações da instância:
+ Gravando dados em um arquivo chamado pg\$1stat\$1statements.stat.
+ Usando o parâmetro pg\$1stat\$1statements.save para controlar o comportamento de persistência.
Quando pg\$1stat\$1statements.save é definido como:
+ ativado (padrão): as estatísticas são salvas no desligamento e recarregadas na inicialização do servidor.
+ desativado: as estatísticas não são salvas no desligamento nem recarregadas na inicialização do servidor.
**Armazenamento de texto de consulta**: a extensão armazena o texto das consultas rastreadas em um arquivo chamado `pgss_query_texts.stat`. Esse arquivo pode aumentar até o dobro do tamanho médio de todas as instruções SQL rastreadas antes que a coleta de resíduos ocorra. A extensão requer um bloqueio exclusivo na tabela de hash durante as operações de limpeza e regravação do arquivo `pgss_query_texts.stat`.
**Processo de desalocação de instruções**: quando o número de instruções rastreadas atinge o limite `pg_stat_statements.max` e novas instruções precisam ser rastreadas, a extensão:
+ Obtém um bloqueio exclusivo (LWLock:pg\$1stat\$1statements) na tabela de hash.
+ Carrega os dados existentes na memória local.
+ Executa uma classificação rápida com base no número de chamadas.
+ Remove as instruções menos chamadas (5% inferiores).
+ Preenche novamente a tabela de hash com as entradas restantes.
**Monitoramento da desalocação de instruções**: no PostgreSQL 14 e versões posteriores, você pode monitorar a desalocação de instruções usando a visualização pg\$1stat\$1statements\$1info. Essa visualização inclui uma coluna de desalocação que mostra quantas vezes as instruções foram desalocadas para abrir espaço para novas.
Se a desalocação de instruções ocorrer com frequência, haverá uma coleta de resíduos mais frequente do arquivo `pgss_query_texts.stat` no disco.
## Possíveis causas do maior número de esperas
As causas típicas do aumento de esperas `LWLock:pg_stat_statements` incluem:
+ Um aumento no número de consultas exclusivas usadas pela aplicação.
+ O valor do parâmetro `pg_stat_statements.max` é pequeno em comparação ao número de consultas exclusivas que estão sendo usadas.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera. Você pode identificar eventos `LWLock:pg_stat_statements` utilizando o Insights de Performance do Amazon RDS ou consultando a visualização `pg_stat_activity`.
Ajuste os parâmetros `pg_stat_statements` a seguir para controlar o comportamento de rastreamento e reduzir os eventos de espera das instruções LWLock:pg\$1stat\$1.
**Topics**
+ [Desabilitar o parâmetro pg\$1stat\$1statements.track](#apg-rpg-lwlockpgstat.actions.disabletrack)
+ [Aumentar o parâmetro pg\$1stat\$1statements.max](#apg-rpg-lwlockpgstat.actions.increasemax)
+ [Desabilitar o parâmetro pg\$1stat\$1statements.track\$1utility](#apg-rpg-lwlockpgstat.actions.disableutility)
### Desabilitar o parâmetro pg\$1stat\$1statements.track
Se o evento de espera LWLock:pg\$1stat\$1statements estiver afetando negativamente o desempenho do banco de dados e for necessária uma solução rápida antes de uma análise mais aprofundada da visualização `pg_stat_statements` para identificar a causa-raiz, o parâmetro `pg_stat_statements.track` poderá ser desabilitado configurando-o como `none`. Isso desabilitará a coleta de estatísticas de instrução.
### Aumentar o parâmetro pg\$1stat\$1statements.max
Para reduzir a desalocação e minimizar a coleta de resíduos do arquivo `pgss_query_texts.stat` no disco, aumente o valor do parâmetro `pg_stat_statements.max`. O valor padrão é `5,000`.
**nota**
O parâmetro `pg_stat_statements.max` é estático. É necessário reinicializar a instância de banco de dados para aplicar qualquer alteração nesse parâmetro.
### Desabilitar o parâmetro pg\$1stat\$1statements.track\$1utility
Você pode analisar a visualização pg\$1stat\$1statements para determinar quais comandos do utilitário estão consumindo mais recursos rastreados por `pg_stat_statements`.
O parâmetro `pg_stat_statements.track_utility` controla se o módulo rastreia os comandos do utilitário, que incluem todos os comandos, exceto SELECT, INSERT, UPDATE, DELETE e MERGE. Esse parâmetro é definido como por padrão `on`.
Por exemplo, quando sua aplicação usa muitas consultas de ponto de salvamento, que são inerentemente exclusivas, ela pode aumentar a desalocação de instruções. Para resolver isso, você pode desabilitar o parâmetro `pg_stat_statements.track_utility` para impedir que `pg_stat_statements` rastreie consultas de pontos de salvamento.
**nota**
O parâmetro `pg_stat_statements.track_utility` é dinâmico. Você pode alterar o respectivo valor sem reiniciar a instância de banco de dados.
**Example Exemplo de consultas exclusivas de ponto de salvamento em pg\$1stat\$1statements**
```
query | queryid
-------------------------------------------------+---------------------
SAVEPOINT JDBC_SAVEPOINT_495701 | -7249565344517699703
SAVEPOINT JDBC_SAVEPOINT_1320 | -1572997038849006629
SAVEPOINT JDBC_SAVEPOINT_26739 | 54791337410474486
SAVEPOINT JDBC_SAVEPOINT_1294466 | 8170064357463507593
ROLLBACK TO SAVEPOINT JDBC_SAVEPOINT_65016 | -33608214779996400
SAVEPOINT JDBC_SAVEPOINT_14185 | -2175035613806809562
SAVEPOINT JDBC_SAVEPOINT_45837 | -6201592986750645383
SAVEPOINT JDBC_SAVEPOINT_1324 | 6388797791882029332
```
O PostgreSQL 17 inclui vários aprimoramentos para o rastreamento de comandos de utilitário:
+ Os nomes de ponto de salvamento agora são exibidos como constantes.
+ Os IDs de transação global (GIDs) dos comandos de confirmação em duas fases agora são exibidos como constantes.
+ Os nomes das instruções DEALLOCATE são mostrados como constantes.
+ Os parâmetros CALL agora são exibidos como constantes.
# Tempo limite:PgSleep
O evento `Timeout:PgSleep` ocorre quando um processo do servidor chama a função `pg_sleep` e está aguardando o tempo limite de suspensão expirar.
**Topics**
+ [Versões compatíveis do mecanismo](#apg-waits.timeoutpgsleep.context.supported)
+ [Possíveis causas do maior número de esperas](#apg-waits.timeoutpgsleep.causes)
+ [Ações](#apg-waits.timeoutpgsleep.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.
## Possíveis causas do maior número de esperas
Esse evento de espera ocorre quando uma aplicação, uma função armazenada ou um usuário emite uma instrução SQL que chama uma das seguintes funções:
+ `pg_sleep`
+ `pg_sleep_for`
+ `pg_sleep_until`
As funções anteriores atrasarão a execução até que o número especificado de segundos tenha decorrido. Por exemplo, `SELECT pg_sleep(1)` pausa por 1 segundo. Para obter mais informações, consulte [Atrasar a execução](https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-DELAY) na documentação do PostgreSQL.
## Ações
Identifique a instrução que estava executando a função `pg_sleep`. Determine se o uso da função é apropriado.