Skip site navigation (1) Skip section navigation (2)

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 12:42:10
Message-ID: 480DDD22.6040402@lelarge.info (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Francois Suter a écrit :
>> Dans le cas d'un grossissement inconsidéré des tables, le conseil 
>> habituel est de vérifier que des VACUUM sont fait régulièrement et que 
>> les paramètres max_fsm_* sont bien configurés. Est-le cas ?
> 
> Pour les VACUUM, ils n'ont pas été fait pendant longtemps, mais les ai 
> remis au goût du jour depuis 1 mois environ :-)
> 

Les VACUUM sont obligatoires pour ne pas voir les tables et index 
explosés. Cela étant dit, sans les paramètres max_fsm_* correctement 
ajustés, PostgreSQL ne se rappelera pas forcément des résultats du 
VACUUM (vu qu'ils sont stockés dans la FSM).

>> Si tu te trouves dans une solution aussi difficile que ça, mon premier 
>> conseil serait de faire un VACUUM FULL et de reconfigurer tes 
>> max_fsm_* pour qu'il soit en adéquation avec l'ensemble de tes bases. 
>> Ensuite, revois avec beaucoup d'attention la fréquence des VACUUM, 
>> quitte à faire des VACUUM super fréquents sur une table particulière.
> 
> Vu que j'ai un gros script d'import de données qui tourne chaque soir, 
> je vais y ajouter un VACUUM à la fin.
> 

Tu as des suppressions ou des modifications de données ? 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).

>> De plus, si tu fais des VACUUM FULL régulièrement (ce que je ne 
>> conseille pas, mais bon certains le font parfois, notamment par 
>> méconnaissance du VACUUM et des paramèters max_fsm_*), n'oublie pas 
>> l'opération de REINDEX après. (Ça pourrait expliquer l'état de tes index)
> 
> Là, j'avoue que ne suis pas au point sur ce genre de choses. J'ai 
> regardé la doc (pour la 7.4.x), mais je ne suis pas très éclairé quant 
> aux valeurs à utiliser pour max_fsm_*.
> 
> Ma base de données compte 22 tables et 45 index (je viens d'ailleurs de 
> m'apercevoir qu'il y avait des index à double). Quelle taille les 
> max_fsm_* doivent-ils donc faire idéalement pour cette structure?
> 

La structure FSM détaille les espaces libres dans les tables et index 
(pages disques complètes uniquement pour ce dernier). PostgreSQL regarde 
dans cette strcture avant d'insérer des données. S'il trouve la place 
nécessaire, il stockera sans ajouter une page. Évidemment, dans le cas 
où il ne trouve pas la place nécessaire, il ajoutera une nouvelle page. 
D'où le grossissement. La structure FSM ne lui permet pas d'avoir l'info 
des trous dans la table, soit parce que la structure est trop petite 
pour tout contenir soit parce qu'elle n'est pas renseignée (le VACUUM 
n'est pas lancé, ou pas suffisament en tout cas).

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');

Évidemment, pour que relpages soit à jour, un ANALYZE est préférable.

Sinon, l'autre possibilité, c'est un VACUUM ANALYZE VERBOSE. Les 
dernières lignes du log indique une taille intéressante. Cependant, j'ai 
assez peu confiance dans ce type d'infos. À noter qu'il faut le faire 
pour chaque base, et additionner chaque valeur trouvée.

>> Voilà, voilà. Bon courage :)
> 
> Merci
> 
> François Suter
> 


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

In response to

Responses

pgsql-fr-generale by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group