Re: Fwd: Décision Inform

Salut à tous,

Je viens de recevoir l'info ci-dessous, que je vous laisse découvrir.
Ce serait vraiment bien si on pouvait faire quelque chose, car je suis
sûr que les autres "concurrents" ne vont pas se gêner pour se mettre à
leur avantage.

Par contre, je ne suis pas du tout spécialiste de l'optimisation dans
PostgreSQL (et en plus je suis en vacances du 18.7 au 2.8), d'où ma
demande: y a-t-il quelqu'un parmi vous qui serait intéressé et aurait
le temps (je ne pense pas que ça en demande tant que ça) d'interface
avec Clever Age, afin que les tests de PostgreSQL se passent le mieux
possible? Ce serait vraiment super. Décision Informatique dispose d'un
lectorat assez conséquent.

Si quelqu'un s'annonce, je transmettrai ses coordonnées à Clever Age,
avec lesquels je vais de ce pas prendre contact de toute façon.

A+

François

Begin forwarded message:

> From: "Fred Bordage" <fbordage(at)francenet(dot)fr>
> Date: July 8, 2004 16:53:46 CEST
> To: <fr(at)postgresql(dot)org>
> Subject: Décision Informatiques - comparatif SGBD/R
> Reply-To: "Fred Bordage" <fbordage(at)francenet(dot)fr>
>
> Bonjour François,
>
> Décision Informatique publiera à la rentrée (début septembre), un
> comparatif
> sur les bases de données relationnelles d'entrée de gamme adaptées aux
> PME.
>
> Ce comparatif de 5 pages portera sur les produits suivants :
> - Oracle 10g Standard Edition One
> - Microsoft SQL Server 2000 Standard Edition
> - IBM DB2 Universal Database Express Edition V8.1
> - MySQL AB MySQL 4.0 (Linux)
> - PostgreSQL 7.4.3 (Linux)
>
> Les tests fonctionnels et de montée en charge seront réalisés par la
> société
> Clever-Age à compter de fin juillet. L'objectif est de comparer les
> SGBD/R
> sur des aspects fonctionnels (couverture, facilité d'installation et
> d'administration, etc.) et techniques (montée en charge,
> performance). La
> société Clever Age réalise les tests (voir grille de critères) pour
> Décision
> Informatique et nous écrivons l'article sur la base de leur rapport de
> test.
>
> Les tests de montée en charge seront réalisé à l'aide du logiciel
> JMeter.
> Ils consistent à charger les machines pour mesurer leur capacité à
> monter en
> charge (point de rupture) et leurs performances. 5 clients "tirent" des
> salves de requêtes SQL sur le serveur.
>
> Vous avez la possibilité de participer activement aux tests en aidant
> la
> société Clever-Age à installer et optimiser votre outil ainsi qu'en
> optimisant les requêtes SQL et les bases utilisées pour le test.
> D'autre
> part, vous pouvez choisir l'os d'installation et la version du produit
> que
> nous allons tester.
>
> Si vous souhaitez intervenir dans ce test, merci de vous mettre en
> relation
> avec Olivier Mansour (omansour(at)clever-age(dot)com - 01 53 34 66 10) chez
> Clever Age.
>
> Je me tiens à ta disposition jusqu'à demain 16h si tu as des questions.
>
> Cordialement,
> Fred Bordage
> +33 6 16 95 96 01
>

Francois Suter wrote:
> Salut à tous,
>
> Je viens de recevoir l'info ci-dessous, que je vous laisse découvrir. Ce
> serait vraiment bien si on pouvait faire quelque chose, car je suis sûr
> que les autres "concurrents" ne vont pas se gêner pour se mettre à leur
> avantage.
>
> Par contre, je ne suis pas du tout spécialiste de l'optimisation dans
> PostgreSQL (et en plus je suis en vacances du 18.7 au 2.8), d'où ma
> demande: y a-t-il quelqu'un parmi vous qui serait intéressé et aurait le
> temps (je ne pense pas que ça en demande tant que ça) d'interface avec
> Clever Age, afin que les tests de PostgreSQL se passent le mieux
> possible? Ce serait vraiment super. Décision Informatique dispose d'un
> lectorat assez conséquent.
>
> Si quelqu'un s'annonce, je transmettrai ses coordonnées à Clever Age,
> avec lesquels je vais de ce pas prendre contact de toute façon.

j'ai un peu de disponibilité actuellement donc si ça peut aider, pas de
problèmes, je suis là.
Pour tout ce qui est optimisations, tests de perfs, on peut tirer
quelque chose de vraiment sympa. A nous de montrer ce que Postgres a
dans le ventre :-)

--
Jean-Max Reymond
CKR Solutions
http://www.ckr-solutions.com

Le vendredi 9 Juillet 2004 09:14, Jean-Max Reymond a écrit :
> Francois Suter wrote:
> > Salut à tous,
> >
> > Je viens de recevoir l'info ci-dessous, que je vous laisse découvrir. Ce
> > serait vraiment bien si on pouvait faire quelque chose, car je suis sûr
> > que les autres "concurrents" ne vont pas se gêner pour se mettre à leur
> > avantage.
> >
> > Par contre, je ne suis pas du tout spécialiste de l'optimisation dans
> > PostgreSQL (et en plus je suis en vacances du 18.7 au 2.8), d'où ma
> > demande: y a-t-il quelqu'un parmi vous qui serait intéressé et aurait le
> > temps (je ne pense pas que ça en demande tant que ça) d'interface avec
> > Clever Age, afin que les tests de PostgreSQL se passent le mieux
> > possible? Ce serait vraiment super. Décision Informatique dispose d'un
> > lectorat assez conséquent.
> >
> > Si quelqu'un s'annonce, je transmettrai ses coordonnées à Clever Age,
> > avec lesquels je vais de ce pas prendre contact de toute façon.
>
> j'ai un peu de disponibilité actuellement donc si ça peut aider, pas de
> problèmes, je suis là.
> Pour tout ce qui est optimisations, tests de perfs, on peut tirer
> quelque chose de vraiment sympa. A nous de montrer ce que Postgres a
> dans le ventre :-)

Ce qui serait super sympa aussi c'est de nous donner les méthodologies
d'optimisation que tu pourrais mettre en oeuvre avec eux ...
Pourquoi ces choix, quelles options dans la conf, quels autres réglages ...

Nous avons tous plus ou moins d'expérience avec PostgreSQL ... mais je pense
que nous ne connaissons pas forcément toutes les optimisations
envisageables ... ou les astuces des uns et des autres pour savoir quel
réglage optimal et en fonction de quels paramètres ...

Le tuning sous PostgreSQL est plus simple que sous Oracle, mais aussi à mon
goût beaucoup plus abstrait dans les optimisations ... enfin je n'ai pas
trouvé à ce jour un site qui donne de vraies clés sur les réglages de
postgresql.conf ...

Enfin à l'occasion, je pense que ce genre de document serait le bienvenue sur
postgresqlfr.org ;o)

Cordialement,
--
Hervé Piedvache

Elma Ingénierie Informatique
6 rue du Faubourg Saint-Honoré
F-75008 - Paris - France
Pho. 33-144949901
Fax. 33-144949902

Hervé Piedvache m'expliquait (le 09.07.2004 11:14):
> Enfin à l'occasion, je pense que ce genre de document serait le bienvenue sur
> postgresqlfr.org ;o)
Pour sur que ce serait bien

Peut-être un point de départ?
http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html

Ca peut donner des idées!

--
Jean-Christophe Arnu
Paratronic

Salut,

> Nous avons tous plus ou moins d'expérience avec PostgreSQL ... mais je
> pense
> que nous ne connaissons pas forcément toutes les optimisations
> envisageables ... ou les astuces des uns et des autres pour savoir quel
> réglage optimal et en fonction de quels paramètres ...

Ce que je pensais, c'est transmettre à la liste de diffusion les
informations fournies par Clever Age (la société qui va faire les
tests) et que chacun y mette son grain de sel. Par contre, il faut
ensuite que quelqu'un fasse une synthèse et la fournisse à Clever Age.
Je le ferai bien, mais je suis en vacances de 18.7 au 2.8...

On verra encore avec ce que me dit Clever Age. Je les ai contacté,
j'attends une réponse.

A+

---------------
Francois

Home page: http://www.monpetitcoin.com/

"Nous sommes peu à penser trop, trop à penser peu." - Françoise Sagan

Ca me semble assez judicieux ...

Il faut peut-être déjà liste les besoins d'informations dont on peut avoir
besoin non ?

Infrastructure hardware ...
Structure de la base et volume de données ...
Requêtes appliquées à la base ... bref modus operandis des tests ... ;o)

Cordialement,

Le vendredi 9 Juillet 2004 11:42, Francois Suter a écrit :
> Salut,
>
> > Nous avons tous plus ou moins d'expérience avec PostgreSQL ... mais je
> > pense
> > que nous ne connaissons pas forcément toutes les optimisations
> > envisageables ... ou les astuces des uns et des autres pour savoir quel
> > réglage optimal et en fonction de quels paramètres ...
>
> Ce que je pensais, c'est transmettre à la liste de diffusion les
> informations fournies par Clever Age (la société qui va faire les
> tests) et que chacun y mette son grain de sel. Par contre, il faut
> ensuite que quelqu'un fasse une synthèse et la fournisse à Clever Age.
> Je le ferai bien, mais je suis en vacances de 18.7 au 2.8...
>
> On verra encore avec ce que me dit Clever Age. Je les ai contacté,
> j'attends une réponse.
>
> A+
>
> ---------------
> Francois
>
> Home page: http://www.monpetitcoin.com/
>
> "Nous sommes peu à penser trop, trop à penser peu." - Françoise Sagan
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend

--
Hervé Piedvache

Elma Ingénierie Informatique
6 rue du Faubourg Saint-Honoré
F-75008 - Paris - France
Pho. 33-144949901
Fax. 33-144949902

> Infrastructure hardware ...
> Structure de la base et volume de données ...
> Requêtes appliquées à la base ... bref modus operandis des tests ...
> ;o)

Tout ce que je sais pour l'instant c'est qu'ils vont utiliser JMeter
pour faire les montées en charge.

Il semblerait que l'on puisse influencer l'OS sur lequel ils installent
PostgreSQL, mais je ne sais si le choix est complètement ouvert ou
quand même limité. Et y a-t-il une variante de *nix sur laquelle
PostgreSQL est vraiment plus rapide...?

A+

---------------
Francois

Home page: http://www.monpetitcoin.com/

"Nous sommes peu à penser trop, trop à penser peu." - Françoise Sagan

Jean-Christophe ...

Le vendredi 9 Juillet 2004 11:29, Jean-Christophe Arnu a écrit :
> Hervé Piedvache m'expliquait (le 09.07.2004 11:14):
> > Enfin à l'occasion, je pense que ce genre de document serait le bienvenue
> > sur postgresqlfr.org ;o)
>
> Pour sur que ce serait bien
>
> Peut-être un point de départ?
> http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html
>
> Ca peut donner des idées!

Oui voilà ça peut donner des idées ;o)

Le soucis c'est que pour moi cela soulève aussi des tas de questions et j'ai
pas de réponse précises ...
Typiquement :
vacuum_mem

1024 to Int Max

Documentation :
Specifies the maximum amount of memory to be used by VACUUM to keep track of
to-be-reclaimed tuples. The value is specified in kilobytes, and defaults to
8192 kilobytes. Larger settings may improve the speed of vacuuming large
tables that have many deleted tuples.

Comments :
As this setting only uses RAM when VACUUM is running, you may wish to
increase it on high-RAM machines to make VACUUM run faster (but never more
than 20% of available RAM!)
Further, this setting can be SET at runtime, so a good approach is often to
set it low for the frequent regular VACUUMs, and set it high for the
nightly/weekly/periodic VACUUM FULL.

Et moi avec ça je me pose des questions du genre :

Comment je vois véritablement l'application des changements de cette valeur ?
Parce qu'en plus comparer 2 vacuum sur une table .... c'est pas possible à la
suite ... et celui du lundi matin ... n'est pas forcément celui du mardi
matin car tes données n'ont pas forcément évoluée de la même façon ...

Comment je suis sûr d'avoir trouvé le bon réglage ? Quels éléments me
permettent de savoir si je m'approche du but ... ?

Il est dit qu'une valeur élevée permet d'améliorer la vitesse du vaccum sur
les grosses tables qui on beaucoup d'enregistrement effacés ...
Super, moi j'ai des tables de 50 000 000 d'enregistrements ... avec 100 à 250
update (donc des delete) par jour ... est-ce que c'est beaucoup de delete par
rapport à mes 50 millions de records ... ?
Ma table elle fait environ 21 Go ... j'ai 8Go de RAM ... est-ce que 20 % de
mémoire pour vacuum_mem c'est vraiment efficace ?
Est-ce que j'ai pas intérêt à augmenter ma mémoire physique ... etc.

Je suis conscient aussi que c'est pas facile d'avoir une doc qui réponde à
cela ... mais il manque des règles de calcul des méthodes d'évaluation de
rapport volume de données, taille des tables, RAM .. bref des choses que tu
vas pouvoir trouver dans l'univers Oracle ... même si tu t'arraches parfois
les cheveux aussi ... ;o)

J'aimerai bien que l'on arrive à trouver un modus operendis pour réaliser ce
genre de chose sur les paramètres de PostregreSQL ... cela rendrait le tuning
plus réaliste et plus humain ... mais je ne sais pas si c'est véritablement
possible ... peut-être on va finir par écrire un bouquin sur le sujet ;o)

Cordialement,
--
Hervé Piedvache

Elma Ingénierie Informatique
6 rue du Faubourg Saint-Honoré
F-75008 - Paris - France
Pho. 33-144949901
Fax. 33-144949902

Bonne question ... mes expériences ne reposent à ce jour que sur Linux et
Solaris ... et pour moi Linux est meilleur ... mais je n'ai jamais effectué
aucun test sur du BSD ...

Le vendredi 9 Juillet 2004 12:11, Francois Suter a écrit :
> > Infrastructure hardware ...
> > Structure de la base et volume de données ...
> > Requêtes appliquées à la base ... bref modus operandis des tests ...
> > ;o)
>
> Tout ce que je sais pour l'instant c'est qu'ils vont utiliser JMeter
> pour faire les montées en charge.
>
> Il semblerait que l'on puisse influencer l'OS sur lequel ils installent
> PostgreSQL, mais je ne sais si le choix est complètement ouvert ou
> quand même limité. Et y a-t-il une variante de *nix sur laquelle
> PostgreSQL est vraiment plus rapide...?
>
> A+
>
> ---------------
> Francois
>
> Home page: http://www.monpetitcoin.com/
>
> "Nous sommes peu à penser trop, trop à penser peu." - Françoise Sagan

--
Hervé Piedvache

Elma Ingénierie Informatique
6 rue du Faubourg Saint-Honoré
F-75008 - Paris - France
Pho. 33-144949901
Fax. 33-144949902

Hervé Piedvache m'expliquait (le 09.07.2004 12:23):
> Bonne question ... mes expériences ne reposent à ce jour que sur Linux et
> Solaris ... et pour moi Linux est meilleur ... mais je n'ai jamais effectué
> aucun test sur du BSD ...
J'ai lu aussi quelque part que (Free)BSD était meilleur pour pg! Oui
mais bon ok, en quoi, ça je n'en sais rien?

--
Jean-Christophe Arnu
Paratronic

Jean-Christophe Arnu wrote:
> Hervé Piedvache m'expliquait (le 09.07.2004 12:23):
>
>> Bonne question ... mes expériences ne reposent à ce jour que sur Linux
>> et Solaris ... et pour moi Linux est meilleur ... mais je n'ai jamais
>> effectué aucun test sur du BSD ...
>
> J'ai lu aussi quelque part que (Free)BSD était meilleur pour pg! Oui
> mais bon ok, en quoi, ça je n'en sais rien?
>
>

pour les mesures que j'ai pu obtenir, les noyaux 2.6 avec optimisation
des I/O ont pris (ou repris) l'avantage.
De toute façon, un comparatif sur des bases de données doit se faire
avec OS identique pour pouvoir vraiment comparer les bases de données
même si cela est dur avec SQL Server. Le mail de Clever Age parlait de
Linux comme support pour Mysql et Postgres donc sans aucun doute, Linux
2.6.X avec XFS comme file system :-)

--
Jean-Max Reymond
CKR Solutions
http://www.ckr-solutions.com

Jean-Christophe Arnu wrote:
> Hervé Piedvache m'expliquait (le 09.07.2004 11:14):
>
>> Enfin à l'occasion, je pense que ce genre de document serait le
>> bienvenue sur postgresqlfr.org ;o)
>
> Pour sur que ce serait bien
>
> Peut-être un point de départ?
> http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html
>
> Ca peut donner des idées!
>

et plus généralement, on se dot de commencer par ceci:
http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html

--
Jean-Max Reymond
CKR Solutions
http://www.ckr-solutions.com

Je crois que les accès disque sont mieux gérés et la mémoire aussi ... mais je
n'ai jamais testé ... je ne connais pas l'impacte non plus ... :o(

Le vendredi 9 Juillet 2004 13:48, Jean-Christophe Arnu a écrit :
> Hervé Piedvache m'expliquait (le 09.07.2004 12:23):
> > Bonne question ... mes expériences ne reposent à ce jour que sur Linux et
> > Solaris ... et pour moi Linux est meilleur ... mais je n'ai jamais
> > effectué aucun test sur du BSD ...
>
> J'ai lu aussi quelque part que (Free)BSD était meilleur pour pg! Oui
> mais bon ok, en quoi, ça je n'en sais rien?

--
Hervé Piedvache

Elma Ingénierie Informatique
6 rue du Faubourg Saint-Honoré
F-75008 - Paris - France
Pho. 33-144949901
Fax. 33-144949902

François,

Le vendredi 9 Juillet 2004 11:42, Francois Suter a écrit :
> Salut,
> On verra encore avec ce que me dit Clever Age. Je les ai contacté,
> j'attends une réponse.
>

Des news ?
--
Hervé Piedvache

Elma Ingénierie Informatique
6 rue du Faubourg Saint-Honoré
F-75008 - Paris - France
Pho. 33-144949901
Fax. 33-144949902

>> On verra encore avec ce que me dit Clever Age. Je les ai contacté,
>> j'attends une réponse.
>
> Des news ?

Pas encore.

Jean-Max, tu t'étais annoncé en premier comme ayant un peu de temps,
serais-tu prêt à reprendre le contact avec Clever Age? Si oui, je leur
envoie un mail avec tes coordonnées. Si les tests ont lieu début août,
je peux reprendre le rôle d'interface, mais si ça bouge dans les 2
semaines à venir, ce serait dommage de rater le coche juste parce que
je suis en vacances.

A+

---------------
Francois

Home page: http://www.monpetitcoin.com/

"Nous sommes peu à penser trop, trop à penser peu." - Françoise Sagan