Espace disque (Vacuum : 15Go => 400Mo) [Résolu]

[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]

J'avais deja supprimé quelques index avant de lancer le VACUUM FULL...
En supprimant les autres, ça ne va me liberer que 4Go
Je vais essayer en nettoyant deja les petites tables.

Disons que pour l'instant, je ne vais prendre qu'un serveur (je n'ai pour l'instant que des données de l'ordre de la centaine de giga) et je me suis donc pas interessé à ces solutions de stockage.

Que pense tu d'un Xeon dual core?

[hpalpha]

Les intels tiennent tres bien, mais ils ont toujours ete tres cher, c'est pour ca que je parlais d'opteron, mais ca fait longtemps que j'ai pas regardé les couts, ca a baissé je pense.

Sinon j'ai trouvé un bench, l'intel est plutot bien
http://tweakers.net/reviews/642/14

Pour les disques durs, tu peux te permettre d'avoir plus de 90go et avec une tolérance de panne en plus.
3 DD de 120go en RAID 5 minimum (soit 240 go utile)

au prix des durs, tu peux taper dans 150 go et plus

[ledjlale]

Alors j'ai libéré la mémoire des index. Depuis ce matin, j'ai eu le même espace libre qu'hier. Mais à partir de 12h, l'espace a faibli et est tombé à 300Mo.

Le VACUUM FULL tourne toujours! (depuis hier à 17h jusqu'à maintenant à 15h15).

Je suis en train de voir si il y a des logs quelques part...

[ledjlale]

Code :

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 :

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!

[Smortex]

Salut

Envoyé par ledjlale

Ouaw. J'ai pas intérêt à le faire tres souvent, c'est beaucoup trop long :/

Tu met le doute mais j'aurai tendance à dire qu'une fois que les données sont rangées, les re-ranger doit aller relativement vite... puisqu'il n'y a rien à faire... A vérifier...

Sous FreeBSD, une tâche cron fais un vacuum quotidien, peut être pas un hasard ?

[hpalpha]

Pour le vacuum, si tes données sont plus en lecture qu'en ecriture, ta table ne devrait plus trop bouger, il faut faire une vacuum regulierement, surtout apres une serie update/insert.

parametre l'autovacuum ca peut d'eviter des tracas.

Sous linux, on utilisait un cron.d qui lancait un vacuum toute les nuits avant l'apparition de l'autovacuum, perso je continue a utiliser ce cron.

Encore une fois, on voit que windows gere mal la memoire (limite de 2go), encore une bonne raison de passer sous *nux ou *bsd. (et en prime tu auras un cron et un shell puissant gratos )

[Smortex]

Envoyé par hpalpha

Encore une fois, on voit que windows gere mal la memoire (limite de 2go), encore une bonne raison de passer sous *nux ou *bsd. (et en prime tu auras un cron et un shell puissant gratos )

Les 2Go par processus sont une limite imposée par l'architecture i386 32bits, pas de l'OS... L'OS fera juste varier comment le SWAP est utilisé puisque chaque OS à sa manière de le gérer: windows aime bien le bourrer de choses qu'il utilise, Linux l'utilise en cas de dernier recours uniquement, FreeBSD l'utilise avant que la RAM vienne a manquer et y met ce qui est alloué et non accédé depuis le plus longtemps... Selon l'usage de la mahcine chaque solution offre ses avantages et inconvénients...

[hpalpha]

Envoyé par hpalpha

Encore une fois, on voit que windows gere mal la memoire (limite de 2go)

au temps pour moi, en tout cas, je pense qu'il est deconseillé de prendre windows pour une base de données ? non ? là est un autre debat...

[ledjlale]

Oui bien sur , lorsque je vais recevoir le serveur (la semaine prochaine), j'installerais FreeBSD (surtout parceque la moitier des machines se trouvent sur cet OS). Mais en attendant, je dois me taper windows. Et si ça se trouve, les problemes que je rencontre aujourd'hui reapparaitront plus tard

Disons que c'est tres lent parcequ'à l'origine, j'avais 200millions de lignes avant de faire un "DELETE * FROM..." (je ne connaissais pas TRUNCATE ) puis "INSERT..." * 300millions, "UPDATE INTO ...pKey_id = pKey_id+20000", puis "UPDATE INTO ... pKey_id=x WHERE pKEY_id=y"
== Effacement de l'ancienne table, reinsertion de nouvelles données, mise à jour des ID pour synchroniser avec une autre base(brut mais facile à ecrire le programme :/
Alors avec un peu de recul, je comprends pourquoi ça prend enormement de temps .. m'enfin, 2 jours quand meme et ce n'est même pas fini.

Merci d'avoir corrigé à propos de l'OS, j'ai toujours vu que c'était Windows qui limitait à 2Go.

D'apres cet article

This 4GB space is evenly divided into two parts, with 2GB dedicated for kernel usage, and 2GB left for application usage. Each application gets its own 2GB, but all applications have to share the same 2GB kernel space.

Mais ils parlent un peu plus bas d'un systeme qui se boot avec une option /PAE et qui permet de manipuler jusqu'à 64Go de mémoire physique (cet article date de 2004), mais j'ai pas tout saisi au premier coup :/

[Smortex]

Envoyé par hpalpha

au temps pour moi, en tout cas, je pense qu'il est deconseillé de prendre windows pour une base de données ? non ?

Je dirai que ça dépends du contexte dans lequel on est... De là a aller le conseiller, comptez pas sur moi [/QUOTE]

Envoyé par hpalpha

là est un autre debat...

Oui, mais il est intéressant... Dans une boite où les connaissances sont limitées à Windows, où le manque d'un système de mise à jour des applications n'est pas critique, où la fiabilité n'est pas critique, l'administration à distance est limitée et les coûts entrent dans la politique locale, je pense que ça peut peut être se faire... Après, il faut voir comment PostgreSQL foncitonne sous Windows (j'en sais rien): si c'est natif, c'est acceptable, si ça passe par cygwin, là on est plus proche d'une installation bidouillage pour faire des tests...

Je me rapelle du temps où j'installais apache1 sous Windows car à l'époque je ne connaissais que ça... Le readme pendant l'installation criait en rouge "DO NOT USE ON A PRODUCTION SERVER"....

Envoyé par ledjlale

m'enfin, 2 jours quand meme et ce n'est même pas fini.

Pour 90 Go de données ? Ça me parrais long, c'est dans ces conditions que j'aime bien attacher un debugger sur un processus pour voir s'il est pas bloqué dans un état incertain... Ca gratte sur le disque (y'a des trucs qui se créent, changent de tailles, disparaissent) ? L'allocation mémoire du processus change ?