Ajuste de vácuo automático adaptável no servidor flexível do Banco de Dados do Azure para PostgreSQL

Este artigo documenta os parâmetros adaptive_autovacuum suportados pelo servidor flexível do Azure Database para PostgreSQL:

• adaptive_autovacuum.optimize_configurations: habilita o ajuste automático de uma série de configurações de vácuo automático.
• adaptive_autovacuum.open_transaction_threshold: define o limite de idade em segundos para detectar e atenuar transações preparadas antigas.

Como cada parâmetro funciona

adaptive_autovacuum.optimize_configurations

Quando você define esse parâmetro como on, o serviço de ajuste periodicamente:

1. Coleta e agrega sinais de carga de trabalho e estatísticas de tabela.
2. Avalia fluxos de trabalho de regras.
3. Calcula atualizações candidatas dos parâmetros de autovacuum.
4. Aplica atualizações e recarrega a configuração do mecanismo.
5. Grava registros de auditoria.

Se nenhuma condição de regra for atendida, uma execução pode ser concluída 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 substituição para parâmetros ajustados

Quando esse recurso altera qualquer um dos cinco parâmetros de destino (autovacuum_vacuum_cost_limit, , autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor, autovacuum_vacuum_cost_delay): autovacuum_analyze_scale_factor

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

Semântica de substituição do usuário:

• Você pode definir qualquer um desses cinco parâmetros diretamente por meio do portal, da API REST, da CLI ou de qualquer um dos SDKs com suporte.
• Se você definir um parâmetro para o mesmo valor retornado atualmente pelo endpoint Configurations do plano de controle, a operação será tratada como um no-op, e nenhuma nova alteração efetiva será aplicada.
• Os valores definidos pelo usuário substituem os valores aplicados pelo recurso no momento em que são aplicados.
• Se adaptive_autovacuum.optimize_configurations permanecer habilitado, as iterações de ajuste posteriores poderão aplicar novos valores novamente com base na avaliação da regra.

adaptive_autovacuum.open_transaction_threshold

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

• 0 significa desabilitado.
• Maior que 0 significa habilitado, com um limite em segundos.

Quando habilitada, se a transação preparada mais antiga exceder o limite, o manipulador de transações órfãs avaliará a qualificação e poderá reverter transações preparadas antigas. O manipulador atualiza seu limite na memória em alterações de parâmetro, portanto, o comportamento segue o valor mais recente.

Detalhes de tempo importantes:

• O recurso primeiro identifica o timestamp mais antigo da transação preparada.
• Essa detecção é baseada em pesquisa, não contínua.
• A verificação é realizada a cada 1.800 segundos (ou seja, a cada 30 minutos); portanto, a mitigação só pode começar depois que uma verificação detectar uma transação preparada com antiguidade suficiente.

Tempo de execução e comportamento de agendamento

• A frequência de ajuste do optimize_configurations é de 30 em 30 minutos.
• Quando você ativa optimize_configurations, ele dispara uma execução de ajuste imediato e, em seguida, as execuções agendadas continuam.
• A manipulação de open_transaction_threshold é orientada por eventos com base em observações de transações preparadas. A mitigação ocorre apenas quando as verificações de idade excedem o limiar.
• O monitoramento de transações preparadas de open_transaction_threshold é atualizado a cada 300 segundos.

Quando o intelligentperformance esquema é criado após a habilitação?

O intelligentperformance esquema é criado no azure_sys banco de dados. Sua criação não é imediata e é realizada pela funcionalidade que persiste as estatísticas utilizadas pela aspiração automática adaptativa, e não pela própria execução inicial de ajuste. Normalmente, o esquema é criado dentro de 0 a 30 minutos depois de habilitar o recurso.

Você pode habilitar o vácuo automático adaptável definindo adaptive_autovacuum.optimize_configurationson ou configurando adaptive_autovacuum.open_transaction_threshold para um valor diferente de zero (ou seja > , 0). O esquema é criado quando o recurso se torna ativo e começa a coletar as estatísticas necessárias.

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

Limitações e pré-requisitos

Ambos os controles estão sujeitos aos seguintes requisitos:

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

Auditoria e observabilidade

O sistema registra ações de ambos os controles em uma exibição de auditoria chamada intelligentperformance.adaptive_tuning_events.

Esquema da visualização

Forma lógica esperada:

• intelligentperformance.adaptive_tuning_events
  • detalhes do evento
  • optimizer_type
  • applied_at

Consulta de atividade recente

Para consultar a atividade recente, use 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 evento e interpretação

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

adaptive_autovacuum_configuration_changed

Origem:

• Caminho de ajuste de optimize_configurations.

Formato da carga útil:

• Matriz JSON de registros de alteração de parâmetro, normalmente incluindo:
  • server_parameter_name
  • valor_anterior
  • updated_tuned_value

Interpretação:

• Indica que o ajuste do autovacuum alterou as configurações do servidor.
• Positivo quando as métricas de carga de trabalho subsequentes melhoram (pressão de tuplas inativas, cadência de vácuo, latência, CPU/E/S).
• Potencialmente negativo quando as alterações são frequentes e oscilantes 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;

orphan_transaction_rollback

Origem:

• open_transaction_threshold caminho de mitigação.

Formato da carga útil:

• Objeto JSON indexado por banco de dados, contendo detalhes sobre o resultado do rollback (por exemplo, informações sobre tentativas e sucessos de rollback de 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 transações preparadas sofreram reversão forçada após ultrapassarem o limite.
• Ocorrências ocasionais podem ser uma forma saudável de comportamento protetor.
• Eventos frequentes geralmente indicam problemas de ciclo de vida de transação do aplicativo que devem ser investigados.

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 os registros de alteração de adaptive_autovacuum_configuration_changed.
2. Compare janelas de 30 a 120 minutos após a alteração em relação a tuplas inativas, cadência de vácuo/análise, latência e CPU/E/S.

Para open_transaction_threshold:

1. Identificar eventos orphan_transaction_rollback
2. Valide se a frequência de reversão é baixa e estabilizadora.
3. Investigue o comportamento do aplicativo se os eventos de reversão 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

A manutenção remove registros mais antigos do armazenamento de auditoria utilizando um período de retenção fixo e não configurável de 90 dias.

Para análise de tendências de longo prazo, exporte as linhas de auditoria para o seu próprio armazenamento de observabilidade.

Conteúdo relacionado

• Ajuste inteligente.