Vous n'êtes pas identifié(e).
Bonjour,
J'aimerai avoir une base de test (3 giga), j'ai trouvé que l'outil pgbench pourrait me servir mais
Est ce que la contrib pgbench est approprié c'est à dire l'initialisation d'une table de 3 giga ??? ainsi que le test de vacuum ???
Merci d'avance,
Hors ligne
Oui, ce module permet de créer des bases de différentes tailles. Voir les options en ligne de commande dans la doc et dans l'aide en ligne.
Guillaume.
Hors ligne
Merci,
Ou se trouve cette contrib STP ????
Merci d'avance,
Hors ligne
Tout dépend de la plateforme (OS) que vous utilisez.
Guillaume.
Hors ligne
OS : LINUX
Hors ligne
Votre distribution linux doit donc avoir un package contrib pour la version de PostgreSQL que vous utilisez. Par exemple, sous Debian, avec un PostgreSQL 8.3, j'ai le paquet postgresql-contrib-8.3.
Guillaume.
Hors ligne
Merci j'installe la contrib !!!
@+
Hors ligne
BONJOUR !!!!!!
J'aimerai avoir quelques éclaircissements sur un vacuum
tout d'abord j'ai fait un delet de 1 000000 de lignes avant de faire le vacuum.
voici le résultat de cette commande : vacuumdb -U pgsql -z -v test > /PGSQL/vacuum.log 2>&1
(analyse et verbose)
INFO: vacuuming "public.accounts"
INFO: scanned index "accounts_pkey" to remove 999999 row versions
DETAIL: CPU 0.23s/1.60u sec elapsed 10.50 sec.
INFO: "accounts": removed 999999 row versions in 16395 pages
DETAIL: CPU 0.34s/0.09u sec elapsed 3.32 sec.
INFO: index "accounts_pkey" now contains 9000001 row versions in 27422 pages
DETAIL: 999999 index row versions were removed.
2730 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "accounts": found 999999 removable, 9000001 nonremovable row versions in 163935 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
16394 pages contain useful free space.
0 pages are entirely empty.
CPU 1.35s/2.43u sec elapsed 17.68 sec.
INFO: analyzing "public.accounts"
INFO: "accounts": scanned 3000 of 163935 pages, containing 165920 live rows and 0 dead rows; 3000 rows in sample, 9066698 estimated total rows
INFO: free space map contains 60 pages in 63 relations
DETAIL: A total of 1008 page slots are in use (including overhead).
1008 page slots are required to track all free space.
Current limits are: 204800 page slots, 1000 relations, using 1305 kB.j'ai des doutes sur la notion de pages ??? " 163935 "
Et les dernières lignes veulent dire quoi concrètement ?
Comment lit-on exactement cette ligne ? "CPU 1.35s/2.43u sec elapsed 17.68 sec"
(En faite je voudrai avoir connaitre l'influence des deletes sur la durée d'un vacumm)
Merci d'avance,
Dernière modification par bil69 (26/05/2009 17:18:14)
Hors ligne
Une page, c'est une page de table. Par défaut, c'est 8 kilo octets.
Les dernières lignes disent si le paramétrage de la free space map, la zone mémoire utilisée pour stocker les pages libérées par vacuum, est suffisant en taille. Ici, en l'occurrence, c'est largement suffisant pour le moment
Marc.
Hors ligne
Merci,
INFO: free space map contains 60 pages in 63 relations
DETAIL: A total of 1008 page slots are in use (including overhead).
1008 page slots are required to track all free space.
Current limits are: 204800 page slots, 1000 relations, using 1305 kB.FSM contient 60 pages ( 8k * 60) pour 63 "relations" ???
On utilise un espace de 1008 pages de la FSM ???
la limite c'est 204800 page slots, 1000 relations pour la FSM ?? "using 1305 kB" ???
Merci d'avance...
Hors ligne
On utilise 1008 des 204800 pages de la FSM. Et on utilise 63 des 1000 relations.
Et au passage, vacuum signale, pour info, que la taille de la FSM est de 1305kB pour être capable de stocker 204800 pages et 1000 relations.
Marc.
Hors ligne
RE-BONJOUR,
Je reviens pour avoir un petit éclaircissement :
Je veux augmenter en volume ma base de données soit j'augmente le nombre de lignes initialisées avec :
-s facteur_echelle Multiplie le nombre de lignes générées par le facteur d'échelle. Par exemple, -s 100 ajoute 10 millions de lignes dans la table accounts. La valeur par défaut est 1.
Sinon il y a le facteur de remplissage seulement je n'arrive pas à le modifier...
-F fecteur_remplissage Crée les tables accounts, tellers et branches avec le facteur de remplissage indiqué. La valeur par défaut est 100.
pgbench -i test -s 100 -F 1000
invalid fillfactor: 1000
Comment on modifie ce paramètre ? une petite idée
Merci d'avance,
Hors ligne
Le facteur de remplissage est une valeur entre 0 et 100 qui indique le pourcentage de remplissage des blocs d'une table. Autrement dit, avec un FILL FACTOR à 100, une table avec 100 Mo de données fera 100 Mo. Avec un FILL FACTOR à 50, une table avec 100 Mo de données fera 200 Mo. Je ne pense pas que cela soit ce que tu veux.
-s est l'option qui t'intéresse.
Guillaume.
Hors ligne
merci,
donc
pgbench -i test -s 100 -F 100 donne une base deux fois plus petite qu'une base initialisée avec pgbench -i test -s 100 -F 50 ?
Hors ligne
Oui, c'est cela.
Guillaume.
Hors ligne
Bonjour à tous,
Je suis toujours dans mes tests 
Je suis face à un probleme concernant un vacuum. J'ai crée une base (avec pgbench) qui possède une table accounts de 300 000 000 de lignes. Après ca je désactive l'autovacuum et lance une suppression de 100 000 000 de lignes.
Ensuite je lance un VACUUM cependant dans les logs j'obtiens
WARNING: relation "public.accounts" contains more than "max_fsm_pages" pages with useful free space
HINT: Consider using VACUUM FULL on this relation or increasing the configuration parameter "max_fsm_pages".et dans mon rapport de Vacuum
INFO: "accounts": found 100000000 removable, 200000000 nonremovable row versions in 10000000 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
10000000 pages contain useful free space.
0 pages are entirely empty.
CPU 348.26s/1432.18u sec elapsed 5563.14 sec.
WARNING: relation "public.accounts" contains more than "max_fsm_pages" pages with useful free space
HINT: Consider using VACUUM FULL on this relation or increasing the configuration parameter "max_fsm_pages".
INFO: analyzing "public.accounts"
INFO: "accounts": scanned 3000 of 10000000 pages, containing 60870 live rows and 0 dead rows; 3000 rows in sample, 202900000 estimated total rowsJe ne comprends pas vraiment le probleme. La FSM n'arrive pas a "reprendre" les 100 000 000 millions de lignes supprimées ????
quelle pourrait etre la nouvelle valeur de "max_fsm_pages"
Merci d'avance,
Hors ligne
Elle n'est pas assez grosse pour contenir les 100 000 000 millions d'enregistrements supprimés.
Dans la mesure du possible, quand on efface un gros pourcentage d'une table, il est préférable de la recréer ... (c'est au moins ce qui est préconisé dans les docs Oracle par exemple, à 10% environ... )
Dans la log, il dit qu'il y a 10 millions de pages libres dans la table. Donc il faudrait 10 millions de pages environ dans la fsm pour stocker toutes ces pages.
Marc.
Hors ligne
Il faut savoir qu'un max_fsm_pages à 10000000 prend en mémoire environ 60 Mo. Vraiment pas grand sur nos serveurs actuels (cela étant dit, c'est la première fois que je vois une valeur aussi importante ).
Guillaume.
Hors ligne
Merci pour vos réponse
je ferai un retour
Hors ligne
bonjour,
Voila les retours suite à un vacuum avec un max_fsm_pages à 10000000
INFO: vacuuming "public.accounts"
INFO: index "accounts_pkey" now contains 300000000 row versions in 822573 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 5.30s/1.18u sec elapsed 61.09 sec.
INFO: "accounts": found 0 removable, 300000000 nonremovable row versions in 10000000 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
10000000 pages contain useful free space.
0 pages are entirely empty.
CPU 70.16s/36.39u sec elapsed 887.40 sec.
INFO: analyzing "public.accounts"
INFO: "accounts": scanned 3000 of 10000000 pages, containing 90000 live rows and 0 dead rows; 3000 rows in sample, 300000000 estimated total rows
INFO: free space map contains 398 pages in 63 relations
DETAIL: A total of 1344 page slots are in use (including overhead).
1344 page slots are required to track all free space.
Current limits are: 10000000 page slots, 1000 relations, using 58698 kB.....
Hors ligne
Etrange qu'il n'y ait pas plus de pages dans la free space map. Les 10 millions de pages devraient y être, ça m'échappe...
Marc.
Hors ligne
Etrange qu'il n'y ait pas plus de pages dans la free space map. Les 10 millions de pages devraient y être, ça m'échappe...
pourquoi dis tu ca ??
10000000 pages contain useful free space.
Current limits are: 10000000 page slots, 1000 relations, using 58698 kB.Merci d'avance,
Hors ligne
A cause de ca :
DETAIL: A total of 1344 page slots are in use (including overhead).
1344 page slots are required to track all free space.
Marc.
Hors ligne
merci
je recommence pour voir ce que ca donne...
Dernière modification par bil69 (06/07/2009 17:09:10)
Hors ligne
Voila le résultat ....
INFO: vacuuming "public.accounts"
INFO: index "accounts_pkey" now contains 300000000 row versions in 822573 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 5.32s/1.07u sec elapsed 62.32 sec.
INFO: "accounts": found 0 removable, 300000000 nonremovable row versions in 10000000 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
10000000 pages contain useful free space.
0 pages are entirely empty.
CPU 69.83s/35.56u sec elapsed 881.64 sec.
INFO: analyzing "public.accounts"
INFO: "accounts": scanned 3000 of 10000000 pages, containing 90000 live rows and 0 dead rows; 3000 rows in sample, 300000000 estimated total rows
INFO: free space map contains 400 pages in 63 relations
DETAIL: A total of 1344 page slots are in use (including overhead).
1344 page slots are required to track all free space.
Current limits are: 10000000 page slots, 1000 relations, using 58698 kB.Rien ne change ...
Merci d'avance
Hors ligne