Discussion :

[donnadieujulien]

Bonjour,

je cherche à optimiser les temps de traitement sur une base assez volumineuse.
En effet, cette base contient plus de 4000 schémas, 50 tables / schéma en moyenne et entre 5 et 10 champs par table.

Le nombre d'entrée est inconnu, mais cette base fait environ 6 gigas, ce qui n'est pas énorme en soit.

Donc le problème, c'est que la la moindre requête se transforme en véritable cauchemard.

J'ai essayé de modifier le paramètre shared buffers, avec une amélioration de 10/15 %. Mais c'est une goutte d'eau dans une botte de foin.

Quelqu'un aurait il une idée? de la doc?

pg : v 8.3.12

[xavier-Pierre]

Mais c'est une goutte d'eau dans une botte de foin.

le pire aurait été
une aiguille dans dans la mer

[donnadieujulien]

effectivement je ne suis pas multitache mdr

[SQLpro]

Quelle est la config du serveur :

• 32 ou 64 bits
• VM ou physique ?
• taille de la RAM
• taille et structure des disques (et niveau de RAID)

Mais aussi : pourquoi 4000 schémas SQL ?
Je redoute un problème de conception...

A +

[donnadieujulien]

il n'y a pas de serveur, postgres tourne sur la machine client en local.
Donc, l'architecture est fonction de l'OS du client, mais nos applications sont en 32 bits.
Donc pas de VM également, pas forcément de raid, ca dépend du client.

Le problème est indépendant de la machine.
Alors bien sur, une machine plus puissante aura un point de rupture plus grand mais ce n'est pas un problème de ressources.

En fait on dirait que postgress mets une plombe à initialiser la requete (il doit faire sa mouture avec ses tables internes), et une fois cela terminé la requete s'effectue très très vite.

Je me demande le sgbd est bien paramétré, parce que 4000 schemas, c'est sur que c'est lourd, mais les concepteurs n'ont t'ils rien prévu pour limiter la casse?

[estofilo]

Poste un EXPLAIN ANALYZE d'une requête qui s'avère trop lente par rapport à ce que à quoi tu t'attends, ça donnera des informations concrètes sur le problème.

[SQLpro]

Un SGBDR travaille C/S exclusivement en RAM. Lorsque vous faites cohabiter un SGBDR C/S avec d'autres application (ce qui est une très mauvaise pratique, un SGBDR C/S nécessite un serveur dédié) les autres applications pompent la RAM du SGBDR lorsqu'il ne traville pas, vidant ainsi le cache.
Dès lors la moindre requête va se traduire par :
1) demande de RAM du SGBDR auprès de l'OS
2) mise en cache des données par lecture du disque
3) exécution de la requête.
Comme en sus PG ne sait pas faire des scans d'index il s'avère gourmand en RAM.

Bref, vous avez deux solutions :

• trouver un réglage pour "fixer" la RAM de PG (quelques GO de RAM physique dédié à PG)
• passer à un serveur dédié.

En tout état de cause vous n'avez pas répondu aux questions. Il est donc difficile de vous aider plus !

A +

[donnadieujulien]

Merci de votre réponse.

J'ai répondu à toutes les questions que vous m'aviez posé il me semble?

Je postera un axplain analyze ASAP

[donnadieujulien]

trouver un réglage pour "fixer" la RAM de PG (quelques GO de RAM physique dédié à PG)

J'ai déja fait des tests en jouant sur "shared buffers" dans un fichier de config de pgsql.conf par exemple, mais le résultat n'est pas concluant.

Comment faire le réglage dont vous parlez?

[SQLpro]

J'ai répondu à toutes les questions que vous m'aviez posé il me semble?

NON : rien sur l'OS, rien sur les disques.... Ces éléments étant très sensibles et les réglages étant différents en fonction des OS il est impossible de vous répondre.

A +

[donnadieujulien]

Donc, l'architecture est fonction de l'OS du client, mais nos applications sont en 32 bits

Je n'ai pas précisé uniquement windows

Les diques dur peu importe, on n'est pas en architecture client-serveur.
il s'agit d'une bdd qui tourne chez le client directement, sur la machine en local.

Je me suis mal éxprimé dès le départ mais je me cite :

il n'y a pas de serveur, postgres tourne sur la machine client en local.
Donc, l'architecture est fonction de l'OS du client, mais nos applications sont en 32 bits.
Donc pas de VM également, pas forcément de raid, ca dépend du client.

Le problème est indépendant de la machine.

En fait je cherche les réglages postgres si il en existe.
Je rajoute que je suis loin d'utiliser le sgbd à fond, c'est juste qu'iul y a trop de schémas, donc je cherche si i lexiste un moyen d'accélérer sensiblement les requêtes sans un refonte du programme qui consisterai à alléger au max le nb de schémas mais qui n'est pas très envisageable et très couteux.

Peut etre que le pb vient de du driver de communication et de l'objet utilisé.
Le programme est codé en delphi et j'utilise ZEOS, on peut peut etre dire à une connection d'exclure des schémas pour l'accélerer et travailler avec plusieurs connexions?
Ou alors postgress peut existe t'il des réglages directement sur postgres?

[JeitEmgie]

Montrez le query et l'explain, ASAP… sans çà on tourne en rond.