| Lists: | pgsql-fr-generale |
|---|
| From: | Christophe Mailhebuau <christophe(dot)mailhebuau(at)laregion-alpc(dot)fr> |
|---|---|
| To: | Pgsql Fr Generale <pgsql-fr-generale(at)postgresql(dot)org> |
| Subject: | A votre avis |
| Date: | 2016-01-28 11:24:26 |
| Message-ID: | 1741780288.6757691.1453980266729.JavaMail.zimbra@aquitaine.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-fr-generale |
Bonjour,
Suite à notre augmentation du max_connexion à 500 sur notre serveur postgres de production (9.2),
ancienne configuration mémoire RAM : 16GB 8 cpu
Nous avons décidé d'augmenter la RAM et le nombre de CPU
Nous allons passer à 40GB de RAM et 16CPU
Pourriez-vous me dire si j'ai du paramétrage postgres à toucher ou est-ce qu'il va se caler tout seul sur ce nouveau paramétrage système ?
(nous sommes sur deux serveurs en réplication, et virtuels (vmware))
Pour le deuxième point j'aimerai avoir votre avis (nous avons eu celui de Dalibo venu en prestation hier ) mais plusieurs avis
valent mieux qu'un ;-)
Nous allons passer en serveur physique dans quelques temps pour renplacer le Master de production pour l'instant en virguel donc (le slave restera en virtuel).
Ce serveur physique sera équipé de 124gb de RAM, 2 disques de 146GB(mirroir système ) et 2SSD de 800GB(mirroir données postgres ) et deux SATA 1T (mirroir pour les backups)
2CPU 4 coeur
Pensez-vous que ce choix en mirroir est une bonne solution ?
Cordialement
Christophe
Christophe Mailhebuau
Administrateur Systèmes Open Source
Direction du Système d'Information
14 Rue François de Sourdis
33077 Bordeaux Cedex - France
Fax : +33 (0)5.56.56.38.58
GSM : +00 33 (0)6.30.11.09.77
| From: | Thomas Boussekey <thomas(dot)boussekey(at)gmail(dot)com> |
|---|---|
| To: | Christophe Mailhebuau <christophe(dot)mailhebuau(at)laregion-alpc(dot)fr> |
| Cc: | Pgsql Fr Generale <pgsql-fr-generale(at)postgresql(dot)org> |
| Subject: | Re: A votre avis |
| Date: | 2016-01-28 12:18:22 |
| Message-ID: | CALUeYmfQ=i-B7u2cb=sruqpzDB_Yh_3-BUOafPV9Ge6pnwh+yA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-fr-generale |
Bonjour Christophe,
Voici mon lien de référence pour ces configuration
<https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server>.
La configuration par défaut est:
shared_buffers: 1/4 de la RAM du serveur
effective_cache_size: 1/2 de la RAM du serveur.
Excellent après-midi,
Thomas
Le 28 janvier 2016 à 12:24, Christophe Mailhebuau <
christophe(dot)mailhebuau(at)laregion-alpc(dot)fr> a écrit :
> Bonjour,
>
> Suite à notre augmentation du max_connexion à 500 sur notre serveur
> postgres de production (9.2),
> ancienne configuration mémoire RAM : 16GB 8 cpu
>
> Nous avons décidé d'augmenter la RAM et le nombre de CPU
> Nous allons passer à 40GB de RAM et 16CPU
>
> Pourriez-vous me dire si j'ai du paramétrage postgres à toucher ou est-ce
> qu'il va se caler tout seul sur ce nouveau paramétrage système ?
>
> (nous sommes sur deux serveurs en réplication, et virtuels (vmware))
>
> Pour le deuxième point j'aimerai avoir votre avis (nous avons eu celui de
> Dalibo venu en prestation hier) mais plusieurs avis
> valent mieux qu'un ;-)
>
> Nous allons passer en serveur physique dans quelques temps pour renplacer
> le Master de production pour l'instant en virguel donc (le slave restera en
> virtuel).
>
> Ce serveur physique sera équipé de 124gb de RAM, 2 disques de
> 146GB(mirroir système ) et 2SSD de 800GB(mirroir données postgres ) et deux
> SATA 1T (mirroir pour les backups)
> 2CPU 4 coeur
>
> Pensez-vous que ce choix en mirroir est une bonne solution ?
>
> Cordialement
>
> Christophe
>
> <http://aquitaine.fr> <http://aquitaine.fr> <http://aquitaine.fr>
> Christophe Mailhebuau
> *Administrateur Systèmes Open Source*
> Direction du Système d'Information
> 14 Rue François de Sourdis
> 33077 Bordeaux Cedex - France
>
>
> *Fax : *+33 (0)5.56.56.38.58
> *GSM : *+00 33 (0)6.30.11.09.77
>
>
>
> <http://ls2.aquitaine.fr/r/25/8268cdf0-fa30-43ac-a6f8-3f55a97aa470>
>
>
| From: | Stéphane Schildknecht <stephane(dot)schildknecht(at)postgres(dot)fr> |
|---|---|
| To: | pgsql-fr-generale(at)postgresql(dot)org |
| Subject: | Re: A votre avis |
| Date: | 2016-01-28 12:34:53 |
| Message-ID: | 56AA0AED.80809@postgres.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-fr-generale |
Bonjour Christophe,
On 28/01/2016 12:24, Christophe Mailhebuau wrote:
> Bonjour,
>
> Suite à notre augmentation du max_connexion à 500 sur notre serveur postgres de
> production (9.2),
> ancienne configuration mémoire RAM : 16GB 8 cpu
>
> Nous avons décidé d'augmenter la RAM et le nombre de CPU
> Nous allons passer à 40GB de RAM et 16CPU
>
> Pourriez-vous me dire si j'ai du paramétrage postgres à toucher ou est-ce qu'il
> va se caler tout seul sur ce nouveau paramétrage système ?
Il ne va pas se caler tout seul, parce qu'il n'a pas connaissance de la
configuration du serveur.
Quelle est la volumétrie estimée de la base ?
Quel est le nombre de connexions attendu ?
S'agit-il de requêtes lentes, de requêtes rapides, de calculs...
Combien de connexions simultanées ?
Les réponses à ce jour de question permettent d'orienter le paramétrage de
PostgreSQL (work_mem, maintenance_work_mem, shared_buffers,
effective_cache_size, autovacuum_max_workers...), mais aussi la configuration
du serveur.
>
> (nous sommes sur deux serveurs en réplication, et virtuels (vmware))
On parle donc de 16vCPU, et de 40GB par machine virtuel ?
>
> Pour le deuxième point j'aimerai avoir votre avis (nous avons eu celui de
> Dalibo venu en prestation hier) mais plusieurs avis
> valent mieux qu'un ;-)
Je suis surpris de cette remarque. Elle laisse supposer plusieurs choses :
1. vous avez des doutes sur votre prestataire ;
2. vous recherchez un avis "gratuit" en plus de l'avis "payant" fourni par
votre prestataire.
Si vous avez des doutes sur votre prestataire, vous pouvez en changer.
Mais il est pour le moins maladroit de laisser penser que les listes de
diffusion aient pour vocation de fournir de l'expertise gratuite en
remplacement ou en complément de prestations commerciales.
>
> Nous allons passer en serveur physique dans quelques temps pour renplacer le
> Master de production pour l'instant en virguel donc (le slave restera en virtuel).
>
> Ce serveur physique sera équipé de 124gb de RAM, 2 disques de 146GB(mirroir
> système ) et 2SSD de 800GB(mirroir données postgres ) et deux SATA 1T (mirroir
> pour les backups)
> 2CPU 4 coeur
Cela représente une puissance de calcul inférieure à vos VM, puisque vous avez
8 coeurs contre 16vCPU.
Aujourd'hui, où se situent vos problèmes de performances ? Si vous n'en avez
pas encore, où les envisagez-vous ? Dans la puissance de calcul, dans les accès
disques, dans les opérations de tri (nécessité de plus de RAM pour éviter les
tris sur disque...) ?
>
> Pensez-vous que ce choix en mirroir est une bonne solution ?
Qu'appelez-vous mirroir ?
RAID 1 ?
Concernant les backups, j'éviterai le stockage sur le serveur de production. Si
vous le perdez, vous perdez vos sauvegardes.
Utilisez plutôt un serveur et/ou un stockage externe.
Librement,
--
Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
Loxodata - Conseil, expertise et formations
06.17.11.37.42
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
| From: | Stéphane Schildknecht <stephane(dot)schildknecht(at)postgres(dot)fr> |
|---|---|
| To: | pgsql-fr-generale(at)postgresql(dot)org |
| Subject: | Re: A votre avis |
| Date: | 2016-01-28 12:40:53 |
| Message-ID: | 56AA0C55.9000400@postgres.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | Postg메이저 토토 사이트SQL |
On 28/01/2016 13:18, Thomas Boussekey wrote:
> Bonjour Christophe,
>
> Voici mon lien de référence pour ces configuration
> <https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server>.
>
> La configuration par défaut est:
> shared_buffers: 1/4 de la RAM du serveur
> effective_cache_size: 1/2 de la RAM du serveur.
>
Sur IRC, RhodiumToad conseillait le paramétrage suivant pour démarrer :
work_mem = RAM/(16*cpus)
maintenance_work_mem = RAM/16
shared_buffers : 10% RAM sans dépasser 2GB
Les 2GB de shared peuvent sembler une limite basse, mais le paramétrage doit
être affiné en fonction des tests sur des jeux de données et des requêtes
représentatives de l'activité réelle.
--
Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
Loxodata - Conseil, expertise et formations
06.17.11.37.42
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
| From: | Christophe Mailhebuau <christophe(dot)mailhebuau(at)laregion-alpc(dot)fr> |
|---|---|
| To: | Thomas Boussekey <thomas(dot)boussekey(at)gmail(dot)com> |
| Cc: | Pgsql Fr Generale <pgsql-fr-generale(at)postgresql(dot)org> |
| Subject: | Re: A votre avis |
| Date: | 2016-01-28 13:36:16 |
| Message-ID: | 1801171699.6812365.1453988176619.JavaMail.zimbra@aquitaine.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-fr-generale |
Merci beaucoup Thomas.
Je vais lire et suivre tout ça.
Christophe
| From: | Rodolphe Quiedeville <rodolphe(at)quiedeville(dot)org> |
|---|---|
| To: | pgsql-fr-generale(at)postgresql(dot)org |
| Subject: | Re: A votre avis |
| Date: | 2016-02-01 14:18:01 |
| Message-ID: | 56AF6919.9030404@quiedeville.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-fr-generale |
On 01/28/2016 12:24 PM, Christophe Mailhebuau wrote:
> Bonjour,
>
> Suite à notre augmentation du max_connexion à 500 sur notre serveur
> postgres de production (9.2),
> ancienne configuration mémoire RAM : 16GB 8 cpu
>
> Nous avons décidé d'augmenter la RAM et le nombre de CPU
> Nous allons passer à 40GB de RAM et 16CPU
>
> Pourriez-vous me dire si j'ai du paramétrage postgres à toucher ou
> est-ce qu'il va se caler tout seul sur ce nouveau paramétrage système ?
>
> (nous sommes sur deux serveurs en réplication, et virtuels (vmware))
>
> Pour le deuxième point j'aimerai avoir votre avis (nous avons eu celui
> de Dalibo venu en prestation hier) mais plusieurs avis
> valent mieux qu'un ;-)
>
> Nous allons passer en serveur physique dans quelques temps pour
> renplacer le Master de production pour l'instant en virguel donc (le
> slave restera en virtuel).
Bonjour,
Tous les autres points ont été traités dans les réponses que vous avez
reçu sur la liste, je me permets d'attirer votre attention sur ce
dernier point. A quoi sert votre slave ? Suivant les volumétires d'ajout
avoir un slave en streaming (je suppute vous infirmez/confirmerez) avec
des deltas d'io important (physical vs virtuel) peut entrainer de
fréquentes désynchronisation, avez-vous inclus cette problématique dans
votre nouvelle architecture ?
--
Rodolphe Quiédeville - @rodoq
Web Performance Evangelist - De omnibus dubitandum
http://blog.rodolphe.quiedeville.org/
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)