[pgsql-fr-generale] Base de données PostgreSQL 8.0.0 de 200 G O - Problèmes de temps de réponse

[ROELTGEN Pierre-Andre DSIC DESP]

De: Jean-Max Reymond [mailto:***@gmail.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

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
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-Paul Argudo]

Post by ROELTGEN Pierre-Andre DSIC DESP

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

Post by ROELTGEN Pierre-Andre DSIC DESP

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!)

Post by ROELTGEN Pierre-Andre DSIC DESP

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.

Post by ROELTGEN Pierre-Andre DSIC DESP

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

http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html

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

Post by ROELTGEN Pierre-Andre DSIC DESP
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 ...

[Xavier Poinsard]

Post by Jean-Paul Argudo
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 ?



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ***@postgresql.org

[Jean-Paul Argudo]

Post by Xavier Poinsard

Post by Jean-Paul Argudo
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



---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Didier BRETIN]

Jean-Paul,

Post by Jean-Paul Argudo
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.

[Jean-Paul Argudo]

Post by Didier BRETIN

Post by Jean-Paul Argudo
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..

Post by Didier BRETIN
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!!

[Guillaume LELARGE]

Post by Jean-Paul Argudo

Post by Didier BRETIN

Post by Jean-Paul Argudo
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..

Post by Didier BRETIN
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 ;)

Post by Jean-Paul Argudo
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.

Post by Jean-Paul Argudo
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 :)

[Jean-Paul Argudo]

Post by Guillaume LELARGE
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é.

Post by Guillaume LELARGE
Exact, il faut être cohérent. De toute façon, drupal est vraiment bien.

CQFD :)

Post by Guillaume LELARGE
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

Post by Guillaume LELARGE

Post by Jean-Paul Argudo
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à!

[Francois Suter]

Post by Jean-Paul Argudo
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

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

http://www.postgresql.org/docs/faq

[Francois Suter]

Post by Jean-Paul Argudo
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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ***@postgresql.org so that your
message can get through to the mailing list cleanly