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 descreve como identificar a causa raiz da alta utilização da CPU. Ele também fornece 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ê pode 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 métricas do Azure, armazenamento de consultas 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 EXPLAIN ANALYZE, pool de conexões e tabelas de vácuo.
Usando os guias de solução de problemas, você pode identificar a causa raiz provável de um cenário de alta CPU e ler as recomendações para mitigar o problema encontrado.
Para saber como configurar e usar os guias de solução de problemas, siga os guias de solução de problemas de configuração.
Considere o uso da seguinte lista de ferramentas para identificar a alta utilização da CPU.
O Azure Metrics é um bom ponto de partida para verificar a utilização da CPU por um período específico. As métricas fornecem informações sobre os recursos utilizados durante o período em que a utilização da CPU é alta. Compare os gráficos de IOPs de gravação, IOPs de leitura, Bytes de taxa de transferência de leitura/s e Bytes de taxa de transferência de gravação/s com a porcentagem de 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.
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 temporais. Os dados de todos os usuários, bancos de dados e consultas são armazenados em um banco de dados nomeado azure_sys no Banco de Dados do Azure para instância de servidor flexível do PostgreSQL.
O repositório de consultas pode correlacionar informações de eventos de espera com estatísticas de tempo de execução de consulta. Use o repositório de consultas para identificar consultas que tenham alto consumo de CPU durante o período de interesse.
Para obter mais informações, consulte repositório de consultas.
A pg_stat_statements extensão ajuda a identificar consultas que consomem tempo no servidor. Para obter mais informações sobre essa extensão, consulte sua documentaçã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;
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;
Se os níveis de consumo de CPU são altos em geral, os seguintes podem ser possíveis causas raiz:
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;
Um grande número de conexões com o banco de dados também 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 state
ORDER BY state ASC;
Use EXPLAIN ANALYZE, considere usar o pool de conexões PgBouncer integrado e encerre transações de longa execução para resolver a alta utilização da CPU.
Depois de conhecer as consultas que estão consumindo mais CPU, use EXPLICAR ANALISAR para investigá-las e ajustá-las ainda mais.
Para obter mais informações sobre o comando EXPLAIN ANALYZE , consulte sua documentação.
Em situações em que há muitas conexões de curta duração, ou muitas conexões que permanecem ociosas durante a maior parte de sua vida, considere usar um pool de conexões como o PgBouncer.
Para obter mais informações sobre PgBouncer, consulte Pool de conexões e práticas recomendadas de manipulação de conexões com o PostgreSQL
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.
Você pode considerar matar uma transação de longa duração como uma opção.
Para encerrar o PID de uma sessão, você precisa encontrar seu 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 encerrá-lo usando a seguinte consulta:
SELECT pg_terminate_backend(pid);
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>;
- Solucione problemas de alta utilização de memória no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.
- Solucione problemas de alta utilização de IOPS no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.
- Solucione problemas e identifique consultas de execução lenta no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.
- Parâmetros de servidor no Banco de Dados do Azure para PostgreSQL - Servidor flexível.
- Ajuste de vácuo automático no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.