Réglage du nettoyage automatique dans Azure Database pour PostgreSQL

Cet article fournit une vue d’ensemble de la fonctionnalité d'autovacuum pour Azure Database pour PostgreSQL ainsi que des guides de dépannage disponibles pour surveiller le gonflement de la base de données et les obstacles à l'autovacuum. Il fournit également des informations sur la proximité de la base de données par rapport à une situation d'urgence ou de débordement.

Qu’est-ce que l'autovacuum ?

Le nettoyage automatique est un processus en arrière-plan de PostgreSQL qui nettoie automatiquement les tuples morts et met à jour les statistiques. Il permet de maintenir les performances de la base de données en exécutant automatiquement deux tâches de maintenance clés :

• VACUUM : récupère de l’espace dans les fichiers de la base de données en supprimant les tuples morts et en marquant cet espace comme réutilisable par PostgreSQL. Elle ne réduit pas nécessairement la taille physique des fichiers de base de données sur le disque. Pour retourner de l’espace au système d’exploitation, utilisez des opérations qui réécriront la table (par exemple, VACUUM FULL ou pg_repack), qui ont des considérations supplémentaires telles que des verrous exclusifs ou des fenêtres de maintenance.
• ANALYZE : collecte les statistiques de table et d’index que le planificateur de requêtes PostgreSQL utilise pour choisir des plans d’exécution efficaces.

Pour vous assurer que l’autovacuum fonctionne correctement, définissez le paramètre du serveur autovacuum sur ON. Quand il est activé, PostgreSQL décide automatiquement quand exécuter une opération VACUUM ou ANALYZE sur une table, ce qui garantit que la base de données reste efficace et optimisée.

Éléments internes du nettoyage automatique

Autovacuum lit les pages à la recherche de tuples morts. S’il ne trouve pas de tuples morts, le nettoyage automatique ignore la page. Quand le nettoyage automatique trouve des tuples morts, il les supprime. Le coût est basé sur les paramètres suivants :

La quantité de travail effectuée par levacuum automatique dépend de deux paramètres :

Dans toutes les versions actuellement prises en charge de PostgreSQL, la valeur par défaut est autovacuum_vacuum_cost_limit 200 (en fait, définie sur -1, ce qui le rend égal à la valeur de la normale vacuum_cost_limit, qui est par défaut 200).

La valeur par défaut pour autovacuum_vacuum_cost_delay est de 2 millisecondes dans PostgreSQL versions 12 et ultérieures (il s'agissait de 20 millisecondes dans la version 11).

Limite d’utilisation de la mémoire tampon (PostgreSQL 16+)

À compter de PostgreSQL version 16, vous pouvez utiliser le paramètre pour contrôler l’utilisation vacuum_buffer_usage_limit de la mémoire pendant les opérations VACUUM, ANALYZE et autovacuum.

Ce paramètre permet d’empêcher VACUUM et auto-vacuum de supprimer trop de pages utiles depuis les buffers partagés, ce qui peut améliorer les performances globales de la base de données pendant les opérations de maintenance. La valeur par défaut est généralement définie en fonction de shared_buffers, et vous pouvez la configurer pour équilibrer les performances d’aspiration avec les besoins des opérations régulières de la base de données.

Seuil maximal pour le nettoyage automatique (PostgreSQL 18+)

À compter de PostgreSQL version 18, vous pouvez utiliser le autovacuum_vacuum_max_threshold paramètre pour définir une limite supérieure sur le nombre de mises à jour de tuple ou de suppressions qui déclenchent le nettoyage automatique.

Ce paramètre est particulièrement utile pour les tables volumineuses où le déclenchement basé sur le facteur d’échelle par défaut peut entraîner un délai trop long avant l'exécution d'autovacuum.

Le nettoyage automatique se réveille 50 fois (50*20 ms=1 000 ms) toutes les secondes. À chaque réveil, le nettoyage automatique lit 200 pages.

Cela signifie qu'en une seconde autovacuum peut effectuer :

• ~80 Mo/s [ (200 pages/vacuum_cost_page_hit) * 50 * 8 Ko par page] si toutes les pages contenant des tuples morts sont trouvées dans des mémoires tampons partagées.
• ~8 Mo/s [ (200 pages/vacuum_cost_page_miss) * 50 * 8 Ko par page] si toutes les pages contenant des tuples morts sont lues sur le disque.
• ~4 Mo/s [ (200 pages/vacuum_cost_page_dirty) * 50 * 8 Ko par page] ; le nettoyage automatique peut écrire jusqu’à 4 Mo/s.

Surveiller le nettoyage automatique

Azure Database pour PostgreSQL fournit les métriques suivantes pour le suivi de l'autovacuum.

Vous pouvez utiliser des métriques de nettoyage automatique pour surveiller et ajuster des performances de nettoyage automatique pour Azure Database pour PostgreSQL – Serveur flexible. Chaque métrique est émise à des intervalles de 30 minutes, puis conservée pendant une période de rétention allant jusqu’à 93 jours. Vous pouvez créer des alertes pour des métriques spécifiques, et vous pouvez fractionner, puis filtrer des données de métriques à l’aide de la dimension DatabaseName.

Comment activer les mesures du nettoyage automatique

• Les métriques de nettoyage automatique sont désactivées par défaut.
• Pour activer ces métriques, définissez le paramètre serveur metrics.autovacuum_diagnostics sur ON.
• Ce paramètre est dynamique et ne nécessite donc pas de redémarrage de l’instance.

Liste des mesures de nettoyage automatique

Considérations pour l'utilisation des métriques d'autovacuum

• Les métriques de nettoyage automatique qui utilisent la dimension DatabaseName ont une limite de 30 bases de données.
• Sur la référence SKU Burstable, la limite est de 10 bases de données pour les métriques qui utilisent la dimension DatabaseName.
• La limite de dimension DatabaseName est appliquée à la colonne OID, qui correspond à l’ordre de création de la base de données.

Pour plus d'informations, consultez Métriques Autovacuum.

Utilisez les requêtes suivantes pour surveiller le nettoyage automatique :

select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;

Les colonnes suivantes vous aident à déterminer si le nettoyage automatique rattrape l’activité de table :

Déclenchement d’un nettoyage automatique

Une action de nettoyage automatique (ANALYZE ou VACUUM) se déclenche lorsque le nombre de tuples morts dépasse un nombre particulier. Ce nombre dépend de deux facteurs : le nombre total de lignes d’une table, ainsi qu’un seuil fixe. ANALYZE est lancé par défaut lorsque 10 % de modifications sur la table plus 50 lignes se produisent, tandis que VACUUM est lancé lorsque 20 % de modifications sur la table plus 50 lignes se produisent. Étant donné que le seuil VACUUM est deux fois plus élevé que le seuil d’ANALYSE , ANALYZE se déclenche plus tôt que VACUUM.

Pour PostgreSQL versions 13 et ultérieures, ANALYZE se déclenche par défaut lorsque 20% de la table plus 1 000 insertions de lignes se produisent.

Les équations exactes pour chaque action sont les suivantes :

• Autoanalyze = autovacuum_analyze_scale_factor * tuples + autovacuum_analyze_threshold ou autovacuum_vacuum_insert_scale_factor * tuples + autovacuum_vacuum_insert_threshold (pour PostgreSQL versions 13 et ultérieures)
• Nettoyage automatique = autovacuum_vacuum_scale_factor * tuples + autovacuum_vacuum_threshold

Par exemple, si vous avez une table avec 100 lignes, les équations suivantes s’affichent lorsque les actions d’analyse et de vide se déclenchent :

Pour les mises à jour et les suppressions : Autoanalyze = 0.1 * 100 + 50 = 60Autovacuum = 0.2 * 100 + 50 = 70

ANALYZE est déclenché après que 60 lignes sont modifiées dans une table, et VACUUM est déclenché lorsque 70 lignes sont modifiées dans une table.

Pour les insertions : Autoanalyze = 0.2 * 100 + 1000 = 1020

ANALYZE se déclenche après l'insertion de 1 020 lignes dans une table.

Voici la description des paramètres utilisés dans l’équation :

Utilisez la requête suivante pour lister les tables d’une base de données et identifier celles qui sont qualifiées pour le processus de nettoyage automatique :

 SELECT *
      ,n_dead_tup > av_threshold AS av_needed
      ,CASE
        WHEN reltuples > 0
          THEN round(100.0 * n_dead_tup / (reltuples))
        ELSE 0
        END AS pct_dead
    FROM (
      SELECT N.nspname
        ,C.relname
        ,pg_stat_get_tuples_inserted(C.oid) AS n_tup_ins
        ,pg_stat_get_tuples_updated(C.oid) AS n_tup_upd
        ,pg_stat_get_tuples_deleted(C.oid) AS n_tup_del
        ,pg_stat_get_live_tuples(C.oid) AS n_live_tup
        ,pg_stat_get_dead_tuples(C.oid) AS n_dead_tup
        ,C.reltuples AS reltuples
        ,round(current_setting('autovacuum_vacuum_threshold')::INTEGER + current_setting('autovacuum_vacuum_scale_factor')::NUMERIC * C.reltuples) AS av_threshold
        ,date_trunc('minute', greatest(pg_stat_get_last_vacuum_time(C.oid), pg_stat_get_last_autovacuum_time(C.oid))) AS last_vacuum
        ,date_trunc('minute', greatest(pg_stat_get_last_analyze_time(C.oid), pg_stat_get_last_autoanalyze_time(C.oid))) AS last_analyze
      FROM pg_class C
      LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
      WHERE C.relkind IN (
          'r'
          ,'t'
          )
        AND N.nspname NOT IN (
          'pg_catalog'
          ,'information_schema'
          )
        AND N.nspname !~ '^pg_toast'
      ) AS av
    ORDER BY av_needed DESC ,n_dead_tup DESC;

Problèmes courants liés au nettoyage automatique

Passez en revue la liste suivante des problèmes courants liés au processus de nettoyage automatique.

Non-suivi du rythme d’un serveur très sollicité

Le processus de nettoyage automatique estime le coût de chaque opération d’E/S, accumule un total pour chaque opération qu’il effectue et s’interrompt une fois la limite supérieure du coût atteinte. Le processus utilise deux paramètres de serveur : autovacuum_vacuum_cost_delay et autovacuum_vacuum_cost_limit.

Par défaut, autovacuum_vacuum_cost_limit est défini sur -1, ce qui signifie que la limite de coût du nettoyage automatique utilise la même valeur que le vacuum_cost_limit paramètre. La valeur par défaut est vacuum_cost_limit 200. vacuum_cost_limit représente le coût d’un aspirateur manuel.

Si vous définissez autovacuum_vacuum_cost_limit sur -1, autovacuum utilise le vacuum_cost_limit paramètre. Si vous définissez autovacuum_vacuum_cost_limit sur une valeur supérieure à -1, autovacuum utilise le autovacuum_vacuum_cost_limit paramètre.

Si l'autovacuum n'arrive pas à suivre, envisagez de modifier les paramètres suivants :

Exécution continue du nettoyage automatique

Si le nettoyage automatique s’exécute en continu, il peut affecter l’utilisation du processeur et des E/S sur le serveur. Voici quelques raisons possibles :

maintenance_work_mem

Le démon autovacuum utilise autovacuum_work_mem, qui est défini -1 par défaut. Ce paramètre par défaut signifie autovacuum_work_mem qu’il utilise la même valeur que le maintenance_work_mem paramètre. Cet article suppose que autovacuum_work_mem est défini à -1 et que le démon de nettoyage automatique utilise maintenance_work_mem pour son fonctionnement.

Si maintenance_work_mem elle est faible, vous pouvez l’augmenter jusqu’à 2 Go sur une instance de serveur flexible Azure Database pour PostgreSQL. En règle générale, 50 Mo sont alloués à maintenance_work_mem pour chaque Go de RAM.

Grand nombre de bases de données

Le nettoyage automatique tente de démarrer un Worker sur chaque base de données toutes les autovacuum_naptime secondes.

Par exemple, si un serveur comporte 60 bases de données et que autovacuum_naptime est défini sur 60 secondes, le Worker de nettoyage automatique démarre toutes les secondes [autovacuum_naptime/Nombre de bases de données].

S’il existe plus de bases de données dans un cluster, augmentez autovacuum_naptime. En même temps, rendez le processus de nettoyage automatique plus agressif en augmentant les autovacuum_cost_limit paramètres et en réduisant les autovacuum_cost_delay paramètres. Vous pouvez également passer autovacuum_max_workers de la valeur par défaut de 3 à 4 ou 5.

Erreurs de mémoire insuffisante

Les valeurs excessivement agressives maintenance_work_mem peuvent entraîner régulièrement des erreurs de mémoire insuffisante dans le système. Comprendre la RAM disponible sur le serveur avant de modifier le maintenance_work_mem paramètre.

Le nettoyage automatique provoque trop d’interruptions

Si le nettoyage automatique consomme trop de ressources, essayez les actions suivantes :

Paramètres de nettoyage automatique

Évaluez les paramètres autovacuum_vacuum_cost_delay, autovacuum_vacuum_cost_limitet autovacuum_max_workers. Une définition incorrecte des paramètres de nettoyage automatique peut aboutir à des scénarios où le nettoyage automatique provoque trop d’interruptions.

Si le nettoyage automatique provoque trop d’interruptions, envisagez les actions suivantes :

• Augmentez et réduisez autovacuum_vacuum_cost_delay si vous le définissez autovacuum_vacuum_cost_limit plus haut que la valeur par défaut de 200.
• Réduisez le nombre de autovacuum_max_workers si vous définissez-le plus haut que la valeur par défaut de 3.

Trop de Workers de nettoyage automatique

L’augmentation du nombre de Workers de nettoyage automatique n’augmente pas nécessairement la vitesse du nettoyage. N’utilisez pas un grand nombre de travailleurs du nettoyage automatique.

L’augmentation du nombre de travailleurs du nettoyage automatique entraîne davantage de consommation de mémoire. En fonction de la valeur de maintenance_work_mem, cela peut entraîner une dégradation des performances.

Chaque processus Worker de nettoyage automatique obtient seulement (1/autovacuum_max_workers) de la autovacuum_cost_limit totale, de sorte qu’avoir un nombre élevé de Workers entraîne le fonctionnement plus lent de chacun d’eux.

Si vous augmentez le nombre de travailleurs, augmentez autovacuum_vacuum_cost_limit et/ou diminuez autovacuum_vacuum_cost_delay pour accélérer le processus de vide.

Toutefois, si vous définissez le paramètre au niveau de la table avec les paramètres autovacuum_vacuum_cost_delay ou autovacuum_vacuum_cost_limit, les workers s'exécutant sur ces tables sont exemptés d’être pris en compte dans l’algorithme d’équilibrage [autovacuum_cost_limit/autovacuum_max_workers].

Protection contre la saturation des ID de transaction (TXID) du nettoyage automatique

Lorsqu’une base de données s’exécute dans une protection wraparound d’ID de transaction, un message d’erreur semblable à l’erreur suivante s’affiche :

Database isn't accepting commands to avoid wraparound data loss in database 'xx'
Stop the postmaster and vacuum that database in single-user mode.

Le problème wraparound se produit lorsque la base de données n’est pas vide ou lorsque le nettoyage automatique ne supprime pas trop de tuples morts.

Les raisons possibles de ce problème incluent les raisons suivantes :

Charge de travail élevée

Une charge de travail lourde provoque trop de tuples morts dans une courte période, ce qui rend difficile pour l'autovacuum de rattraper son retard. Les tuples morts dans le système s’accumulent sur une période, conduisant à une dégradation des performances des requêtes et à une situation de saturation. Une des raisons de cette situation peut être que les paramètres du nettoyage automatique ne sont pas correctement définis et qu’il ne suive donc pas le rythme d’un serveur très sollicité.

Transactions de longue durée

Toute transaction longue dans le système ne permet pas au processus d'autovacuum de supprimer les tuples morts. Ce sont des bloqueurs du processus de nettoyage. La suppression des transactions de longue durée libère des tuples morts pour pouvoir les supprimer lorsque le nettoyage automatique s’exécute.

Les transactions de longue durée peuvent être détectées à l’aide de la requête suivante :

    SELECT pid, age(backend_xid) AS age_in_xids,
    now () - xact_start AS xact_age,
    now () - query_start AS query_age,
    state,
    query
    FROM pg_stat_activity
    WHERE state != 'idle'
    ORDER BY 2 DESC
    LIMIT 10;

Instructions préparées

S’il existe des instructions préparées qui ne sont pas validées, elles empêchent l'autovacuum de supprimer les tuples morts. La requête suivante permet de trouver les instructions préparées non commitées :

    SELECT gid, prepared, owner, database, transaction
    FROM pg_prepared_xacts
    ORDER BY age(transaction) DESC;

Utilisez COMMIT PREPARED ou ROLLBACK PREPARED pour valider ou restaurer ces instructions.

Emplacements de réplication non utilisés

Les emplacements de réplication inutilisés empêchent le nettoyage automatique de revendiquer des tuples morts. La requête suivante permet d’identifier les emplacements de réplication non utilisés :

    SELECT slot_name, slot_type, database, xmin
    FROM pg_replication_slots
    ORDER BY age(xmin) DESC;

Utilisez pg_drop_replication_slot() pour supprimer les emplacements de réplication non utilisés.

Quand la base de données s’exécute dans une protection contre la saturation des ID de transaction, recherchez les éventuels bloqueurs mentionnés précédemment et supprimez-les manuellement pour que le nettoyage automatique continue et se termine. Vous pouvez également augmenter la vitesse du nettoyage automatique en définissant autovacuum_cost_delay sur 0 et en augmentant autovacuum_cost_limit à une valeur supérieure à 200. Cependant, les modifications apportées à ces paramètres ne s’appliquent pas aux Workers existants du nettoyage automatique. Redémarrez la base de données ou tuez manuellement les Workers existants pour appliquer les modifications des paramètres.

Exigences spécifiques à des tables

Vous pouvez définir des paramètres de nettoyage automatique pour des tables individuelles. Ces paramètres sont particulièrement importants pour les petites et grandes tables. Par exemple, pour une petite table qui contient seulement 100 lignes, le nettoyage automatique déclenche l’opération VACUUM lorsque 70 lignes changent (comme calculé précédemment). Si vous mettez fréquemment à jour cette table, vous pouvez voir des centaines d’opérations de nettoyage automatique par jour. Ces opérations empêchent l'autovacuum de maintenir d'autres tables où le pourcentage de modifications n'est pas aussi élevé. Par contre, une table contenant un milliard de lignes doit subir des changements sur 200 millions de lignes pour déclencher des opérations de nettoyage automatique. Une définition adéquate des paramètres de nettoyage automatique empêche ce type de scénarios.

Pour définir les paramètres de nettoyage automatique pour chaque table, modifiez les paramètres du serveur, comme indiqué dans les exemples suivants :

    ALTER TABLE <table name> SET (autovacuum_analyze_scale_factor = xx);
    ALTER TABLE <table name> SET (autovacuum_analyze_threshold = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_scale_factor = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_threshold = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_cost_delay = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_cost_limit = xx);
    -- For PostgreSQL 16 and later:
    ALTER TABLE <table name> SET (vacuum_buffer_usage_limit = 'xx MB');

Charges de travail d’insertion uniquement

Dans les versions 13 et antérieures de PostgreSQL, autovacuum ne s'exécute pas sur des tables avec une charge de travail uniquement de type insertion, car il n'existe aucun tuple mort et aucun espace libre qui doit être récupéré. En revanche, l’analyse automatique s’exécute pour les charges de travail d’insertion uniquement en raison de la présence de nouvelles données. Les inconvénients de ce comportement sont les suivants :

• La carte de visibilité des tables n’est pas mise à jour et par conséquent, les performances des requêtes, en particulier là où il y a des analyses d’index uniquement, commencent à se dégrader au fil du temps.
• La base de données peut s’exécuter avec une protection contre la saturation des ID de transaction.
• Les bits d’indicateur ne sont pas définis.

Solutions

PostgreSQL versions 13 et antérieures

À l’aide de l’extension pg_cron, vous pouvez configurer un cron job pour planifier un vacuum analyze périodique sur la table. La fréquence de la tâche cron dépend de la charge de travail.

Pour obtenir des conseils, consultez des considérations spéciales sur l’utilisation de pg_cron dans Azure Database pour PostgreSQL.

PostgreSQL 13 et versions ultérieures

Le nettoyage automatique s’exécute sur des tables avec une charge de travail d’insertion uniquement. Deux paramètres de serveur, autovacuum_vacuum_insert_threshold et autovacuum_vacuum_insert_scale_factor, aident à contrôler quand le nettoyage automatique peut être déclenché sur les tables exclusivement insérées.

Guides de résolution des problèmes

Le serveur flexible Azure Database pour PostgreSQL fournit des guides de résolution des problèmes dans le portail qui vous aident à surveiller les ballonnements au niveau de la base de données ou du schéma individuel et à identifier les bloqueurs potentiels au processus de nettoyage automatique.

Deux guides de résolution des problèmes sont disponibles :

• Surveillance de l'autovacuum : utilisez ce guide pour surveiller le gonflement au niveau de la base de données ou du schéma individuel.
• Bloqueurs de nettoyage automatique et wraparound : ce guide vous aide à identifier les bloqueurs de nettoyage automatique potentiels et fournit des informations sur la distance entre les bases de données sur le serveur et les situations d’urgence.

Les guides de résolution des problèmes contiennent aussi des suggestions pour atténuer les problèmes potentiels. Pour plus d’informations sur la configuration et l’utilisation des guides de résolution des problèmes, consultez les guides de résolution des problèmes de configuration.

Fin du processus de nettoyage automatique : rôle pg_signal_autovacuum_worker

Le nettoyage automatique est un processus important en arrière-plan, car il permet de gérer efficacement le stockage et la maintenance des performances dans la base de données. Dans le processus normal de nettoyage automatique, il s’annule lui-même après le deadlock_timeout. Si un utilisateur exécute une instruction DDL sur une table, l’utilisateur peut être amené à attendre jusqu’à l’intervalle deadlock_timeout . Le processus Autovacuum n'autorise pas l'exécution de lectures ou d'écritures sur la table demandée provenant de différentes demandes de connexion, ce qui augmente la latence de la transaction.

Nous avons introduit un nouveau rôle pg_signal_autovacuum_worker à partir de PostgreSQL, qui permet aux membres non-utilisateurs de mettre fin à une tâche de nettoyage automatique en cours. Le nouveau rôle permet aux utilisateurs d’obtenir un accès sécurisé et contrôlé au processus de nettoyage automatique. Les non-superutilisateurs peuvent annuler le processus de nettoyage automatique une fois qu’on leur a octroyé le rôle pg_signal_autovacuum_worker à l'aide de la commande pg_terminate_backend. Le rôle pg_signal_autovacuum_worker est disponible dans Azure Database pour PostgreSQL dans PostgreSQL versions 15 et ultérieures.

Approche recommandée pour les processus répétitifs de nettoyage automatique

Dans de rares scénarios, tels que l’anti-wraparound autovacuum, les processus peuvent redémarrer immédiatement après leur arrêt, car ils sont essentiels pour empêcher l’épuisement de l’ID de transaction. Pour réduire les conflits répétés, procédez comme suit :

• Mettre en file d’attente l’opération DDL avant l’arrêt :

  • Session 1 : Préparez et exécutez l’instruction DDL.

  • Session 2 : Terminez le processus d'autovacuum.

    Important

    Ces deux étapes doivent être exécutées consécutivement. Si l’instruction DDL reste bloquée pendant trop longtemps, elle peut contenir des verrous et bloquer d’autres opérations DML sur le serveur.

• Terminer le nettoyage automatique et exécuter DDL : si le DDL doit s’exécuter immédiatement :

  • Terminez le processus de nettoyage automatique à l’aide de pg_terminate_backend().
  • Exécutez l’instruction DDL juste après l’arrêt.

Étapes pour éviter les conflits répétés :

1. Accorder un rôle à l’utilisateur

   GRANT pg_signal_autovacuum_worker TO app_user;
   

   1. Identifier l’ID de processus de nettoyage automatique

   SELECT pid, query FROM pg_stat_activity WHERE query LIKE '%autovacuum%' and pid!=pg_backend_pid();
   

2. Terminer le nettoyage automatique

   SELECT pg_terminate_backend(<pid>);
   

3. Exécuter l’instruction DDL immédiatement

   ALTER TABLE my_table ADD COLUMN new_col TEXT;
   

Recommandations d’Azure Advisor

Les recommandations d’Azure Advisor identifient de manière proactive si un serveur a un ratio de ballonnement élevé ou si le serveur approche d’un scénario wraparound de transaction. Vous pouvez également créer des alertes Azure Advisor pour les recommandations.

Les recommandations sont les suivantes :

• Taux de ballonnement élevé : un ratio de ballonnement élevé peut affecter les performances du serveur de plusieurs façons. Un problème important est que l’optimiseur du moteur PostgreSQL peut avoir du mal à sélectionner le meilleur plan d’exécution, ce qui entraîne une dégradation des performances des requêtes. Par conséquent, une recommandation est déclenchée quand le pourcentage d’encombrement sur un serveur atteint un certain seuil pour éviter ces problèmes de performances.

• Transaction wraparound : ce scénario est l’un des problèmes les plus graves qu’un serveur peut rencontrer. Une fois que votre serveur est dans cet état, il peut cesser d’accepter davantage de transactions, ce qui entraîne le serveur à devenir en mode lecture seule. Par conséquent, une recommandation est déclenchée lorsque le serveur dépasse un seuil de 1 milliard de transactions.

Contenu connexe

• Nettoyage complet en utilisant pg_repack dans Azure Database pour PostgreSQL
• Résoudre les problèmes d’utilisation élevée du processeur dans Azure Database pour PostgreSQL
• Résoudre les problèmes d’utilisation élevée de la mémoire dans Azure Database pour PostgreSQL
• Résoudre les problèmes d’utilisation élevée des IOPS dans Azure Database pour PostgreSQL
• Résoudre les problèmes et identifier les requêtes en cours d’exécution lente dans Azure Database pour PostgreSQL
• Paramètres de serveur dans Azure Database pour PostgreSQL