Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Existe t'il un moyen d'estimer le temps d’exécution d'un VACUUM FULL ?
Sur une base 9.0+, je pense que diviser la vitesse moyenne de lecture+ecriture du disque par la taille de la base doit être pas si mal comme estimation.... Mais pour une base 8.3 ou 8.4 une idée ?
Hors ligne
Même en 9.0, l'estimation va être fausse: la réécriture de la table va être effectivement à peu près ce temps là. Par contre, il y aura encore toute la reconstruction des index de la table derrière.
Pour une 8.3 ou une 8.4, c'est très aléatoire, puisque c'est fonction avant tout de votre fragmentation (donc du nombre d'enregistrements à déplacer) et du nombre d'index.
Marc.
Hors ligne
Pour une version 9.0, oui, je pense que l'estimation peut être bonne si on ne tient compte de la réécriture que des tables. En effet, un VACUUM FULL ne réécrit pas les index et il n'est pas incohérent d'avoir plus de volumes pour les index que pour les tables. Attention aussi que cela dépend beaucoup des autres activités du serveur (et encore plus en cas de virtualisation).
Pour des bases en 8.3, 8.4 (en fait pour tout ce qui est inférieur à la 9.0), l'implémentation du VACUUM FULL est complétement différente. Il est bien plus long car il passe son temps à déplacer des blocs, donc à déplacer la tête d'écriture, ce qui est extrêmement coûteux.
Ceci étant dit, dans la majorité des cas, le VACUUM FULL ne doit pas être utilisé.
Guillaume.
Hors ligne
Il me semble avoir fait des tests en 9.0 et le résultat était que lorsque l'on faisait un VACUUM FULL sur une table, les indexes ce cette table subissaient eux aussi un VACUUM. Est ce que ça reconstruit l'index ou juste récupère les "trous", ça je ne saurais pas dire. C'est pourquoi je pensais que si je faisais un VACUUM FULL sur une base, diviser sa tailler par la vitesse de mes disques me donnerait une bonne estimation.
En 8.x, j'ai entendu dire que le VACUUM FULL pouvait prendre plus d'une journée et c'est ce que je voudrais éviter...
> Ceci étant dit, dans la majorité des cas, le VACUUM FULL ne doit pas être utilisé.
J'en suis bien conscient, mais je me trouve face a une base sur laquelle aucun VACUUM n'a lancé depuis plus de 6 mois, et beaucoup de DELETE ont été effectués.
Hors ligne
Il me semble avoir fait des tests en 9.0 et le résultat était que lorsque l'on faisait un VACUUM FULL sur une table, les indexes ce cette table subissaient eux aussi un VACUUM.
L'action du VACUUM FULL sur une table est de défragmenter la table de façon à récupérer de la place disque sur le système de fichiers associés. Les index ne sont pas subi au même traitement avec le VACUUM FULL. Il faut utiliser REINDEX pour ça. Pour les versions inférieures à la 9.0, l'implémentation du VACUUM FULL avait même tendance à faire grossir très fortement les index.
Tout ça pour dire que le VACUUM FULL ne traite pas les index.
En 8.x, j'ai entendu dire que le VACUUM FULL pouvait prendre plus d'une journée et c'est ce que je voudrais éviter...
Sans contexte, ça a peu de sens. Mais, oui, un VACUUM FULL peut durer très longtemps, surtout sur les versions antérieures à la 9.0. L'ancienne implémentation nécessitait beaucoup de déplacements de la tête d'écriture, ce qui est très coûteux.
Guillaume.
Hors ligne
En 9.0, Vacuum Full traite les index: il crée une nouvelle table en scannant la table principale (comme une commande CLUSTER, mais par ctid croissant au lieu de suivre un index). Il est donc bien obligé de recréer les index…
Marc.
Hors ligne
Pages : 1
