PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 18/06/2021 08:43:52

ruizsebastien
Membre

pg_repack

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

#2 18/06/2021 09:14:04

rjuju
Administrateur

Re : pg_repack

Personnellement, je m'en tiens à https://www.postgresql.org/message-id/C … .gmail.com


Robert Haas a écrit :

> [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.

De plus: https://github.com/reorg/pg_repack/issues/135

Hors ligne

#3 21/06/2021 11:47:26

krysztophe
Membre

Re : pg_repack

pgcompacttable est une alternative plus sûre (script perl qui génère des UPDATE) : https://github.com/dataegret/pgcompacttable

Hors ligne

#4 22/06/2021 05:37:02

rjuju
Administrateur

Re : pg_repack

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

Hors ligne

#5 22/06/2021 09:57:12

ruizsebastien
Membre

Re : pg_repack

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

#6 22/06/2021 10:30:18

ioguix
Administrateur

Re : pg_repack

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 smile


++

Hors ligne

#7 22/06/2021 11:18:12

rjuju
Administrateur

Re : pg_repack

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.

Hors ligne

#8 22/06/2021 13:43:25

ioguix
Administrateur

Re : pg_repack

rjuju a écrit :

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 hmm

Hors ligne

#9 22/06/2021 15:16:20

rjuju
Administrateur

Re : pg_repack

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.

Hors ligne

Pied de page des forums