Autovacuum adattivo nel server flessibile del Database di Azure per PostgreSQL

Questo articolo documenta i parametri supportati da adaptive_autovacuum Database di Azure per PostgreSQL flexible server:

• adaptive_autovacuum.optimize_configurations: abilita l'ottimizzazione automatica di una serie di impostazioni autovacuum.
• adaptive_autovacuum.open_transaction_threshold: imposta la soglia temporale in secondi per rilevare e mitigare le transazioni preparate obsolete.

Funzionamento di ogni parametro

adaptive_autovacuum.optimize_configurations

Quando imposti questo parametro su on, il servizio di ottimizzazione esegue periodicamente le seguenti operazioni:

1. Raccoglie e aggrega i segnali del carico di lavoro e delle statistiche delle tabelle.
2. Valuta i flussi di lavoro delle regole.
3. Calcola gli aggiornamenti candidati dei parametri autovacuum.
4. Applica gli aggiornamenti e ricarica la configurazione del motore.
5. Scrive le voci di controllo.

Se non viene soddisfatta alcuna condizione della regola, un'esecuzione può concludersi senza modifiche.

Parametri ottimizzabili correnti:

• autovacuum_vacuum_cost_limit
• autovacuum_vacuum_threshold
• autovacuum_vacuum_scale_factor
• autovacuum_vacuum_cost_delay
• autovacuum_analyze_scale_factor

Visibilità e comportamento di override per i parametri ottimizzati

Quando questa funzionalità modifica uno dei cinque parametri di destinazione (autovacuum_vacuum_cost_limit, autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factorautovacuum_vacuum_cost_delay, , autovacuum_analyze_scale_factor):

• L'endpoint Configurations del piano di controllo (ad esempio, l'API GET Configurations o il gruppo di comandi CLI az postgres flexible-server parameter) non mostra queste modifiche effettive in fase di esecuzione.
• Per visualizzare i valori effettivi, usare le query del piano dati sull'endpoint PostgreSQL , ad esempio SHOW <guc_name> o SELECT name, setting FROM pg_settings WHERE name IN (...).

Semantica di override dell'utente:

• È possibile impostare uno di questi cinque parametri direttamente tramite il portale, l'API REST, l'interfaccia della riga di comando o uno qualsiasi degli SDK supportati.
• Se si imposta un parametro sullo stesso valore restituito dall'endpoint Configurations del piano di controllo, l'operazione viene considerata come un no-op e non viene applicata alcuna nuova modifica effettiva.
• I valori impostati dall'utente sostituiscono i valori applicati alle funzionalità al momento dell'applicazione.
• Se adaptive_autovacuum.optimize_configurations rimane abilitata, le iterazioni di ottimizzazione successive possono applicare di nuovo nuovi valori in base alla valutazione delle regole.

adaptive_autovacuum.open_transaction_threshold

Questo parametro controlla la mitigazione delle transazioni preparate orfane:

• 0 significa disabilitato.
• Un valore maggiore di 0 indica che è abilitato con una soglia espressa in secondi.

Se abilitata, se la transazione preparata meno recente supera la soglia, il gestore delle transazioni orfane valuta l'idoneità e può eseguire il rollback delle transazioni preparate precedenti. Il gestore aggiorna la soglia in memoria in base alle modifiche dei parametri, quindi il comportamento segue il valore più recente.

Importante dettaglio sulla tempistica:

• La funzionalità determina per prima cosa il timestamp della transazione preparata più vecchia.
• Tale rilevamento avviene tramite polling, non in modo continuo.
• Il poll viene eseguito ogni 1.800 secondi (cioè ogni 30 minuti), quindi la mitigazione può iniziare solo dopo che un poll rileva una transazione preparata abbastanza vecchia.

Comportamento in fase di esecuzione e di schedulazione

• La frequenza di ottimizzazione optimize_configurations è di 30 minuti.
• Quando si attiva optimize_configurations, viene avviata immediatamente un'esecuzione di ottimizzazione, dopodiché continuano le esecuzioni pianificate.
• La gestione di open_transaction_threshold è guidata dagli eventi derivati dalle osservazioni delle transazioni preparate. La mitigazione viene eseguita solo quando i controlli di età superano la soglia.
• Il monitoraggio della transazione preparata per open_transaction_threshold si aggiorna ogni 300 secondi.

Quando viene creato lo schema intelligentperformance dopo essere stato abilitato?

Lo schema intelligentperformance viene creato nel database azure_sys. La creazione non è immediata ed è gestita dalla funzionalità che memorizza in modo persistente le statistiche usate dall'autovacuum adattivo, anziché dall'esecuzione iniziale della procedura di ottimizzazione. In genere, lo schema viene creato entro 0-30 minuti dopo l'abilitazione della funzionalità.

È possibile abilitare l'autovacuum adattivo impostando adaptive_autovacuum.optimize_configurations su on oppure configurando adaptive_autovacuum.open_transaction_threshold su un valore diverso da zero (ossia > 0). Lo schema viene creato dopo che la funzionalità diventa attiva e inizia a raccogliere le statistiche necessarie.

La creazione potrebbe essere ritardata o ignorata se alcuni prerequisiti non sono soddisfatti.

Limitazioni e prerequisiti

Entrambi i controlli sono soggetti ai requisiti seguenti:

• L'istanza deve essere primaria.
• PostgreSQL non è in modalità di ripristino.
• Il calcolo del server ha almeno 4 vCore.
• Il server è un server flessibile normale, non un cluster elastico. La funzionalità non è supportata nei cluster elastici.
• adaptive_autovacuum.optimize_configurations è supportato nelle versioni principali maggiori o uguali a 14.
• adaptive_autovacuum.open_transaction_threshold è supportato nelle versioni principali maggiori o uguali a 13.

Controllo e osservabilità

Il sistema registra le azioni di entrambi i controlli in una vista di controllo denominata intelligentperformance.adaptive_tuning_events.

Schema della vista

Forma logica prevista:

• intelligentperformance.adaptive_tuning_events
  • event_details
  • optimizer_type
  • applied_at

Query per l'attività recente

Per eseguire query sulle attività recenti, usare le query seguenti:

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;

Tipi di evento e interpretazione

La optimizer_type colonna indica l'origine dell'azione.

adaptive_autovacuum_configuration_changed

Origine:

• Percorso di ottimizzazione di optimize_configurations.

Struttura del payload:

• Matrice JSON di record di modifica dei parametri, in genere tra cui:
  • server_parameter_name
  • valore_precedente
  • updated_tuned_value

Interpretazione:

• Indica che la regolazione di autovacuum ha modificato le impostazioni del server.
• Positivo se migliorano le metriche successive del carico di lavoro (pressione delle tuple inattive, cadenza di vacuum, latenza, CPU e I/O).
• Potenzialmente negativo quando le modifiche sono frequenti e oscillatorie e sono seguite da regressioni.

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

Origine:

• open_transaction_threshold percorso di mitigazione.

Struttura del payload:

• Oggetto JSON indicizzato per database, con i dettagli dell’esito del rollback (ad esempio informazioni sui tentativi di rollback GID tentati e completati correttamente).

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

Interpretazione:

• Indica che le transazioni preparate sono state sottoposte a rollback forzato una volta superata la soglia.
• Gli eventi occasionali possono essere comportamenti protettivi sani.
• Gli eventi frequenti indicano in genere problemi relativi al ciclo di vita delle transazioni dell'applicazione che devono essere esaminati.

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;

Determinare se l'impatto è positivo o negativo

Per optimize_configurations:

1. Identificare i timestamp delle modifiche da adaptive_autovacuum_configuration_changed.
2. Confrontare le finestre le finestre visualizzate da 30 a 120 minuti dopo la modifica per identificare tuple inattive, cadenza di vacuum/analisi, latenza, CPU e I/O.

Per open_transaction_threshold:

1. Identificare orphan_transaction_rollback gli eventi.
2. Verificare se la frequenza di rollback è bassa e stabilizzante.
3. Esaminare il comportamento dell'applicazione se gli eventi di rollback sono persistenti.

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

Conservazione e manutenzione

La manutenzione rimuove i record meno recenti dall'archiviazione di controllo usando una finestra di conservazione fissa e non configurabile di 90 giorni.

Per l'analisi delle tendenze a lungo termine, esportare le righe di controllo nell'archivio di osservabilità.

Contenuti correlati

• Ottimizzazione intelligente.