# Solução inicial de problemas de desempenho comuns do PostgreSQL no RDS para PostgreSQL
Este guia aborda os quatro problemas de desempenho mais comuns que afetam os bancos de dados RDS para PostgreSQL: sobrecarga de tabelas e índices, esgotamento de recursos de consultas paralelas, alta pressão de conexão e autenticação e ajuste de autovacuum. Antes de iniciar uma investigação mais aprofundada, use este guia como uma lista de verificação de diagnóstico inicial quando houver degradação de desempenho.
Cada seção descreve os sintomas que você pode observar, oferece consultas de diagnóstico para confirmar a causa raiz e recomenda etapas específicas de correção.
**Noções básicas sobre regressões de desempenho do tipo “nada mudou”**
As workloads do PostgreSQL geralmente são executadas sem problemas por semanas ou meses e, em seguida, sofrem uma degradação repentina de desempenho, mesmo que o código da aplicação e os padrões de consulta pareçam inalterados. Isso ocorre porque o ambiente do banco de dados nunca é verdadeiramente estático. Vários fatores invisíveis mudam com o tempo e podem desencadear mudanças de plano ou contenção de recursos:
**A sobrecarga excessiva é uma mudança na workload.** O controle de simultaneidade de várias versões (MVCC) do PostgreSQL retém versões de linha antigas até que o autovacuum as recupere. Quando as tuplas mortas se acumulam mais depressa do que o autovacuum consegue processá-las, as tabelas e os índices ficam fisicamente maiores. O planejador de consultas pode então mudar de verificações de índice eficientes para verificações sequenciais porque as estimativas de custo mudam à medida que o tamanho da tabela aumenta. Seu SQL não mudou, mas os dados que o planejador vê mudaram.
**Novos valores de parâmetro são uma mudança na workload.** Uma consulta parametrizada com bom desempenho para um intervalo de valores pode ter um desempenho ruim quando a aplicação começa a usar um intervalo diferente. O PostgreSQL pode reutilizar um plano de execução genérico que não leve em conta a distorção de dados no novo intervalo ou as estatísticas do planejador podem não refletir com precisão a distribuição desses valores. Quando também há sobrecarga, o impacto aumenta. Um plano abaixo do ideal agora verifica uma quantidade significativamente maior de dados obsoletos.
**As estatísticas podem ficar obsoletas mesmo quando o autovacuum é executado.** O autovacuum aciona `ANALYZE` com base no número de linhas inseridas ou atualizadas, não na possibilidade de a distribuição de dados ter sido alterada significativamente. Se sua aplicação passar a consultar um intervalo de valores ou janela de tempo diferente, as estimativas de custo do planejador provavelmente serão imprecisas, mesmo que o autovacuum tenha sido executado recentemente.
**O crescimento geral do banco de dados é uma mudança na workload.** À medida que as tabelas crescem ao longo do tempo, o volume de páginas de dados que as consultas devem verificar aumenta. As consultas com bom desempenho em tabelas menores podem gerar latência à medida que o tamanho da tabela aumenta, mesmo quando a lógica e os índices de consulta permanecem inalterados. Monitore `FreeStorageSpace` para acompanhar as tendências de crescimento do armazenamento.
Ao investigar regressões de desempenho em que “nada mudou”, considere a sobrecarga excessiva, os novos intervalos de valores de parâmetro, o crescimento geral do banco de dados e as estatísticas obsoletas como as causas mais prováveis. Use as etapas de diagnóstico deste guia para confirmar qual fator se aplica.
Para saber mais, consulte:
[Atividades de manutenção de bancos de dados do PostgreSQL no Amazon RDS e no Amazon Aurora](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/introduction.html) (Recomendações da AWS)
[Otimizar o desempenho de consultas do PostgreSQL](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-query-tuning/introduction.html) (Recomendações da AWS)
[Ajustar parâmetros do PostgreSQL no Amazon RDS e no Amazon Aurora](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-postgresql-parameters/introduction.html)
[Métricas em nível de instância do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html#rds-cw-metrics-instance) (monitorar `FreeStorageSpace` em busca de tendências de crescimento do armazenamento)
## Lista de verificação de diagnóstico rápido
Use as seguintes etapas de triagem ordenada ao investigar pela primeira vez um problema de desempenho:
1. **Verificar `pg_stat_activity`.** Examine a contagem de conexões, as sessões ociosas na transação e as consultas de longa duração. Para ter mais informações, consulte [Conceitos essenciais para o ajuste do RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Tuning.concepts.html).
1. **Verifique se há sobrecarga.** Em `pg_stat_user_tables`, procure valores de `n_dead_tup` altos e considere a possibilidade de usar `pgstattuple` para uma medição precisa. Para ter mais informações, consulte [Reduzir o inchaço em tabelas e índices com a extensão pg\_repack](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pg_repack.html).
1. **Verificar `pg_stat_user_tables`.** Procure valores de `n_dead_tup` altos e carimbos de data/hora de `last_autovacuum` obsoletos. Para ter mais informações, consulte [Trabalhar com o autovacuum do PostgreSQL no Amazon RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
1. **Análise `EXPLAIN ANALYZE` sobre consultas lentas.** Procure planos paralelos e verificações sequenciais em tabelas grandes. Para ter mais informações, consulte [Práticas recomendadas para consultas paralelas no RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ParallelQueries.html).
1. **Métricas do Amazon CloudWatch para o Insights de Performance.** Analise fatores como utilização da CPU, número de conexões, IOPS e memória liberável. Para ter mais informações, consulte [Monitoramento do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MonitoringOverview.html). Quanto a eventos de espera comuns e ações corretivas, consulte [Eventos de espera do RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Tuning.concepts.summary.html).
1. **Analise seu grupo de parâmetros de banco de dados.** Verifique as configurações de `max_parallel_workers_per_gather` e de autovacuum. Para ter mais informações, consulte [Ajustar parâmetros do PostgreSQL no Amazon RDS e no Amazon Aurora](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-postgresql-parameters/introduction.html).
## Sobrecarga de tabelas e índices
A sobrecarga de tabelas e índices ocorre quando tuplas mortas se acumulam nas tabelas mais depressa do que o autovacuum consegue recuperá-las. Com o tempo, isso degrada gradualmente o desempenho das consultas, aumenta o uso do armazenamento e gera planos de consulta abaixo do ideal.
### Sintomas
+ O desempenho das consultas degrada gradualmente ao longo de semanas ou meses.
+ O uso do armazenamento aumenta ainda que o volume de dados seja estável.
+ O planejador de consultas escolhe verificações sequenciais em vez de verificações de índice devido a estatísticas obsoletas.
+ O valor de `dead_tuple_count` é alto nas estatísticas de tabela.
### Diagnóstico
É possível estimar a sobrecarga em todas as tabelas consultando o catálogo do sistema. Esta abordagem não requer nenhuma extensão:
```
SELECT schemaname, relname,
n_dead_tup,
n_live_tup,
ROUND(n_dead_tup::numeric / GREATEST(n_live_tup, 1) * 100, 2) AS dead_pct,
last_autovacuum,
last_autoanalyze
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000
ORDER BY n_dead_tup DESC
LIMIT 20;
```
Para lidar com a sobrecarga, você pode usar a extensão `pg_repack` para reorganizar tabelas e índices com o mínimo de bloqueio. Para ter mais informações, consulte [Reduzir o inchaço em tabelas e índices com a extensão pg\_repack](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pg_repack.html) e [Remove bloat from Amazon Aurora and RDS for PostgreSQL with pg\_repack](https://aws.amazon.com/blogs/database/remove-bloat-from-amazon-aurora-and-rds-for-postgresql-with-pg_repack/).
**Importante**
Em vez de depender de manutenção manual, verifique se o autovacuum está habilitado e ajustado adequadamente para a workload. Consulte [Ajuste do autovacuum](#PostgreSQL.InitialTroubleshooting.Autovacuum) para ver recomendações de ajuste.
## Esgotamento dos recursos de consulta paralela
O PostgreSQL pode executar consultas paralelamente para melhorar o desempenho de grandes verificações sequenciais e agregações. No entanto, cada operador paralelo é um processo de backend completo é contabilizado em relação a `max_worker_processes` (e ao sublimite `max_parallel_workers`) e aloca seu próprio `work_mem`. Uma única consulta com quatro operadores paralelos pode consumir centenas de megabytes de memória e uma quantidade significativa de CPU. Em condições de alta simultaneidade, o paralelismo excessivo pode esgotar a CPU e a memória rapidamente.
Os sintomas comuns incluem picos repentinos de CPU, alto uso de memória por consulta e aumento de `DatabaseConnections` no CloudWatch sem alterações na aplicação. Você também pode observar eventos de espera, como `IPC:BgWorkerStartup`, `IPC:ExecuteGather` e `IPC:ParallelFinish`. Para obter mais informações sobre esses eventos de espera [IPC: eventos de espera paralelos](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rpg-ipc-parallel.html).
Para a maioria das workloads de OLTP e de produção de alta simultaneidade, desabilite o paralelismo automático configurando `max_parallel_workers_per_gather = 0` em seu grupo de parâmetros de banco de dados. Em seguida, você pode habilitar seletivamente o paralelismo para sessões específicas de analytics ou geração de relatórios definindo o parâmetro por sessão ou por perfil.
Para ver orientações detalhadas sobre como diagnosticar e controlar o comportamento de consultas paralelas, consulte [Práticas recomendadas para consultas paralelas no RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ParallelQueries.html).
## Alta pressão de conexão e autenticação
A rotatividade de conexão (abertura e fechamento frequentes de conexões de banco de dados sem agrupamento) cria sobrecarga de autenticação e pode esgotar os slots de conexão disponíveis. As conexões ociosas que permanecem abertas também consomem slots sem realizar trabalhos úteis.
### Sintomas
+ Número elevado de `total_auth_attempts` no monitoramento do Insights de Performance. Para ter mais informações, consulte [Contadores não nativos para o RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights_Counters.html#USER_PerfInsights_Counters.PostgreSQL.NonNative).
+ Tempos lentos de estabelecimento de conexão
+ Erros `FATAL: too many connections for role` ou `remaining connection slots are reserved`.
+ Picos de CPU correlacionados com a rotatividade de conexão.
### Diagnóstico
Execute a seguinte consulta para verificar o estado da conexão atual:
```
SELECT
setting::int AS max_connections,
(SELECT count(*) FROM pg_stat_activity) AS current_connections,
(SELECT count(*) FROM pg_stat_activity WHERE state = 'idle') AS idle_connections,
(SELECT count(*) FROM pg_stat_activity WHERE state = 'idle in transaction') AS idle_in_txn
FROM pg_settings
WHERE name = 'max_connections';
```
Um número alto de conexões `idle` ou `idle in transaction` em relação a `max_connections` indica que as conexões não estão sendo liberadas adequadamente. As conexões ociosas na transação são especialmente problemáticas porque bloqueiam e impedem que o autovacuum recupere tuplas mortas.
### Correção
+ **Implante o agrupamento de conexões.** Use o PgBouncer ou o Amazon RDS Proxy para reduzir o número de conexões diretas com o banco de dados. O agrupamento de conexões reutiliza as conexões existentes em vez de criar outras para cada solicitação.
+ **Defina `idle_in_transaction_session_timeout`.** Esse parâmetro encerra automaticamente as sessões que permanecem ociosas em uma transação por um tempo que ultrapassa a duração especificada. Isso evita que transações ociosas de longa duração mantenham bloqueios e bloqueiem o autovacuum.
+ **Analise o tratamento da conexão da aplicação.** Sua aplicação deve fechar as conexões imediatamente e não manter as transações abertas por mais tempo do que o necessário.
**nota**
Os operadores de consulta paralelos consomem CPU e memória. Se você observar esgotamento de recursos acompanhado de atividades de consultas paralelas, consulte [Esgotamento dos recursos de consulta paralela](#PostgreSQL.InitialTroubleshooting.ParallelQuery) para obter orientação sobre como controlar o uso de operadores paralelos.
## Usar eventos de espera do Insights de Performance para solução de problemas
O Insights de Performance captura eventos de espera que mostram onde o banco de dados está gastando tempo. Ao investigar problemas de desempenho, os eventos de espera ajudam a identificar se o gargalo é de CPU, E/S, bloqueio, rede ou comunicação entre processos. As categorias comuns de eventos de espera que aparecem durante os problemas descritos neste guia incluem:
+ **CPU**: a sessão está ativa na CPU ou aguardando a CPU. Eventos de alta espera de CPU geralmente estão correlacionados com paralelismo excessivo ou planos de consulta ineficientes que examinam tabelas sobrecarregadas.
+ **IPC (comunicação entre processos)**: eventos de espera como `IPC:BgWorkerStartup`, `IPC:ExecuteGather` e `IPC:ParallelFinish` indicam sobrecarga de coordenação de consultas paralelas.
+ **E/S**: eventos de espera como `IO:DataFileRead` indicam que as consultas estão lendo dados do armazenamento porque as páginas necessárias não estão na memória compartilhada. Isso é comum quando tabelas sobrecarregadas excedem o cache do buffer.
+ **Bloqueio**: eventos de espera como `Lock:transactionid` e `Lock:tuple` indicam contenção entre as sessões. As conexões ociosas na transação podem conter bloqueios que impedem outras consultas e o autovacuum.
+ **Cliente**: eventos de espera como `Client:ClientRead` indicam que o banco de dados está aguardando o envio de dados pela aplicação. Eventos de alta espera de cliente podem indicar perda de conexão ou latência de rede.
Para ver uma referência completa dos eventos de espera que geralmente indicam problemas de desempenho e as respectivas ações corretivas recomendadas, consulte [Eventos de espera do RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Tuning.concepts.summary.html).
## Ajuste do autovacuum
O autovacuum é o processo em segundo plano que recupera tuplas mortas, evita a sobrecarga de tabelas e índices, atualiza as estatísticas do planejador e impede o encapsulamento de IDs de transação. As configurações padrão de autovacuum são conservadoras e projetadas para bancos de dados pequenos. Workloads de produção com alto volume de gravação quase sempre exigem ajustes.
Quando o autovacuum não consegue acompanhar a workload de gravação, a sobrecarga aumenta, as estatísticas do planejador ficam obsoletas e o risco de encapsulamento de IDs de transação aumenta. Se `age(relfrozenxid)` se aproximar de 2 bilhões, o banco de dados será encerrado para evitar a corrupção de dados.
Para obter orientações detalhadas sobre como ajustar parâmetros de autovacuum, monitorar a atividade de vacuum e configurar substituições por tabela, consulte [Trabalhar com o autovacuum do PostgreSQL no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
## Informações relacionadas
+ [Práticas recomendadas para consultas paralelas no RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ParallelQueries.html)
+ [Tratamento de conexões inativas no PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.html)
+ [Trabalho com o autovacuum do PostgreSQL no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
+ [Tarefas comuns de DBA do RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html)
+ [Trabalho com o autovacuum do PostgreSQL no Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
+ [Conceitos básicos do autovacuum em ambientes do Amazon RDS para PostgreSQL](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/)