Vous n'êtes pas identifié(e).
Bonjour,
L'un d'entre vous a t'il déjà expérimenté pg_repack ?
https://github.com/reorg/pg_repack
Est-il utilisable raisonnablement en production ?
sans danger ?
Merci à vous pour votre retour d'expérience.
Cordialement,
Sébastien.
Hors ligne
Personnellement, je m'en tiens à https://www.postgresql.org/message-id/C … .gmail.com
> [3] https://github.com/reorg/pg_repack/issues/152
Wow. That's really bad. It will corrupt your database.
surtout que l'issue n'est toujours pas fermée.
Julien.
https://rjuju.github.io/
Hors ligne
pgcompacttable est une alternative plus sûre (script perl qui génère des UPDATE) : https://github.com/dataegret/pgcompacttable
Hors ligne
Sauf erreur de ma part cet outil à cependant d'autres inconvénients:
- il va devoir s'exécuter pendant très longtemps étant donné qu'il va essayer de réduire le bloat par succession d'UPDATE
- il risque de générer plus de WAL du fait du mouvement de chaque ligne + index associés + ensuite différent REINDEX
- les index vont se retrouver extrêment fragmentés durant l'exécution du fait de la multitude d'INSERT effectués, ce qui risque de nuire aux performances. C'est à mon avis d'autant plus problématique que l'exécution risque d'être assez longue
Julien.
https://rjuju.github.io/
Hors ligne
merci pour vos réponses.
Dois-je en conclure qu'il n'y a pas de salut en dehors de vacuum full ?
Cordialement,
Sébastien.
Hors ligne
Salut,
pgcompacttable fait en sorte d'être lent, pour justement éviter de surcharger le système. L'avantage des UPDATE est que l'outil défragmente lentement la table. Un vacuum est exécuté régulièrement durant toute la période du traitement afin de libérer de l'espace de façon "incrémentale" dirons nous.
Par défaut, pgcompacttable tente de limiter son impact sur le système en appelant "ionice -c 3" sur son backend. En théorie donc, le backend ne sera actif qu'en période de faible activité en IO.
Coté index, il me semble que l'outil utilise un "create index concurrently"/"drop index concurrently" et gère les contraintes associées. Il va donc utiliser un verrou bloquant lors de la bascule d'index, mais l'opération est en théorie plus courte. reste que la remarque de rjuju est toujours valable à propos de leur performance... À mesurer, puis déterminer si le jeu en vaut la chandelle. Un traitement plus ou moins agressif et régulier pourrait aussi limiter le problème, par rapport à un traitement d'urgence après une longue période de non maintenance. En attendant, faute de mieux...
Enfin, il reste aussi pgcompact, qui utilise le même principe: https://github.com/grayhemp/pgtoolkit/b … /pgcompact
Mais ce dernier est abandonné et n'a plus bougé depuis longtemps. Néanmoins, si vous avez le temps d'y jeter un œil, n'hésitez pas à partager vos conclusions 
++
Hors ligne
Par défaut, pgcompacttable tente de limiter son impact sur le système en appelant "ionice -c 3" sur son backend. En théorie donc, le backend ne sera actif qu'en période de faible activité en IO.
C'est cependant à double tranchant. Cela peut tout à fait avoir le résultat opposé à ce qu'on cherche, notamment si le processus n'est pas schédulé alors qu'il a un lightweight lock, ou pire un spinlock.
Au final, si la fragmentation supplémentaire sur les index ne pose pas trop de problème de performance et si le fait d'avoir une tâche qui s'exécute pendant de longues heures voire plusieurs jours n'est pas un problème, c'est probablement la meilleure alternative à VACUUM FULL.
Julien.
https://rjuju.github.io/
Hors ligne
Par défaut, pgcompacttable tente de limiter son impact sur le système en appelant "ionice -c 3" sur son backend. En théorie donc, le backend ne sera actif qu'en période de faible activité en IO.
C'est cependant à double tranchant. Cela peut tout à fait avoir le résultat opposé à ce qu'on cherche, notamment si le processus n'est pas schédulé alors qu'il a un lightweight lock, ou pire un spinlock.
Yep...ceci dit, j'ai du mal à estimer si ce type de situation puisse être très fréquente...
pg_compact n'est pas exposé à ce risque car lui permet de contrôler l'impact système non pas avec un outil externe (ici ionice) indépendant de sa volontée, mais en prenant lui même des pauses en fonction du paramétrage passé. Le rythme est donc contrôlé, mais forcé. Bref, dommage qu'il soit à l'abandon 
Hors ligne
Les verrous étant justement pris au moment de faire des IO pour éviter des accès concurrents, je pense que ça pourrait réduire les performances globales plutôt qu'aider, sur des serveurs bien chargés.
Julien.
https://rjuju.github.io/
Hors ligne
