Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Pour des raisons d'exploitabilité nous allons mettre en place 6 instances Postgresql sur la même machine physique (et non pas 6 bases de données dans la même instance). Chaque instance contiendra une base. Les caractéristiques de la machine physique sont :
Intel(R) Xeon(R) CPU L5630 @ 2.13GHz
2 CPU 16 Cores
32 GB RAM
Linux Red Hat 5.4
Nous ne pouvons pas réaliser de métrologie poussée, ma question concerne principalement les paramètres du noyau Linux kernel.shmall et kernel.shmmax je ne sais pas comment je dois les régler. Et concernant le shared_buffers qui doit être réglé à 1/4 de la RAM lorsqu'on a un serveur Postgresql, qu'en est-il si nous avons plusieurs serveurs Postgresql en parallèle ?
Quant aux paramètres work_mem, max_connections et effective_cache_size nous allons partir avec des valeurs faibles puis les réévaluer par la suite soit respectivement 5MB, 100 et 1GB
D'avance merci pour votre aide
Hors ligne
Pour des raisons d'exploitabilité
Lesquels si ce n'est pas indiscret ? Beaucoup de mes clients me demandent du multi-instances, peu ont de vraies raisons de le faire.
Et concernant le shared_buffers qui doit être réglé à 1/4 de la RAM lorsqu'on a un serveur Postgresql, qu'en est-il si nous avons plusieurs serveurs Postgresql en parallèle ?
Et bien, un quart à distribuer entre chaque instance. La façon de les distribuer dépend de leur taille, de leur activité, etc. En plaçant toutes les bases dans la même instance, vous passez ce problème à PostgreSQL. En plaçant les bases dans différentes instances de la même machine, vous vous attribuez ce travail. Et dès que le comportement d'une instance change au point qu'il faut revoir sa configuration du shared_buffers, c'est tout le monde qu'il faut revoir et redémarrer. Que du bonheur en perspective. Bon courage 
Quant aux paramètres work_mem, max_connections et effective_cache_size nous allons partir avec des valeurs faibles puis les réévaluer par la suite soit respectivement 5MB, 100 et 1GB
J'aurais plutôt tendance à mettre efective_cache_size au 2/3 de la mémoire si l'ensemble des shared_buffers arrive bien à 1/4 de la mémoire.
Guillaume.
Hors ligne
Lesquels si ce n'est pas indiscret ? Beaucoup de mes clients me demandent du multi-instances, peu ont de vraies raisons de le faire.
Pour pouvoir faire des arrêts/relance et sauvegardes physiques de manière indépendante (lié à nos kits d'exploit).
Merci pour votre réponse
Hors ligne
Je m’immisce dans ce sujet, si vous en avez la possibilité je vous conseille de partir sur une version de red hat plus récente.
La 5.4 date de 2009, en général la 5.X ne sera supporté par red hat que jusqu'en 2017. 2 ans ça fait court. Par ailleurs les versions 6, et à fortiori 7 disposent de noyaux plus récents.
Adrien Nayrat
DBA PostgreSQL Freelance
Hors ligne
Une sauvegarde pg_dump ne serait pas suffisante ? on parle de quelles volumétries ?
Guillaume.
Hors ligne
Non car ils ont besoin de pouvoir réaliser des restauration de type PITR. La volumétrie totale est de l'ordre de 200GB. En fait même si vous me trouvez des arguments convaincants pour éviter le multi-instances, je ne pourrai rien y changer car je travaille uniquement sur le RUN et je n'ai pas mon mot à dire sur la solution d'architecture qui a été retenue
Hors ligne
Pages : 1
