Re: [pgsql-fr-generale] Re: [pgsql-fr-generale] Augmentation de taille incontrôlée d'une base

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Francois Suter <fsuter(at)cobweb(dot)ch>
Cc: Listes Advocacy <pgsql-fr-generale(at)postgresql(dot)org>
Subject: Re: [pgsql-fr-generale] Re: [pgsql-fr-generale] Augmentation de taille incontrôlée d'une base
Date: 2008-04-22 13:55:11
Message-ID: 480DEE3F.4040302@lelarge.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Francois Suter a écrit :
>> Tu as des suppressions ou des modifications de données ?
>
> En temps normal, environ 180'000 UPDATE, plus un peu d'INSERT et de DELETE.
>

Sans VACUUM, il est logique que tes tables explosent.

>> Parce qu'un simple import ne peut expliquer des tables qui explosent
>> (à moins que le gros import se fasse dans une transaction qui foire
>> quelque fois).
>
> Tiens, c'est intéressant, ça. L'import est effectivement dans une
> transaction et il y a eu récemment des plantées pour manque d'espace
> disque. Cela laisserait-il de gros espaces bloqués mais inutiles? Et si
> oui, comment les récupérer?
>

Pendant ta transaction, les données sont enregistrées, y compris dans
les fichiers de données. Si la transaction est annulée, les données sont
considérées comme supprimées de la même façon que si elles avaient subi
un DELETE lors de la transaction. Du coup, tu te retrouves avec un ou
plusieurs gros trous.

Pour les récupérer, VACUUM FULL est la solution la plus simple. Ne pas
oublier un REINDEX après chaque VACUUM FULL.

>> Vu la quantité de table et d'index, seul max_fsm_pages compte. Il
>> indique le nombre de pages à surveiller. Le moyen le plus simple pour
>> connaître cette valeur est de récupérer la taille de toutes les bases
>> et de diviser par 8 Ko (une page disque fait 8 Ko). L'autre moyen est
>> d'exécuter cette requête sur chaque base (y compris les bases systèmes) :
>>
>> SELECT sum(relpages) FROM pg_class WHERE relkind IN ('r', 't', 'i');
>
> Merci pour toutes ces explications. En faisant cela, j'arrive à environ
> 13'000 Ko, ce qui devrait être ok puisque le défaut est de 20'000, non?
>

13 Mo, c'est 1625 pages disques. Donc 20000, t'es tranquille de ce côté.

Mais ça m'étonne, c'est vraiment très peu.

> Par contre, si je prends la taille des bases, c'est une autre paire de
> manches, puisqu'elles ont justement une taille tout à fait déraisonnable
> (820 Mo, contre ~50 Mo pour une copie locale propre). Mais je vais déjà
> voir avec la mise à jour en 7.4.19...
>

Ça ne serait pas les catalogues système qui ont explosé ? après un
VACUUM FULL, tu retrouves une taille "normale" ?

Oh, et oui, bien sûr, la mise à jour, à faire le plus rapidement possible :)

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

In response to

Responses

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Francois Suter 2008-04-22 14:12:50 Re: Re: [pgsql-fr-generale] Augmentation de taille incontrôlée d'une base
Previous Message Francois Suter 2008-04-22 13:36:50 Re: Re: [pgsql-fr-generale] Augmentation de taille incontrôlée d'une base