Adaptiv autovacuum i Azure Database för PostgreSQL – Flexibel server

Den här artikeln beskriver de adaptive_autovacuum parametrar som stöds av Azure Database for PostgreSQL – Flexibel server:

• adaptive_autovacuum.optimize_configurations: Aktiverar automatisk justering av en serie autovacuum-inställningar.
• adaptive_autovacuum.open_transaction_threshold: Anger ålderströskeln i sekunder för att identifiera och minimera gamla förberedda transaktioner.

Så här fungerar varje parameter

adaptive_autovacuum.optimize_configurations

När du ställer in den här parametern på on, justerar tjänsten regelbundet:

1. Samlar in och aggregerar arbetsbelastnings- och tabellstatistiksignaler.
2. Utvärderar regelarbetsflöden.
3. Beräknar föreslagna uppdateringar av autovacuum-parametrar.
4. Tillämpar uppdateringar och läser in motorkonfigurationen igen.
5. Skriver granskningsposter.

Om inga regelvillkor uppfylls kan en körning slutföras utan ändringar.

Nuvarande justerbara parametrar:

• autovacuum_vacuum_cost_limit
• autovacuum_vacuum_threshold
• autovacuum_vacuum_scale_factor
• autovacuum_vacuum_cost_delay
• autovacuum_analyze_scale_factor

Synlighets- och åsidosättningsbeteende för finjusterade parametrar

När den här funktionen ändrar någon av de fem målparametrarna (autovacuum_vacuum_cost_limit, autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor, autovacuum_vacuum_cost_delay, autovacuum_analyze_scale_factor):

• Slutpunkten för Konfigurationer i kontrollplanet (till exempel Configurations-API:et GET eller kommandogruppen az postgres flexible-server parameter CLI) visar inte dessa faktiska ändringar vid körning.
• Om du vill se de effektiva värdena använder du dataplansfrågor mot PostgreSQL-slutpunkten (till exempel SHOW <guc_name> eller SELECT name, setting FROM pg_settings WHERE name IN (...)).

Användaren åsidosätter semantik:

• Du kan ange någon av dessa fem parametrar direkt via portalen, REST API, CLI eller någon av de SDK:er som stöds.
• Om du anger en parameter till samma värde som kontrollplanets konfigurationsslutpunkt för närvarande returnerar behandlas åtgärden som en no-op och ingen ny effektiv ändring tillämpas.
• Användarangivna värden åsidosätter de värden som funktionen tillämpar när de tillämpas.
• Om adaptive_autovacuum.optimize_configurations förblir aktiverat kan senare justering av iterationer tillämpa nya värden igen baserat på regelutvärdering.

adaptive_autovacuum.open_transaction_threshold

Den här parametern styr överblivna åtgärder för förberedda transaktioner:

• 0 betyder inaktiverad.
• Mer än 0 betyder att funktionen är aktiverad med ett tröskelvärde i sekunder.

Om den äldsta förberedda transaktionen överskrider tröskelvärdet när den aktiveras utvärderar hanteraren för överblivna transaktioner berättigande och kan återställa gamla förberedda transaktioner. Hanteraren uppdaterar tröskelvärdet i minnet för parameterändringar, så beteendet följer det senaste värdet.

Viktig tidsinformation:

• Funktionen avgör först den äldsta förberedda transaktionstidsstämpeln.
• Den upptäckten sker genom avsökning, inte kontinuerligt.
• Undersökningen körs var 1 800:e sekund (dvs. var 30:e minut), så åtgärden kan bara starta efter att en undersökning observerat en tillräckligt gammal förberedd transaktion.

Beteende vid körning och schemaläggning

• Justeringsfrekvensen optimize_configurations är var 30:e minut.
• När du aktiverar optimize_configurationsutlöser den en omedelbar justeringskörning och sedan fortsätter schemalagda körningar.
• Hanteringen av open_transaction_threshold är händelsedriven utifrån observationer av förberedda transaktioner. Åtgärden utförs endast när ålderskontrollerna överstiger tröskelvärdet.
• Observationsvyn för förberedda transaktioner för open_transaction_threshold uppdateras var 300:e sekund.

När skapas intelligentperformance schemat efter aktivering?

Schemat intelligentperformance skapas under azure_sys databasen. Dess skapande sker inte omedelbart, utan hanteras av den funktionalitet som sparar den statistik som används av adaptiv autovacuum, inte av den inledande justeringskörningen i sig. Vanligtvis skapas schemat inom 0–30 minuter efter att funktionen har aktiverats.

Du kan aktivera anpassningsbar autovacuum genom att ange adaptive_autovacuum.optimize_configurations till on eller genom att konfigurera adaptive_autovacuum.open_transaction_threshold till ett värde som inte är > noll (dvs. 0). Schemat skapas när funktionen blir aktiv och börjar samla in nödvändig statistik.

Skapandet kan fördröjas eller utebli om vissa förutsättningar inte uppfylls.

Begränsningar och förutsättningar

Båda kontrollerna omfattas av följande krav:

• Instansen måste vara en primär instans.
• PostgreSQL är inte i återställningsläge.
• Beräkningen av servern har minst 4 virtuella kärnor.
• Servern är en vanlig flexibel server, inte ett elastiskt kluster. Funktionen stöds inte i elastiska kluster.
• adaptive_autovacuum.optimize_configurations stöds på större versioner som är större än eller lika med 14.
• adaptive_autovacuum.open_transaction_threshold stöds på större versioner som är större än eller lika med 13.

Granskning och observerbarhet

Systemet registrerar åtgärder från båda kontrollerna i en granskningsvy med namnet intelligentperformance.adaptive_tuning_events.

Schema för vyn

Förväntad logisk form:

• intelligentperformance.adaptive_tuning_events
  • event_details
  • optimizer_type
  • applied_at

Fråga efter den senaste aktiviteten

Om du vill fråga efter den senaste aktiviteten använder du följande frågor:

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;

Händelsetyper och tolkning

Kolumnen optimizer_type anger åtgärdskällan.

adaptive_autovacuum_configuration_changed

Källa:

• optimize_configurations justeringssökväg.

Nyttolastens form:

• JSON-matris med parameterändringsposter, vanligtvis inklusive:
  • server_parameter_name
  • föregående_värde
  • uppdaterat_justerat_värde

Tolkning:

• Visar att justering av autovacuum ändrade serverinställningarna.
• Positivt när efterföljande arbetsbelastningsmått förbättras (död tuppelns tryck, vakuumtakt, svarstid, CPU/I/O).
• Potentiellt negativa när ändringar är frekventa och oscillatoriska och följs av regressioner.

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

Källa:

• open_transaction_threshold väg för riskreducering.

Nyttolastens form:

• JSON-objekt som är nyckelat efter databas, med information om återställningsresultat (till exempel försök till och lyckad GID-återställningsinformation).

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

Tolkning:

• Anger att förberedda transaktioner tvingades att återställas efter att tröskelvärdet överskreds.
• Tillfälliga händelser kan vara ett hälsosamt skyddsbeteende.
• Frekventa händelser indikerar vanligtvis problem med programtransaktionslivscykeln som ska undersökas.

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;

Avgöra om effekten är positiv eller negativ

För optimize_configurations:

1. Identifiera ändringstidsstämplar från adaptive_autovacuum_configuration_changed.
2. Jämför 30 till 120 minuters efterbytesfönster för döda tupplar, vakuum/analysera kadens, svarstid, CPU/I/O.

För open_transaction_threshold:

1. Identifiera orphan_transaction_rollback händelser.
2. Kontrollera om återställningsfrekvensen är låg och stabiliseras.
3. Undersöka programmets beteende om återställningshändelser är beständiga.

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

Bevarande och rensning

Hushållning tar bort äldre poster från granskningslagringen med ett fast och icke-konfigurerbart kvarhållningsfönster på 90 dagar.

Exportera granskningsrader till ditt eget observerbarhetslager för långsiktig trendanalys.

Relaterat innehåll

• Intelligent justering.