Vous n'êtes pas identifié(e).
Bonjour,
Je vous explique mon problème, j'ai une application qui tourne 24h/24h et 7j/7j et utilise la base en permanence.
Si je n'effectue pas de VACUUM, les performances se dégradent.
Si j'effectue des VACUUM quotidien, mes performances reviennent mais le temps de traitement du vacuum se dégrade au fil des jours (au debut ca prend 2mn pis apres 7j, ca prend 1h)
alors que le nombre d'enregistrement est stable (j'effectue des inserts en permanence et des delete toutes les heures pour purger les anciennes données)
Si j'effectue un VACUUM FULL (qui dure 10h), je récupère plein d'espace disque et les vacuum simple redeviennent performant
Donc voici mes questions:
Comment se passer d'un VACUUM FULL ?
Je lis souvent qu'il n'est pas conseillé d'effectuer de VACUUM FULL.
La chute des performances de mon application provient-elle d'un mauvais réglages des paramètres FSM ?
Extrait de mon postgres.conf:
shared_buffers = 512MB
max_fsm_pages = 153600
max_fsm_relations = 6000
#maintenance_work_mem = 16MB
Un vacuum analyse m'indique ceci:
NOTICE: number of page slots needed (191328) exceeds max_fsm_pages (153600)
Quelques infos sur ma base:
Nombre d'objets: 1191
Ma plus grande table stagne à 10 millions d'enregistrements.
Nombre de pages observées: 1 673 258 (j'obtient ce nombre avec la requete suivante: SELECT sum(relpages) FROM pg_class WHERE relkind IN (‘r’, ‘t’, ‘i’))
Mon serveur Linux a 8go de RAM
Merci d'avoir lu jusqu'au bout 
Hors ligne
Votre max_fsm_pages me semble trop bas et votre max_fsm_relations trop haut. Le plus important me semble d'augmenter le max_fsm_pages et d'augmenter la fréquence des VACUUM. Comme valeur pour le max_fsm_pages, je proposerais assez facilement 1000000 (ie 1 million), voire plus. Ça ne prendra que 6 Mo en mémoire. Autant dire que ça ne changera pas grand chose à la mémoire utilisée vu que vous avez 8 Go de RAM
Petite question, le sum(relpages) a été fait avant ou après un VACUUM FULL ? Après le VACUUM FULL, vous faites bien un REINDEX n'est-ce pas ?
Guillaume.
Hors ligne
Bonjour Guillaume,
Merci de ta réponse
En fait je fais pas mal de test pour trouver la meilleure stratégie.
Le sum(relpages) a été lancé sur une base qui a été torturé par mon application pendant 2.5jours environ.
Un VACUUM "simple" etait programmé quotidiennement ce qui fait que 3 se sont lancés. Cette base n'a jamais subit de VACUUM FULL.
Non je ne fais pas de REINDEX apres un VACUUM FULL.
De toute façon, la durée du 1er VACUUM FULL est bien trop longue pour être acceptable.
Pour donner plus d'infos sur mon application, elle fait de l'acquisition de données (13 000 lignes) toutes les 5 minutes. (24h/24, 7j/7)
Ce qui fait que la table en question contient plus de 3 000 000 d'enregistrements en 1 journée.
J'ai un script de purge qui ne garde qu'un historique de 48h de données lancé toutes les heures.
J'ai fait le test de lancer un VACUUM FULL quotidien.
Au bout de 0.5 journée de donnée, il a duré 2mn
Au bout de 1.5 journée de donnée, il a duré 3mn30
Au bout de 2.5 journée de donnée:
mon script de purge a supprimé 0.5 journée de données (requete DELETE) donc environ 1 500 000 lignes supprimées.
et le VACUUM FULL s'est retrouvé avec pas mal de boulot à faire: il a duré 3h20
J'ai relancé un second VACUUM FULL aussitot apres, il a duré 2mn20, je retrouve un temps raisonnable.
Ok pour faire un test avec max_fsm_pages à 1 000 000 mais pour max_fsm_relations, quelle valeur ?
Sachant que j'ai 1191 objets dans la base, je le met à 1200 ou il faut prévoir de la marge ?
Est ce que le maintenance_work_mem peut réduire significativement les performances du VACUUM ?
Sachant que mon application publie des resultats toutes les 5 minutes, arrêter l'application pendant 3h pour effectuer un VACUUM FULL ou un REINDEX n'est pas envisageable en fait.
Désolé pour ce post un peu long...
Hors ligne
Bonjour, si vous avez un script de purge lancé toutes les heures, et qui efface un grand nombre d'enregistrements, lancez un vacuum juste après, cela permettra de réutiliser les blocs libérés par les delete plus rapidement.
Par aillers, en quelle version de PostgreSQL êtes vous. Si elle est récente, avez vous bien activé l'autovacuum ?
Marc.
Hors ligne
Pour max_fsm_relations, je dirais qu'une bonne valeur se situe entre 1000 et 2000 pour ce que tu nous as dit de ton schéma. Et en espérant qu'il n'y a pas d'autres bases de données.
Quelques conseils :
1. Ne JAMAIS faire de VACUUM FULL (sauf cas très particulier, pas le tien en tout cas, et toujours suivi d'un REINDEX).
2. Si tu tiens toujours à tes DELETE toutes les heures, faire un VACUUM simple immédiatement après. Bien comprendre que le VACUUM simple n'est pas bloquant, donc il n'empêche pas les insertions (il ne fera que les ralentir).
3. Solution que j'aurais tendance à préférer : partitionner la table par journée. Chaque jour, un peu avant minuit, créer la nouvelle partition et supprimer celle de J-3. Toujours insérer dans la table du jour (plus rapide que l'utilisation d'un trigger). Extraire les données à partir de la table mère. Du coup, plus de DELETE, donc pas besoin de VACUUM (pas tout à fait vrai, mais vrai dans ton cadre).
Guillaume.
Hors ligne
Merci pour vos réponses.
Alors j'ai relancé avec les paramètres suivants:
max_fsm_pages = 1000000 au lieu de 153600
max_fsm_relations = 2000 au lieu de 6000
et j'ai programmé un VACUUM ANALYSE apres la purge.
Pour Marc, j'ai la version 8.2.4 et l'autovacuum doit être à OFF car j'ai cette ligne dans le fichier conf:
#autovacuum = off
Pour Guillaume, le partitionnement logiciel est une super solution mais c'est trop tard pour l'envisager vu l'avancement de mon projet 
Sinon pour info, ma base vide prend 14mo sur le disque, il y a 1122 objets et le sum(relpage) renvoie 1140
Donc la je viens de relancer mon application, à voir comment ca va évoluer dans les jours à venir.
Question: Quand on fait que des inserts sans jamais d'update ou delete sur une table, il est nécessaire malgré tout de lancer un VACUUM ANALYSE ?
Dernière modification par Redge (26/04/2010 18:41:22)
Hors ligne
Le ANALYZE, oui, car ce sont des nouvelles données, donc les statistiques sur les données vont forcément être impactées.
Le VACUUM, ça se discute. Mais de préférence, oui. Ne serait-ce que parce que si un INSERT échoue le VACUUM pourrait bien être utile pour récupérer la place manquante.
Guillaume.
Hors ligne
bon alors c'est génial, je viens de m'apercevoir qu'on peut lancer VACUUM sans aucun paramètre. Du coup quand je parle d'un VACUUM simple, je faisais des VACUUM ANALYSE en fait...
Donc je récapitule:
Je dois lancer un VACUUM apres un delete massif, ca OK, c'est programmé.
Par contre pour le VACUUM ANALYSE, quel politique mettre en place sachant que j'ai des insert de 30 000 lignes toutes les 5 minutes
Une fois par jour ? Une fois par heure?
Merci
Hors ligne
S'il n'y a que des insert, un simple analyze suffira. Et dans ce cas là, une fois par heure sera certainement très bien.
Après le delete massif, autant faire an vacuum analyze plutot qu'un simple vacuum, histoire de recalculer les stats à ce moment là aussi.
Marc.
Hors ligne
Ok donc en gros j'ai mit en place un script de purge lancé toutes les heures par la crontab.
Si le DELETE du script a supprimé quelque chose, il lance un "VACUUM;" et sinon DELETE ou pas, il lance un "ANALYSE;" juste après
Merci pour votre aide.
Plus qu'à voir comment ca évolue dans le temps.
Hors ligne
Je vois que mon post est passé en résolu.
Donc en fait je confirme, je suis à 7 jours de traitement, la taille de ma base stagne sur mon disque. Et la durée des traitements VACUUM et ANALYSE ont tendance à stagner.
Donc un VACUUM après chaque DELETE massif et un ANALYSE assez fréquent (toutes les heures) est une bonne politique pour mon application.
Merci Guillaume et Marc
Hors ligne
