Re: PostgreSQL et tuning ...

From: LELARGE Guillaume <gleu(at)wanadoo(dot)fr>
To: Hervé Piedvache <herve(at)elma(dot)fr>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: PostgreSQL et tuning ...
Date: 2004-02-23 20:37:25
Message-ID: 403A6485.4030301@wanadoo.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Bonsoir,

Hervé Piedvache a écrit :
> Le questionnaire de Jean-Paul Argudo (que vous pouvez consulter sur
> postgresqlfr.org) ... pose la question de la facilité du tuning de
> PostgreSQL.
>
> J'aurai aimé savoir si quelqu'un pouvait nous faire partager une ou des règles
> de fonctionnement précises de paramètrage de la gestion mémoire de
> PotsgreSQL ?
>
Thierry Missimilly, du groupe Bull, a indiqué lors de sa présentation
des tests qu'il a pu effectuer sur des bases de données Open Source que
le minimum de tuning se faisait ainsi :
- shared_mem : 1/4 de la RAM ;
- wal_buffers : 10% du shared_mem ;
- sort_mem : 10% du shared_mem.

Je ne suis pas tout à fait d'accord avec lui, notamment sur le sort_mem.
Mais en fait, le problème de tels chiffres est que cela dépend
clairement d'un nombre de paramètres effrayant : processeur, RAM, disque
(vitesse, age, système RAID?, ...) mais aussi système utilisé (Linux,
*BSD, windows). La base elle-même joue un rôle important et pas
uniquement au niveau de sa taille : structure de la base, index,
fréquence d'utilisation.

Sincèrement, lors de notre passage de SQL Server à PostgreSQL, je pense
que j'ai merdé en sous-estimant grandement l'importance du tuning (je
viens d'y penser, désolé c'est un peu décousu, le nombre de clients et
leur méthode de connexions est un facteur essentiel pour tout tuning).

> La documentation n'est effectivement pas toujours claire (même en français),
> surtout quant aux différents cas de figure que l'on peut rencontrer dans la
> productions de base de données. Souvent
>
Entièrement d'accord, mais certains liens sont très intéressants. Le
document proposé par François est un point de départ important.

> Il est clair que sur des machines dédiées on ne gère pas la mémoire de la même
> façon que sur une machine qui aura d'autres fonctions que de faire tourner
> PostgreSQL ...
Excellent argument. Autant les informations ne manquent pas (même si
elles sont éparpillées) sur les serveurs dédiés, autant le manque
d'informations sur les serveurs non dédiés est flagrant (et compréhensible).

> Mais si l'on part d'un cas pratique, avec machine dédiée à PostgreSQL, avec
> petit volume de données (tables ne dépassant pas 1 million
> d'enregistrements), puis avec de gros volumes de données (tables de plus de
> 100 millions d'enregistrements) ... et encore ces informations sont-elles
> suffisantes pour pouvoir définir les paramètres qui vont le mieux coller à
> une utilisation de la base ? Il faudra prendre en compte son utilisation
> (service web, ou dataming par exemple), et peut-être d'autres paramètres ...
> et bien sûr les capacités mémoire de la machine.
>
J'en profite pour demander ce que veut dire datawarehouse et datamining.
Ca m'évitera de passer pour un abruti si j'essaie de remplir le
questionnaire de Jean-Paul :)

> Avez-vous des procédures, des tests, des barèmes qui vous permettent de
> définir au mieux votre tuning ? Je sais que c'est un vaste sujet, mais je
> pense que cela peut intéresser beaucoup de monde et ça animera un peut notre
> liste ;o)
>
Comme l'a dit Jean-Christophe, il est tout à fait possible de créer un
document sur ce sujet. Le mieux serait de mettre à jour le document de
Jean-Paul et de le proposer sur son site (www.postgresqlfr.org).

Comme j'ai fait pas mal de recherches sur le sujet, je vais essayer de
regarder ça demain et de fournir une réponse plus détaillée à ce moment-là.

Un dernier point, essentiel à mon goût. Parler de performances avec
Postgres n'a pas d'intérêt si on ne parle pas des versions. Sans parler
du fait qu'une version 7.4 a plus de chances d'être plus rapide et moins
bugguée qu'une 7.3, il existe aussi de nouveaux paramètres de
configuration pour mieux sensibiliser le serveur. Tom Lane vient de
proposer une modification du moteur qui utiliserait le vacuum_mem pour
la création d'un index. Actuellement, il est conseillé d'augmenter la
valeur de sort_mem lors de la création d'un index btree. L'utilisation
du vacuum_mem ou d'une autre variable changerait grandement la donne
entre le tuning d'une 7.4 et antérieure et celui de la version disposant
de cette nouvelle fonctionnalité.

Et encore un dernier point. Comment tester une charge importante sans
utilisateur mais en mimiquant leur comportement ? une question pour
laquelle je n'ai pas encore de réponse.

Bref, de belles dicussions en perspective :)

--
Guillaume.
<!-- http://absfr.tuxfamily.org/
http://pgsql-fr.tuxfamily.org/ -->

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Bruno LEVEQUE 2004-02-23 22:41:14 Re: PostgreSQL Weekly News
Previous Message LELARGE Guillaume 2004-02-23 20:17:35 Re: PostgreSQL et tuning ...