Vous n'êtes pas identifié(e).
Bonjour à tous,
J'aimerai savoir s'il était possible de voir où se trouve les stats d'un vacumm ?
en effet suite à un vacuum trop long... étant donné qu'il lui faut un verrou exclusif sur la table. je veux savoir quel verrou bloque le vacuum ??
Merci,
Hors ligne
Seul le VACUUM FULL met un verrou exclusif sur la table. Si votre VACUUM est bloqué, c'est que quelqu'un d'autre accède à la table. La liste des verrous déjà posé se trouve dans le catalogue système pg_locks.
Guillaume.
Hors ligne
Merci,
Sinon je n'arrive pas a voir la différence entre les param : vacuum_cost_delay et vacuum_cost_limit
Merci d'avance,
Hors ligne
Ils permettent de déterminer la 'vitesse' à laquelle vacuum travaille (c'est à dire lui imposer une courte période de repos après une série de traitements). Le but étant d'éviter de surcharger les disques
La doc sur le sujet :
http://docs.postgresql.fr/8.3/runtime-c … ource.html
Attention à ne pas rendre vacuum trop lent. Pendant ce temps, impossible de faire par exemple un alter table sur la table en cours de vacuum.
Marc.
Hors ligne
en résumé :
vacuum_cost_delay : durée du repos du vacuum
vacuum_cost_limit : durée du travail du vacuum
?????
Merci,
Hors ligne
le delay c'est le temps d'attente entre 2 unités de travail vacuum
le limit, c'est la quantité de travail dans une unité de travail de vacuum (l'évaluation pour ce chiffre, c'est les 3 autres paramètres)
donc pour accélérer vacuum : diminuer delay (pas en dessous de 10 ms je crois, après on a des pbs de précision d'horloge sur le système d'exploitation), ou augmenter le cost_limit. Pour le ralentir, on fait évidemment l'inverse 
Marc.
Hors ligne
Merci pour tes réponses,
Seulement dans un cas d'une table de trés grande taille. Est-il normale que le vacuum dure plusieurs heures ?
Quels param peuvent influencés sur la duréé du vacuum autre que ceux cités au dessus ???
PS : comment connaitre la taille d'un base de donnée sous POSTGRESQL ?
Merci d'avance,
Dernière modification par bil69 (13/05/2009 15:59:00)
Hors ligne
Seulement dans un cas d'une table de trés grande taille. Est-il normale que le vacuum dure plusieurs heures ?
Oui. Mais bon tout dépend évidemment de la valeur de « très grande taille » et de « plusieurs heures ».
Quels param peuvent influencés sur la duréé du vacuum autre que ceux cités au dessus ???
À priori, rien. Avec un vacuum_cost_delay à 0, la vitesse est maximale. Ensuite, il faut quand même qu'il lise la table complète donc ça peut prendre du temps.
PS : comment connaitre la taille d'un base de donnée sous POSTGRESQL ?
SELECT pg_size_pretty(pg_database_size('la base de données'));
Guillaume.
Hors ligne
En fait, si il y a un paramètre : le maintenance_work_mem, si la table a des index.
Plus la valeur est élevée, moins vacuum aura de passes à faire sur les index.
Marc.
Hors ligne
Exact, j'avais oublié ce paramètre. Honte sur moi. Cela étant dit, les index sur la table n'ont rien à voir. Ou j'ai loupé un truc ?
Guillaume.
Hors ligne
A ma connaissance, il collecte les tuples effacés lors d'un vacuum pour nettoyer les index. Mais pas le temps de vérifier là
Marc.
Hors ligne
Bon, finalement, j'ai voulu vérifier
Le travail se fait dans lazy_scan_heap, qui stocke les tid via lazy_record_dead_tuple, et une fois que la maintenance_work_mem est presque pleine de tuples, vacuum fait un scan des index, via lazy_vacuum_index, qui lui même fait un index_bulk_delete, pour virer les enregistrements qui correspondent à ces tid, puis retourne dans la table pour faire le ménage (une fois que les index sont nettoyés, pas avant). L'intérêt d'avoir un gros maintenance_work_mem, c'est donc de réduire le nombre de scans de l'index avant tout (je pense...).
C'est un truc qu'on constate et qui est assez frustrant avec les vacuum partiels de la 8.4 : on se tape quand même un scan d'index sur tous les index de la table, même s'il n'y a quasiment rien à faire dans le heap.
Marc.
Hors ligne
MERCI BEAUCOUP
Je vais voir ça de plus près !!! mais ça l'air très compliqué !!
Hors ligne
Bonjour,
SELECT pg_size_pretty(pg_database_size('pagila'));
pg_size_pretty
----------------
4573 MB
(1 row)
SELECT pg_database_size('pagila');
pg_database_size
------------------
4795362924Voilà j'aimerai savoir quelle est la différence entre ces 2 commandes ? Je voulais avoir un base d'au moins 2 giga !!
insert into film (film_id, title, language_id) select generate_series(1001,1000000), 'RAMBOAZERTYUIOPQSDFGHJKLMWXCVBNAZERUEZOEZEZIJEZOINJDSFCNDCDS.NFKDSLJFVCNX.NSDLJFDLSJFDSJFCDSLKF?V?DPFJDOPFJZEFHDSKNFDSLFNDSLJFPODSJFNDFKLDSNFLDSJFPDSJFDSNFLXCNLJDSJFDSNFEZKFODSK?FCDSLM?DSKJDDLC?SLDMKFPODSDSDSMLFSDMKPO' || generate_series(1001,1000000),1;
ERROR: could not extend relation 1663/16863/16894: No space left on device
HINT: Check free disk space.Merci d'avance,
Dernière modification par bil69 (14/05/2009 10:19:36)
Hors ligne
En fait, ca ne l'est pas, j'étais pas très clair hier soir dans mes explications
Le fonctionnement de vacuum, grosso modo, c'est ceci :
1) il part en full scan sur la table (sauf en 8.4, ou il sait ou aller chercher dans la table, mais c'est une autre histoire), et stocke tous les tid (tuple id, c'est l'adresse de l'enregistrement dans la table, qui permet de l'identifier de façon unique et est ce que l'index stocke) des enregistrements qui sont supprimables.
2) une fois qu'il a rempli maintenance_work_mem de tid (ou bien fini le parcours de la table), il scan les index 1 par 1 pour supprimer toutes les références à ces tid
3) une fois le nettoyage des index faits, il revient sur la table et fait la suppression effective des enregistrements dans les blocs, et continue le scan de la table si il n'a pas fini (retour à 1)
Marc.
Hors ligne
Pour ce qui est de la commande, le second ordre affiche la taille en octets, le premier la convertit en une version lisible par un cerveau humain (en Méga octets).
Ensuite, l'erreur, comme indiquée, c'est que le disque est plein et qu'il ne peut donc plus agrandir une des relations, probablement la table.
Marc.
Hors ligne
Bon, finalement, j'ai voulu vérifier
Le travail se fait dans lazy_scan_heap, qui stocke les tid via lazy_record_dead_tuple, et une fois que la maintenance_work_mem est presque pleine de tuples, vacuum fait un scan des index, via lazy_vacuum_index, qui lui même fait un index_bulk_delete, pour virer les enregistrements qui correspondent à ces tid, puis retourne dans la table pour faire le ménage (une fois que les index sont nettoyés, pas avant). L'intérêt d'avoir un gros maintenance_work_mem, c'est donc de réduire le nombre de scans de l'index avant tout (je pense...).C'est un truc qu'on constate et qui est assez frustrant avec les vacuum partiels de la 8.4 : on se tape quand même un scan d'index sur tous les index de la table, même s'il n'y a quasiment rien à faire dans le heap.
Pourrais tu me passer le lien stp
Merci,
Hors ligne
En fait, ca ne l'est pas, j'étais pas très clair hier soir dans mes explications
Le fonctionnement de vacuum, grosso modo, c'est ceci :
1) il part en full scan sur la table (sauf en 8.4, ou il sait ou aller chercher dans la table, mais c'est une autre histoire), et stocke tous les tid (tuple id, c'est l'adresse de l'enregistrement dans la table, qui permet de l'identifier de façon unique et est ce que l'index stocke) des enregistrements qui sont supprimables.
2) une fois qu'il a rempli maintenance_work_mem de tid (ou bien fini le parcours de la table), il scan les index 1 par 1 pour supprimer toutes les références à ces tid
3) une fois le nettoyage des index faits, il revient sur la table et fait la suppression effective des enregistrements dans les blocs, et continue le scan de la table si il n'a pas fini (retour à 1)
Merci de m'avoir eclairer
Aurais tu un lien ... ??? stp
Dernière modification par bil69 (15/05/2009 10:49:07)
Hors ligne
Marc, on est bien d'accord que le VACUUM ne supprime physiquement rien, mais qu'il stocke des pointeurs vers les espaces libres dans une structure en mémoire ? (la fameuse structure FSM) que ce soit pour les tables et pour les index d'ailleurs...
Guillaume.
Hors ligne
VACUMM VERBOSE
Affiche un rapport détaillé de l'activité de vacuum sur chaque table. Peut être utilisé pour aider à déterminer le paramètrage approprié pour max_fsm_pages, max_fsm_relations et default_statistics_target.
il me semble que ces param rentrent en compte pour avoir un vacuum optimisé...
merci,
Hors ligne
Non, on n'est pas d'accord
C'est le boulot de la fonction lazy_vacuum_heap, appelée après le nettoyage des index, dans le lazy. Elle fait un ItemIdSetUnused pour les tuples à supprimer, page par page, et réorganise les pages derrière si nécessaire. Tout ça se trouve dans lazy_scan_heap.
C'est aussi pour ça qu'on a un vacuum_cost_page_dirty, pour avoir le coût du 'salissage' d'une page quand on a du nettoyage dedans.
Désolé pour l'appropriation du thread, bil69, mais c'est un sujet passionnant
Marc.
Hors ligne
bil69 : ces paramètres n'optimisent pas les performances du vacuum. Ils permettent (les max_fsm) de dimensionner la free space map (une structure mémoire qui stocke la quantité de mémoire libre dans chaque bloc non totalement rempli d'une table ou d'un index) afin de pouvoir mémoriser tous les blocs 'libres' de la base. Le problème étant que si la FSM est trop petite, on se retrouve avec des blocs libres mais non réutilisables (les processus postgres ne savent pas que ces blocs sont libres) et une base qui grossit inutilement. Ces deux paramètres disparaissent en 8.4, on a une sorte de free space map automatique.
le default_statistics_target ne permet que de modifier la finesse d'échantillonnage et la quantité de données stockées pour les statistiques sur les tables (et les histogrammes), donc de savoir par exemple qu'il y a 1% d'enregistrements ayant 'toto' dans la colonne nom de famille, et d'obtenir ce 1% avec plus ou moins de précision, ce qui permettra à l'optimiseur de mieux choisir ses plans d'exécution.
Marc.
Hors ligne
Merci pour tes réponses !!!
C'est pas grave ça m'intéresse justement de connaitre les mécanismes du vacuum afin de l'optimiser au maximum !!! smile
en résumé : avoir la FSM suffisamment grande pour pas perdre des tuples suite à un vacuum (surtout si avant le vacuum on a fait un gros delete)
Sinon si tu dois optimisé un vacuum qui agit sur une base de plusieurs millions de tuples, à part maintenance_work_mem quels seront les autres param à étudier ???
Merci,
Hors ligne
voila, la FSM doit être suffisamment grande. Pour savoir si elle est suffisamment grande, 2 solutions :
- regarder les messages à la fin d'un vacuum sur une base
- utiliser le contrib pg_freespacemap, qui permet de faire des requêtes sur la fsm, et voir son état de remplissage
Pour un gros vacuum, le maintenance_work_mem est je pense le plus important : c'est ce qui va déterminer combien de passes tu feras sur tes index (tu le verras dans le vacuum verbose, si tu vois passer plusieurs fois le même index...)
Ensuite, avoir pas mal de shared_buffers peut aider aussi (histoire que les écritures dues au vacuum puissent être retardées un maximum et faites de façon asynchrones), et surveiller les checkpoints (checkpoint_segments) doit être assez gros pour ne pas se retrouver à faire un checkpoint toutes les 10 secondes...
Je pense que ce sont les paramètres les plus importants.
Un dernier truc : maintenance_work_mem, les checkpoints et tout ça, c'est dans le cas ou il y a un grand nombre d'enregistrements à nettoyer. Si une table fait 10 millions de tuples, mais qu'il n'y en a que 10 000 à nettoyer, ça n'aura pas beaucoup d'impact.
Marc.
Hors ligne
Merci beaucoup !!!!!!!
Hors ligne