Résolution des bloqueurs de vide non identifiables dans

Cette section explore d'autres raisons qui peuvent empêcher l'utilisation de l'aspirateur de progresser. Ces problèmes ne sont actuellement pas directement identifiables par la postgres_get_av_diag() fonction.

Incohérence de l'index

Un indice logiquement incohérent peut empêcher l'autovacuum de progresser. Les erreurs suivantes ou des erreurs similaires sont enregistrées pendant la phase de vide 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

Orientations

Reconstruisez l'index ou ignorez les index en utilisant INDEX_CLEANUP le manuelVACUUM FREEZE.

• Utilisation de l'option CONCURRENTLY : avant la version 12 de PostgreSQL, la reconstruction d'un index nécessitait un verrouillage de table exclusif, limitant ainsi l'accès à la table. Avec la version 12 de PostgreSQL et les versions 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;

  CONCURRENTLY est moins perturbateur, mais il peut être plus lent lorsque les tables sont occupées. Si possible, envisagez de créer l'indice pendant les périodes de faible trafic. Pour plus d'informations, consultez REINDEX dans la documentation de PostgreSQL.

• À l'aide de l'option INDEX_CLEANUP FALSE : si les index sont volumineux et qu'on estime qu'ils nécessitent beaucoup de temps pour être terminés, vous pouvez débloquer l'autovacuum en exécutant un VACUUM FREEZE manuel tout en excluant les index. Cette fonctionnalité est disponible dans PostgreSQL version 12 et versions ultérieures.

  Le contournement des index vous permettra d'éviter le processus d'élimination de l'index incohérent et d'atténuer le problème d'encapsulation. Toutefois, cela ne résoudra pas le problème sous-jacent de page non valide. Pour résoudre complètement le problème de page non valide, vous devez 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 d'Autovacuum, ce qui ralentit le nettoyage des tuples morts et augmente le risque d'encapsulation des identifiants de transaction. Vous pouvez surveiller le taux de transaction en mesurant la différence max(age(datfrozenxid)) entre deux périodes, généralement par seconde. En outre, vous pouvez utiliser les indicateurs de compteur suivants de RDS Performance Insights pour mesurer le taux de transaction (la somme de xact_commit et xact_rollback), qui est le nombre total de transactions.

Compteur	Type	Unité	Métrique
xact_commit	Transactions	Validations par seconde	db.Transactions.xact_commit
xact_rollback	Transactions	Restaurations par seconde	db.Transactions.xact_rollback

Une augmentation rapide indique une charge de transactions élevée, qui peut surcharger Autovacuum, provoquant un gonflement, des problèmes de verrouillage et des problèmes de performances potentiels. Cela peut avoir un impact négatif sur le processus d'aspiration automatique 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 du système L'ensemble du système est peut-être surchargé, ce qui rend difficile pour 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 suivre ses tâches :

1. Réduisez le taux de transaction si possible. Envisagez de regrouper ou de regrouper des transactions similaires dans la mesure du possible.

2. Ciblez des tables fréquemment mises à jour avec un VACUUM FREEZE fonctionnement manuel tous les soirs, toutes les semaines ou toutes les deux semaines en dehors des heures de pointe.

3. Envisagez d'étendre votre classe d'instance pour allouer davantage de ressources système afin de gérer le volume élevé de transactions et d'autovacuum.