Vous n'êtes pas identifié(e).
Le max_fsm_pages est probablement trop petit en production, pour un infocentre
Le maintenance_work_mem est trop petit en dev
Sinon rien de choquant.
Mais vous feriez mieux d'avoir des configurations plus proches entre les deux environnements, ça pourrait vous éviter des surprises à la mise en production. Vous pouvez aussi comparer les schémas, histoire de voir si il ne vous manquerait pas d'autres index. J'ai déjà utilisé ce programme pour le faire : http://apgdiff.sourceforge.net/ , il fonctionne plutôt bien.
Marc.
Hors ligne
Quels sont les critères qui me permettront de déterminer la bonne valeur de ces 2 paramètres ?
Très intéressant cet outil ! Je le teste aujourd'hui ou demain au pire. 
Hors ligne
Le default_statistics_target = 1000 est un peu brutal. Cela signifie que lors d'un ANALYSE, PostgreSQL prend 1000 échantillons dans chaque colonne de chaque table.
Le plus souvent c'est inutile. Si vous voulez monter aussi haut, autant le faire sur les colonnes qui vous semblent les plus pertinentes :
ALTER COLUMN colonne SET STATISTICS 1000;
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Pour comparer les schémas, il existe aussi check_postgres.pl.
Guillaume.
Hors ligne
daamien : pas tout à fait d'accord pour les statistiques dans le cas d'un infocentre. Étant donné le volume de données probablement manipulées, et le fait que les changements (et donc passages de stats) se font à heure maîtrisée, je pense qu'il vaut mieux avoir des stats aussi précises que possible. À moins que tu voies un cas où celà pourrait être contre-productif ? (je n'en vois pas)
Dernière modification par Marc Cousin (10/03/2010 10:19:11)
Marc.
Hors ligne
gleu : à moins que j'aie raté quelque chose, check_postgres.pl va se contenter de dire si les schémas sont identiques.
apgdiff génère le script permettant de corriger le schéma.
Marc.
Hors ligne
PS : gom : on te vole un peu ton thread, mais il s'agit de problématiques intéressantes, autant garder la trace de la discussion.
Marc.
Hors ligne
Ah mais au contraire, je suis très content que vous débattiez sur mon thread !
Mais je veux bien encore un peu d'aide pour en finir avec le paramétrage de mes machines ! 
Quels sont les critères qui me permettront de déterminer la bonne valeur de ces 2 paramètres ?
Gôm
Hors ligne
pour les 2 paramètres :
max_fsm_pages : c'est la Free Space Map, la zone mémoire contenant la liste des blocs contenant de l'espace disponible. il doit être capable de contenir toutes les pages nettoyées par vacuum. si il n'est pas assez gros la base risque de grossir inutilement. il est assez pénible à paramétrer et suivre (c'est d'ailleurs une des meilleures raisons de passer en 8.4, la FSM est dynamique). J'aurais tendance à accepter de sacrifier un peu de place sur la FSM (mettre une valeur trop grosse) que d'avoir le risque qu'elle soit pleine.
Pour savoir si elle est suffisante, c'est assez pénible : soit faire un vacuum et regarder les dernières lignes (c'est lent et ça charge la base inutilement), soit installer un module contrib, le pg_freespacemap, qui fournit une vue permettant de rapidement savoir l'état de remplissage. Dans le doute, je crois qu'il vaut mieux le surdimensionner. Une FSM à 2 millions comme sur le dev permet de tracer 2 millions de blocs réutilisable, soit de l'ordre de 16 Go.
maintenance_work_mem : c'est la quantité de mémoire utilisée pour les opérations de création d'index et de vacuum. 512 Mo est une bonne valeur (pour une machine ayant suffisamment de mémoire pour avoir des processus allouant de temps en temps autant de mémoire bien sûr, donc au moins 4 Go de RAM…)
Marc.
Hors ligne
OK, merci pour ces explications très détaillées.
Donc en résumé, je pense mettre :
DEV :
default_statistics_target : 100 (idem PROD)
shared_buffers : 4096 (idem PROD)
maintenance_work_mem : 262144 (soit 256 Mo)PROD :
max_fsm_pages : 2048000 (idem DEV)En PROD, dois-je également passer max_fsm_relations à 20000, comme c'est le cas sur DEV ?
Gôm
Hors ligne
Si vous avez 20000 objets (tables, index, sequence en tout oui, sinon c'est peut être un peu exagéré )
Pour la prod, attention, ça nécessite un redémarrage.
Marc.
Hors ligne
Existe-t-il une requête permettant de connaître précisément le nombre d'objets ?
Ainsi je pourrai mettre une valeur la plus proche possible de la réalité, non ? Par exemple, si j'ai 12432 objets, alors je positionne "max_fsm_relations" à 10000 ?
Hors ligne
À peu de chose près, le nombre d'objets dans une base va correspondre au nombre d'enregistrements dans pgclass. Il peut y avoir plusieurs bases dans un cluster. Il faut donc faire la somme des pg_class de toutes les bases. Et avoir max_fsm_relations à une valeur supérieure pour être sûr de ne pas avoir d'ennuis.
Marc.
Hors ligne
J'ai 1260 objets en PROD et 863 en DEV ...
Je positionne "max_fsm_relations" à 2000 sur les 2 serveurs ou dois-je prendre davantage de marge de sécurité ?
Dernière modification par gom (10/03/2010 14:53:08)
Hors ligne
ça a un coût très faible en mémoire. une marge de sécurite ne fera pas de mal de toutes façons
Marc.
Hors ligne
OK, "max_fsm_relations" à 5000.
Merci ÉNORMÉMENT pour votre aide ! 
Gôm
Hors ligne
Marc : oui, check_postgres.pl n'indique que le nombre d'objets manquants et la liste de ses objets. Il ne te génère pas un script de mise à jour.
Guillaume.
Hors ligne