Re: Base de données Postg

De: Jean-Max Reymond [mailto:jmreymond(at)gmail(dot)com]
Date: jeudi 20 janvier 2005 10:45
À: ROELTGEN Pierre-Andre DSIC DESP
Objet: Re: [pgsql-fr-generale] Base de données PostgreSQL 8.0.0 de 200 G
O - Problèmes de temps de réponse

On Thu, 20 Jan 2005 10:35:46 +0100, ROELTGEN Pierre-Andre DSIC DESP
<Pierre-Andre(dot)ROELTGEN(at)interieur(dot)gouv(dot)fr> wrote:
>
>
> Bonjour;
>
> Sur une base de test PostgreSQL 8.0.0 (30 GO de "données brutes", 200 GO
de
> données et d'index sur disque) hébergée sur un système Linux 2.6, j'ai de
> graves soucis de temps de réponse. Toutes les opérations (analyze, vacuum,
> etc ...) ont été correctement effectuées. La base de données ne subit
> dorénavant plus de MAJ (insertion, suppression et modification). Voici
> quelques questions qui demandent aide de votre part :
>
> 1. Deux index créés et analysés sur une même table peuvent-ils être
utilisés
> en même temps lors de l'exécution d'une requête qui travaille sur cette
> table uniquement ?

je ne suis pas sur de bien comprendre la question.

==>==> En fait, je voudrais que l'index INDEX1 sur la colonne COL1 de la
table TABLE_A et l'index INDEX2 de la colonne COL2 de la même table TABLE_A
soient utilisés en même temps à l'exécution de la requête : fusion d'index
(INDEX MERGING), technique de hachage, etc ...

> 2. Peut-on orienter l'optimiseur sur les index de son choix (notamment
avec
> des hints ou directives à la mode Oracle) ?

non, pas à ma connaissance

==>==> OK. Merci.

> 3. Quels sont les paramètres du postgresql.conf qui vous semblent
pertinents
> à modifier ou prendre en compte, pour orienter l'optimiseur sur les index,
> au lieu de le laisser s'orienter sur des lectures séquentielles de tables
> (qui font quand même quelques dizaines de millions de lignes) ?

si tout est bien configuré, l'optimiseur ira au mieux. Il faut donc
bien configurer Postgres ;-) et ne pas oublier le VACUUM ANALYZE

==>==> En fait, le VACUUM ANALYZE a été fait de nombreuses fois.

> 4. Enfin, d'après votre expérience bien plus grande que la mienne,
possédez
> vous une liste d'URLs permettant enfin la mise en place d'un tuning
efficace
> de PostgreSQL ? (votre expérience vécue sur les paramètres du
> postgresql.conf).

un bon début est là:
http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html

==>==> Merci.

Après, il faut faire un EXPLAIN ANALYZE de tes requêtes trop lentes
pour pouvoir analyser ce qui se passe.

==>==> Ca, j'en ai hélas un peu trop la pratique.
==>==> Merci déjà pour tous ces conseils.

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

> > 1. Deux index créés et analysés sur une même table peuvent-ils être
> utilisés
> > en même temps lors de l'exécution d'une requête qui travaille sur cette
> > table uniquement ?
>
> je ne suis pas sur de bien comprendre la question.
>
> ==>==> En fait, je voudrais que l'index INDEX1 sur la colonne COL1 de la
> table TABLE_A et l'index INDEX2 de la colonne COL2 de la même table
> TABLE_A soient utilisés en même temps à l'exécution de la requête :
> fusion d'index (INDEX MERGING), technique de hachage, etc ...

si les deux champs (col1 et col2 de table_a) sont utilisés par vos
requetes vous avez tout intérêt à créer un index sur les deux à la fois:

Create index_1_2 on table_a (col1,col2);

Vous pourriez tester les résultats en comparant avec la création de deux
index distincts:

create index_1 on table_a (col1);
create index_2 on table_b (col2);

Dans un 1er temps, testez (un explain suffit..) avec index_1 et index_2
présents mais sans index_1_2. Ensuite, droppez index_1 et index_2, créez
index_1_2, testez.

Enfin, re-creés index_1 et index_2, en laissant index_1_2, testez:

Quels index l'optimiseur va t il choisir dans votre cas? Merci de
re-poster ici le résultat, pour analyse..

N'oubliez pas que vous devez faire un vacuum analyze table_a à chaque
création d'index afin de remettre à jour les stats disponibles pour
l'optimiseur, sinon il risque d'avoir un peu mal à la tête! :)

Enfin, vous pouvez aussi ré-organiser les données à l'interieur de la
table en fonction d'un index. Par exemple, faire en sorte que les
données soient organisées selon index_1_2; utilisez CLUSTER:

cluster index_1_2 on table_a;

Et encore une fois, vacuum full analyze puis re-tests..

Je suis curieux de connaître les résultats de ces tests, vous semblez
disposer d'une bases de données sérieuse ;-)

Merci pour votre retour sur cette liste, je pense que votre recherche et
vos résultats pourraient servir à tout le monde ici.

D'ailleurs je vous annonce ici la création prochaine sur le site
PostgreSQLFr.org d'une section particulière consacrée à la résolution de
problèmes divers et variés... En clair, il s'agira d'un document de type
"Livre", qui rassemblera plusieurs articles postés et à venir. A ce jour
un seul "Livre" existe sur le site c'est " Témoignage de pros"... Enjoy!
(Merci à Sébastien Dinot pour cette idée lumineuse!).

> > 2. Peut-on orienter l'optimiseur sur les index de son choix
> (notamment avec
> > des hints ou directives à la mode Oracle) ?
>
> non, pas à ma connaissance

Non, pas de pragama / hints à la Oracle, que je sache (attention, j'ai
des 10aine de pages de doc à lire et re-lire avec la nouvelle version 8!)

> > 3. Quels sont les paramètres du postgresql.conf qui vous semblent
> pertinents
> > à modifier ou prendre en compte, pour orienter l'optimiseur sur les
> index,
> > au lieu de le laisser s'orienter sur des lectures séquentielles de
> tables
> > (qui font quand même quelques dizaines de millions de lignes) ?

> si tout est bien configuré, l'optimiseur ira au mieux. Il faut donc
> bien configurer Postgres ;-) et ne pas oublier le VACUUM ANALYZE
>
> ==>==> En fait, le VACUUM ANALYZE a été fait de nombreuses fois.

Jean-Max dit vrai. Envoyer des "set enable_seqscan=off" (pour interdire
au postmaster de faire des full scan...) ne doit rester qu'une pratique
destinée aux tests...

Si votre serveur est plutôt puissant, faites en sorte que le cout du
hasard soit moins cher, soit baissez la valeur de random_page_cost,
souvent à 4 par défaut à 2 ou 1.. et re-testez...

Faites attention à permettre à PostgreSQL d'utiliser la mémoire du
système comme il faut: augmeter les parametres kernel shmemall et
shmemmax.. voir documentation:

http://developer.postgresql.org/docs/postgres/kernel-resources.html

Pour un tuning un peu plus "hard", je vous reccomande la lecture du
document de Bruce:

http://www.ca.postgresql.org/docs/momjian/hw_performance/0.html

Cela devrait répondre à vos questions sur le postgresql.conf

Sachez toutes fois que dans 3 cas sur 4, ce sont les requêtes
elles-mêmes qui sont en cause en cas de mauvaises performances (en tout
cas, c'est la statistique que je me suis faite depuis mes qques années
de pratique de PostgreSQL... ;-) )

Pour cela, la lecture de ma baffouille peut aider aussi:

http://www.argudo.org/postgresql/soft-tuning.php

Mais attention, mon article est bien vieux et dépassé à présent, je vais
le ré-écrire complètement afin de permettre aux gens d'utiliser
PostgreSQL 8 au mieux de ses capacités.

> > 4. Enfin, d'après votre expérience bien plus grande que la mienne,
> possédez
> > vous une liste d'URLs permettant enfin la mise en place d'un tuning
> efficace
> > de PostgreSQL ? (votre expérience vécue sur les paramètres du
> > postgresql.conf).
>
> un bon début est là:
> http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html

Oui, plus voir URLs ci-dessus, aussi. Elein est une grande spécialiste
de PostgreSQL...

> Après, il faut faire un EXPLAIN ANALYZE de tes requêtes trop lentes
> pour pouvoir analyser ce qui se passe.
>
> ==>==> Ca, j'en ai hélas un peu trop la pratique.
> ==>==> Merci déjà pour tous ces conseils.

L'utilisation d'EXPLAIN est simplissime avec PG, il suffit d'ajouter le
mot-clé "EXPLAIN" devant toute requête DML:

EXPLAIN SELECT...;

Et le plan d'exécution apparaît! Rien à voir avec d'autres SGBDR ou
plusieurs manipulations sont à faire ...

--
Jean-Paul Argudo
www.PostgreSQLFr.org

Jean-Paul Argudo a écrit :

> Enfin, re-creés index_1 et index_2, en laissant index_1_2, testez:
>
> Quels index l'optimiseur va t il choisir dans votre cas? Merci de
> re-poster ici le résultat, pour analyse..
>
> N'oubliez pas que vous devez faire un vacuum analyze table_a à chaque
> création d'index afin de remettre à jour les stats disponibles pour
> l'optimiseur, sinon il risque d'avoir un peu mal à la tête! :)

un ANALYZE n'est pas suffisant ?

Jean-Paul,

Jean-Paul Argudo a écrit :
> D'ailleurs je vous annonce ici la création prochaine sur le site
> PostgreSQLFr.org d'une section particulière consacrée à la résolution de
> problèmes divers et variés... En clair, il s'agira d'un document de type
> "Livre", qui rassemblera plusieurs articles postés et à venir. A ce jour
> un seul "Livre" existe sur le site c'est " Témoignage de pros"... Enjoy!
> (Merci à Sébastien Dinot pour cette idée lumineuse!).

Ils seront disponibles dans le futur wiki ;) ? Ou alors un bon vieux spip
des familles ;)

Cordialement.
--
Didier BRETIN
INFORMACTIS
http://www.informactis.com/

>> N'oubliez pas que vous devez faire un vacuum analyze table_a à chaque
>> création d'index afin de remettre à jour les stats disponibles pour
>> l'optimiseur, sinon il risque d'avoir un peu mal à la tête! :)

> un ANALYZE n'est pas suffisant ?

Euh... si en fait. Mais bon, abondance de biens ... :-)

Bon, j'avoue je suis un peu bourrin...

Désolé pour le délai dans les réponses, je suis "un peu" chargé en ce
moment..

--
Jean-Paul Argudo
www.PostgreSQLFr.org

>> D'ailleurs je vous annonce ici la création prochaine sur le site
>> PostgreSQLFr.org d'une section particulière consacrée à la résolution
>> de problèmes divers et variés... En clair, il s'agira d'un document de
>> type "Livre", qui rassemblera plusieurs articles postés et à venir. A
>> ce jour un seul "Livre" existe sur le site c'est " Témoignage de
>> pros"... Enjoy! (Merci à Sébastien Dinot pour cette idée lumineuse!).
>
>
> Ils seront disponibles dans le futur wiki ;) ?

Bin apparement, seules 14 personnes ont voté sur le site
http://www.PostgreSQLFr.org ....... Je suis vraiment déçu.. Si tous les
lecteurs de la liste pouvaient faire l'éffort de voter...??

allez.. C'est deux clics..

> Ou alors un bon vieux spip des familles ;)

Alors je voudrais pas polémiquer... Juste que SPIP n'est dispo que sous
MySQL... Quand j'ai vu ce que ça faisait (tout plein de sites
intéressants et bien faits sous SPIP!...) je me suis dit que je
porterais bien sous PG.

Alors j'ai téléchargé le dernier tarball et lorsque j'ai "ouvert le
capot", je l'ai dessuite refermé. Je me sentais pas assez courageux pour
me taper tous les sources php avec des vrais morceaux de MySQL dedans de
partout... En clair j'ai été extrêmement déçu, je m'attendais à un
module SQL à traduire en PG et pas plus... C'est clairement pas le cas.

Je suppose qu'il doit y avoir tout un tas de bonnes raisons, surement
historiques, etc... Je suis certain que plein de gens l'utilisent
avantageusement, etc... Mais on ne pouvait vraiment pas faire tourner
PostgreSQLFr.org sous MySQL :-)

Alors pour faire pgfr.org j'ai opté pour Drupal, qui lui est un gros
veau bien lent, mais qui est relativement propre question code.

Relativement, parceque dans la version originale j'ai dû corriger pas
mal de requêtes (y'a encore des bugs, le dernier étant trouvé par un
certain Rémi... qui se recconaîtra..).

Voilà pour l'histoire.

Aujourd'hui, Drupal assure vraiment bien, mais est toujours un peu trop
lourd pour le processeur Géode que possède l'Open Brick sur lequel
tourne le site!!

--
Jean-Paul Argudo
www.PostgreSQLFr.org

Jean-Paul Argudo wrote:
>>> D'ailleurs je vous annonce ici la création prochaine sur le site
>>> PostgreSQLFr.org d'une section particulière consacrée à la résolution
>>> de problèmes divers et variés... En clair, il s'agira d'un document
>>> de type "Livre", qui rassemblera plusieurs articles postés et à
>>> venir. A ce jour un seul "Livre" existe sur le site c'est "
>>> Témoignage de pros"... Enjoy! (Merci à Sébastien Dinot pour cette
>>> idée lumineuse!).
>>
>> Ils seront disponibles dans le futur wiki ;) ?
>
> Bin apparement, seules 14 personnes ont voté sur le site
> http://www.PostgreSQLFr.org ....... Je suis vraiment déçu.. Si tous les
> lecteurs de la liste pouvaient faire l'éffort de voter...??
>
> allez.. C'est deux clics..
>
> > Ou alors un bon vieux spip des familles ;)
>
> Alors je voudrais pas polémiquer... Juste que SPIP n'est dispo que sous
> MySQL... Quand j'ai vu ce que ça faisait (tout plein de sites
> intéressants et bien faits sous SPIP!...) je me suis dit que je
> porterais bien sous PG.
>

Pour informations, spip-agora est une version acceptant mysql et
postgresql. Elle fonctionne plutôt bien... nous l'utilisons au boulot ;)

> Alors j'ai téléchargé le dernier tarball et lorsque j'ai "ouvert le
> capot", je l'ai dessuite refermé. Je me sentais pas assez courageux pour
> me taper tous les sources php avec des vrais morceaux de MySQL dedans de
> partout... En clair j'ai été extrêmement déçu, je m'attendais à un
> module SQL à traduire en PG et pas plus... C'est clairement pas le cas.
>
> Je suppose qu'il doit y avoir tout un tas de bonnes raisons, surement
> historiques, etc... Je suis certain que plein de gens l'utilisent
> avantageusement, etc... Mais on ne pouvait vraiment pas faire tourner
> PostgreSQLFr.org sous MySQL :-)
>

Exact, il faut être cohérent. De toute façon, drupal est vraiment bien.
Bon, je n'ai toujours pas compris la taxinomie, mais c'est pas grave.

> Alors pour faire pgfr.org j'ai opté pour Drupal, qui lui est un gros
> veau bien lent, mais qui est relativement propre question code.
>
> Relativement, parceque dans la version originale j'ai dû corriger pas
> mal de requêtes (y'a encore des bugs, le dernier étant trouvé par un
> certain Rémi... qui se recconaîtra..).
>
> Voilà pour l'histoire.
>
> Aujourd'hui, Drupal assure vraiment bien, mais est toujours un peu trop
> lourd pour le processeur Géode que possède l'Open Brick sur lequel
> tourne le site!!
>

L'OpenBrick suffit pour l'instant... on verra plus tard :)

--
Guillaume.
<!-- http://abs.traduc.org/
http://lfs.traduc.org/
http://traduc.postgresqlfr.org/ -->

> Pour informations, spip-agora est une version acceptant mysql et
> postgresql. Elle fonctionne plutôt bien... nous l'utilisons au boulot ;)

Ah alors j'ai du passer à côté lorsque j'ai cherché un gestionnaire de
contenu à l'époque. J'avais choisi Drupal pour son sérieux, sa
complétude, son support de PG, sa modularité et son évolutivité.. à voir
les dernières versions, j'ai l'impression de ne m'être pas trop planté.

> Exact, il faut être cohérent. De toute façon, drupal est vraiment bien.

CQFD :)

> Bon, je n'ai toujours pas compris la taxinomie, mais c'est pas grave.

La taxinomie te permet juste de créer ton propre vocabulaire.. de faire
des liens entre les termes, de définir une hiérarchie entre eux, etc..

Pour l'instant, sur le site, ça ne permet que de trier les articles par
"type"... Par exemple, si qqun clique sur le terme "Dans les bacs" il ne
s'affichera sur le site que les articles qualifiés avec cette
désignation là...

Demain, on pourrait aller plus loin, par exemple:
News->
-> Nouvelle version
-> Core
-> Contribs
-> autres
-> Officielles
-> PG Weekly News
-> traduction post pgsql-announce

etc.. En clair, ce sont des section, sous-sections, catégories.. appelle
ça comme tu veux! :)

Sinon, tu peux approfondir en lisant ceci:

http://drupal.org/index.php?q=node/299

>> Aujourd'hui, Drupal assure vraiment bien, mais est toujours un peu
>> trop lourd pour le processeur Géode que possède l'Open Brick sur
>> lequel tourne le site!!
>>
>
> L'OpenBrick suffit pour l'instant... on verra plus tard :)

Non c'est tout vu... apparement un généreux donateur nous offre un
serveur 2U, Bi-P3 700 MHz avec 1 Go de ram, disques durs, etc... C'est
un ancien serveur de production qui "a fait son temps" mais est "en
pleine forme".

Je devrai l'avoir sous peu, et après une petite cure de jouvence (achat
probable de deux disques durs de 80 Go... nettoyage de fond en
combles... ) je descendrai à Marseille le mettre dans un rack, bien au
chaud chez notre hébergeur favori!

Voilà!

--
Jean-Paul Argudo
www.PostgreSQLFr.org

> Bin apparement, seules 14 personnes ont voté sur le site
> http://www.PostgreSQLFr.org ....... Je suis vraiment déçu.. Si tous
> les lecteurs de la liste pouvaient faire l'éffort de voter...??
>
> allez.. C'est deux clics..

Paf, paf, arrête de taper, Jean-Paul, j'ai voté!

:-)

Et j'ai même ajouté un commentaire, c'est bien, hein?

A+

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

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

"Si ce n'est pas de moi, c'est de Confucius" - Lao Tseu

> Non c'est tout vu... apparement un généreux donateur nous offre un
> serveur 2U, Bi-P3 700 MHz avec 1 Go de ram, disques durs, etc... C'est
> un ancien serveur de production qui "a fait son temps" mais est "en
> pleine forme".
>
> Je devrai l'avoir sous peu, et après une petite cure de jouvence
> (achat probable de deux disques durs de 80 Go... nettoyage de fond en
> combles... ) je descendrai à Marseille le mettre dans un rack, bien au
> chaud chez notre hébergeur favori!

Excellente nouvelle et un grand merci au mécène!

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

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

"Si ce n'est pas de moi, c'est de Confucius" - Lao Tseu