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. 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 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 de vacuum agressif sont signalés lorsque leur âge dépasse le seuil d’autovacuum adaptatif de 500 millions d’ID de transaction dans RDS.

Quel est l’âge de l’ID de transaction ?

La fonction age() pour les ID de transaction calcule le nombre de transactions survenues depuis le plus ancien ID 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 de vacuum agressif effectue une analyse complète de toutes les pages d’une table, y compris celles qui sont généralement ignorées lors d’un vacuum standard. Cette analyse approfondie vise à « geler » les ID de transaction approchant de leur âge maximum, empêchant ainsi une situation connue sous le nom de bouclage de l’ID de transaction.

Pour que postgres_get_av_diag() signale un bloqueur, celui-ci doit dater d’au moins 500 millions de transactions.