Adaptives Autovacuum in Azure Database for PostgreSQL – Flexibler Server

In diesem Artikel werden die von Azure Database for PostgreSQL – Flexibler Server unterstützten adaptive_autovacuum Parameter dokumentiert:

• adaptive_autovacuum.optimize_configurations: Aktiviert die automatische Optimierung einer Reihe von Autovacuum-Einstellungen.
• adaptive_autovacuum.open_transaction_threshold: Legt den Altersschwellenwert in Sekunden fest, um alte vorbereitete Transaktionen zu erkennen und abzumildern.

Funktionsweise der einzelnen Parameter

adaptive_autovacuum.optimize_configurations

Wenn Sie diesen Parameter auf on setzen, führt der Optimierungsdienst regelmäßig Folgendes aus:

1. Erfasst und aggregiert Arbeitsauslastungs- und Tabellenstatistiksignale.
2. Wertet Regelworkflows aus.
3. Berechnet mögliche Aktualisierungen der Autovacuum-Parameter.
4. Wendet Aktualisierungen an und lädt die Engine-Konfiguration neu.
5. Schreibt Auditprotokolleinträge.

Wenn keine Regelbedingungen erfüllt sind, kann ein Durchlauf ohne Änderungen enden.

Aktuelle tunbare Parameter:

• autovacuum_vacuum_cost_limit
• autovacuum_vacuum_threshold
• autovacuum_vacuum_scale_factor
• autovacuum_vacuum_cost_delay
• autovacuum_analyze_scale_factor

Sichtbarkeits- und Außerkraftsetzungsverhalten für abgestimmte Parameter

Wenn dieses Feature einen der fünf Zielparameter ändert (autovacuum_vacuum_cost_limit, autovacuum_vacuum_threshold, , autovacuum_vacuum_scale_factor, autovacuum_vacuum_cost_delay): autovacuum_analyze_scale_factor

• Der Endpunkt "Konfigurationen" der Steuerungsebene (z. B. GET-Konfigurations-API oder az postgres flexible-server parameter CLI-Befehlsgruppe) zeigt diese effektiven Laufzeitänderungen nicht an.
• Um die effektiven Werte anzuzeigen, verwenden Sie Datenebenenabfragen für den PostgreSQL-Endpunkt (z. B. SHOW <guc_name> oder SELECT name, setting FROM pg_settings WHERE name IN (...)).

Benutzerüberschreibungssemantik:

• Sie können jeden dieser fünf Parameter direkt über das Portal, die REST-API, die CLI oder eine der unterstützten SDKs festlegen.
• Wenn Sie einen Parameter auf denselben Wert festlegen, den der Endpunkt "Konfigurationen" der Steuerungsebene derzeit zurückgibt, wird der Vorgang als no-op behandelt, und es wird keine neue effektive Änderung angewendet.
• Vom Benutzer festgelegte Werte setzen die vom Feature angewendeten Werte zum Zeitpunkt der Anwendung außer Kraft.
• Wenn adaptive_autovacuum.optimize_configurations sie aktiviert bleibt, können spätere Optimierungsiterationen neue Werte basierend auf der Regelauswertung erneut anwenden.

adaptive_autovacuum.open_transaction_threshold

Dieser Parameter steuert die Minderung von Problemen mit verwaisten vorbereiteten Transaktionen:

• 0 bedeutet deaktiviert.
• Ein Wert größer als 0 bedeutet, dass die Funktion mit einem Schwellenwert in Sekunden aktiviert ist.

Wenn diese Funktion aktiviert ist und die älteste vorbereitete Transaktion den Schwellenwert überschreitet, prüft der Handler für verwaiste Transaktionen, ob sie infrage kommen, und kann alte vorbereitete Transaktionen zurückrollen. Der Handler aktualisiert seinen Speicherschwellenwert bei Parameteränderungen, sodass das Verhalten auf den neuesten Wert folgt.

Wichtige Zeitangaben:

• Das Feature bestimmt zuerst den ältesten vorbereiteten Transaktionszeitstempel.
• Diese Erkennung ist umfragebasiert, nicht fortlaufend.
• Die Abfrage erfolgt alle 1.800 Sekunden (d. h. alle 30 Minuten), sodass eine Gegenmaßnahme erst eingeleitet werden kann, nachdem bei einer Abfrage eine vorbereitete Transaktion erkannt wurde, die alt genug ist.

Laufzeit- und Planungsverhalten

• Der Optimierungsrhythmus für optimize_configurations beträgt 30 Minuten.
• Wenn Sie optimize_configurations aktivieren, wird sofort ein Optimierungslauf gestartet, danach werden die geplanten Läufe weiterhin ausgeführt.
• Die Behandlung von open_transaction_threshold erfolgt ereignisgesteuert auf Grundlage von Beobachtungen vorbereiteter Transaktionen. Die Abhilfemaßnahme wird nur ausgeführt, wenn die Altersprüfungen den Schwellenwert überschreiten.
• Die Beobachtung vorbereiteter Transaktionen für open_transaction_threshold wird alle 300 Sekunden aktualisiert.

Wann wird das intelligentperformance Schema nach dem Aktivieren erstellt?

Das intelligentperformance Schema wird unter der azure_sys Datenbank erstellt. Seine Erstellung erfolgt nicht unmittelbar, sondern durch die Funktionalität, die die vom adaptiven Autovacuum verwendeten Statistiken dauerhaft speichert, und nicht durch den ersten Tuning-Durchlauf selbst. Normalerweise wird das Schema innerhalb von 0 bis 30 Minuten nach dem Aktivieren des Features erstellt.

Sie können adaptives Autovacuum aktivieren, indem Sie adaptive_autovacuum.optimize_configurations auf on setzen oder indem Sie adaptive_autovacuum.open_transaction_threshold auf einen Wert ungleich null festlegen (d. h. > 0). Das Schema wird erstellt, sobald das Feature aktiv wird und mit der Erfassung der erforderlichen Statistiken beginnt.

Die Erstellung kann verzögert oder übersprungen werden, wenn bestimmte Voraussetzungen nicht erfüllt sind.

Einschränkungen und Voraussetzungen

Beide Steuerelemente unterliegen den folgenden Anforderungen:

• Die Instanz muss eine primäre Instanz sein.
• PostgreSQL befindet sich nicht im Wiederherstellungsmodus.
• Die Berechnung des Servers weist mindestens 4 vCores auf.
• Der Server ist ein normaler flexibler Server, kein elastischer Cluster. Das Feature wird für elastische Cluster nicht unterstützt.
• adaptive_autovacuum.optimize_configurations wird für Hauptversionen unterstützt, die größer oder gleich 14 sind.
• adaptive_autovacuum.open_transaction_threshold wird für Hauptversionen unterstützt, die größer oder gleich 13 sind.

Überwachung und Beobachtbarkeit

Das System zeichnet Aktionen aus beiden Steuerelementen in einer Überwachungsansicht mit dem Namen intelligentperformance.adaptive_tuning_eventsauf.

Schema der Ansicht

Erwartete logische Form:

• intelligentperformance.adaptive_tuning_events
  • Veranstaltungsdetails
  • optimizer_type
  • applied_at

Abfrage nach der letzten Aktivität

Verwenden Sie zum Abfragen der letzten Aktivität die folgenden Abfragen:

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;

Ereignistypen und Interpretationen

Die optimizer_type Spalte gibt die Aktionsquelle an.

adaptive_autovacuum_configuration_changed

Quelle:

• optimize_configurations Optimierungspfad.

Nutzlastform:

• JSON-Array von Parameteränderungsdatensätzen, in der Regel einschließlich:
  • server_parameter_name
  • vorheriger_Wert
  • aktualisierter_abgestimmter_Wert

Interpretation:

• Gibt an, dass das Autovacuum-Tuning die Servereinstellungen geändert hat.
• Positiv, wenn sich nachfolgende Workload-Metriken verbessern (Dead Tuple Pressure, Vacuum Cadence, Latenz, CPU/IO).
• Potenziell negativ, wenn Änderungen häufig und oszillierend sind und regressionen folgen.

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

Quelle:

• open_transaction_threshold Mitigationspfad.

Nutzlastform:

• JSON-Objekt mit Schlüsseln pro Datenbank und Details zum Rollback-Ergebnis (z. B. Informationen zu versuchten und erfolgreichen GID-Rollbacks).

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

Interpretation:

• Gibt an, dass vorbereitete Transaktionen nach Überschreiten des Schwellenwerts zwangsweise zurückgesetzt wurden.
• Gelegentliche Ereignisse können ein gesundes Schutzverhalten sein.
• Häufige Ereignisse deuten in der Regel auf Anwendungstransaktionslebenszyklus-Probleme hin, die untersucht werden sollten.

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;

Bestimmen, ob die Auswirkung positiv oder negativ ist

Für optimize_configurations:

1. Identifizieren Sie Änderungszeitstempel aus adaptive_autovacuum_configuration_changed.
2. Vergleichen Sie 30- bis 120-minütige Zeitfenster nach der Änderung hinsichtlich toter Tupel, der Vacuum-/Analyze-Taktung, der Latenz sowie der CPU-/I/O-Auslastung.

Für open_transaction_threshold:

1. Identifizieren von orphan_transaction_rollback Ereignissen.
2. Überprüfen Sie, ob die Rollbackhäufigkeit niedrig und stabil ist.
3. Untersuchen Sie das Anwendungsverhalten, wenn Rollbackereignisse persistent sind.

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

Aufbewahrung und Haushaltung

Die Hausverwaltung entfernt ältere Datensätze aus dem Überwachungsspeicher mithilfe eines festen und nicht konfigurierten Aufbewahrungsfensters von 90 Tagen.

Für längerfristige Trendanalysen exportieren Sie Audit-Zeilen in Ihren eigenen Observability-Speicher.

Verwandte Inhalte

• Intelligente Optimierung.