Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
L'analyse d'un VACUUM sur une table d'une de nos bases nous indique le message suivant "DETAIL: 193074 dead row versions cannot be removed yet."
Quel est la signification de ce message, quelles en sont les conséquences et bien sur, comment y remédier?
En vous remerciant par avance de vos informations et réponses.
ps: Le résultat complet du vacuum verbose analyse:
INFO: vacuuming "public.fcommer"
INFO: index "fcommer_ix" now contains 240965 row versions in 1555 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.01s/0.00u sec elapsed 0.71 sec.
INFO: index "i_co_id" now contains 240965 row versions in 1042 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.38 sec.
INFO: index "i_co_id2" now contains 240965 row versions in 1560 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.01s/0.00u sec elapsed 0.40 sec.
INFO: index "i_cosiret" now contains 240965 row versions in 1380 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.39 sec.
INFO: index "i_cosite" now contains 240965 row versions in 1049 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.31 sec.
INFO: index "i_coenseigne" now contains 240965 row versions in 1375 pages
DETAIL: 0 index row versions were removed.
17 index pages have been deleted, 0 are currently reusable.
CPU 0.01s/0.00u sec elapsed 0.56 sec.
INFO: "fcommer": found 0 removable, 240965 nonremovable row versions in 7154 pages
DETAIL: 193074 dead row versions cannot be removed yet.
There were 268 unused item pointers.
1 pages contain useful free space.
0 pages are entirely empty.
CPU 0.13s/0.04u sec elapsed 4.78 sec.
INFO: analyzing "public.fcommer"
INFO: "fcommer": scanned 3000 of 7154 pages, containing 20804 live rows and 80252 dead rows; 3000 rows in sample, 49611 estimated total rows
Hors ligne
Bonjour,
Cela indique que postgreSQL ne pouvait pas récupérer l'espace à cet instant. On peut imaginer qu'une (ou plusieurs) autre transaction travaillait ou verrrouilait sur ces lignes au moment du VACUUM. Si ce message est récurrent, il faut jeter un coup d'oeil dans les tables pg_locks et pg_stat_activity à la recherche de vieilles transactions.
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Pour informations, les dead rows sont des lignes mortes (traduction bête 
). C'est-à-dire des lignes qui ne sont plus visibles par les transactions en cours. Autrement dit, la table est fragmentée. Ce n'est pas grave en soi, tout dépend du taux de fragmentation. 193074 versions mortes de lignes sur 240965 est clairement un gros taux. Il serait bon d'avoir des VACUUM plus fréquents. Un VACUUM FULL pourrait aussi être intéressant pour défragmenter la table. À noter que cette dernière opération n'est pas à faire régulièrement, c'est plutôt à utiliser dans des cas très spéciaux comme un taux élevé de lignes mortes.
Guillaume.
Hors ligne
Bonjour et merci beaucoup pour vos réponses.
Des vacuum sont effectués tous les jours sur la base. La table pg_locks ne contenait pas d'anciennes transactions. Par contre la base est en activité permanante (insert/update/delete/select) et il n'est pas possible d'interrompre le service.
Nous avons toutefois arrêté toutes les activités le temps d'un vacuum FULL, qui a duré 1 heure 1/2 et qui a rétabli la situation (plus de dead rows).
le résultat du vacuum journalier effectué le lendemain, alors que l'activité avait reprise, montre de nouveau quelques deads rows qui ne peuvent pas être supprimés.
Quelles pistes devrions nous suivre?
Hors ligne
Avoir des lignes mortes n'est pas un problème en soi. Au contraire, ça permet d'accélérer les écritures sur la table. Par contre, en avoir trop est un problème car cela va demander plus de mémoire pour les avoir en cache, ce qui veut dire des lectures plus lentes.
L'important est d'avoir des VACUUM assez fréquents pour que les lignes mortes puissent être ré-utilisées rapidement et que du coup la table ne soit pas trop fragmentée.
Guillaume.
Hors ligne
Comme le dit Guillaume, avoir des lignes mortes n'est pas un problème très grave si le VACUUM est exécuté fréquemment.
Par ailleurs, si la base est soumise à une activité constante, il est normal d'obtenir des messages du type "193074 dead row versions cannot be removed yet", là encore l'essentiel est de refaire un VACUUM ultérieurement pour tenter de récupérer ces lignes mortes un peu plus tard.
Pour tout cela, l'autovacuum est une solution pratique, simple et efficace. L'avez-vous activé ?
On peut aussi vous conseiller de tester la version 8.4 qui vient de sortir, car elle dispose d'un tout nouveau mécanisme de gestion des lignes mortes qui pourrait être intéressant dans votre cas...
Pour finir, pouvez-vous nous donner quelques précisions ? Quels est la version de PostgreSQL que vous utilisez ? Quelle est la valeur du paramètres max_fsm_pages ?
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Bonjour et encore merci pour vos réponses.
La version utilisée est 8.2, elle ne peut être changée, nous ne somme pas administrateur du serveur.
la valeur de max_fsm_pages est de 40 000 ce qui était suffisant avant le vacuum full ... et qui ne l'est plus depuis. un Notice en fin de vacuum journalier indique que le besoin augmente tous les jours: 46000, 72000, 90000, 125000.
Nous allons en augmenter la valeur.
Suite à vos conseils, nous pensons également mettre en oeuvre un autovacuum. Reste à régler ses paramètres.
Hors ligne
Avez-vous fait un REINDEX après le VACUUM FULL ? car sinon, vos index doivent être dans un mauvais état.
Guillaume.
Hors ligne
Malheureusement non, le vacuum ayant duré 1h30, nous redoutions le temps du reindex!
Hors ligne
Un Vacuum full va faire grossir indument vos index. Il faut toujours faire un REINDEX après un VACUUM FULL. Ou alors un CLUSTER qui fait les deux.
Guillaume.
Hors ligne
Pages : 1
