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

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