Partilhar via


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.

Guias de resolução de problemas

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.

Ferramentas para identificar a alta utilização da CPU

Considere o uso da seguinte lista de 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 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.

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 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.

pg_stat_statements

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.

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, os 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 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;

Resolva a alta utilização da CPU

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.

Use EXPLICAR ANALISAR

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.

PgBouncer, um pooler de conexões integrado

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.

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ê 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);

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>;