Vous n'êtes pas identifié(e).
Bonjour,
OS : Redhat 4.1.2 (64 bits)
1ère instance : PostgreSQL 8.2.13 (une dizaine de bases de données hétéroclites : dev, recette, validation, etc.)
2e instance : PostgreSQL 8.4.5 (un entrepôt de données de recette pour Business Objects où nous réalisons des alimentations hebdo et de la consultation ponctuellement (1 à 3 fois par mois))
Quelles questions dois-je me poser pour réaliser le paramétrage de mes 2 postgresql.conf ?
Merci d'avance.
Gôm
Dernière modification par gom (03/03/2011 17:58:47)
Hors ligne
Bon, excepté le fait que la version de Red Hat est totalement obsolète, surtout si c'est pour un nouveau serveur, et de même pour une 8.2, qui sera EOL en décembre, tu devrais pouvoir obtenir des bons points de départ en utilisant pgtune:
http://pgfoundry.org/frs/?group_id=1000 … se_id=1511
Marc.
Hors ligne
Bonjour,
Bon j'ai un problème ... j'ai récupéré la configuration de notre serveur de production, qui possède les mêmes caractéristiques machine.
CPU : Bi Xeon (2 x 4 cœurs) 2,0 GHz
Mémoire vive : 8Go
Par contre, mon serveur de développement où j'ai mes 2 instances n'est pas un serveur dédié ! Il y a dessus des bases Oracle, des applications Java, etc.
Ma question est donc comment puis-je adapter ma configuration ci-dessous sans "trop" 
perturber les autres utilisateurs de ce serveur de développement ?!
# - Connexions -
listen_addresses = '*'
# - Memoire -
shared_buffers = 2GB
wal_buffers = 8MB
work_mem = 300MB
maintenance_work_mem = 512MB
# - Journaux de transactions -
checkpoint_segments = 50
checkpoint_timeout = 10min
checkpoint_completion_target = 0.9
# - Optimiseur -
effective_cache_size = 5376MB
random_page_cost = 2.0
# - Statistiques -
track_activity_query_size = 4096
# - Traces -
log_filename = 'postgresql-%Y-%m-%d.log'
log_truncate_on_rotation = off
log_line_prefix = '%t [%p]: [%l-1] '
lc_messages = 'C'
log_connections = on
log_checkpoints = on
log_lock_waits = on
log_temp_files = 0
log_autovacuum_min_duration = 0
# - Module pg_stat_statements -
shared_preload_libraries = 'pg_stat_statements'
custom_variable_classes = 'pg_stat_statements'
pg_stat_statements.max = 1000
pg_stat_statements.track = top
pg_stat_statements.save = onGôm
Dernière modification par gom (04/03/2011 10:02:28)
Hors ligne
Par contre, mon serveur de développement où j'ai mes 2 instances n'est pas un serveur dédié ! Il y a dessus des bases Oracle, des applications Java, etc.
Ma question est donc comment puis-je adapter ma configuration ci-dessous sans "trop"
Il n'y a pas de formule magique pour ce genre de situations. Essaie déjà de mesurer la quantité de ressources (CPU / RAM) dont les autres logiciels ont besoin....
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Si c'est un serveur partagé:
Moins de shared_buffers: autant utiliser le cache du système. 512Mo, ça devrait suffire.
Le reste, ça devrait aller.
Surtout, sur un serveur de dev mutualisé de ce genre, vérifier qu'il ne swap pas trop, histoire qu'il n'y ait pas trop de ralentissements inutiles.
Marc.
Hors ligne
OK, merci, par contre quelles sont les conséquences de laisser ça ?
# - Optimiseur -
effective_cache_size = 5376MB
random_page_cost = 2.0Gôm
Dernière modification par gom (04/03/2011 14:35:28)
Hors ligne
Les conséquences sont difficiles à chiffrer.
Le effective_cache_size n'a de toutes façons que peu d'effet sur les plans. Ce que je veux dire c'est qu'entre 2 et 4Go, par exemple, ça ne change habituellement pas grand chose. Mettez le tout de même à une valeur reflétant un peu mieux ce qui va être disponible à Postgres… 1Go par exemple, pour pas qu'il ait de fausses espérances sur le cache.
Par contre, remontez le random_page_cost (à 4, la valeur par défaut)… dans le cas d'un environnement de test, où peu de données sont en cache, et où les performances disque sont difficile à évaluer (voire changeante suivant l'activité du reste), autant lui dire d'être assez pessimiste sur les performances des accès aléatoires.
Marc.
Hors ligne
OK, c'est fait. 
Merci merci beaucoup ! Vous êtes vraiment tous très forts !!! 
Gôm
Hors ligne
N'exagérons rien. On fait juste ça à longueur de journée 
Marc.
Hors ligne
Tant que tu es là ...
pg_ctl reload -D '/app/dwh/pgsql/data' -s -m fastC'est la bonne manière de faire ?
Gôm
Hors ligne
le -m fast ne sert que pour le shutdown, pas pour le reload.
sinon oui.
Marc.
Hors ligne
OK, merci ... encore !
Gôm
Hors ligne