Utilisation de PostgreSQL Autovacuum sur Amazon RDS pour PostgreSQL - Amazon Relational Database Service
Allocation de mémoire pour la fonction autovacuumRéduction de la probabilité de renvoi à la ligne de l'ID de transaction

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation de PostgreSQL Autovacuum sur Amazon RDS pour PostgreSQL

Nous vous conseillons vivement d'utiliser la fonction autovacuum afin de maintenir l'intégrité de votre instance de base de données PostgreSQL. La fonction autovacuum automatise le lancement des commandes VACUUM et ANALYZE. Elle vérifie les tables ayant eu un grand nombre de tuples insérés, mis à jour ou supprimés. Après cette vérification, elle récupère le stockage en supprimant les données ou les tuples obsolètes de la base de données PostgreSQL.

Par défaut, autovacuum est activée sur les instances de base de données Amazon RDS for PostgreSQL que vous créez en utilisant l'un des groupes de paramètres de base de données PostgreSQL par défaut. Il s'agit notamment de default.postgres10, default.postgres11, etc. Tous les groupes de paramètres de base de données PostgreSQL par défaut ont un paramètre rds.adaptive_autovacuum défini sur 1, ce qui permet d'activer la fonction. Les autres paramètres de configuration associés à la fonction autovacuum sont également définis par défaut. Comme ces valeurs par défaut sont relativement génériques, vous pouvez bénéficier du réglage de certains paramètres associés à la fonction d'autovacuum pour votre charge de travail spécifique.

Vous trouverez ci-dessous de plus amples informations sur l'autovacuum et sur la façon de régler certains de ses paramètres sur votre instance de base de données RDS for PostgreSQL. Pour obtenir des informations de haut niveau, veuillez consulter Bonnes pratiques pour utiliser les moteurs de stockage PostgreSQL.

Rubriques

Allocation de mémoire pour la fonction autovacuum

L'un des paramètres les plus importants qui influencent les performances d'autovacuum est autovacuum_work_mem. Dans les versions 14 et antérieures d'Amazon RDS for PostgreSQLautovacuum_work_mem, le paramètre est défini sur -1, ce qui indique que le paramètre de est utilisé à la maintenance_work_mem place. Pour toutes les autres versions, autovacuum_work_mem est déterminé par GREATEST ({DBInstanceClassMemory/32768}, 65536).

Les opérations d'aspiration manuelles utilisent toujours ce maintenance_work_mem réglage, le réglage par défaut étant GREATEST ({DBInstanceClassMemory/63963136 *1024}, 65536), et il peut également être ajusté au niveau de la session à l'aide de la commande pour des opérations manuelles plus ciblées. SET VACUUM

autovacuum_work_memDétermine la mémoire permettant à Autovacuum de contenir les identifiants des tuples morts (pg_stat_all_tables.n_dead_tup) pour les index d'aspiration.

Lorsque vous effectuez des calculs pour déterminer la valeur du autovacuum_work_mem paramètre, tenez compte des points suivants :

  • Si vous définissez le paramètre trop bas, le processus d'aspiration devra peut-être scanner la table plusieurs fois pour terminer son travail. Ces nombreuses analyses peuvent avoir un impact négatif sur les performances. Pour les instances plus importantes, le réglage maintenance_work_mem autovacuum_work_mem d'au moins 1 Go peut améliorer les performances des tables d'aspiration contenant un grand nombre de tuples morts. Cependant, dans les versions 16 et antérieures de PostgreSQL, l'utilisation de la mémoire de Vacuum est limitée à 1 Go, ce qui est suffisant pour traiter environ 179 millions de tuples morts en un seul passage. Si une table contient plus de tuples morts que cela, vacuum devra effectuer plusieurs passages dans les index de la table, ce qui augmentera considérablement le temps requis. À partir de la version 17 de PostgreSQL, il n'y a pas de limite de 1 Go et Autovacuum peut traiter plus de 179 millions de tuples en utilisant des arbres de base.

    Un identifiant de tuple a une taille de 6 octets. Pour estimer la mémoire nécessaire pour vider un index d'une table, recherchez le nombre de tuples morts, puis multipliez ce nombre par 6 pour déterminer la mémoire requise pour vider l'index en un seul passage. pg_stat_all_tables.n_dead_tup Vous pouvez utiliser la requête suivante :

    SELECT
    relname AS table_name,
    n_dead_tup,
    pg_size_pretty(n_dead_tup * 6) AS estimated_memory
FROM
    pg_stat_all_tables
WHERE
    relname = 'name_of_the_table';

  • Le paramètre autovacuum_work_mem fonctionne en conjonction avec le paramètre autovacuum_max_workers. Chaque travailleur autovacuum_max_workers peut utiliser la mémoire que vous allouez. Si vous avez beaucoup de petites tables, allouez plus de autovacuum_max_workers et moins de autovacuum_work_mem. Si vos tables sont volumineuses (plus de 100 Go), allouez plus de mémoire et réduisez le nombre de processus de travail. Vous devez avoir alloué suffisamment de mémoire pour pouvoir prendre en charge votre plus grande table. Assurez-vous donc que la combinaison des processus de travail et de la mémoire est égale à la mémoire totale que vous souhaitez allouer.

Réduction de la probabilité de renvoi à la ligne de l'ID de transaction

Dans certains cas, les valeurs du groupe de paramètres associées à la fonction autovacuum peuvent ne pas être suffisamment agressives pour empêcher le renvoi à la ligne de l'ID de transaction. Pour résoudre ce problème, RDS for PostgreSQL fournit un mécanisme qui adapte automatiquement les valeurs des paramètres de la fonction autovacuum. Le réglage adaptatif des paramètres d'autovacuum est une fonction pour RDS for PostgreSQL. Une explication détaillée du renvoi à la ligne de l'ID de transaction figure dans la documentation PostgreSQL.

Le réglage adaptatif des paramètres autovacuum est activé par défaut pour les instances RDS for PostgreSQL avec le paramètre dynamique rds.adaptive_autovacuum défini sur ON (ACTIVÉ). Nous vous recommandons vivement de garder cette option activée. Toutefois, pour désactiver le réglage adaptatif des paramètres d'autovacuum, définissez le paramètre rds.adaptive_autovacuum sur 0 ou OFF.

Le renvoi à la ligne de l'ID de transaction est encore possible même lorsque Amazon RDS règle les paramètres d'autovacuum. Nous vous encourageons à implémenter une CloudWatch alarme Amazon pour l'encapsulation des identifiants de transaction. Pour plus d'informations, consultez l'article Implémenter un système d'alerte précoce pour l'encapsulation des identifiants de transaction dans RDS pour PostgreSQL sur le blog de base de données. AWS

Lorsque le réglage adaptatif des paramètres d'aspiration automatique est activé, Amazon RDS commence à ajuster les paramètres d'aspiration automatique lorsque la CloudWatch métrique MaximumUsedTransactionIDs atteint la valeur du autovacuum_freeze_max_age paramètre ou 500 000 000, la valeur la plus élevée étant retenue.

Amazon RDS continue à ajuster les paramètres pour la fonction autovacuum si une table continue à s'orienter vers le renvoi à la ligne de l'ID de transaction. Chacun de ces ajustements dédie plus de ressources à la fonction d'autovacuum pour éviter le renvoi à la ligne. Amazon RDS met à jour les paramètres suivants associés à la fonction d'autovacuum :

RDS modifie ces paramètres seulement si la nouvelle valeur rend la fonction d'autovacuum plus agressive. Ces paramètres sont modifiés dans la mémoire sur l'instance de base de données. Les valeurs figurant dans le groupe de paramètres ne sont pas modifiées. Pour afficher les paramètres en mémoire actuels, utilisez la commande SQL SHOW de PostgreSQL.

Chaque fois que Amazon RDS modifie l'un de ces paramètres d'autovacuum, il génère un événement pour l'instance de base de données concernée. Cet événement est visible sur AWS Management Console et via l'API Amazon RDS. Une fois que la MaximumUsedTransactionIDs CloudWatch métrique est revenue en dessous du seuil, Amazon RDS réinitialise les paramètres relatifs à l'autovacuum en mémoire aux valeurs spécifiées dans le groupe de paramètres. Il génère ensuite un autre événement correspondant à cette modification.