Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
Je sollicite votre aide au sujet d'une BDD qui grossit beaucoup (trop ?). Elle fait actuellement 630 Go, mais la restauration d'un dump sur un autre cluster ne prend que 470 Go. Je me demande à quoi servent les 160 Go de différence, et sont-ils bien utiles ? D'autant que depuis quelques semaines cette BDD a triplée sont taux de croissance. N'y a-t-il pas un problème ?
Voici quelques infos
OS Debian lenny
PostgreSQL 8.3.14
RAM 32 Go (effective_cache_size=24G)
pas de vaccum full (trop long)
pg_temp est sur un axe dédié.
J'ai d'abord pensé à un problème de la FSM car il y a trois ans j'ai eu le même problème en raison d'une taille de la FSM insuffisante. Marc Cousin m'avait aidé à le résoudre. J'avais alors passé max_fsm_pages à 1500000 ; la volumétrie avait stoppée sa croissance pendant quelques semaines, puis avait repris mais plus lentement. Je pensais le problème résolu. Aujourd'hui encore les logs du vacuum concernant la FSM semblent correctes :
INFO: free space map contains 2797130 pages in 144 relations
DETAIL: A total of 2499840 page slots are in use (including overhead).
2499840 page slots are required to track all free space.
Current limits are: 15000000 page slots, 1000 relations, using 87995 kB.
Ce n'est donc probablement pas la FSM, mais vous aurez peut-être un autre avis ?
Sinon, d'où cela peut-il venir ?
Merci d'avance pour votre aide.
Hors ligne
Des VACUUM trop peu fréquents peuvent en être la cause. Un manque de REINDEX aussi. Des transactions très longues qui empêchent le VACUUM d'être efficace. Bref, il existe plein de raisons. Il serait intéressant de voir quels objets ont changé de taille entre les deux clusters. Si ce sont les index, c'est qu'il vous faut des REINDEX. Si ce sont les tables, c'est certainement dû à des VACUUM trop peu fréquents.
Guillaume.
Hors ligne
Pages : 1
