Vous n'êtes pas identifié(e).

#1 15/12/2010 10:33:16

Gil34
Membre

Monitorer perf : explain ?

Bonjour,

Pour monitorer les perfs des requetes, y a t il un autre moyen que explain ? Car étant dans un centre hébergeur j'aimerai savoir s'il n'existe pas une commande évitant de "tripatouiller" les sources.

Merci de votre aide et suggestions

Gilbert

Hors ligne

#2 15/12/2010 10:39:23

kenrio
Membre

Re : Monitorer perf : explain ?

Par curiosité c'est quoi que vous appeler "monitorer les perfs des requetes" ?

Leur vitesse d'execution ? leur consommation cpu ? i/O ?

Hors ligne

#3 15/12/2010 10:40:02

Marc Cousin
Membre

Re : Monitorer perf : explain ?

C'est suffisamment vague pour ne pas pouvoir vous répondre.

Explain n'est pas un outil de monitoring, c'est un outil de diagnostic. Explain ne vous aidera pas à découvrir quelle requête est lente, mais pourquoi elle est lente.

Si c'est vraiment du monitoring que vous cherchez, il y a déjà le 'log_min_duration_statement', qui tracera les requêtes qui durent plus d'un certain temps.

Sinon, il y a deux modules de contrib intéressants : pg_stat_statements et autoexplain. Mais ils ne sont disponibles qu'à partir de la 8.4. Le premier fournit une vue mémoire avec les requêtes les plus fréquentes et leur durée, le second trace le plan d'exécution des requêtes les plus lentes, directement dans la log.


Marc.

Hors ligne

#4 16/12/2010 10:06:24

Gil34
Membre

Re : Monitorer perf : explain ?

J'entends mar minitorer : consommation CPU  et  temps de réponse à la requete faite.

Pour le moment mon souci est surtout la consommation CPU. Postgres tourne sur un vserver et lorsqu'on fait un test de charge la CPU du système hote "explose" avec un load-average important.

Hors ligne

#5 16/12/2010 10:23:05

Marc Cousin
Membre

Re : Monitorer perf : explain ?

Le temps de réponse d'une requête, c'est facile: log_min_duration_statement par exemple vous permettra de le tracer.

La consommation CPU n'est pas tracée, sauf à activer log_executor_stats, mais là ça va devenir très gourmand.

Par ailleurs, avoir une forte charge cpu sur un test de charge d'une base de données, c'est normal. C'est même plutôt bon signe, ça veut dire que vous avez suffisamment de RAM ou des disques suffisamment puissants pour ne pas avoir d'attentes d'entrées-sorties.


Marc.

Hors ligne

#6 17/12/2010 10:52:21

Gil34
Membre

Re : Monitorer perf : explain ?

j'avais déjà mis le log_min_duration-statement qui donne pas mal de renseignement sur le temps de réponse.

Ensuite j'ai mis (sur un environnement de test) log_statement_stats = on 
et j'obtiens des renseignements que j'ai du mal à interpreter, par exemple :

ec 16 23:08:59 v222ent-db1 postgres[16408]: [2084-12] #011!#011Direct blocks:          0 read,          0 written
Dec 16 23:08:59 v222ent-db1 postgres[16408]: [2084-13] moodleINSTRUCTION :  SELECT * FROM "test"
Dec 16 23:08:59 v222ent-db1 postgres[16408]: [2085-1] moodleLOG:  durée : 0.009 ms  exécute <unnamed>: SELECT * FROM "test"
Dec 16 23:08:59 v222ent-db1 postgres[16408]: [2086-1] moodleLOG:  EXECUTE MESSAGE STATISTICS
Dec 16 23:08:59 v222ent-db1 postgres[16408]: [2086-2] moodleDÃ~ITAIL:  ! system usage stats:
Dec 16 23:08:59 v222ent-db1 postgres[16408]: [2086-3] #011!#0110.000028 elapsed 0.000000 user 0.000000 system sec
Dec 16 23:08:59 v222ent-db1 postgres[16408]: [2086-4] #011!#011[0.276957 user 0.210967 sys total]

Dec 16 23:08:59 v222ent-db1 postgres[16408]: [2086-5] #011!#0110/0 [0/0] filesystem blocks in/out
Dec 16 23:08:59 v222ent-db1 postgres[16408]: [2086-6] #011!#0110/0 [0/991] page faults/reclaims, 0 [0] swaps
Dec 16 23:08:59 v222ent-db1 postgres[16408]: [2086-7] #011!#0110 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
Dec 16 23:08:59 v222ent-db1 postgres[16408]: [2086-8] #011!#0110/0 [2601/81] voluntary/involuntary context switches
Dec 16 23:08:59 v222ent-db1 postgres[16408]: [2086-9] #011! buffer usage stats:
Dec 16 23:08:59 v222ent-db1 postgres[16408]: [2086-10] #011!#011Shared blocks:          0 read,          0 written, buff

A quoi correspond : 0.276957 user 0.210967 sys total     c'est du temps cpu consommé par l'user et le temps cpu consommé par le systàme/ 

et comment interpreter la ligne : #011!#0110.000028 elapsed 0.000000 user 0.000000 system sec

Merci de votre aide
A+
Gilbert

Dernière modification par Gil34 (17/12/2010 10:54:28)

Hors ligne

#7 17/12/2010 15:11:25

flo
Membre

Re : Monitorer perf : explain ?

Gil34 a écrit :

j'avais déjà mis le log_min_duration-statement qui donne pas mal de renseignement sur le temps de réponse.


A quoi correspond : 0.276957 user 0.210967 sys total     c'est du temps cpu consommé par l'user et le temps cpu consommé par le systàme/ 

et comment interpreter la ligne : #011!#0110.000028 elapsed 0.000000 user 0.000000 system sec

Merci de votre aide
A+
Gilbert

Je suppose que user et system font référence aux modes d'exécution :
http://stackoverflow.com/questions/5564 … t-of-time1
(Que quelqu'un m'arrête si je dis des âneries!)
Je suppose donc que
0.000028 elapsed 0.000000 user 0.000000 system sec
c'est 0.000028 en temps passé, mais 0 en temps CPU pour le processus en mode utilisateur, et 0 dans le noyau.

Je ne sais par contre pas à quoi correspond la ligne entourée par des crochets. Avez-vous cherché dans la documentation de PostgreSQL??

Hors ligne

#8 17/12/2010 15:38:48

Marc Cousin
Membre

Re : Monitorer perf : explain ?

Ce n'est pas documenté à ma connaissance.

Les valeurs entre crochets sont les valeurs cumulées depuis le début de la session. Contrairement aux valeurs pas entre crochets, qui ne concernent que l'ordre précédent.

Ensuite une ligne 0.000028 elapsed 0.000000 user 0.000000 system sec
Signifie 28µs de temps total d'exécution de la requête, pour 0 de temps d'exécution 'user' et 0 de temps d'exécution 'sys'. sys, c'est la quantité de processeur consommé pendant les appels systèmes. user, c'est le reste.


Marc.

Hors ligne

Pied de page des forums