Autovacuum adaptatif dans Azure Database pour PostgreSQL : Serveur flexible

Cet article documente les paramètres adaptive_autovacuum pris en charge par Azure Database pour PostgreSQL - Serveur flexible :

• adaptive_autovacuum.optimize_configurations : Active l’ajustement automatique d’une série de paramètres d’autovacuum.
• adaptive_autovacuum.open_transaction_threshold: définit le seuil d’âge en secondes pour détecter et atténuer les anciennes transactions préparées.

Fonctionnement de chaque paramètre

adaptive_autovacuum.optimize_configurations

Lorsque vous définissez ce paramètre sur on, le service de réglage effectue périodiquement les opérations suivantes :

1. Collecte et agrège les signaux de charge de travail et de statistiques de table.
2. Évalue les flux de travail de règle.
3. Calcule les mises à jour des paramètres autovacuum candidats.
4. Applique les mises à jour et recharge la configuration du moteur.
5. Écrit les entrées d’audit.

Si aucune condition de règle n’est remplie, une exécution peut se terminer sans aucune modification.

Paramètres paramétrables actuels :

• autovacuum_vacuum_cost_limit
• autovacuum_vacuum_threshold
• autovacuum_vacuum_scale_factor
• autovacuum_vacuum_cost_delay
• autovacuum_analyze_scale_factor

Visibilité et comportement de remplacement pour les paramètres paramétrés

Lorsque cette fonctionnalité modifie l’un des cinq paramètres cibles (autovacuum_vacuum_cost_limit, autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor, autovacuum_vacuum_cost_delayautovacuum_analyze_scale_factor) :

• Le point de terminaison Configurations du plan de contrôle (par exemple, l’API GET Configurations ou az postgres flexible-server parameter le groupe de commandes CLI) n’affiche pas ces modifications d’exécution effectives.
• Pour afficher les valeurs effectives, utilisez des requêtes de plan de données sur le point de terminaison PostgreSQL (par exemple, SHOW <guc_name> ou SELECT name, setting FROM pg_settings WHERE name IN (...)).

Sémantique de priorité définie par l’utilisateur :

• Vous pouvez définir l’un de ces cinq paramètres directement via le portail, l’API REST, l’interface CLI ou l’un des kits SDK pris en charge.
• Si vous définissez un paramètre sur la même valeur que celle que le point de terminaison Configurations du plan de contrôle renvoie actuellement, l’opération est considérée comme sans effet et aucun nouveau changement effectif n’est appliqué.
• Les valeurs définies par l’utilisateur remplacent les valeurs appliquées par les fonctionnalités au moment où elles sont appliquées.
• Si adaptive_autovacuum.optimize_configurations elle reste activée, les itérations de réglage ultérieures peuvent appliquer de nouvelles valeurs en fonction de l’évaluation des règles.

adaptive_autovacuum.open_transaction_threshold

Ce paramètre contrôle le mécanisme d’atténuation des transactions préparées orphelines :

• 0 signifie désactivé.
• Une valeur supérieure à 0 indique que l’option est activée, avec un seuil exprimé en secondes.

Lorsqu’elle est activée, si la transaction préparée la plus ancienne dépasse le seuil, le gestionnaire de transactions orphelins évalue l’éligibilité et peut restaurer les anciennes transactions préparées. Le gestionnaire met à jour son seuil en mémoire sur les modifications de paramètres, de sorte que le comportement suit la dernière valeur.

Détail important concernant le timing :

• La fonctionnalité détermine d’abord l’horodatage de transaction préparé le plus ancien.
• Cette détection est basée sur des sondages, et non continue.
• Le sondage s’exécute toutes les 1 800 secondes (c’est-à-dire toutes les 30 minutes), de sorte que l’atténuation ne peut démarrer qu’après qu’un sondage observe une transaction préparée assez ancienne.

Comportement d’exécution et de planification

• La fréquence d'ajustement de optimize_configurations est de 30 minutes.
• Lorsque vous activez optimize_configurations, il déclenche une exécution de réglage immédiate, puis les exécutions planifiées continuent.
• La gestion de open_transaction_threshold est pilotée par des événements, à partir d’observations de transactions préparées. La mesure d’atténuation ne s’exécute que lorsque les contrôles d’âge dépassent le seuil.
• L’observation de la transaction préparée pour open_transaction_threshold est actualisée toutes les 300 secondes.

Quand le intelligentperformance schéma est-il créé après l’activation ?

Le intelligentperformance schéma est créé sous la azure_sys base de données. Sa création n’est pas immédiate et est gérée par la fonctionnalité qui conserve les statistiques utilisées par le nettoyage automatique adaptatif, plutôt que par l’exécution initiale du réglage. En règle générale, le schéma est créé dans les 0 à 30 minutes après l’activation de la fonctionnalité.

Vous pouvez activer le nettoyage automatique adaptatif en définissant adaptive_autovacuum.optimize_configurations ou en configurant on sur une valeur différente de zéro (c’est-à-dire adaptive_autovacuum.open_transaction_threshold> 0). Le schéma est créé une fois la fonctionnalité active et commence à collecter les statistiques requises.

La création peut être retardée ou ignorée si certaines conditions préalables ne sont pas remplies.

Limitations et conditions préalables

Les deux contrôles sont soumis aux exigences suivantes :

• L’instance doit être une instance primaire.
• PostgreSQL n’est pas en mode de récupération.
• Le calcul du serveur a au moins 4 vCores.
• Le serveur est un serveur flexible standard, et non un cluster élastique. La fonctionnalité n’est pas prise en charge sur les clusters élastiques.
• adaptive_autovacuum.optimize_configurations est pris en charge sur les versions majeures supérieures ou égales à 14.
• adaptive_autovacuum.open_transaction_threshold est pris en charge sur les versions majeures supérieures ou égales à 13.

Audit et observabilité

Le système enregistre les actions des deux contrôles dans une vue d’audit nommée intelligentperformance.adaptive_tuning_events.

Schéma de la vue

Forme logique attendue :

• intelligentperformance.adaptive_tuning_events
  • Détails de l’événement
  • type_optimiseur
  • applied_at

Rechercher une activité récente

Pour interroger l’activité récente, utilisez les requêtes suivantes :

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;

Types d’événements et interprétation

La optimizer_type colonne indique la source d’action.

adaptive_autovacuum_configuration_changed

Source :

• optimize_configurations parcours de réglage.

Schéma de la charge utile :

• Tableau JSON d’enregistrements de modification de paramètre, notamment :
  • server_parameter_name
  • valeur_précédente
  • updated_tuned_value

Interprétation :

• Indique que le réglage d’autovacuum a modifié les paramètres du serveur.
• Positif si les métriques de charge de travail s’améliorent par la suite (pression des tuples morts, fréquence des opérations de nettoyage automatique, latence, processeur/E/S).
• Potentiellement négatif lorsque les changements sont fréquents et oscillants et sont suivis de régressions.

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

Source :

• open_transaction_threshold chemin d’atténuation.

Schéma de la charge utile :

• Objet JSON indexé par base de données, avec les détails du résultat de l’annulation (par exemple, des informations sur les tentatives d’annulation de GID et les annulations de GID réussies).

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

Interprétation :

• Indique que les transactions préparées ont été annulées de force après avoir dépassé le seuil.
• Les événements occasionnels peuvent être un comportement protecteur sain.
• Les événements fréquents indiquent généralement des problèmes de cycle de vie des transactions d’application qui doivent être examinés.

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;

Déterminer si l’impact est positif ou négatif

Pour optimize_configurations:

1. Identifier les horodatages des modifications à partir de adaptive_autovacuum_configuration_changed.
2. Comparez des fenêtres post-changement de 30 à 120 minutes pour les tuples morts, la fréquence des opérations de nettoyage/d’analyse, la latence et le processeur/les E/S.

Pour open_transaction_threshold:

1. Identifier les orphan_transaction_rollback événements.
2. Vérifiez si la fréquence des retours en arrière est faible et se stabilise.
3. Analysez le comportement de l’application si les événements d’annulation persistent.

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

Rétention et maintenance

La tâche de nettoyage supprime les enregistrements les plus anciens du stockage d’audit selon une période de rétention fixe et non configurable de 90 jours.

Pour une analyse des tendances à plus long terme, exportez les entrées d’audit vers votre propre plateforme d’observabilité.

Contenu connexe

• Réglage intelligent.