Partilhar via

Solucionar problemas de alta utilização de IOPS para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível

  • Artigo

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 de IOPS (operações de entrada/saída por segundo) e fornece ações corretivas para controlar a utilização de IOPS quando você estiver usando o Banco de Dados do Azure para servidor flexível PostgreSQL.

Neste artigo, vai aprender a:

  • Sobre guias de solução de problemas para identificar e obter recomendações para mitigar as causas raiz.
  • Use ferramentas para identificar alta utilização de entrada/saída (E/S), como Métricas do Azure, Repositório de Consultas e pg_stat_statements.
  • Identifique as causas principais, como consultas de longa execução, tempos de ponto de verificação, um processo de daemon de autovácuo com interrupções e alta utilização do armazenamento.
  • Resolva a alta utilização de E/S usando o Explain Analyze, ajuste os parâmetros do servidor relacionados ao ponto de verificação e ajuste o daemon de vácuo automático.

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 a alta utilização de IOPS. 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 alta utilização de E/S

Considere as seguintes ferramentas para identificar a alta utilização de E/S.

Azure Metrics

O Azure Metrics é um bom ponto de partida para verificar a utilização de E/S para uma data e período definidos. As métricas fornecem informações sobre o tempo durante o qual a utilização de E/S é 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 para descobrir os momentos em que a carga de trabalho está causando alta utilização de E/S. 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 recurso Repositório de Consultas captura automaticamente o histórico de consultas e estatísticas de tempo de execução e as retém para sua revisão. Ele divide os dados por tempo para 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 Monitorar o desempenho com o Repositório de Consultas.

Use a instrução a seguir para exibir as cinco principais instruções SQL que consomem E/S:

select * from query_store.qs_view qv where is_system_query is FALSE
order by blk_read_time + blk_write_time  desc limit 5;

A extensão pg_stat_statements

A pg_stat_statements extensão ajuda a identificar consultas que consomem E/S no servidor.

Use a instrução a seguir para exibir as cinco principais instruções SQL que consomem E/S:

SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY blk_read_time + blk_write_time desc
LIMIT 5;

Nota

Ao usar o repositório de consultas ou pg_stat_statements para colunas blk_read_time e blk_write_time a serem preenchidas, você precisa habilitar o parâmetro track_io_timingserver . Para obter mais informações sobre track_io_timingo , consulte Parâmetros do servidor.

Identificar as causas profundas

Se os níveis de consumo de E/S forem altos em geral, as seguintes podem ser as causas principais:

Transações de longa duração

Transações de longa duração podem consumir E/S, o que pode levar a uma alta utilização de E/S.

A consulta a seguir ajuda a identificar conexões que estão sendo executadas 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;

Horários dos pontos de verificação

E/S altas também podem ser vistas em cenários em que um ponto de verificação está acontecendo com muita frequência. Uma maneira de identificar isso é verificando o banco de dados do Azure para o arquivo de log do servidor flexível PostgreSQL para o seguinte texto de log: "LOG: os pontos de verificação estão ocorrendo com muita frequência".

Você também pode investigar usando uma abordagem em que instantâneos periódicos de com um carimbo de pg_stat_bgwriter data/hora são salvos. Usando os instantâneos salvos, você pode calcular o intervalo médio de pontos de verificação, o número de pontos de verificação solicitados e o número de pontos de verificação cronometrados.

Processo de daemon de autovácuo disruptivo

Execute a seguinte consulta para monitorar o autovacuum:

SELECT schemaname, relname, n_dead_tup, n_live_tup, autovacuum_count, last_vacuum, last_autovacuum, last_autoanalyze, autovacuum_count, autoanalyze_count FROM pg_stat_all_tables WHERE n_live_tup > 0;

A consulta é usada para verificar com que frequência as tabelas no banco de dados estão sendo aspiradas.

  • last_autovacuum: A data e hora em que o último autovácuo correu sobre a mesa.
  • autovacuum_count: O número de vezes que a mesa foi aspirada.
  • autoanalyze_count: O número de vezes que a tabela foi analisada.

Resolver problemas com a utilização de E/S elevada

Para resolver a alta utilização de E/S, você pode usar qualquer um dos três métodos a seguir.

O EXPLAIN ANALYZE comando

Depois de identificar a consulta que está consumindo E/S alta, use EXPLAIN ANALYZE para investigar mais a consulta e ajustá-la. Para obter mais informações sobre o EXPLAIN ANALYZE comando, revise o plano EXPLICAR.

Encerrar transações de longa duração

Você pode considerar matar uma transação de longa duração como uma opção.

Para encerrar a ID de processo (PID) de uma sessão, você precisa 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) ou datname (nome do banco de dados).

Depois de ter o PID da sessão, você pode encerrá-lo usando a seguinte consulta:

SELECT pg_terminate_backend(pid);

Ajustar parâmetros do servidor

Se você observar que o ponto de verificação está acontecendo com muita frequência, aumente o parâmetro do servidor até que a max_wal_size maioria dos pontos de verificação seja orientada pelo tempo, em vez de solicitada. Eventualmente, 90% ou mais devem ser baseados no tempo, e o intervalo entre dois pontos de verificação deve ser próximo ao checkpoint_timeout valor definido no servidor.

  • max_wal_size: O horário comercial de pico é um bom momento para chegar a um max_wal_size valor. Para chegar a um valor, faça o seguinte:

    1. Execute a seguinte consulta para obter o LSN WAL atual e, em seguida, anote o resultado:

      select pg_current_wal_lsn();

    2. Aguarde alguns checkpoint_timeout segundos. Execute a seguinte consulta para obter o LSN WAL atual e, em seguida, anote o resultado:

      select pg_current_wal_lsn();

    3. Execute a seguinte consulta, que usa os dois resultados, para verificar a diferença, em gigabytes (GB):

      select round (pg_wal_lsn_diff ('LSN value when run second time', 'LSN value when run first time')/1024/1024/1024,2) WAL_CHANGE_GB;

  • checkpoint_completion_target: Uma boa prática seria definir o valor para 0,9. Por exemplo, um valor de 0,9 para um checkpoint_timeout de 5 minutos indica que o destino para concluir um ponto de verificação é de 270 segundos (0,9 * 300 segundos). Um valor de 0,9 fornece uma carga de E/S bastante consistente. Um valor agressivo de pode resultar em um aumento da carga de checkpoint_completion_target E/S no servidor.

  • checkpoint_timeout: Você pode aumentar o checkpoint_timeout valor a partir do valor padrão definido no servidor. À medida que você aumenta o valor, leve em consideração que aumentá-lo também aumentaria o tempo de recuperação de falhas.

Sintonize o autovacuum para diminuir interrupções

Para obter mais informações sobre monitoramento e ajuste em cenários em que o autovacuum é muito perturbador, consulte Autovacuum tuning.

Aumentar o armazenamento

Aumentar o armazenamento ajuda quando você adiciona mais IOPS ao servidor. Para obter mais informações sobre armazenamento e IOPS associadas, consulte Opções de computação e armazenamento.

Conteúdos relacionados