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

[Guillaume Lelarge <guillaume(at)lelarge(dot)info>]

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