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 do uso elevado da CPU. Ele também fornece possíveis ações de correção para controlar o uso da CPU ao usar o Servidor Flexível do Banco de Dados do Azure para PostgreSQL.
Neste artigo, você aprenderá o seguinte:
- Sobre guias de solução de problemas para identificar e obter recomendações para atenuar as causas raiz.
- Sobre ferramentas para identificar uso elevado da CPU, como Métricas do Azure, repositório de consultas e pg_stat_statements.
- Como identificar causas raiz, como consultas de execução prolongada e conexões totais.
- Como resolver o uso elevado da CPU usando EXPLAIN ANALYZE, pool de conexões e tabelas de limpeza.
Guias de solução de problemas
Usando os Guias de solução de problemas, você pode identificar a provável causa raiz de um cenário de uso elevado da 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 configurar guias de solução de problemas.
Ferramentas para identificar a alta utilização da CPU
Considere o uso da lista a seguir de ferramentas para identificar o uso elevado da CPU.
Métricas do Azure
As Métricas do Azure são um bom ponto de partida para verificar o uso da CPU em um período específico. As métricas fornecem informações sobre os recursos utilizados durante o período em que o uso da CPU é alto. Compare os gráficos de IOPs de Gravação, IOPs de Leitura, Taxa de Transferência de Leitura Bytes/s e Taxa de Transferência de Gravação Bytes/s com Porcentagem de CPU para descobrir quando a carga de trabalho causou o uso elevado da CPU.
Para monitoramento proativo, você pode configurar alertas nas métricas. Para obter diretrizes passo a passo, consulte Métricas do Azure.
Repositório de consultas
O repositório de consultas captura automaticamente o histórico de consultas e as estatísticas de runtime e as retém para sua análise. Ele divide os dados por tempo, para que você possa ver os 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 do Banco de Dados do Azure para PostgreSQL com Servidor Flexível.
O repositório de consultas pode correlacionar informações de eventos de espera com estatísticas de runtime de consultas. Use o repositório de consultas para identificar consultas que têm alto consumo de CPU durante o período de interesse.
Para obter mais informações, confira o repositório de consultas.
pg_stat_statements
A extensão pg_stat_statements ajuda a identificar consultas que consomem tempo no servidor. Para obter mais informações sobre essa extensão, confira sua documentação.
Tempo médio de execução
Para as versões 13 e superiores do Postgres, use a seguinte instrução para exibir as cinco principais instruções SQL por tempo 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;
Tempo total de execução
Execute as instruções a seguir para exibir as cinco principais instruções SQL pelo tempo total de execução.
Para as versões 13 e superiores do Postgres, 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 causas raiz
Se os níveis de consumo de CPU estiverem altos em geral, as seguintes poderão ser possíveis causas raiz:
Transações de longa execução
Transações de execução longa podem consumir recursos de CPU que podem levar à alta utilização da CPU.
A consulta a seguir ajuda a identificar conexões em execução pelo maior 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 pode levar ao aumento do uso 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;
Resolver alta utilização da CPU
Use EXPLAIN ANALYZE, considere usar o pooler de conexões PgBouncer interno e encerre transações de longa duração para resolver o uso elevado da CPU.
Use EXPLAIN ANALYZE
Depois de conhecer as consultas que estão consumindo mais CPU, use EXPLAIN ANALYZE para investigá-las e ajustá-las.
Para obter mais informações sobre o comando EXPLAIN ANALYZE, confira sua documentação.
PgBouncer, um pooler de conexão interno
Em situações em que há muitas conexões de curta duração ou muitas conexões que permanecem inativas na maior parte de sua vida útil, considere usar um pooler de conexão como o PgBouncer.
Para obter mais informações sobre o PgBouncer, confira pooler de conexão e práticas recomendadas de manipulação de conexões com PostgreSQL
O servidor flexível do Banco de Dados do Azure para PostgreSQL oferece o PgBouncer como uma solução interna de pooling de conexões. Para obter mais informações, confira PgBouncer.
Encerrar transações de execução prolongada
Você pode considerar encerrar uma transação prolongada como uma opção.
Para encerrar o PID de uma sessão, você precisará encontrar 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 obter o PID da sessão, você poderá encerrá-lo usando a seguinte consulta:
SELECT pg_terminate_backend(pid);
Monitorar estatísticas de vácuo e tabela
Manter as estatísticas da tabela atualizadas ajuda a melhorar o desempenho da consulta. Monitore se a manutenção periódica regular está sendo realizada.
A consulta a seguir ajuda a identificar as tabelas que precisam receber manutenção periódica:
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;
As colunas last_autovacuum e last_autoanalyze dão a data e a hora em que a tabela recebeu manutenção periódica automática ou foi analisada pela última vez. Se as tabelas não estiverem recebendo manutenção periódica regularmente, execute as etapas para ajustar a manutenção periódica automática.
Para obter mais informações sobre solução de problemas e ajuste de manutenção periódica automática, consulte Solução de problemas de manutenção periódica automática.
Uma solução de curto prazo seria fazer uma análise de manutenção periódica manual das tabelas em que as consultas lentas são vistas:
VACUUM ANALYZE <table>;