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. # Identification et résolution des bloqueurs de vacuum agressifs dans RDS pour PostgreSQL Dans PostgreSQL, l’opération de vacuum est essentielle pour garantir l’intégrité de la base de données, car elle permet de récupérer de l’espace de stockage et d’éviter les problèmes de [bouclage de l’ID de transaction.](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) Cependant, il peut arriver que l’opération de vacuum ne fonctionne pas comme vous le souhaitez, ce qui peut entraîner une dégradation des performances ou une surcharge de l’espace de stockage et même avoir un impact sur la disponibilité de votre instance de base de données par bouclage de l’ID de transaction. Il est donc essentiel d’identifier et de résoudre ces problèmes pour optimiser les performances et la disponibilité des bases de données. Lisez [Présentation d’autovacuum dans les environnements Amazon RDS pour PostgreSQL](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) pour en savoir plus sur l’autovacuum. La fonction `postgres_get_av_diag()` permet d’identifier les problèmes qui empêchent ou retardent la progression du vacuum agressif. Des suggestions sont fournies, qui peuvent inclure des commandes pour résoudre le problème lorsqu’il est identifiable ou des conseils pour des diagnostics supplémentaires lorsque le problème n’est pas identifiable. Les bloqueurs d'aspiration agressifs sont signalés lorsque leur âge dépasse le seuil d'[autoaspiration adaptatif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) de 500 millions de transactions fixé par RDS. IDs **Quel est l’âge de l’ID de transaction ?** La `age()` fonction de transaction IDs calcule le nombre de transactions survenues depuis le plus ancien identifiant de transaction dégelé pour une base de données (`pg_database.datfrozenxid`) ou une table (`pg_class.relfrozenxid`). Cette valeur indique l’activité de la base de données depuis la dernière opération de vacuum agressif et met en évidence la charge de travail probable pour les prochains processus VACUUM. **Qu’est-ce qu’un vacuum agressif ?** Une opération VACUUM agressive effectue une numérisation complète de toutes les pages d'un tableau, y compris celles qui sont généralement ignorées en mode normal VACUUMs. Cette analyse approfondie vise à « geler » les transactions IDs qui approchent de leur âge maximum, évitant ainsi une situation connue sous le nom d'[encapsulation des identifiants de transaction](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND). Pour que `postgres_get_av_diag()` signale un bloqueur, celui-ci doit dater d’au moins 500 millions de transactions. **Topics** + [Installation d’outils de surveillance et de diagnostic d’autovacuum dans RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md) + [Fonctions de postgres\$1get\$1av\$1diag() dans RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md) + [Résolution des bloqueurs de vacuum identifiables dans RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md) + [Résolution des bloqueurs de vacuum non identifiables dans RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md) + [Résolution des problèmes de performance de vacuum dans RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md) + [Explication des messages NOTICE dans RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md) # Installation d’outils de surveillance et de diagnostic d’autovacuum dans RDS pour PostgreSQL La fonction `postgres_get_av_diag()` est actuellement disponible dans les versions RDS pour PostgreSQL suivantes : + 17.2 et versions 17 ultérieures + 16.7 et versions 16 ultérieures + 15.11 et versions 15 ultérieures + 14.16 et versions 14 ultérieures + 13.19 et versions 13 ultérieures Pour pouvoir utiliser `postgres_get_av_diag()`, créez l’extension `rds_tools`. ``` postgres=> CREATE EXTENSION rds_tools ; CREATE EXTENSION ``` Vérifiez que l’extension est installée. ``` postgres=> \dx rds_tools List of installed extensions Name | Version | Schema | Description ----------+---------+-----------+---------------------------------------------------------- rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL 1 row ``` Vérifiez que la fonction est créée. ``` postgres=> SELECT proname function_name, pronamespace::regnamespace function_schema, proowner::regrole function_owner FROM pg_proc WHERE proname = 'postgres_get_av_diag'; function_name | function_schema | function_owner ----------------------+-----------------+---------------- postgres_get_av_diag | rds_tools | rds_superuser (1 row) ``` # Fonctions de postgres\$1get\$1av\$1diag() dans RDS pour PostgreSQL La fonction `postgres_get_av_diag()` récupère des informations de diagnostic sur les processus autovacuum qui bloquent ou sont en retard dans une base de données RDS pour PostgreSQL. Pour obtenir des résultats précis, la requête doit être exécutée dans la base de données dont l’ID de transaction est le plus ancien. Pour plus d’informations sur l’utilisation de la base de données ayant l’ID de transaction le plus ancien, consultez [Non connecté à la base de données dont l’ID de transaction est le plus ancien](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md). ``` SELECT blocker, DATABASE, blocker_identifier, wait_event, TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by, suggestion, suggested_action FROM ( SELECT * FROM rds_tools.postgres_get_av_diag () ORDER BY autovacuum_lagging_by DESC) q; ``` La fonction `postgres_get_av_diag()` retourne un tableau avec les informations suivantes : **blocker** Spécifie la catégorie d’activité de base de données qui bloque le vacuum. + [Instruction active](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement) + [État Idle in transaction (Transaction inactive)](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction) + [Transaction préparée](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction) + [Emplacement de réplication logique](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot) + [Réplica en lecture avec emplacement de réplication physique](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas) + [Réplica en lecture avec réplication de streaming](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas) + [Tables temporaires](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables) **database** Spécifie le nom de la base de données, le cas échéant. Il s’agit de la base de données dans laquelle l’activité est en cours et bloque ou bloquera l’autovacuum. Il s’agit de la base de données à laquelle vous devez vous connecter et sur laquelle vous devez agir. **blocker\$1identifier** Spécifie l’identifiant de l’activité qui bloque ou bloquera l’autovacuum. Il peut s’agir d’un ID de processus accompagné d’une instruction SQL, d’une transaction préparée, de l’adresse IP d’un réplica en lecture et du nom de l’emplacement de réplication, logique ou physique. **wait\$1event** Spécifie l’[événement d’attente](PostgreSQL.Tuning.md) de la session de blocage et s’applique aux bloqueurs suivants : + Instruction active + État Idle in transaction (Transaction inactive) **autovacum\$1lagging\$1by** Spécifie le nombre de transactions pour lesquelles l’autovacuum a pris du retard dans le traitement des éléments en attente par catégorie. **suggestion** Spécifie des suggestions pour résoudre le bloqueur. Ces instructions incluent le nom de la base de données dans laquelle l’activité existe, le cas échéant, l’ID de processus (PID) de la session, le cas échéant, et les actions à effectuer. **suggested\$1action** Suggère l’action à effectuer pour résoudre le bloqueur. # Résolution des bloqueurs de vacuum identifiables dans RDS pour PostgreSQL L’autovacuum effectue des opérations vacuum agressives et abaisse l’âge des ID de transaction en dessous du seuil spécifié par le paramètre `autovacuum_freeze_max_age` de votre instance RDS. Vous pouvez suivre cet âge à l’aide de la métrique `MaximumUsedTransactionIDs` d’Amazon CloudWatch. Pour trouver le paramètre `autovacuum_freeze_max_age` (dont la valeur par défaut est de 200 millions d’ID de transaction) pour votre instance Amazon RDS, vous pouvez utiliser la requête suivante : ``` SELECT TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'; ``` Notez que `postgres_get_av_diag()` recherche uniquement les bloqueurs de vacuum agressifs quand l’âge dépasse le seuil de 500 millions d’ID de transaction pour l’[autovacuum adaptatif](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) d’Amazon RDS. Pour que `postgres_get_av_diag()` détecte un bloqueur, celui-ci doit dater d’au moins 500 millions de transactions. La fonction `postgres_get_av_diag()` identifie les types de bloqueurs suivants : **Topics** + [Instruction active](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement) + [État Idle in transaction (Transaction inactive)](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction) + [Transaction préparée](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction) + [Emplacement de réplication logique](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot) + [Réplicas en lecture](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas) + [Tables temporaires](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables) ## Instruction active Dans PostgreSQL, une instruction active est une instruction SQL qui est exécutée par la base de données. Cela inclut les requêtes, les transactions ou les opérations en cours. Lors de la surveillance via `pg_stat_activity`, la colonne d’état indique que le processus avec le PID correspondant est actif. La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle identifie une instruction active. ``` blocker | Active statement database | my_database blocker_identifier | SELECT pg_sleep(20000); wait_event | Timeout:PgSleep autovacuum_lagging_by | 568,600,871 suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. suggested_action | {"SELECT pg_terminate_backend (29621);"} ``` **Action suggérée** En suivant les instructions de la colonne `suggestion`, l’utilisateur peut se connecter à la base de données dans laquelle l’instruction active se trouve et, comme indiqué dans la colonne `suggested_action`, il est conseillé de vérifier attentivement l’option permettant de mettre fin à la session. Si la résiliation est sûre, vous pouvez utiliser la fonction `pg_terminate_backend()` pour résilier la session. Cette action peut être effectuée par un administrateur (tel que le compte principal RDS) ou par un utilisateur disposant du privilège `pg_terminate_backend()` requis. **Avertissement** Une session résiliée annule (`ROLLBACK`) les modifications apportées. En fonction de vos besoins, vous souhaiterez peut-être réexécuter l’instruction. Cependant, il est recommandé de ne le faire qu’une fois que le processus d’autovacuum a terminé son opération de vacuum agressif. ## État Idle in transaction (Transaction inactive) Une instruction idle in transaction fait référence à toute session qui a ouvert une transaction explicite (par exemple en émettant une instruction `BEGIN`), qui a effectué un certain travail et qui attend maintenant que le client transmettre plus de travail ou signale la fin de la transaction en émettant une instruction `COMMIT`, `ROLLBACK`, ou `END` (ce qui se traduirait par un `COMMIT` implicite). La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle identifie une instruction `idle in transaction` comme un bloqueur. ``` blocker | idle in transaction database | my_database blocker_identifier | INSERT INTO tt SELECT * FROM tt; wait_event | Client:ClientRead autovacuum_lagging_by | 1,237,201,759 suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. suggested_action | {"SELECT pg_terminate_backend (28438);"} ``` **Action suggérée** Comme indiqué dans la colonne `suggestion`, vous pouvez vous connecter à la base de données dans laquelle la session idle in transaction est présente et mettre fin à la session à l’aide de la fonction `pg_terminate_backend()`. L’utilisateur peut être votre administrateur (compte principal RDS) ou un utilisateur disposant du privilège `pg_terminate_backend()`. **Avertissement** Une session résiliée annule (`ROLLBACK`) les modifications apportées. En fonction de vos besoins, vous souhaiterez peut-être réexécuter l’instruction. Cependant, il est recommandé de ne le faire qu’une fois que le processus d’autovacuum a terminé son opération de vacuum agressif. ## Transaction préparée PostgreSQL autorise les transactions qui font partie d’une stratégie de validation en deux phases appelée [transactions préparées](https://www.postgresql.org/docs/current/sql-prepare-transaction.html). Elles sont activées en définissant une valeur différente de zéro pour le paramètre `max_prepared_transactions`. Les transactions préparées sont conçues pour garantir qu’une transaction est durable et reste disponible même après une panne de base de données, un redémarrage ou une déconnexion du client. Comme les transactions régulières, elles reçoivent un ID de transaction et peuvent affecter l’autovacuum. Si elles restent à l’état préparé, l’autovacuum ne peut pas les geler et cela peut entraîner un bouclage de l’ID de transaction. Lorsque les transactions restent à l’état préparé indéfiniment sans être résolues par un gestionnaire de transactions, elles deviennent des transactions préparées orphelines. La seule façon de résoudre ce problème est de valider ou d’annuler la transaction à l’aide des commandes `COMMIT PREPARED` ou `ROLLBACK PREPARED`, respectivement. **Note** Sachez qu’une sauvegarde effectuée lors d’une transaction préparée contiendra toujours cette transaction après restauration. Reportez-vous aux informations suivantes pour savoir comment localiser et clôturer de telles transactions. La fonction `postgres_get_av_diag()` affiche le résultat suivant lorsqu’elle identifie un bloqueur qui est une transaction préparée. ``` blocker | Prepared transaction database | my_database blocker_identifier | myptx wait_event | Not applicable autovacuum_lagging_by | 1,805,802,632 suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"} ``` **Action suggérée** Comme indiqué dans la colonne de suggestions, connectez-vous à la base de données où se trouve la transaction préparée. Sur la base de la colonne `suggested_action`, examinez attentivement s’il faut exécuter `COMMIT` ou `ROLLBACK`, et quelle est l’action appropriée. Pour surveiller les transactions préparées en général, PostgreSQL propose une vue de catalogue appelée `pg_prepared_xacts`. Vous pouvez utiliser la requête suivante pour rechercher les transactions préparées. ``` SELECT gid, prepared, owner, database, transaction AS oldest_xmin FROM pg_prepared_xacts ORDER BY age(transaction) DESC; ``` ## Emplacement de réplication logique L’objectif d’un emplacement de réplication est de conserver les modifications non consommées jusqu’à ce qu’elles soient répliquées sur un serveur cible. Pour plus d’informations, consultez [Réplication logique](https://www.postgresql.org/docs/current/logical-replication.html) de PostgreSQL. Il existe deux types d’emplacement de réplication logique. **Emplacements de réplication logique inactifs** Lorsque la réplication est interrompue, les journaux de transactions non consommés ne peuvent pas être supprimés et l’emplacement de réplication devient inactif. Même si un emplacement de réplication logique inactif n’est pas utilisé par un abonné, il reste sur le serveur, ce qui entraîne la conservation des fichiers WAL et empêche la suppression des anciens journaux de transactions. Cela peut augmenter l’utilisation du disque et empêcher spécifiquement l’autovacuum de nettoyer les tables de catalogue internes, car le système doit empêcher le remplacement des informations LSN. Si rien n’est fait, cela peut entraîner un gonflement du catalogue, une dégradation des performances et un risque accru de vacuum de bouclage, ce qui peut entraîner une durée d’indisponibilité des transactions. **Emplacements de réplication logique actifs mais lents** Parfois, la suppression des tuples inactifs du catalogue est retardée en raison de la dégradation des performances de la réplication logique. Ce retard de réplication ralentit la mise à jour de `catalog_xmin` et peut entraîner un gonflement du catalogue et un vacuum de bouclage. La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle trouve un emplacement de réplication logique en tant que bloqueur. ``` blocker | Logical replication slot database | my_database blocker_identifier | slot1 wait_event | Not applicable autovacuum_lagging_by | 1,940,103,068 suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"} ``` **Action suggérée** Pour résoudre ce problème, vérifiez la configuration de réplication afin de détecter tout problème lié au schéma cible ou aux données susceptibles de mettre fin au processus d’application. Voici les raisons les plus courantes de ce problème : + Colonnes manquantes + Types de données incompatibles + Non-correspondance des données + Table manquante Si le problème est lié à des problèmes d’infrastructure : + Problèmes de réseau : [comment résoudre les problèmes liés à une base de données Amazon RDS dans un état réseau incompatible](https://repost.aws/knowledge-center/rds-incompatible-network). + La base de données ou l’instance de base de données n’est pas disponible pour les raisons suivantes : + L’instance de réplica n’a plus d’espace de stockage : consultez [Instances de base de données Amazon RDS à court de stockage](https://repost.aws/knowledge-center/rds-out-of-storage) pour en savoir plus sur l’ajout d’espace de stockage. + Paramètres incompatibles : consultez [Comment puis-je réparer une instance de base de données Amazon RDS bloquée avec le statut de paramètres incompatibles ?](https://repost.aws/knowledge-center/rds-incompatible-parameters) pour plus d’informations sur la façon dont vous pouvez résoudre le problème. Si votre instance se trouve en dehors du réseau AWS ou sur AWS EC2, demandez à votre administrateur comment résoudre les problèmes liés à la disponibilité ou à l’infrastructure. **Suppression de l’emplacement inactif** **Avertissement** Attention : avant de supprimer un emplacement de réplication, assurez-vous qu’il n’est pas en cours de réplication, qu’il est inactif et qu’il est dans un état irrécupérable. La suppression prématurée d’un emplacement peut perturber la réplication ou entraîner une perte de données. Après avoir confirmé que l’emplacement de réplication n’est plus nécessaire, supprimez-le pour permettre à l’autovacuum de continuer. La condition `active = 'f'` garantit que seul un emplacement inactif est supprimé. ``` SELECT pg_drop_replication_slot('slot1') WHERE active ='f' ``` ## Réplicas en lecture Lorsque le paramètre `hot_standby_feedback` est activé pour les [réplicas en lecture Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md), il empêche l’autovacuum sur la base de données principale de supprimer les lignes inactives qui pourraient encore être nécessaires aux requêtes exécutées sur le réplica en lecture. Cela concerne tous les types de réplicas en lecture physiques, y compris ceux gérés avec ou sans emplacements de réplication. Ce comportement est nécessaire, car les requêtes exécutées sur le réplica de secours nécessitent que ces lignes restent disponibles sur le réplica principal pour éviter les [conflits de requêtes](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT) et les annulations. **Réplica en lecture avec emplacement de réplication physique** Les réplicas en lecture avec des emplacements de réplication physiques améliorent considérablement la fiabilité et la stabilité de la réplication dans RDS pour PostgreSQL. Ces emplacements garantissent que la base de données principale conserve les fichiers journaux d’écriture anticipée essentiels jusqu’à ce que le réplica les traite, préservant ainsi la cohérence des données même en cas de perturbation du réseau. À partir de RDS pour PostgreSQL version 14, tous les réplicas utilisent des emplacements de réplication. Dans les versions antérieures, seuls les réplicas entre régions utilisaient des emplacements de réplication. La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle trouve un réplica en lecture avec un emplacement de réplication logique en tant que bloqueur. ``` blocker | Read replica with physical replication slot database | blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx wait_event | Not applicable autovacuum_lagging_by | 554,080,689 suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query: | SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377; | Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + | suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," + | [OR] + | ","Disable hot_standby_feedback"," + | [OR] + | ","Delete the read replica if not needed"} ``` **Réplica en lecture avec réplication de streaming** Amazon RDS permet de configurer des réplicas en lecture sans emplacement de réplication physique dans les anciennes versions, jusqu’à la version 13. Cette approche réduit la surcharge en permettant au système principal de recycler les fichiers WAL de manière plus agressive, ce qui est avantageux dans les environnements où l’espace disque est limité et peut tolérer des retards de réplica occasionnels. Cependant, sans emplacement, le réplica de secours doit rester synchronisé pour éviter de manquer des fichiers WAL. Amazon RDS utilise des fichiers WAL archivés pour aider le réplica à rattraper son retard, mais ce processus nécessite une surveillance attentive et peut être lent. La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle trouve un réplica en lecture de diffusion avec un emplacement de réplication logique en tant que bloqueur. ``` blocker | Read replica with streaming replication slot database | Not applicable blocker_identifier | xx.x.x.xxx/xx wait_event | Not applicable autovacuum_lagging_by | 610,146,760 suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: + | SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; + | Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + | suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," + | [OR] + | ","Disable hot_standby_feedback"," + | [OR] + | ","Delete the read replica if not needed"} ``` **Action suggérée** Comme recommandé dans la colonne `suggested_action`, examinez attentivement ces options pour débloquer l’autovacuum. + **Résilier la requête** : en suivant les instructions de la colonne de suggestions, vous pouvez vous connecter au réplica en lecture, comme indiqué dans la colonne suggested\$1action. Il est conseillé de vérifier attentivement l’option permettant de résilier la session. Si la résiliation est considérée comme sûre, vous pouvez utiliser la fonction `pg_terminate_backend()` pour résilier la session. Cette action peut être effectuée par un administrateur (tel que le compte principal RDS) ou par un utilisateur disposant du privilège pg\$1terminate\$1backend() requis. Vous pouvez exécuter la commande SQL suivante sur le réplica en lecture pour résilier la requête qui empêche le vacuum sur la base de données principale de nettoyer les anciennes lignes. La valeur de `backend_xmin` est indiquée dans la sortie de la fonction : ``` SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = backend_xmin; ``` + **Désactiver les commentaires de veille permanente** : pensez à désactiver le paramètre `hot_standby_feedback` s’il entraîne des retards de vacuum importants. Le paramètre `hot_standby_feedback` permet à un réplica en lecture d’informer la base de données principale de son activité de requête, empêchant ainsi la base de données principale d’effectuer une opération de vacuum sur les tables ou les lignes utilisées sur le réplica de secours. Bien que cela garantisse la stabilité des requêtes sur le réplica de secours, cela peut retarder considérablement l’opération de vacuum sur la base de données principale. La désactivation de cette fonction permet à la base de données principale d’effectuer l’opération de vacuum sans attendre que le réplica de secours rattrape le retard. Toutefois, cela peut entraîner des annulations de requêtes ou des échecs sur le réplica de secours s’il tente d’accéder à des lignes qui ont été supprimées par la base de données principale. + **Supprimer les réplicas en lecture s’ils ne sont pas nécessaires** : si le réplica en lecture n’est plus nécessaire, vous pouvez le supprimer. Cela supprime la surcharge de réplication associée et permet au système principal de recycler les journaux de transactions sans être freiné par le réplica. ## Tables temporaires Les [tables temporaires](https://www.postgresql.org/docs/current/sql-createtable.html), créées à l’aide du mot-clé `TEMPORARY`, résident dans le schéma temporaire, par exemple pg\$1temp\$1xxx, et ne sont accessibles qu’à la session qui les a créées. Les tables temporaires sont supprimées à la fin de la session. Cependant, ces tables sont invisibles pour le processus autovacuum de PostgreSQL et doivent être nettoyées manuellement par la session qui les a créées. Essayer d’effectuer un vacuum sur la table temporaire d’une autre session n’a aucun effet. Dans des circonstances exceptionnelles, une table temporaire peut exister sans qu’elle appartienne à une session active. Si la session liée à une table temporaire se termine de façon inattendue en raison d’un incident fatal, d’un problème réseau ou d’un événement similaire, il est possible que cette table ne soit pas nettoyée et qu’elle devienne ainsi une table « orpheline ». Lorsque le processus autovacuum de PostgreSQL détecte une table temporaire orpheline, il consigne le message suivant : ``` LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\" ``` La fonction `postgres_get_av_diag()` affiche une sortie similaire à la suivante lorsqu’elle identifie une table temporaire comme un bloqueur. Pour que cette fonction affiche correctement la sortie relative aux tables temporaires, elle doit être exécutée dans la base de données dans laquelle se trouvent ces tables. ``` blocker | Temporary table database | my_database blocker_identifier | pg_temp_14.ttemp wait_event | Not applicable autovacuum_lagging_by | 1,805,802,632 suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. suggested_action | {"DROP TABLE ttemp;"} ``` **Action suggérée** Suivez les instructions fournies dans la colonne `suggestion` de sortie pour identifier et supprimer la table temporaire qui empêche l’exécution de l’autovacuum. Utilisez la commande suivante pour supprimer la table temporaire signalée par `postgres_get_av_diag()`. Remplacez le nom de la table en fonction de la sortie fournie par la fonction `postgres_get_av_diag()`. ``` DROP TABLE my_temp_schema.my_temp_table; ``` La requête suivante peut être utilisée pour identifier les tables temporaires : ``` SELECT oid, relname, relnamespace::regnamespace, age(relfrozenxid) FROM pg_class WHERE relpersistence = 't' ORDER BY age(relfrozenxid) DESC; ``` # Résolution des bloqueurs de vacuum non identifiables dans RDS pour PostgreSQL Cette section explore d’autres raisons qui peuvent empêcher l’opération de vacuum de progresser. Ces problèmes ne sont actuellement pas directement identifiables par la fonction `postgres_get_av_diag()`. **Topics** + [Pages non valides](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages) + [Incohérence de l’index](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency) + [Taux de transaction exceptionnellement élevé](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate) ## Pages non valides Une erreur de page non valide se produit lorsque PostgreSQL détecte une incompatibilité dans le total de contrôle d’une page lors de l’accès à cette page. Le contenu est illisible, ce qui empêche l’autovacuum de geler les tuples. Cela arrête efficacement le processus de nettoyage. L’erreur suivante est écrite dans le journal de PostgreSQL : ``` WARNING: page verification failed, calculated checksum YYYYY but expected XXXX ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX CONTEXT: automatic vacuum of table myschema.mytable ``` **Détermination du type d’objet** ``` ERROR: invalid page in block 4305910 of relation base/16403/186752608 WARNING: page verification failed, calculated checksum 50065 but expected 60033 ``` À partir du message d’erreur, le chemin `base/16403/186752608` fournit les informations suivantes : + « base » est le nom du répertoire situé sous le répertoire de données PostgreSQL. + « 16403 » est l’OID de la base de données, que vous pouvez consulter dans le catalogue système `pg_database`. + « 186752608 » est le `relfilenode`, que vous pouvez utiliser pour rechercher le schéma et le nom de l’objet dans le catalogue système `pg_class`. En vérifiant le résultat de la requête suivante dans la base de données concernée, vous pouvez déterminer le type d’objet. La requête suivante récupère les informations d’objet pour l’oid 186752608. Remplacez l’OID par celui correspondant à l’erreur que vous avez rencontrée. ``` SELECT relname AS object_name, relkind AS object_type, nspname AS schema_name FROM pg_class c JOIN pg_namespace n ON c.relnamespace = n.oid WHERE c.oid = 186752608; ``` Pour plus d’informations, consultez la documentation de PostgreSQL [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html) pour connaître tous les types d’objets pris en charge, indiqués par la colonne `relkind` dans `pg_class`. **Conseils** La solution la plus efficace à ce problème dépend de la configuration de votre instance Amazon RDS spécifique et du type de données concerné par la page incohérente. **Si le type d’objet est un index :** Il est recommandé de reconstruire l’index. + **Utilisation de l’option `CONCURRENTLY`** : avant PostgreSQL version 12, la reconstruction d’un index nécessitait un verrou de table exclusif, limitant ainsi l’accès à la table. Avec PostgreSQL versions 12 et ultérieures, l’option `CONCURRENTLY` permet le verrouillage au niveau des lignes, ce qui améliore considérablement la disponibilité de la table. Voici la commande : ``` REINDEX INDEX ix_name CONCURRENTLY; ``` Bien que l’option `CONCURRENTLY` soit moins perturbatrice, elle peut être plus lente sur les tables très occupées. Envisagez de générer l’index pendant les périodes de faible trafic si possible. Pour plus d’informations, consultez la documentation de PostgreSQL sur [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html). + **Utilisation de l’option `INDEX_CLEANUP FALSE`** : si les index sont volumineux et que le temps estimé pour les finaliser est significatif, vous pouvez débloquer l’autovacuum en exécutant une opération `VACUUM FREEZE` manuelle tout en excluant les index. Cette fonctionnalité est disponible dans PostgreSQL versions 12 et ultérieures. Ignorer les index vous permet d’éviter le processus de vacuum de l’index incohérent et d’atténuer le problème de bouclage. Toutefois, cela ne résout pas le problème sous-jacent de page non valide. Pour résoudre complètement le problème de page non valide, vous devrez tout de même reconstruire l’index. **Si le type d’objet est une vue matérialisée :** Si une erreur de page non valide se produit sur une vue matérialisée, connectez-vous à la base de données concernée et actualisez-la pour corriger la page non valide : Actualisez la vue matérialisée : ``` REFRESH MATERIALIZED VIEW schema_name.materialized_view_name; ``` Si l’actualisation échoue, essayez de recréer la vue : ``` DROP MATERIALIZED VIEW schema_name.materialized_view_name; CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query; ``` L’actualisation ou la recréation de la vue matérialisée permet de la restaurer sans affecter les données de la table sous-jacente. **Pour tous les autres types d’objets :** Pour tous les autres types d’objets, contactez l’assistance AWS. ## Incohérence de l’index Un index dont la logique est incohérente peut empêcher l’autovacuum de progresser. Les erreurs suivantes ou des erreurs similaires sont journalisées pendant la phase de vacuum de l’index ou lorsque des instructions SQL accèdent à l’index. ``` ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name ``` ``` ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX CONTEXT: while vacuuming index index_name of relation schema.table ``` **Conseils** Reconstruisez l’index ou ignorez les index en utilisant `INDEX_CLEANUP` lors d’une opération `VACUUM FREEZE` manuelle. Pour plus d’informations sur la façon de reconstruire l’index, consultez [Si le type d’objet est un index](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages). + **Utilisation de l’option CONCURRENTLY** : avant PostgreSQL version 12, la reconstruction d’un index nécessitait un verrou de table exclusif, limitant ainsi l’accès à la table. Avec PostgreSQL versions 12 et ultérieures, l’option CONCURRENTLY permet le verrouillage au niveau des lignes, ce qui améliore considérablement la disponibilité de la table. Voici la commande : ``` REINDEX INDEX ix_name CONCURRENTLY; ``` Bien que l’option CONCURRENTLY soit moins perturbatrice, elle peut être plus lente sur les tables très occupées. Envisagez de générer l’index pendant les périodes de faible trafic si possible. Pour plus d’informations, consultez [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html) dans la documentation de *PostgreSQL*. + **Utilisation de l’option INDEX\$1CLEANUP FALSE** : si les index sont volumineux et que le temps estimé pour les finaliser est significatif, vous pouvez débloquer l’autovacuum en exécutant une opération VACUUM FREEZE manuelle tout en excluant les index. Cette fonctionnalité est disponible dans PostgreSQL versions 12 et ultérieures. Ignorer les index vous permet d’éviter le processus de vacuum de l’index incohérent et d’atténuer le problème de bouclage. Toutefois, cela ne résout pas le problème sous-jacent de page non valide. Pour résoudre complètement le problème de page non valide, vous devrez tout de même reconstruire l’index. ## Taux de transaction exceptionnellement élevé Dans PostgreSQL, les taux de transactions élevés peuvent avoir un impact significatif sur les performances de l’autovacuum, ce qui ralentit le nettoyage des tuples inactifs et augmente le risque de bouclage des ID de transaction. Vous pouvez surveiller le taux de transaction en mesurant la différence de `max(age(datfrozenxid))` entre deux périodes, généralement par seconde. En outre, vous pouvez utiliser les métriques de compteur suivantes de RDS Performance Insights pour mesurer le taux de transaction (somme de xact\$1commit et xact\$1rollback), qui est le nombre total de transactions. | Compteur | Type | Unité | Métrique | | --- | --- | --- | --- | | xact\$1commit | Transactions | Validations par seconde | db.Transactions.xact\$1commit | | xact\$1rollback | Transactions | Restaurations par seconde | db.Transactions.xact\$1rollback | Une augmentation rapide indique une charge de transactions élevée, qui peut surcharger l’autovacuum, provoquant un gonflement, des conflits de verrouillage et des problèmes de performances potentiels. Cela peut avoir un impact négatif sur le processus d’autovacuum de plusieurs manières : + **Activité liée à la table :** la table en question peut faire l’objet d’un volume élevé de transactions, ce qui peut entraîner des retards. + **Ressources système :** l’ensemble du système est peut-être surchargé, ce qui rend difficile pour l’autovacuum d’accéder aux ressources nécessaires pour fonctionner efficacement. Envisagez les stratégies suivantes pour permettre à l’autovacuum de fonctionner plus efficacement et de mener à bien ses tâches dans le délai imparti : 1. Réduisez le taux de transaction si possible. Envisagez de traiter par lots ou de regrouper les transactions similaires dans la mesure du possible. 1. Ciblez les tables fréquemment mises à jour avec une opération `VACUUM FREEZE` manuelle tous les soirs, toutes les semaines ou toutes les deux semaines pendant les heures creuses. 1. Envisagez d’augmenter verticalement votre classe d’instance pour allouer davantage de ressources système afin de gérer le volume élevé de transactions et l’autovacuum. # Résolution des problèmes de performance de vacuum dans RDS pour PostgreSQL Cette section décrit les facteurs qui contribuent souvent au ralentissement des performances de vacuum et explique comment résoudre ces problèmes. **Topics** + [Vacuum des index de grande taille](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes) + [Trop de tables ou de bases de données pour le vacuum](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables) + [Un vacuum agressif (pour éviter tout bouclage) est en cours d’exécution](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum) ## Vacuum des index de grande taille VACUUM fonctionne selon des phases séquentielles : initialisation, analyse des tas, vacuum des index et des tas, nettoyage des index, troncature des tas et nettoyage final. Pendant l’analyse des tas, le processus élague les pages, les défragmente et les gèle. Une fois l’analyse des tas terminée, VACUUM nettoie les index, renvoie les pages vides au système d’exploitation et effectue les dernières tâches de nettoyage, telles que le vacuum de la carte de l’espace libre et la mise à jour des statistiques. L’opération de vacuum de l’index peut nécessiter plusieurs passages lorsque la capacité `maintenance_work_mem` (ou `autovacuum_work_mem`) est insuffisante pour traiter l’index. Dans PostgreSQL 16 et versions antérieures, une limite de mémoire de 1 Go pour le stockage des ID de tuple inactifs imposait souvent plusieurs passages sur les index volumineux. PostgreSQL 17 introduit `TidStore`, qui alloue de la mémoire de manière dynamique au lieu d’utiliser un tableau à allocation unique. Cela permet de supprimer la contrainte de 1 Go, d’utiliser la mémoire de manière plus efficace et d’éviter d’avoir à analyser plusieurs fois chaque index. Les index de grande taille peuvent toujours nécessiter plusieurs passages dans PostgreSQL 17 si la mémoire disponible ne peut pas prendre en charge l’intégralité du traitement des index en une seule fois. Généralement, les index de grande taille contiennent davantage de tuples inactifs qui nécessitent plusieurs passages. **Détection des opérations de vacuum lentes** La fonction `postgres_get_av_diag()` peut détecter les opérations de vacuum qui sont lentes en raison d’une mémoire insuffisante. Pour plus d’informations sur cette fonction, consultez [Installation d’outils de surveillance et de diagnostic d’autovacuum dans RDS pour PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md). La fonction `postgres_get_av_diag()` émet les notifications suivantes lorsque la mémoire disponible n’est pas suffisante pour terminer l’opération de vacuum de l’index en un seul passage. **`rds_tools` 1.8** ``` NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow. ``` ``` NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory. Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). ``` **`rds_tools` 1.9** ``` NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow. ``` ``` NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) . ``` **Note** La fonction `postgres_get_av_diag()` repose sur `pg_stat_all_tables.n_dead_tup` pour l’estimation de la quantité de mémoire requise pour l’opération de vacuum de l’index. Lorsque la fonction `postgres_get_av_diag()` identifie une opération de vacuum lente qui nécessite plusieurs analyses d’index en raison d’une capacité `autovacuum_work_mem` insuffisante, elle génère le message suivant : ``` NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming. For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html). ``` **Conseils** Vous pouvez appliquer les solutions de contournement suivantes à l’aide d’une opération `VACUUM FREEZE` manuelle pour accélérer le gel de la table. **Augmentation de la mémoire pour l’opération de vacuum** Comme suggéré par la fonction `postgres_get_av_diag()`, il est conseillé d’augmenter le paramètre `autovacuum_work_mem` pour faire face aux contraintes de mémoire potentielles au niveau de l’instance. Même si `autovacuum_work_mem` est un paramètre dynamique, il est important de noter que pour que le nouveau paramètre de mémoire prenne effet, le démon autovacuum doit redémarrer ses applications de travail. Pour ce faire : 1. Vérifiez que le nouveau paramètre est en place. 1. Arrêtez les processus qui exécutent une opération d’autovacuum. Cette approche garantit que l’allocation de mémoire ajustée est appliquée aux nouvelles opérations d’autovacuum. Pour des résultats plus immédiats, pensez à effectuer une opération `VACUUM FREEZE` manuelle avec un paramètre `maintenance_work_mem` augmenté au cours de votre session : ``` SET maintenance_work_mem TO '1GB'; VACUUM FREEZE VERBOSE table_name; ``` Si vous utilisez Amazon RDS et que vous constatez que vous avez besoin de mémoire supplémentaire pour prendre en charge des valeurs plus élevées pour `maintenance_work_mem` ou `autovacuum_work_mem`, envisagez de passer à une classe d’instance avec plus de mémoire. Cela peut fournir les ressources nécessaires pour améliorer les opérations de vacuum manuelles et automatiques, ce qui se traduit par une amélioration des performances globales du vacuum et des bases de données. **Désactivation d’INDEX\$1CLEANUP** L’opération `VACUUM` manuelle de PostgreSQL 12 et versions ultérieures permet d’ignorer la phase de nettoyage de l’index, tandis que l’autovacuum d’urgence dans PostgreSQL 14 et versions ultérieures le fait automatiquement en fonction du paramètre [https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE). **Avertissement** Ignorer le nettoyage de l’index peut entraîner un gonflement de l’index et avoir un impact négatif sur les performances des requêtes. Pour pallier ce problème, pensez à réindexer les index concernés ou à en effectuer le vacuum pendant une période de maintenance. Pour obtenir des conseils supplémentaires sur la gestion des index de grande taille, reportez-vous à la documentation sur [Gestion de la fonction autovacuum avec de grands index](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md). **Opérations de vacuum d’index en parallèle** À partir de PostgreSQL 13, les index peuvent faire l’objet d’un vacuum et d’un nettoyage en parallèle par défaut avec une opération `VACUUM` manuelle. Un processus de travail de vacuum est alors assigné à chaque index. Cependant, pour que PostgreSQL puisse déterminer si une opération de vacuum peut être exécutée en parallèle, des critères spécifiques doivent être remplis : + Il doit y avoir au moins deux index. + Le paramètre `max_parallel_maintenance_workers` doit être défini sur au moins 2. + La taille de l’index doit dépasser la limite de `min_parallel_index_scan_size`, qui est par défaut de 512 Ko. Vous pouvez ajuster le paramètre `max_parallel_maintenance_workers` en fonction du nombre de processeurs virtuels disponibles sur votre instance Amazon RDS et du nombre d’index sur la table afin d’optimiser le délai d’exécution de l’opération de vacuum. Pour plus d’informations, consultez [Opérations de vacuum en parallèle dans Amazon RDS pour PostgreSQL et Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/). ## Trop de tables ou de bases de données pour le vacuum Comme indiqué dans la documentation [The Autovacuum Daemon](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM') de PostgreSQL, le démon autovacuum fonctionne par le biais de plusieurs processus. Cela inclut un lanceur d’autovacuum permanent chargé de démarrer les processus de travail d’autovacuum pour chaque base de données du système. Le lanceur programme ces applications de travail pour qu’elles soient lancées environ toutes les `autovacuum_naptime` secondes par base de données. Avec « N » bases de données, une nouvelle application de travail commence environ toutes les [`autovacuum_naptime`/N secondes]. Cependant, le nombre total d’applications de travail simultanés est limité par le paramètre `autovacuum_max_workers`. Si le nombre de bases de données ou de tables qui nécessitent un vacuum dépasse cette limite, la base de données ou table suivante est traitée dès qu’une application de travail est disponible. Lorsque de nombreuses tables ou bases de données volumineuses nécessitent un vacuum simultané, toutes les applications de travail d’autovacuum disponibles peuvent être occupées pendant une période prolongée, ce qui retarde la maintenance des autres tables et bases de données. Dans les environnements où les taux de transactions sont élevés, ce goulot d’étranglement peut rapidement s’aggraver et potentiellement entraîner des problèmes de vacuum de bouclage au sein de votre instance Amazon RDS. Lorsque `postgres_get_av_diag()` détecte un nombre élevé de tables ou de bases de données, il fournit la recommandation suivante : ``` NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow. ``` ``` NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers. ``` **Conseils** **Augmentation d’autovacuum\$1max\$1workers** Pour accélérer l’opération de vacuum, nous vous recommandons de régler le paramètre `autovacuum_max_workers` afin d’autoriser un plus grand nombre d’applications de travail d’autovacuum simultanées. Si les problèmes de performances persistent, envisagez d’augmenter verticalement votre instance Amazon RDS vers une classe comportant davantage de processeurs virtuels, ce qui peut améliorer encore les capacités de traitement parallèle. ## Un vacuum agressif (pour éviter tout bouclage) est en cours d’exécution L’âge de la base de données (MaximumUsedTransactionIDs) dans PostgreSQL ne diminue que lorsqu’un vacuum agressif (pour empêcher tout bouclage) s’est terminé avec succès. Jusqu’à ce que ce vacuum se termine, l’âge continue d’augmenter en fonction du taux de transaction. La fonction `postgres_get_av_diag()` génère le message `NOTICE` suivant lorsqu’elle détecte un vacuum agressif. Cependant, elle ne déclenche cette sortie qu’après que le vacuum a été actif pendant au moins deux minutes. ``` NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance. ``` Pour plus d’informations sur le vacuum agressif, consultez [Lorsqu’un vacuum agressif est déjà en cours d’exécution](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md). Vous pouvez vérifier si un vacuum agressif est en cours à l’aide de la requête suivante : ``` SELECT a.xact_start AS start_time, v.datname "database", a.query, a.wait_event, v.pid, v.phase, v.relid::regclass, pg_size_pretty(pg_relation_size(v.relid)) AS heap_size, ( SELECT string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ') FROM pg_index i WHERE i.indrelid = v.relid ) AS index_sizes, trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct, v.index_vacuum_count || '/' || ( SELECT count(*) FROM pg_index i WHERE i.indrelid = v.relid ) AS step2_vacuum_indexes, trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct, age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar FROM pg_stat_activity a INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid; ``` Vous pouvez déterminer s’il s’agit d’un vacuum agressif (pour éviter tout bouclage) en vérifiant la colonne de requête dans la sortie. L’expression « pour éviter tout bouclage » indique qu’il s’agit d’un vacuum agressif. ``` query | autovacuum: VACUUM public.t3 (to prevent wraparound) ``` Supposons, par exemple, que vous disposiez d’un bloqueur à l’âge d’un milliard de transactions et d’une table nécessitant un vacuum agressif pour éviter tout bouclage au même âge de transaction. De plus, il existe un autre bloqueur à l’âge de 750 millions de transactions. Après avoir éliminé le bloqueur à l’âge d’un milliard de transactions, l’âge des transactions ne tombera pas immédiatement à 750 millions. Il restera élevé jusqu’à ce que la table nécessitant un vacuum agressif ou toute transaction dont l’âge est supérieur à 750 millions soit finalisée. Au cours de cette période, l’âge des transactions de votre cluster PostgreSQL continuera d’augmenter. Une fois le processus de vacuum terminé, l’âge des transactions tombe à 750 millions, mais recommence à augmenter jusqu’à ce que l’opération de vacuum soit terminée. Ce cycle se poursuit tant que ces conditions persistent, jusqu’à ce que l’âge des transactions atteigne finalement le niveau configuré pour votre instance Amazon RDS, spécifié par `autovacuum_freeze_max_age`. # Explication des messages NOTICE dans RDS pour PostgreSQL La fonction `postgres_get_av_diag()` fournit les messages NOTICE suivants : **Lorsque l’âge n’a pas encore atteint le seuil de surveillance** Le seuil de surveillance `postgres_get_av_diag()` pour identifier les bloqueurs est de 500 millions de transactions par défaut. Si `postgres_get_av_diag()` génère le message NOTICE suivant, l’âge de la transaction n’a pas encore atteint ce seuil. ``` NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2. ``` **Non connecté à la base de données dont l’ID de transaction est le plus ancien** La fonction `postgres_get_av_diag()` fournit le résultat le plus précis lorsqu’elle est connectée à la base de données dont l’ID de transaction est le plus ancien. La base de données dont l’âge de l’ID de transaction est le plus ancien indiqué par `postgres_get_av_diag()` sera différente de « my\$1database » dans votre cas. Si vous n’êtes pas connecté à la bonne base de données, le message NOTICE suivant est généré : ``` NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting. ``` Il est important de se connecter à la base de données dont l’âge de la transaction est le plus ancien pour les raisons suivantes : + **Identification des bloqueurs de tables temporaires :** les métadonnées des tables temporaires étant spécifiques à chaque base de données, elles se trouvent généralement dans la base de données dans laquelle elles ont été créées. Toutefois, si une table temporaire se trouve être le principal bloqueur et qu’elle se trouve dans la base de données contenant la transaction la plus ancienne, cela peut prêter à confusion. La connexion à la base de données appropriée garantit l’identification précise du bloqueur de table temporaire. + **Diagnostic des vacuums lents :** les métadonnées d’index et les informations relatives au nombre de tables sont spécifiques à chaque base de données et sont nécessaires pour diagnostiquer les problèmes de lenteur du vacuum. **La base de données dont l’âge de la transaction est le plus ancien se trouve sur une base de données rdsadmin ou template0** Dans certains cas, les bases de données `rdsadmin` ou `template0` peuvent être identifiées comme étant celles dont l’ID de transaction est le plus ancien. Dans ce cas, `postgres_get_av_diag()` émet le message NOTICE suivant : ``` NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0. ``` Vérifiez que le bloqueur répertorié ne provient d’aucune de ces deux bases de données. Si la présence du bloqueur est signalée dans `rdsadmin` ou `template0`, contactez le support, car ces bases de données ne sont pas accessibles aux utilisateurs et nécessitent une intervention. Il est très peu probable que la base de données `rdsadmin` ou `template0` contienne un bloqueur principal. **Lorsqu’un vacuum agressif est déjà en cours d’exécution** La fonction `postgres_get_av_diag()` est conçue pour signaler lorsqu’un processus de vacuum agressif est en cours d’exécution, mais elle ne déclenche cette sortie que lorsque le vacuum est actif depuis au moins 1 minute. Ce délai intentionnel contribue à réduire les risques de faux positifs. En attendant, la fonction garantit que seuls les vacuums efficaces et significatifs sont signalés, ce qui permet une surveillance plus précise et plus fiable de l’activité du vacuum. La fonction `postgres_get_av_diag()` génère le message NOTICE suivant lorsqu’elle détecte un ou plusieurs vacuums agressifs en cours. ``` NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance. ``` Comme indiqué dans le message NOTICE, continuez à surveiller les performances du vacuum. Pour plus d’informations sur le vacuum agressif, consultez [Un vacuum agressif (pour éviter tout bouclage) est en cours d’exécution](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum) **Lorsque l’autovacuum est désactivé** La fonction `postgres_get_av_diag()` génère le message NOTICE suivant si l’autovacuum est désactivé sur votre instance de base de données : ``` NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary. ``` L’autovacuum est une fonctionnalité essentielle de votre instance de base de données RDS pour PostgreSQL. Elle garantit le bon fonctionnement de la base de données. Elle supprime automatiquement les anciennes versions de lignes, récupère de l’espace de stockage et évite le gonflement des tables, ce qui contribue à garantir l’efficacité des tables et des index pour des performances optimales. En outre, elle protège contre le bouclage des ID de transaction, qui peut interrompre les transactions sur votre instance Amazon RDS. La désactivation de l’autovacuum peut entraîner une baisse à long terme des performances et de la stabilité de la base de données. Nous vous conseillons de laisser cette fonctionnalité activée en permanence. Pour plus d’informations, consultez [Présentation d’autovacuum dans les environnements RDS pour PostgreSQL](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/). La désactivation de l’autovacuum n’arrête pas les vacuums agressifs. Ils se produiront toujours une fois que vos tables auront atteint le seuil `autovacuum_freeze_max_age`. **Le nombre de transactions restantes est extrêmement faible** La fonction `postgres_get_av_diag()` génère le message NOTICE suivant lorsqu’un vacuum de bouclage est imminent. Ce message NOTICE est émis lorsque votre instance Amazon RDS est à 100 millions de transactions avant que de nouvelles transactions ne soient potentiellement rejetées. ``` WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions. ``` Une action immédiate est nécessaire pour éviter toute durée d’indisponibilité de la base de données. Vous devez surveiller de près vos opérations de vacuum et envisager de lancer manuellement une opération `VACUUM FREEZE` sur la base de données concernée afin d’éviter les échecs de transaction.