Share 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 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á o seguinte:

  • Sobre guias de solução de problemas para identificar e obter recomendações para atenuar as causas raiz.
  • Sobre ferramentas para identificar a alta utilização 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 a alta utilização da CPU usando tabelas Explain Analyze, Connection Pooling e Vacuuming.

Guias de solução de problemas

Usando os guias de solução de problemas de recursos, que estão disponíveis no Portal do Servidor Flexível do Banco de Dados do Azure para PostgreSQL, a provável causa raiz e as recomendações para o cenário de mitigação de CPU alta podem ser encontradas. Para saber como configurar os guias de solução de problemas para usá-los, siga configurar os guias de solução de problemas.

Ferramentas para identificar a alta utilização da CPU

Considere essas ferramentas para identificar a alta utilização da CPU.

Métricas do Azure

As Métricas do Azure são 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 a qual a utilização da CPU está alta. Compare os grafos de IOPs de Gravação, IOPs de Leitura, Taxa de Transferência de Leitura e Taxa de Transferência de Gravação com utilização da CPU para descobrir os horários em que a carga de trabalho causou alta 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 das estatísticas de runtime e consultas e o retém para sua análise. Ele divide os dados por tempo para que você possa ver os 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 chamado azure_sys na instância do servidor flexível do Banco de Dados do Azure para PostgreSQL. Para obter uma 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 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 forem altos em geral, as seguintes podem ser as 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 conexões numéricas 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;

Resolver alta utilização da CPU

Use Explain Analyze, PG Bouncer, pooling de conexões e encerrar transações de execução prolongada para resolver a alta utilização da CPU.

Usar o Explain Analyze

Depois de saber a consulta que está em execução há muito tempo, use EXPLAIN para investigar ainda mais a consulta e ajustá-la.
Para obter mais informações sobre o comando EXPLAIN, examine Explain Plan.

PGBouncer e pooling de conexões

Em situações onde 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 obter mais detalhes sobre PgBouncer, examine:

Pooler de conexões

Melhores práticas

O Banco de Dados do Azure para servidor flexível 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 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á detectar o PID fazendo 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 de banco de dados) etc.

Depois de ter o PID da sessão, você pode encerrar 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_name>;