Solucionar problemas de alta utilização da CPU no Banco de Dados do Azure para PostgreSQL - Servidor Flexível
APLICA-SE A: 
Banco de Dados do Azure para PostgreSQL - Servidor Flexível
Este artigo mostra como identificar rapidamente a causa raiz da alta utilização da CPU e possíveis ações corretivas para controlar a utilização da CPU ao usar o Banco de Dados do Azure para o servidor flexível PostgreSQL.
Neste artigo, você aprenderá:
- Sobre guias de solução de problemas para identificar e obter recomendações para mitigar as causas raiz.
- Sobre ferramentas para identificar alta utilização da CPU, como Azure Metrics, Query Store e pg_stat_statements.
- Como identificar causas raiz, como consultas de longa duração e conexões totais.
- Como resolver a alta utilização da CPU usando as tabelas Explicar Análise, Pool de Conexões e Aspirar.
Guias de resolução de problemas
Usando os guias de solução de problemas de recursos disponíveis no portal do servidor flexível do Banco de Dados do Azure para PostgreSQL, é possível encontrar a causa raiz provável e as recomendações para mitigar o cenário de alta CPU. Como configurar os guias de solução de problemas para usá-los, siga os guias de solução de problemas de configuração.
Ferramentas para identificar a alta utilização da CPU
Considere essas ferramentas para identificar a alta utilização da CPU.
Azure Metrics
O Azure Metrics é um bom ponto de partida para verificar a utilização da CPU para a data e o período definidos. As métricas fornecem informações sobre a duração do tempo durante o qual a utilização da CPU é alta. Compare os gráficos de IOPs de gravação, IOPs de leitura, taxa de transferência de leitura e taxa de transferência de gravação com a utilização da CPU para descobrir os momentos em que a carga de trabalho causou alta CPU. Para monitoramento proativo, você pode configurar alertas nas métricas. Para obter orientação passo a passo, consulte Métricas do Azure.
Query Store (Arquivo de Consultas)
O Repositório de Consultas captura automaticamente o histórico de consultas e estatísticas de tempo de execução e os retém para sua revisão. Ele fatia os dados por tempo para que você possa ver padrões de uso temporal. Os dados de todos os usuários, bancos de dados e consultas são armazenados em um banco de dados chamado azure_sys na instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. Para obter orientação passo a passo, consulte Repositório de consultas.
pg_stat_statements
A extensão pg_stat_statements ajuda a identificar consultas que consomem tempo no servidor.
Tempo médio ou médio de execução
Para Postgres versões 13 e superiores, use a seguinte instrução para exibir as cinco principais instruções SQL por tempo médio ou médio de execução:
SELECT userid::regrole, dbid, query, mean_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time
DESC LIMIT 5;
Prazo total de execução
Execute as instruções a seguir para exibir as cinco principais instruções SQL por tempo total de execução.
Para Postgres versões 13 e superiores, use a seguinte instrução para exibir as cinco principais instruções SQL por tempo total de execução:
SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY total_exec_time
DESC LIMIT 5;
Identificar as causas profundas
Se os níveis de consumo de CPU são altos em geral, as seguintes podem ser possíveis causas raiz:
Transações de longa duração
Transações de longa duração podem consumir recursos da CPU que podem levar a uma alta utilização da CPU.
A consulta a seguir ajuda a identificar conexões em execução por mais tempo:
SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;
Número total de conexões e número de conexões por estado
Um grande número de conexões com o banco de dados também é outro problema que pode levar ao aumento da utilização da CPU e da memória.
A consulta a seguir fornece informações sobre o número de conexões por estado:
SELECT state, count(*)
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
GROUP BY 1 ORDER BY 1;
Resolva a alta utilização da CPU
Use Explain Analyze, PG Bouncer, pool de conexões e encerre transações de longa execução para resolver a alta utilização da CPU.
Usar Explicar Analisar
Depois de saber a consulta que está sendo executada por um longo tempo, use EXPLAIN para investigar melhor a consulta e ajustá-la.
Para obter mais informações sobre o comando EXPLICAR , consulte Explicar plano.
PGBouncer e pool de conexões
Em situações em que há muitas conexões ociosas ou muitas conexões, que estão consumindo a CPU, considere o uso de um pool de conexões como o PgBouncer.
Para mais detalhes sobre o PgBouncer, consulte:
O servidor flexível do Banco de Dados do Azure para PostgreSQL oferece o PgBouncer como uma solução interna de pool de conexões. Para obter mais informações, consulte PgBouncer
Encerrar transações de longa duração
Você pode considerar matar uma transação de longa duração como uma opção.
Para encerrar o PID de uma sessão, você precisará detetar o PID usando a seguinte consulta:
SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;
Você também pode filtrar por outras propriedades como usename (nome de usuário), datname (nome do banco de dados) etc.
Depois de ter o PID da sessão, você pode encerrar usando a seguinte consulta:
SELECT pg_terminate_backend(pid);
Monitore estatísticas de vácuo e mesa
Manter as estatísticas da tabela atualizadas ajuda a melhorar o desempenho da consulta. Monitore se a autoaspiração regular está sendo realizada.
A consulta a seguir ajuda a identificar as tabelas que precisam ser aspiradas:
select schemaname,relname,n_dead_tup,n_live_tup,last_vacuum,last_analyze,last_autovacuum,last_autoanalyze
from pg_stat_all_tables where n_live_tup > 0;
last_autovacuum e last_autoanalyze as colunas indicam a data e a hora em que a tabela foi autoaspirada ou analisada pela última vez. Se as mesas não estiverem a ser aspiradas regularmente, tome medidas para ajustar o autoaspirador. Para obter mais informações sobre solução de problemas e ajuste de vácuo automático, consulte Solução de problemas de vácuo automático.
Uma solução de curto prazo seria fazer uma análise manual de vácuo das tabelas onde consultas lentas são vistas:
vacuum analyze <table_name>;