PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48

Vacuum sensé libérer de la place

Technique - général | Vacuum sensé libérer de la place

Par ledjlale le 27/07/2007 - 16:44

Bonjour,

En Bref, je n'avais plus beaucoup de place sur le disque (15Go) et j'avais fait beaucoup de DELETE/UPDATE. J'ai tenté VACUUM FULL, mais au lieu de me libérer de la place, je n'en ai plus eu (je suis maintenant à 100Ko :/)

Je suis sur Windows Server 2003 (plus pour longtemps vu que je voulait faire un transfert vers un serveur dédié sous FreeBSD ;))
Ma Base comporte deux grosses tables (80Go et 25Go) et d'autres beaucoup plus petites.

A l'époque (il y a une semaine), je ne connaissais pas la fonction TRUNCATE. Donc, j'ai fais plein de DELETE.
Avant-hier, je me suis retrouvé à 15Go de mémoire. J'ai alors lancé un VACUUM FULL dans l'espoir de gagner de la place.
Le processus a tourné toute la nuit. Le lendemain matin, il ne me restait que 1Go. Le temps de chercher une solution, ça a tombé à 400Mo. J'ai décidé d'annuler la requête (de peur de corrompre la base).
Apres quelques recherche, j'ai vu qu'un VACUUM de risquait pas de corrompre les donnée dans ce cas. On m'a conseillé d'effacer les index et de relander le VACUUM.
N'ayant pas trop eu confiance, je n'ai pas tout effacer, et ai laissé juste 2Go.
J'ai alors relancé hier soir à 17h le VACUUM FULL.
Aujourd'hui à 12h, l'espace disponible commencait à baisser. J'ai "attendu" jusqu'à cette erreur :

********************************************************************

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.

***************************************************

Sachant que je peux encore libérer 2Go de mémoire, que me conseillez vous de faire?
Est-ce normal que le VACUUM FULL sensé liberer de la mémoire fasse le contraire?
Y a t'il une configuration à mettre en place?
Un dump/reconstruction servirait-il à quelque chose?

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

Un detail

ledjlale/ = 27 Juillet, 2007 - 17:13

J'ai juste oublié de dire : je suis sur PostgreSQL 8.1.


vacuum verbose

jmreymond/ = 28 Juillet, 2007 - 15:24

il faudrait lancer le vaccum avec l'option verbose pour repérer un éventuel message d'erreur t'indiquant que tu as un paramètre avec une mauvaise valeur.

Jean-Max Reymond
CKR Solutions Open Source
http://www.ckr-solutions.com


Le message de debug dans le p

ledjlale/ = 30 Juillet, 2007 - 14:54

Le message de debug dans le premier post est la sortie d'un VACUUM FUUL en mode verbeux. J'ai tenté de faire un VACUUM FULL sur la deuxieme table (25Go). Ca m'a libéré 14Go. Je respire un peu plus ;)

En gros, ce que je viens de decouvrir, c'est que la routine de nettoyage neccessite de la place pour stocker ses fichiers temporaires. Peut-on avoir une éstimation sur la place à libérer minimale pour pouvoir faire un VACUUM FULL?
Peut-on désigner un endroit sur les disque dur pour pouvoir y mettre les fichiers temporaires du VACUUM FULL?

Je trouve que c'est assez gênant de prévoir un éspace mémoire dynamique (dependant de la taille de la plus grosse table). N'y a t'il pas un moyen pour éviter cette nuisance?
On m'a conseillé d'augmenter le "maintenance_work_mem". Ca peut resoudre le probleme? Ou ça recul seulement les limites?


conseil

aitali/ = 1 Août, 2007 - 12:19

reindex les tables
et fait un vaccum full table par table, vaccum full sur toute la base n'a pas bien fonctionné chez moi !!
vaccumdb --table xxxx full db

bn courage


Au passage, lorsque que l'on

daamien/ = 13 Août, 2007 - 17:27

Au passage, lorsque que l'on souhaite libérer de l'espace disque en vidant des tables entières à base de DELETE massifs, il est préférable d'utiliser la commande (non-standard) TRUNCATE :

http://docs.postgresqlfr.org/8.2/sql-truncate.html

--
damien clochard
http://dalibo.com | http://dalibo.org


© PostgreSQLFr, tous droits réservés.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.