Lenteur extrême PostgreSQL

donnadieujulien · 22/11/2011, 12h35

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 · 22/11/2011, 13h00

Citation:

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

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

donnadieujulien · 22/11/2011, 13h31

effectivement je ne suis pas multitache mdr

SQLpro · 22/11/2011, 14h23

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 · 22/11/2011, 17h16

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 · 09/12/2011, 14h42

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 · 14/12/2011, 16h45

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 · 15/12/2011, 13h26

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 · 15/12/2011, 13h32

Citation:

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 · 15/12/2011, 23h18

Citation:

Envoyé par donnadieujulien

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 · 19/12/2011, 12h33

Citation:

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 :

Citation:

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 · 19/12/2011, 12h42

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

22/11/2011, 12h35	#1
donnadieujulien Membre habitué Développeur informatique Inscription : avril 2008 Messages : 410 Détails du profil Informations personnelles : Âge : 27 Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : avril 2008 Messages : 410 Points : 142 Points : 142	Lenteur extrême PostgreSQL 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 __________________ On ne peut créér ce qu'on ne peut imaginer... Tu sens la puissance du BIT?
	00

22/11/2011, 13h31	#3
donnadieujulien Membre habitué Développeur informatique Inscription : avril 2008 Messages : 410 Détails du profil Informations personnelles : Âge : 27 Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : avril 2008 Messages : 410 Points : 142 Points : 142	effectivement je ne suis pas multitache mdr __________________ On ne peut créér ce qu'on ne peut imaginer... Tu sens la puissance du BIT?
	00

22/11/2011, 14h23	#4
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 959 Points : 17 791 Points : 17 791	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 + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

22/11/2011, 17h16	#5
donnadieujulien Membre habitué Développeur informatique Inscription : avril 2008 Messages : 410 Détails du profil Informations personnelles : Âge : 27 Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : avril 2008 Messages : 410 Points : 142 Points : 142	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? __________________ On ne peut créér ce qu'on ne peut imaginer... Tu sens la puissance du BIT?
	00

14/12/2011, 16h45	#7
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 959 Points : 17 791 Points : 17 791	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 + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

09/12/2011, 14h42	#6
estofilo Modérateur Inscription : octobre 2008 Messages : 1 508 Détails du profil Informations personnelles : Localisation : France, Paris (Île de France) Informations forums : Inscription : octobre 2008 Messages : 1 508 Points : 2 040 Points : 2 040	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.
	00

15/12/2011, 13h26	#8
donnadieujulien Membre habitué Développeur informatique Inscription : avril 2008 Messages : 410 Détails du profil Informations personnelles : Âge : 27 Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : avril 2008 Messages : 410 Points : 142 Points : 142	Merci 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 __________________ On ne peut créér ce qu'on ne peut imaginer... Tu sens la puissance du BIT?
	00

19/12/2011, 12h42	#12
JeitEmgie Expert Confirmé Inscription : septembre 2006 Messages : 2 291 Détails du profil Informations personnelles : Sexe : Informations forums : Inscription : septembre 2006 Messages : 2 291 Points : 2 738 Points : 2 738	Montrez le query et l'explain, ASAP… sans çà on tourne en rond.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email