Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'ai lu que la requette CLUSTER permettait de ré-ordonner une table (c'est du moins ce que j'ai compris.).
Est-ce que ce serait l'équivalent d'un VACUUM FULL par exemple ?
Cela permet-il vraiment d'obtenir de meilleurs performance que une table ou ça n'a rien à voire ?
+Eric.
Hors ligne
Cluster permet de réordonner la table, ce que ne fait pas vacuum full. Par contre, cluster crée une nouvelle table pour le faire, ce qui prend de la place. La plupart du temps cluster est plus rapide.
Ceci dit, il faut être capable de décider sur quoi clusteriser : l'idée est de regrouper physiquement, dans les mêmes blocs, des enregistrements susceptibles d'être souvent ramenés ensemble dans une même requête. Il faut donc une connaissance de l'application et des requêtes exécutées.
L'exemple typique, c'est une table de clients, sur laquelle les utilisateurs recherchent le plus souvent les clients par leur nom. On aura fortement intérêt à clusteriser sur le nom dans ce cas (surtout si l'application permet de faire des recherche de type like sur le début du nom).
Évidemment, le problème c'est qu'on ne peut clusteriser que sur un seul index. Et qu'on ne peut clusteriser que sur ce qui est indexé…
Donc ça permet d'avoir des meilleures perfs. Mais pas en clusterisant au hasard. Et rarement sur la clé primaire, surtout si elle est technique (autogénérée).
Marc.
Hors ligne
Merci pour la réponse (c'est rapide!).
Ca à l'air intéressant mais plus destiné aux développeurs à priori.
En fait mon objectif c'est d'optimiser des tables sur lesquelles il y a beaucoup de mouvement (UPDATE, DELETE, INSERT en masse).
J'ai remarqué que la requette VACUUM FULL sur les tables incriminées améliorait les temps de réponses de l'application.
J'ai donc imaginé de lance tous les jours un VACUUM FULL suivit d'un REINDEX.
Mais peut être peut-on faire plus subtil ?
Aurais-je intérêt à faire un ANALYZE en plus ?
Merci d'avance.
+Eric.
Hors ligne
Si c'est le cas, c'est, je pense, que le vacuum "normal" n'est pas passé assez souvent, ou que la free space map est trop petite. Le vacuum full, c'est plus une mesure desespérée qu'autre chose. Quelle version de postgres ? y a t'il un autovacuum ? si oui, est ce qu'il se déclenche ?
Par contre oui, autant passer un analyze en même temps que vacuum.
Marc.
Hors ligne
Effectivement les perfs de nos applis web deviennent parfois désespérentes...
Une vielle version de postgres 7.4.23 sur Debian.
le vacuum analyze est passé tous les jours.
Il n' y a pas de autovacuum, je me suis laissé dire qu'il était buggé.
Pour exemple:
J'ai une table de -300 000 lignes, ~30 colonnes qui fait plus de ~1.5Go et qui doit tomber à ~Mo après un vacuum full.
+Eric.
Hors ligne
Ok. oui avec cette version autovacuum était plutot approximatif.
Vu l'activité (passage de qq Mo a 1500Mo chaque jour), le vacuum devrait être beaucoup plus fréquent.
Essayez de le passer chaque heure, voire plus fréquemment.
Pour info, combien vaut max_fsm_pages à l'heure actuelle ? Si c'est moins de 100 000 je vous conseille de l'augmenter, pour au moins pouvoir contenir tous le blocs de cette table. Par contre cela risque de vous demander d'augmenter shmmax au niveau du système.
Des liens vers les docs à lire avant de se lancer :
http://docs.postgresql.fr/7.4/runtime-c … G-RESOURCE
http://docs.postgresqlfr.org/8.4/kernel-resources.html (elle n'existait pas dans la doc de la 7.4)
Dernière modification par Marc Cousin (15/09/2009 15:49:48)
Marc.
Hors ligne
* Pour être plsu précis c'est plutôt ~100Mo par jour.
* max_fsm_pages vaut 20 000 (valeur par défaut). Je vais regarder pour auguementer.
Je suppose que cette valeur est partagée par toutes les bases, Je devrais en tenir compte, non ?
* Merci pour la doc.
Hors ligne
* Ok, c'est déja plus raisonnable, mais si la taille de la table est multipliée entre le matin et le soir, c'est qu'il n'y a pas assez de vacuum.
* Oui, la valeur est pour toutes les bases. 20 000, ca veut dire que le système ne peut tracer, en tout, que 80 Mo de pages réutilisables après le vacuum.
Marc.
Hors ligne
Bonjour,
Effectivement le VACUUM toute les heures améliorement beaucoup les choses (testé sur une autre table à problème).
Question bête un VACUUM ANALYZE c'est bien l'équivalent des deux commandes séparée (VACCUM et ANALYZE) ?
+Eric.
Hors ligne
oui, sachant qu'en les passant en même temps, on augmente ses chances que les données soient dans le cache et donc de ne pas faire trop d'entrées-sorties inutiles.
Le vacuum pourrait très bien être toutes les minutes si c'est justifié. Ça dépend vraiment de l'activité sur la table (qui peut être tracée en activant stats_row_level en 7.4)
Marc.
Hors ligne
Le stats_row_level est à true dans postgresql.conf.
Je suppose que le résultat est stocké dans pg_stat_*_tables, en tout cas ce sont les infos que j'ai utilisé pour identifier les tables à "problèmes".
Par rapport à ce que j'ai lu et compris de postgres et de sa gestion des updates/insert/delete j'ai fait une requette qui me ramène les tables les plus mouvementées.
Mais je reconnais volontier que je ne sais pas forcement bien en interpréter le résultat.
Pour l'une des tables les plus solicités j'obtiens ceci:
relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del
---------+----------+--------------+----------+---------------+-----------+-----------+-----------
offre | 10169 | 2813393725 | 554878 | 687402756 | 853 | 620862 | 0
(1 ligne)Question bête (encore): les valeurs représentent un cumul depuis la première mise en route de postgres ?
Dernière modification par Erjo (16/09/2009 14:25:08)
Hors ligne
Oui, les valeurs sont un cumul. On peut soit calculer le différentiel soit même entre 2 relevés, soit les remettre à zéro avec pg_stat_reset() (personnellement j'historise à intervalle régulier le contenu de pg_stat_user_tables dans une table à moi.
Habituellement un vacuum commence à être justifié à partir de 20% d'enregistrements supprimé ou mis à jour (pas insérés). C'est la valeur par défaut d'auto vacuum dans les versions récentes.
Bref le mieux c'est peut être d'historiser le contenu de cette vue toutes les quelques minutes afin de pouvoir évaluer le pourcentage de mise à jour dans une journée. Et de là trancher pour la politique de vacuum.
Marc.
Hors ligne
Bonjour,
Merci pour touts ces infos, les choses deviennent plus claires.
J'ai retenu l'idée de l'historisattion (excellente). Ca ma permet de comprendre un peut mieux comment "fonctionne" cette table.
J'ai fait un pg_stat_reset et programmé un cron pour collecter et stocker les stats de cette table toutes les 15 mn.
A vue de nez je pense que les 20% sont largement atteint.
+Eric.
Hors ligne
Pages : 1