Skip site navigation (1) Skip section navigation (2)

Rép. : Fwd: Questions d'optimisation

From: "Erwan DUROSELLE" <EDuroselle(at)seafrance(dot)fr>
To: <dba(at)paragraf(dot)ch>, <pgsql-fr-generale(at)postgresql(dot)org>
Subject: Rép. : Fwd: Questions d'optimisation
Date: 2004-08-30 10:32:34
Message-ID: c6a50485cb8f801e517b8367941372bc413301d1@ (view raw or flat)
Thread:
Lists: pgsql-fr-generale
De mon expérience personnelle qui ne vaut que ce qu'elle vaut (même si ça fait maintenant 10 ans que je bosse avec des SGBD divers) et n'est étayée par aucun bench:

- Opteron ou bipro: D'instinct, je penche pour le bi-athlon, car je suis sceptique sur l'apport du 64 bits pour les bases de données. Mais c'est absolument sans preuve. Voir des benchs de perfs CPU pure sur différents sites pour se décider. 

- Autres composants: 
    MEMOIRE: avant la CPU ou les disques, je crois que la mémoire est _le_ composant essentiel d'un serveur de SGBD: toute lecture qui peut être faite en mémoire cache au lieu du disque est bonne à prendre. De plus, chaque utilisateur connecté consomme de la mémoire.
  Il faut donc une mémoire surdimensionnée. 1 Go semble être un minimum de nos jours pour un serveur de BDD. 2 ou 4 Go le confort.

   CONTROLEUR: le raid 0+1 ( mirroir + stripping) semble être la solution qui optimise le rapport vitesse/sécurité. De mon point de vue, la sécurité des données est primordiale. Si on n'a pas les moyens de faire du 0+1, le Raid5 est une solution "moyenne". 
  Evidemment, du raid Hard est préférable au raid soft. 
  Utiliser aussi un contrôleur avec une mémoire cache la plus grosse possible (256 Mo, ...). La mémoire cache doit être sécurisée (batterie) pour être sûr de ne pas perdre de données en cas de crash.

   DISQUE: Le SCSI semble être plébiscité, pour sa sécurité (s'il dit que c'est écrit sur disque, c'est effectivement écrit, contrairement à l'ATA) et pour sa capacité à traiter et optimiser différentes demandes en même temps (contrairement à l'ATA). Question perfs pures, il semble que les disques Serial ATA aient maintenant des perfs quasi équivalentes aux disques SCSI. Comme ils sont bon marché, c'est sans doute un bon compromis. Faire aussi attention à la vitesse de rotation des disques: un 15000 tours/min est plus performant qu'un 7200!
  L'idéal, est d'avoir plusieurs "axes": 2 contrôleurs différents ( ou 3...) pointant vers autant de baies RAID différentes. On parallélise encore plus les IO. Mais là, il faut être riche!
  

J'espère que ça peut aider...

Erwan

>>> Francois Suter <dba(at)paragraf(dot)ch> 30/08/2004 11:36:04 >>>
Salut à tous,

J'ai reçu le message suivant, vie le site Advocacy et ce n'est pas ma 
spécialité. Est-ce que quelqu'un aurait un conseil?

Merci d'avance.

François

Begin forwarded message:

> Nous utilisons postgresql depuis plus de 4 ans maintenant, sous 
> RedHat,  et
>  nous sommes de plus en plus satisfait de notre choix \: coût \+ 
> puissance\.
>  Nous avons suivi avec étonnement la progression de ce SGBD \: nous 
> sommes à
>  la version 7\.4 et nos  réglages sont optimisés\. Mais, notre serveur
>  commence à souffrir de notre monter de charge \: nous avons par jours 
> 130
>  000 requêtes, 16 Mo répliqués, 400 utilisateurs distants avec une 
> base qui
>  frôle les 5 go\. Nous voudrions acheter un PC UNIQUEMENT pour notre 
> base de
>  données mais nous ne savons quoi chercher\. Pouvez vous nous aider \? 
> Nous
>  avons entendu parler de la compatibilité avec l\'opteron\. Plusieurs
>  questions donc \: \(en supposant que notre budget soit illimité\)
>  - faut-il mieux un bi processeur opteron 250 ou un super AMD Athelon 
> 64
>  3800\+ - y a t-il d\'autres composants à optimiser pour la gestion 
> d\'un
>  SGBD \(mémoire, disque, carte\) Les réponses vous paraîtront simples 
> et
>  évidentes, mais nous avons eu tant de conseils différents sur le 
> sujet que
>  nous aimerions avoir votre avis\.


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html


pgsql-fr-generale by date

Next:From: Erwan DUROSELLEDate: 2004-08-30 13:26:56
Subject: Re: Rép. : Fwd: Questions d'optimisation
Previous:From: Francois SuterDate: 2004-08-30 09:36:04
Subject: Fwd: Questions d'optimisation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group