Adaptieve autovacuum in Azure Database for PostgreSQL flexibele server

In dit artikel worden de adaptive_autovacuum-parameters beschreven die worden ondersteund door Azure Database voor PostgreSQL Flexible Server:

• adaptive_autovacuum.optimize_configurations: Schakelt automatische afstemming van een reeks autovacuum-instellingen in.
• adaptive_autovacuum.open_transaction_threshold: Hiermee stelt u de leeftijdsdrempel in seconden in om oude voorbereide transacties te detecteren en te beperken.

Hoe elke parameter werkt

adaptive_autovacuum.optimize_configurations

Wanneer u deze parameter instelt op on, voert de afstemmingsservice periodiek het volgende uit:

1. Verzamelt en aggregeert signalen over werklast en tabelstatistieken.
2. Evalueert regelwerkstromen.
3. Berekent mogelijke updates van autovacuumparameters.
4. Hiermee past u updates toe en laadt u de engineconfiguratie opnieuw.
5. Schrijft auditvermeldingen.

Als aan geen regelvoorwaarden wordt voldaan, kan een uitvoering zonder wijzigingen worden afgerond.

Huidige instelbare parameters:

• autovacuum_vacuum_cost_limit
• autovacuum_vacuum_threshold
• autovacuum_vacuum_scale_factor
• autovacuum_vacuum_cost_delay
• autovacuum_analyze_scale_factor

Zichtbaarheid en overschrijvingsgedrag voor aangepaste parameters

Wanneer deze functie een van de vijf doelparameters (autovacuum_vacuum_cost_limit, autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor, , , autovacuum_vacuum_cost_delay) autovacuum_analyze_scale_factorwijzigt:

• Het configuratie-eindpunt van het besturingsvlak (bijvoorbeeld GET Configurations-API of az postgres flexible-server parameter CLI-opdrachtgroep) toont deze effectieve runtimewijzigingen niet.
• Als u de effectieve waarden wilt zien, gebruikt u gegevensvlakquery's voor het PostgreSQL-eindpunt (bijvoorbeeld SHOW <guc_name> of SELECT name, setting FROM pg_settings WHERE name IN (...)).

Gebruiker overschrijft semantiek:

• U kunt een van deze vijf parameters rechtstreeks instellen via de portal, REST API, CLI of een van de ondersteunde SDK's.
• Als u een parameter instelt op dezelfde waarde die het besturingsvlakconfiguratie-eindpunt momenteel retourneert, wordt de bewerking behandeld als een no-op en wordt er geen nieuwe effectieve wijziging toegepast.
• Door de gebruiker ingestelde waarden overschrijven de door de functie toegepaste waarden op het moment dat ze worden toegepast.
• Als adaptive_autovacuum.optimize_configurations ingeschakeld blijft, kunnen latere afstemmingsiteraties opnieuw nieuwe waarden toepassen op basis van de evaluatie van regels.

adaptive_autovacuum.open_transaction_threshold

Met deze parameter wordt de beperking van zwevende voorbereide transacties beheerd:

• 0 betekent uitgeschakeld.
• Groter dan 0 betekent dat het is ingeschakeld, met een drempelwaarde in seconden.

Wanneer deze functie is ingeschakeld en de oudste voorbereide transactie de drempelwaarde overschrijdt, beoordeelt de weestransactie-handler of deze hiervoor in aanmerking komen en kan deze oude voorbereide transacties terugdraaien. De handler werkt de drempelwaarde in het geheugen bij bij parameterwijzigingen, dus gedrag volgt de meest recente waarde.

Belangrijk detail over de timing:

• De functie bepaalt eerst de oudste voorbereide transactietijdstempel.
• Deze detectie gebeurt op basis van polling, niet continu.
• De poll wordt elke 1.800 seconden uitgevoerd (dat wil zeggen, elke 30 minuten), zodat mitigatie pas kan beginnen nadat de poll een voldoende oude voorbereide transactie heeft waargenomen.

Uitvoerings- en planningsgedrag

• De optimize_configurations afstemmingsfrequentie bedraagt 30 minuten.
• Wanneer u optimize_configurations inschakelt, wordt onmiddellijk een afstemmingsrun gestart, waarna geplande runs doorgaan.
• De afhandeling van open_transaction_threshold wordt gebeurtenisgestuurd op basis van waarnemingen van voorbereide transacties. Risicobeperking wordt alleen uitgevoerd wanneer leeftijdscontroles de drempelwaarde overschrijden.
• De voorbereide transactieobservatie voor open_transaction_threshold elke 300 seconden wordt vernieuwd.

Wanneer wordt het intelligentperformance-schema aangemaakt nadat dit is ingeschakeld?

Het intelligentperformance schema wordt gemaakt onder de azure_sys database. De aanmaak ervan gebeurt niet direct en wordt afgehandeld door de functionaliteit die statistieken opslaat die door de adaptieve autovacuum worden gebruikt, in plaats van door de eerste afstemmingsrun zelf. Normaal gesproken wordt het schema binnen 0-30 minuten na het inschakelen van de functie gemaakt.

U kunt adaptive autovacuum inschakelen door adaptive_autovacuum.optimize_configurations in te stellen op on of door adaptive_autovacuum.open_transaction_threshold te configureren op een waarde ongelijk aan nul (dat wil zeggen > 0). Het schema wordt gemaakt zodra de functie actief wordt en begint met het verzamelen van de vereiste statistieken.

Het maken kan worden vertraagd of overgeslagen als niet aan bepaalde vereisten wordt voldaan.

Beperkingen en vereisten

Beide besturingselementen zijn onderworpen aan de volgende vereisten:

• De instantie moet de primaire instantie zijn.
• PostgreSQL bevindt zich niet in de herstelmodus.
• De berekening van de server heeft minimaal 4 vCores.
• De server is een gewone flexibele server, geen elastisch cluster. De functie wordt niet ondersteund in elastische clusters.
• adaptive_autovacuum.optimize_configurations wordt ondersteund voor primaire versies die groter zijn dan of gelijk zijn aan 14.
• adaptive_autovacuum.open_transaction_threshold wordt ondersteund voor primaire versies die groter zijn dan of gelijk zijn aan 13.

Controle en waarneembaarheid

Het systeem registreert acties van beide bedieningselementen in een auditweergave genaamd intelligentperformance.adaptive_tuning_events.

Schema van de weergave

Verwachte logische vorm:

• intelligentperformance.adaptive_tuning_events
  • gebeurtenisdetails
  • optimizer_type
  • applied_at

Query uitvoeren op recente activiteit

Als u recente activiteit wilt opvragen, gebruikt u de volgende query's:

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;

Gebeurtenistypen en interpretatie

De optimizer_type kolom geeft de actiebron aan.

adaptive_autovacuum_configuration_changed

Bron:

• optimize_configurations afstelpad.

Payloadstructuur:

• JSON-matrix van records voor parameterwijziging, meestal inclusief:
  • server_parameter_name
  • vorige_waarde
  • updated_tuned_value

Interpretatie:

• Geeft aan dat door autovacuum-afstemming de serverinstellingen zijn gewijzigd.
• Positief wanneer de volgende metrische gegevens van de werkbelasting verbeteren (dode tupledruk, vacuümfrequentie, latentie, CPU/IO).
• Potentieel negatief wanneer wijzigingen frequent en oscillatory zijn en worden gevolgd door regressies.

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

Bron:

• open_transaction_threshold risicobeperkingspad.

Payloadstructuur:

• JSON-object dat is gesleuteld door de database, met details van het terugdraairesultaat (bijvoorbeeld geprobeerd en geslaagde GID-terugdraaigegevens).

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

Interpretatie:

• Geeft aan dat voorbereide transacties geforceerd zijn teruggedraaid na het overschrijden van de drempelwaarde.
• Incidentele gebeurtenissen kunnen gezond beschermend gedrag zijn.
• Frequente gebeurtenissen geven meestal problemen aan met de levenscyclus van toepassingen die moeten worden onderzocht.

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;

Bepalen of de impact positief of negatief is

Voor optimize_configurations:

1. Wijzigingstijdstempels van adaptive_autovacuum_configuration_changedidentificeren.
2. Vergelijk vensters van 30 tot 120 minuten na wijzigingen voor dode tuples, vacuum/analysefrequentie, latentie en CPU/IO.

Voor open_transaction_threshold:

1. Identificeer orphan_transaction_rollback gebeurtenissen.
2. Controleer of de terugdraaifrequentie laag en stabiel is.
3. Onderzoek het gedrag van toepassingen als terugdraaigebeurtenissen permanent zijn.

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

Retentie en huishouding

Opschoning verwijdert oudere records uit de auditopslag met een vaste, niet-configureerbare bewaartermijn van 90 dagen.

Voor een langetermijntrendanalyse exporteert u controlerijen naar uw eigen waarneembaarheidsarchief.

Verwante inhoud

• Intelligente afstemming.