Discussion :

[ledjlale]

Hier, la taille de ma base de donnée était de 90Go et il ne me restait plus que 15Go.
J'ai lancé un Vacuum standart pour libérer de la place (j'avais fait plein de delete/update).

Le processus est encore en train de tourner, et il ne me reste plus que ... 400Mo.

Je commence à stresser

Que se passe-til? (je suis le seul à avoir accés à la base de donnée, et je n'y ai fait aucune modification depuis hier... sauf vacuum)

Edit : je suis sous Postgres 8.1 et sous Windows

[hpalpha]

Bonjour,

quel genre de vacuum ?
un simple vacuum ne va pas faire grand ménage, essaye de faire un VACUUM FULL sur tes tables.

J'ai tout de meme 2 conseils :

- change de version de pg >> 8.2 ou attend la 8.3
- passe sous linux !!!!! la base en sera que plus rapide, et en plus tu peux utiliser le LVM pour l'espace disque c'est plus rassurant de savoir que l'on peut augmenter la taille du disque a chaud sans rien perdre)

Sinon pour ton pb, en resumant :

solution 1 :
- vacuum full des tables

Solution 2 :
- supprime tes indexs
- vacuum full des tables
- creer un tablespace sur un autre disque dur
- recree tes index avec le nouveau tablespace

comme ca deja, tes données seront sur un disque et les index sur l'autre, ca te permettra peut etre de tenir le temps de passer sous linux ;-)


Solution 3 :
- backup ta base
- installe linux avec des gros DD (ca coute plus rien)
- restore la base

[ledjlale]

Oups, j'ai fait un lapsus :/

Le processus qui tourne depuis hier est le VACUUM en mode FULL.
Lorsque j'ai atteinds les 400Mo, j'ai arreter la commande et ai lancé un VACCUM normal, sans option (j'utilise pgadminIII). La taille est restée fixe depuis et tourne toujours(il fonctionne depuis 6h).

Je me suis référé à :
Docs Postgres8.1

Il aurait du me liberer de la place au lieu d'en prendre

Pour ce qui est du Linux, on attend d'avoir une bécane spécialisée pour stocker notre Base de donnée. Bécane

[hpalpha]

Le comportement semble normal,
en fait le vacuum prend de la place pour les fichiers temporaires, grossomodo quand tu fais du vide dans le fichier, ca ce passe comme ca :

(un X représente un octet utile, Y un octet dont on a plus besoin )

temps 0 (15 octects)
fichier1: XXXYYYXXXYYXYXY

VACUUM FULL fichier1
temps 1
fichier1 (15 octets): XXXYYYXXXYYXYXY
fichier1_tmp (8octets): XXXXXXXX

temps 2
del fichier1
ren fichier1_tmp fichier1

temps 3
fichier1 (8octets): XXXXXXXX


C'est un peu imagé, mais ca explique pourquoi l'espace disque dispo diminue
en temp1, des fichiers temporaires sont creer et donc prenne plus de place (on passe de 15 octects a 15+8=23 octets)

tu me suis ?


sinon niveau serveur, le liens chez dell marche pas, c'est quel model ?
sinon tu as de tres bon serveurs chez la concurrence (transtec par exemple)

Je te préconise du opteron, pg est optimisé pour ce proc, en 64bits, cela va de soit, et en SMP.
Au niveau DD, prend du RAID 10, plus interessant que le raid 5 pour une base de données.
RAM : mini 4 Go, mais vraiment, prend plus.

[ledjlale]

Ok, je n'ai pas osé continuer jusqu'à n'avoir plus d'espace libre du tout...
A ton avis, je peux relancer le VACUUM FULL avec seulement les 171Mo? (je suppose qu'il effacerait les anciens fichiers temporaires lorsqu'il sera en rupture d'espace)

J'ai corrigé le lien.
C'est un "DELL PowerEdge™ 2900" sur lequel je compte mettre (au debut):

• Dual Core Intel® Xeon® 5150, 2.66GHz, 4MB Cache, 1333FSB
• 4GB FB 667MHz (2 x 2048MB dual rank)
• 3 ou 4 DD de 300Go à 15k Tr/min

Bien sur, pour la RAM et les DD, ce n'est qu'un début
Je cherche à avoir un systeme me permettant de gerer quelques To de données et d'avoir un accés rapide (D'où SAS et 15k Tr/Min).
Je vais voir ce qu'il en ai des opterons.

[hpalpha]

145 Mo !!!! ouch c'est juste

peut etre en stoppant ta base et en la restart, ca fera peut etre du menage.

Pour recup de la place le temps du vacumm, supprime tes index, ca a pas l'air comme ca, mais c'est fou ce que ces petites betes prennent de la place

Pour les stockage de plusieurs To, as tu pensé aux solutions SAN en fibre chanel, ou iSCSI ?

[ledjlale]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
INFO:  vacuuming "public.option_quotes"
INFO:  "option_quotes": found 223902959 removable, 323138941 nonremovable row versions in 5139678 pages
DETAIL:  0 dead row versions cannot be removed yet.
Nonremovable row versions range from 69 to 69 bytes long.
There were 2903610 unused item pointers.
Total free space (including removable row versions) is 16535662824 bytes.
2119290 pages are or will become empty, including 0 at the end of the table.
2120358 pages containing 16414890024 free bytes are potential move destinations.
CPU 110.56s/84.03u sec elapsed 5570.29 sec.
INFO:  index "option_quotes_pkey1" now contains 323138941 row versions in 5790962 pages
DETAIL:  104103249 index row versions were removed.
1901289 index pages have been deleted, 20000 are currently reusable.
CPU 197.39s/316.85u sec elapsed 14256.06 sec.
 
ERROR:  could not extend relation 1663/25249/25758: No space left on device
HINT:  Check free disk space.

Et il me bloque à... 100Ko... :/
Je suis sur que c'est un probleme de configuration, mais alors où

[hpalpha]

tu as plus de place dispo, le vacuum te l'indique

[ledjlale]

Je le vois bien, je n'essaierais pas de faire un VACUUM FULL sinon.
Dans toutes les docs que j'ai lu, rien n'indique que le VACUUM bouffe de la memoire, bien au contraire, il est sensé en libérer dans les cas où les DELETE/UPDATE ont été importantes (ce qui est le cas)

[hpalpha]

Oui le vacuum libere de la memoire, mais apres qu'il ai fini de travailler.
D'ailleurs tu peux regarder le code source,
/src/backend/commands/vacuum.c

il y a par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
/*
* Clean up working storage --- note we must do this after
* StartTransactionCommand, else we might be trying to delete the active
* context!
*/
MemoryContextDelete(vac_context);
vac_context = NULL;
if (anl_context)
MemoryContextDelete(anl_context);

sinon, dans ton fichier de conf, change la valeur de maintenance_work_mem par defaut a 16Mo, passe le a plus, bcp plus, c'est le nb de ram qui sera utilisé pour le vacuum (entre autre), ca améliora la perf, et il devrait moins utiliser de DD

[ledjlale]

Bong, alors j'ai reussi à libérer 14Go sur la deuxieme table. J'ai donc relancé un VACUUM FULL sur la premiere table, et ça fait deja un peu plus de 2 jours que ça tourne... il lui reste 9Go pour finir son truc. pfff, ils auraient pu prevoir des étapes intermediaires au lieu de tout nettoyer d'un coup (ou du moins, j'espere c'est une option que je ne connais pas).

Ouaw. J'ai pas intérêt à le faire tres souvent, c'est beaucoup trop long :/ d'autant plus que ce n'est que le début (et comme conseillé dans la doc, j'ai fais des VACUUM à des frequences regulieres avant des faire le FULL)

J'ai mis la variable maintenance_work_mem à 256Mo. J'ai pas interet à mettre plus parceque le processus prends deja 1.5Go (limite des 2Go par processus de windaube). J'y ai vu une grande difference quand j'ai libérer de la mémoire sur la seconde table, merci!