Vous n'êtes pas identifié(e).
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
merci
je recommence pour voir ce que ca donne...
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,
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.....
Merci pour vos réponse 
je ferai un retour
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,
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 ?
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,
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...
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,
Merci j'installe la contrib !!!
@+
OS : LINUX
Merci,
Ou se trouve cette contrib STP ????
Merci d'avance,
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,
Merci !!
Finalement j'ai opté pour la solution suivante :
sur serveur1 :
pg_dump -Fc test > /PGSQL/test.pg_dump
scp /PGSQL/test.pg_dump postgres@serveur2:/home/postgres
sur serveur2:
pg_restore -Fc -d test /PGSQL/test.pg_dump
Suite de mon pb :
Sur serveur1 :
pg_dump -h serveur1 test | pg_restore -h serveur2 test
pg_restore: [archiver] could not open input file "test": No such file or directory
pg_dump: [archiver (db)] connection to database "test" failed: could not connect to server: Connection refused
Is the server running on host "serveur1" and accepting
TCP/IP connections on port 5432?J'ai pourtant créé test sur serveur2 : createdb test et postgre tourne bien sur les 2 serveurs
Merci d'avance,
merci pour ta réponse précise !!
Sinon le lancement d'un vacuum analyse donne t il la durée du vacuum a la fin ?
pg_dump -h serveur1 base | psql -h serveur2 baseCette commande duplique les données sur le serveur 2 ???
merci d'avance
Merci beaucoup,
Voici les resultats des commandes :
test=# SELECT pg_database_size('test');
pg_database_size
------------------
3251392108
(1 row)
3179376 ./PGTEST01/base/16420merci d'avance
Bonjour,
J'ai une petite question bête : les commandes suivantes me donne 2 tailles différentes pour la base WORLD Pourquoi ???
SELECT pg_size_pretty(pg_database_size('world'));
-[ RECORD 1 ]--+--------
pg_size_pretty | 4948 kB
du * -h
4.8M base/1
4.8M base/11510
4.9M base/11511
5.5M base/16384
20M base-[ RECORD 4 ]-+----------
datid | 16384
datname | world
numbackends | 1
xact_commit | 46
xact_rollback | 1
blks_read | 212
blks_hit | 11069
tup_returned | 24884
tup_fetched | 2485
tup_inserted | 5490
tup_updated | 36
tup_deleted | 0
MERCI d'avance,
Merci beaucoup !!!!!!!
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,
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,
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
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,
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,