Autovacuum adaptativa no servidor flexível do Base de Dados do Azure para PostgreSQL

Este artigo documenta os adaptive_autovacuum parâmetros suportados pelo Base de Dados do Azure para PostgreSQL para servidores flexíveis:

• adaptive_autovacuum.optimize_configurations: Permite o ajuste automático de um conjunto de definições do autovacuum.
• adaptive_autovacuum.open_transaction_threshold: Define o limiar de idade em segundos para detetar e mitigar transações antigas preparadas.

Como funciona cada parâmetro

adaptive_autovacuum.optimize_configurations

Quando configuras este parâmetro para on, o serviço de otimização periodicamente:

1. Recolhe e agrega sinais de carga de trabalho e estatísticas de tabelas.
2. Avalia os fluxos de trabalho de regras.
3. Calcula as possíveis atualizações dos parâmetros de vácuo automático.
4. Aplica atualizações e recarrega a configuração do motor.
5. Escreve registos de auditoria.

Se não se verificar nenhuma condição de regra, uma execução pode terminar sem alterações.

Parâmetros ajustáveis atuais:

• autovacuum_vacuum_cost_limit
• autovacuum_vacuum_threshold
• autovacuum_vacuum_scale_factor
• autovacuum_vacuum_cost_delay
• autovacuum_analyze_scale_factor

Visibilidade e comportamento de sobreposição para parâmetros ajustados

Quando esta característica altera qualquer um dos cinco parâmetros alvo (autovacuum_vacuum_cost_limit, autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor, autovacuum_vacuum_cost_delay, autovacuum_analyze_scale_factor):

• O endpoint Configurations do plano de controlo (por exemplo, a API GET Configurations ou o grupo de comandos da CLI az postgres flexible-server parameter) não mostra estas alterações efetivas em tempo de execução.
• Para ver os valores efetivos, use consultas no plano de dados contra o endpoint PostgreSQL (por exemplo, SHOW <guc_name> ou SELECT name, setting FROM pg_settings WHERE name IN (...)).

Semântica de sobreposição do utilizador:

• Pode definir qualquer um destes cinco parâmetros diretamente através do portal, REST API, CLI ou qualquer um dos SDKs suportados.
• Se definir um parâmetro com o mesmo valor que o endpoint Configurations do plano de controlo devolve atualmente, a operação é tratada como um no-op e nenhuma nova alteração efetiva é aplicada.
• Os valores definidos pelo utilizador sobrepõem-se aos valores aplicados pela funcionalidade no momento em que estes são aplicados.
• Se adaptive_autovacuum.optimize_configurations continuar ativado, as iterações de afinação posteriores podem aplicar novos valores novamente com base na avaliação das regras.

adaptive_autovacuum.open_transaction_threshold

Este parâmetro controla a mitigação de transações preparadas por órfãos:

• 0 significa incapacitado.
• Maior que 0 significa ativado com limiar em segundos.

Quando ativada, se a transação preparada mais antiga ultrapassar o limite, o gestor de transações órfãs avalia a elegibilidade e pode reverter transações preparadas antigas. O handler atualiza o seu limiar em memória com alterações de parâmetro, de modo que o comportamento segue o valor mais recente.

Aspeto temporal importante:

• A funcionalidade começa por determinar a marca temporal da transação preparada mais antiga.
• Essa deteção é baseada em sondagens, não contínua.
• A sondagem decorre a cada 1.800 segundos (ou seja, a cada 30 minutos), pelo que a mitigação só pode começar depois de uma sondagem observar uma transação suficientemente antiga e preparada.

Tempo de execução e comportamento de agendamento

• A optimize_configurations frequência de ajuste é de 30 minutos.
• Quando ativa optimize_configurations, é acionada imediatamente uma execução de otimização e, em seguida, as execuções agendadas continuam.
• O tratamento de open_transaction_threshold é orientado por eventos com base na observação de transações preparadas. A mitigação só ocorre quando as verificações de idade excedem o limiar.
• A monitorização da transação preparada para open_transaction_threshold é atualizada a cada 300 segundos.

Quando é que o esquema intelligentperformance é criado depois de ser ativado?

O intelligentperformance esquema é criado através da base de azure_sys dados. A sua criação não é imediata e é gerida pela funcionalidade que mantém as estatísticas usadas pelo autovácuo adaptativo, em vez da execução inicial da afinação. Normalmente, o esquema é criado entre 0 e 30 minutos após ativar a funcionalidade.

Pode ativar o autovácuo adaptativo definindo adaptive_autovacuum.optimize_configurations para on ou configurando adaptive_autovacuum.open_transaction_threshold para um valor diferente de zero (isto é, > 0). O esquema é criado assim que a funcionalidade se torna ativa e começa a recolher as estatísticas necessárias.

A criação pode ser adiada ou omitida se determinados pré-requisitos não forem cumpridos.

Limitações e pré-requisitos

Ambos os controlos estão sujeitos aos seguintes requisitos:

• A instância tem de ser primária.
• O PostgreSQL não está em modo de recuperação.
• A computação do servidor tem um mínimo de 4 vCores.
• O servidor é um servidor flexível normal, não um cluster elástico. A funcionalidade não é suportada em clusters elásticos.
• adaptive_autovacuum.optimize_configurations é suportado em versões maiores maiores ou iguais a 14.
• adaptive_autovacuum.open_transaction_threshold é suportado em versões maiores maiores ou iguais a 13.

Auditoria e observabilidade

O sistema regista ações de ambos os controlos numa vista de auditoria chamada intelligentperformance.adaptive_tuning_events.

Esquema da visualização

Forma lógica esperada:

• intelligentperformance.adaptive_tuning_events
  • event_details
  • optimizer_type
  • applied_at

Consulta de atividade recente

Para consultar atividades recentes, utilize as seguintes consultas:

SELECT
    applied_at,
    optimizer_type,
    event_details
FROM intelligentperformance.adaptive_tuning_events
ORDER BY applied_at DESC
LIMIT 100;

SELECT
    optimizer_type,
    COUNT(*) AS events
FROM intelligentperformance.adaptive_tuning_events
WHERE applied_at >= now() - interval '7 days'
GROUP BY optimizer_type
ORDER BY events DESC;

Tipos de eventos e interpretação

A optimizer_type coluna indica a origem da ação.

autovacuum_adaptativa_configuracao_alterada

Origem:

• optimize_configurations Caminho de ajuste.

Estrutura da payload:

• Array JSON de registos de alteração de parâmetros, normalmente incluindo:
  • server_parameter_name
  • valor_anterior
  • valor_ajustado_atualizado

Interpretação:

• Indica que o ajuste do autovacuum alterou as definições do servidor.
• Positivo quando as métricas de carga de trabalho subsequentes melhoram (pressão morta da tupla, cadência de vácuo, latência, CPU/IO).
• Potencialmente negativo quando as mudanças são frequentes e oscilatórias e são seguidas por regressões.

SELECT
    applied_at,
    elem->>'server_parameter_name' AS parameter_name,
    elem->>'previous_value' AS previous_value,
    elem->>'updated_tuned_value' AS updated_value
FROM intelligentperformance.adaptive_tuning_events e
CROSS JOIN LATERAL jsonb_array_elements(e.event_details) AS elem
WHERE e.optimizer_type = 'adaptive_autovacuum_configuration_changed'
ORDER BY applied_at DESC;

transação_órfã_reversão

Origem:

• open_transaction_threshold Caminho de mitigação.

Estrutura da payload:

• Objeto JSON indexado pela base de dados, com detalhes dos resultados de rollback (por exemplo, informação de rollback tentada e bem-sucedida do GID).

{
    "<example-database-name>": {
        "Timestamp": "2026-03-22T18:20:22.0000000Z", 
        "RollbackGids": ["<example-global-identifier-one>", "<example-global-identifier-two>"], 
        "OperationSuccessful": true
    }
}

Interpretação:

• Indica que as transações preparadas foram anuladas à força depois de ultrapassarem o limiar.
• Eventos ocasionais podem ser um comportamento protetor saudável.
• Eventos frequentes geralmente indicam questões no ciclo de vida da transação da aplicação que devem ser investigadas.

SELECT
    applied_at,
    jsonb_pretty(event_details) AS rollback_details
FROM intelligentperformance.adaptive_tuning_events
WHERE optimizer_type = 'orphan_transaction_rollback'
ORDER BY applied_at DESC
LIMIT 50;

Determinar se o impacto é positivo ou negativo

Para optimize_configurations:

1. Identifique as marcas temporais da alteração a partir de adaptive_autovacuum_configuration_changed.
2. Compare janelas pós-mudança de 30 a 120 minutos para tuplas mortas, aspire/analisar cadência, latência, CPU/IO.

Para open_transaction_threshold:

1. Identificar eventos orphan_transaction_rollback.
2. Valide se a frequência de rollback é baixa e estabilizadora.
3. Investigue o comportamento da aplicação se os eventos de rollback forem persistentes.

SELECT
    applied_at,
    optimizer_type,
    event_details
FROM intelligentperformance.adaptive_tuning_events
WHERE applied_at >= now() - interval '7 days'
ORDER BY applied_at DESC;

Retenção e manutenção

O serviço de manutenção remove registos antigos do armazenamento de auditoria usando uma janela de retenção fixa e não configurável de 90 dias.

Para uma análise de tendências a longo prazo, exporte os registos de auditoria para o seu próprio repositório de observabilidade.

Conteúdo relacionado

• Otimização inteligente.