Vous n'êtes pas identifié(e).
Pages : 1
Bonjour tout le monde,
Par manque de documentation je voudrai savoir si quelqu'un à un retour d'expérience avec pg_squeeze?
Le problème c'est que je ne peux pas scheduler une tâche sur une table.
Il est expliqué dans la documentation (https://github.com/cybertec-postgresql/pg_squeeze), qu'il faut renseigner la table (squeeze.tables) surtout la colonne (schedule) qui contient la paramètre de la date(jour de la semaine)/heure
du déclenchement.
Pour ma part j'ai renseigner cette table mais rien ne se passe.
Je surveille le log PostgreSQL (log_min_duration_statement='0'), je n'ai rien vu et la taille de la table bloatée est toujours le même?!
en revanche quand j’exécute la fonction "SELECT squeeze.squeeze_table('squeeze', 't_test', null, null, null);" ça fonctionne et la taille de la table diminue.
les paramètres :
squeeze.worker_autostart = 'ma_base'
squeeze.worker_role = 'postgres'
sont bien renseignés
J'ai aussi modifié ces paramètres "free_space_extra,min_size et vacuum_max_age" dans (tables) en diminuant leurs valeurs toujours rien ne se d’éclanche; en tout cas la table est toujours bloatée et je ne voit d'erreur
Est ce que j'ai oublié une/des étapes
Par avance Merci
Hors ligne
Bonjour,
Pour ma part c'est la première fois que j'entends parler de cette extension. À votre place j'ouvrirais une issue sur le dépot github.
Julien.
https://rjuju.github.io/
Hors ligne
Merci Julien pour ta réponse,
Par ailleurs je te conseil si tu as la possibilité de le tester ça l'air intéressant.
Merci encore
Hors ligne
Je ne pense pas utiliser un jour cette extension en production. pg_repack avait (et a toujours) un bug sur le freeze pouvant corrompre les données, et après une rapide vérification je n'ai aucune confiance sur la gestion de cette partie dans cette extension. Cf https://github.com/cybertec-postgresql/ … 3124-L3297
Je note particulièrement que le commentaire de la fonction mentionne :
* XXX Unlike PG core, we currently receive neither frozenXid nor cutoffMulti
* arguments. Instead we only copy these fields from r2 to r1. This should
* change if we preform regular rewrite instead of INSERT INTO ... SELECT ...
alors que le code fait autre chose :
/*
* Set rel1's frozen Xid and minimum MultiXid.
*/
if (relform1->relkind != RELKIND_INDEX)
{
TransactionId frozenXid;
MultiXactId cutoffMulti;
frozenXid = RecentXmin;
Assert(TransactionIdIsNormal(frozenXid));
/*
* Unlike CLUSTER command (see copy_heap_data()), we don't derive the
* new value from any freeze-related configuration parameters, so
* there should be no way to see the value go backwards.
*/
Assert(!TransactionIdPrecedes(frozenXid, relform2->relfrozenxid));
relform1->relfrozenxid = frozenXid;
cutoffMulti = GetOldestMultiXactId();
Assert(MultiXactIdIsValid(cutoffMulti));
Assert(!MultiXactIdPrecedes(cutoffMulti, relform2->relminmxid));
relform1->relminmxid = cutoffMulti;
}Je n'ai pas cherché à savoir si cela vient d'une modification dans postgres ou de cette extension, mais c'est un point particulièrement critique et il n'y a aucun commentaire expliquant pourquoi cette approche est correcte. Surtout si le code provient de CLUSTER, qui détient un verrou exclusif durant toute l'opération, alors que cette extension n'a pas du tout le même verrouillage.
Bref, personnellement je n'ai pas confiance dans cette extension et si j'étais confronté à un problème de bloat excessif je chercherais plutôt un moyen d'éviter l'apparation de bloat trop important plutôt que risquer une corruption ou perte de données.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
....personnellement je n'ai pas confiance dans cette extension et si j'étais confronté à un problème de bloat excessif je chercherais plutôt un moyen d'éviter l'apparation de bloat trop important plutôt que risquer une corruption ou perte de données.
Au fait là on est au cœur du sujet:
Entre pg_repack qui utilse des triggers et demande d'ajouter de l'espace disque pour "défragmenter" les tables avec une complexité si la tâche s'arrête ou ne fini pas pour une raison ou pour une autre...etc
pg_squeeze qui un nouveau produit (extension) avec peu de documentation...
Comment faire mieux tout en évitant ces risques et préservant les données et leurs sécurité?
Le sujet est riche peut être mais tu pourras STP donner les grandes lignes. Le but c'est d'éviter un éventuel "lock exclusif" avec le "vacuum full" et réorganisation des tables et recupération de l'espace vide pour une meilleure optimisation.
Par avance merci
Dernière modification par lemjid (17/08/2021 10:15:33)
Hors ligne
Il faut idéalement éviter le besoin de défragmenter, c'est-à-dire :
1) chercher la ou les tables fragmentées
2) chercher pourquoi la fragmentation arrive, à quelle fréquence etc
3) faire en sorte que la fragmentation reste sous controle
C'est difficile d'aller plus dans le détail vu que l'étape 3) dépend de l'étape 2), et l'étape 2) peut être causée par tellement de chose. Il existe probablement des cas pathologiques ou la fragmentation ne peut pas être évitée et où faire un vacuum full (ou équivalent) est obligatoire, mais je n'en ai personnellement jamais rencontré. Par contre des cas où éviter de la fragmentation implique des modifications plus ou moins importante dans le code client, c'est fréquent.
Julien.
https://rjuju.github.io/
Hors ligne
..3) faire en sorte que la fragmentation reste sous controle ...
Pour ce qui est recherche et listing des tables fragmentées, c'est clair. Pour le pourquoi et fréquence c'est souvent des mises à jours intensives (batchs) sur les tables de la base (certaines tables plus que d'autres).
Reste le point "3", contrôler la fragmentation reste un peu vague. Comme on maitrise pas le code applicatif (les données fonctionnelles), on peut que constater après coup le fragmentation. On peut aussi connaitre la fréquence voir savoir en avance de phase qu'il y aura un batch qui va insérer X lignes sur tel ou tel tables chose qu'on ne peut pas éviter et encore moins l'interdir.
Donc à quel niveau on peu contrôler? S'il s'agit juste d'avoir les informations que j'ai cité. Permettez moi cette question terre à terre, ça me servira à quoi ce contrôle comme je l'ai cité?
Par avance merci
Hors ligne
Tout d'abord, quand je parle de "contrôler la fragmentation" je ne veux dire d'essayer d'avoir 0% de bloat à tout prix. C'est relativement impossible et c'est de toutes façons une mauvaise idée : certaines optimisations existent pour profiter de cette fragmentation. Ce que je veux dire c'est de faire en sorte d'avoir une fragmentation relativement stable. Avoir 1% de bloat, 10% ou même 30% n'est pas un problème en soi, le problème est d'avoir une quantité de fragmentation qui continue toujours à augmenter. Et c'est ça qu'il faut corriger.
Dans votre cas (au passage des insertions n'entrainent pas de fragmentation), si vous avez de la fragmentation à cause de batch de modifications, la solution est probablement d'effectuer un VACUUM juste après ces batchs, ou après les batch les plus volumineux. Vous aurez certes de l'espace perdus suite à ces bachs, mais l'espace sera presque immédiatement réutilisable, et vous fonctionnerez donc avec une sorte de "circuit fermé" avec vos X% de fragmentation, qui devrait à priori correspondre à la quantité de modification effectuée par votre plus grand batch, ou votre plus grande série de batch, en fonction de ce que vous faites.
Le seul problème serait si vous avez une table gigantesque, et un de vos batch supprime une grande partie des données (mais pas suffisamment pour rendre un VACUUM FULL presque immédiate par exemple), ou réécrit l'intégralité des données ou presque. Dans ce cas effectivement vous pourrez garder un bloat sous controle, mais il sera pourra représenter un espace de stockage trop important pour que de futures écritures réutilisent l'espace avant de longs mois voire années. Dans ce cas, le seul moyen est effectivement de trouver un compromis acceptable (découper le batch en plusieurs transaction et effectuer des vacuums au milieu, utiliser du partitionnement pour supprimer des tables plutôt que des lignes...).
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1