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

Re: Rép. : Fwd: Questions d'optimisation

From: "Erwan DUROSELLE" <EDuroselle(at)seafrance(dot)fr>
To: <jmreymond(at)gmail(dot)com>, <pgsql-fr-generale(at)postgresql(dot)org>
Subject: Re: Rép. : Fwd: Questions d'optimisation
Date: 2004-08-30 13:26:56
Message-ID: 2f88d378adad7c9862d3f47dd0d115db41332aaa@ (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Ce genre de sujet est évidemment la porte ouverte à des discussions sans fin car il n'y a pas 1 seule réponse valable: tout dépend de la base elle-même, de son  activité, du budget disponible, des convictions religieuses du DBA ( Unix vs Windows vs Mac..., RISC vs CISC...)

Néanmoins, un article de référence a été écrit par Bruce Momjian, sans doute suite à de nombreuses discussions sur le sujet sur les forums en anglais:
http://www.ca.postgresql.org/docs/momjian/hw_performance/0.html
ou en pdf
http://www.ca.postgresql.org/docs/momjian/hw_performance.pdf


Essayons cepandant d'approfondir...

> >>> Jean-Max Reymond <jmreymond(at)gmail(dot)com> 30/08/2004 12:48:18 >>>
> > On Mon, 30 Aug 2004 12:32:34 +0200, Erwan DUROSELLE <eduroselle(at)seafrance(dot)fr> wrote:
> > 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.
> > 
> 
> hors instinct, l'Athlon 64 bits va plus vite. Clair et net, toutes les
> mesures et témoignages concordent. Comme Postgres est I/O bound, c'est
> moins important que la carte RAID sur batterie.

Dont acte.

> 
> > - 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.

> Tout dépend de la taille de ta base, bien sur. Plus, c'est toujours
> mieux. Mais j'ai un client avec une base de 32 Mo et 256 Mo de RAM
> sufisent très largement :-)
Evidemment!

L'idéal pour les performances est de pouvoir monter la base entière en RAM, mais c'est rarement possible sauf dans ton exemple de petite base.
Je persiste à dire que la RAM doit être très largement dimensionnée pour éviter des _lectures_ disque, qui sont infiniment plus lentes que les lectures mémoire. Et la RAM est assez bon marché => ne pas s'en priver.
Si la base fait surtout des _écritures_, il faut optimiser le système disque. Mais ce n'est pas le cas général: un système transactionnel ou décisionnel "classique" fait beaucoup plus de lectures que d'écritures: il faut peupler l'écran (1 lecture au moins), puis il y a toujours 3 ou 4 règles de gestion à vérifier (lectures) avant de faire enfin une écriture.

> > 
> >    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".

> RAID 5 sans perte et plus rapide.
Beaucoup d'admin que le 0+1 est le + rapide: Dans les 2 cas, un écriture logique nécessite 2 écritures physiques. Par contre, en 0+1, tu peux paralléliser les lectures car les données sont à 2 endroits différents. Par contre, le 0+1 coute cher en disques. Le Raid5 est donc souvent un bon compromis.

Pour la sécurité, ne pas oublier la loi de Murphy: Comme le RAID sécurise la perte de n disques, ce sont n+1 disques qui vont tomber en panne.
Je l'ai déja vécu 2 fois... 1 fois le contrôleur avait écrit n'importe quoi sur tous les disques, une autre fois une surtension avait fait cramer les 9 (!) disques d'une baie.

> >   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.

> Ets urtout la mémoire cache sur batterie te permet de mettre le fameux
> paramètre fsync à off et d'obtenir des gains spectaculaires de perfs
> car ne l'oublions pas, Postgres est I/O bound et en particulier à
> cause de ce paramètre.
En est-tu bien sur?
En relisant la doc (http://www.postgresql.org/docs/7.4/interactive/runtime-config.html, §16.4.3.1. Settings) , ce que je comprends, c'est qu'avec fsync off, tu prends le risque que l'OS n'ait pas encore donné l'ordre d'écriture au disque lors d'un crash. Dans ce cas, cache sécurisé ou non, tu as perte de données.
En conséquence, il ne faut mettre fsync que si 
 - on peut se permettre de perdre les données saisies depuis le dernier backup, ce qui n'est pas souvent le cas dans un système transactionnel (en tout cas pas dans ma boîte!)
ou
 - le besoin de performances est supérieur au risque de pertes de données. Mais le risque persiste quelque soit le hard sécurisé.

> > 
> >    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!
> oui mais les essais montrent qu'avec 10000tours/mn, tu as le meilleur
> compromis prix/vitesse/fiabilité.
Bien sur. Mais on parlait "performances pures".

> >   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!
> Il te faut des tablespace's pour utiliser tes différents axes ou alors
> aller faire des liens symboliques.
> 
Evidement, les tablespaces (disponibles dans quelques semaines avec PostgreSQL 8 !) servent exactement à cela, mais en attendant, je pensais surtout à séparer les activités d'écriture dans les logs des activités d'écriture dans les tables. Voir doc de B Momjian.

-- 


pgsql-fr-generale by date

Next:From: Thierry GARCIADate: 2004-08-30 17:58:19
Subject: Re: Type Blob
Previous:From: Erwan DUROSELLEDate: 2004-08-30 10:32:34
Subject: Rép. : Fwd: Questions d'optimisation

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