Re: Big performance problem

Bonsoir,

Le jeudi 17 septembre 2009 à 12:03:25, Damien Passot a écrit :
> [...]
> Tout d'abord merci d'avoir répondu aussi rapidement.
> Je m'excuse par avance si je pose des questions peu pertinente mais je ne
> suis pas spécialiste des bases de données et de postgres.
>

Aucun soucis.

> 1. Y a-t-il un moyen de savoir si c'est le cas ?

Oui, il faut activer le paramètre log_connections, voire même
log_disconnections, pour voir les connexions dans les journaux applicatifs (ie
les traces) de PostgreSQL.

> Pouvez vous me dire ce
> qu'est un spooler de connexion ?

Un pooler de connexion a pour but de conserver les connexions ouvertes par les
clients, histoire d'économiser le temps d'établissement de la connexion.

> 2. J'ai modifié le fichier de
> configuration de postgres en changeant le paramètre "shared_buffers" que
> j'ai mis à 30000. Y a-t-il d'autres paramètres à modifier pour faire en
> sorte que postgres optimise la mémoire ?
>

Oui. Le mieux est certainement de lire l'article suivant que j'ai écrit pour
le linux mag :

http://dalibo.org/glmf107_gestion_memoire_avec_postgresql

Pour informations, un shared_buffers à 30000, cela veut dire que PostgreSQL
peut conserver en mémoire 234 Mo de données.

> La mémoire alloué à la machine virtuelle est de 1Go.

Utiliser une machine virtuelle avec un serveur de bases de données est une
très mauvaise idée. En effet, une base de données a besoin d'un accès très
rapide aux disques et les outils de virtualisation fournissent assez peu de
réponse à ce niveau-là.

Attention qu'il ne suffit pas d'allouer de la mémoire pour que PostgreSQL
l'utilise immédiatement après. La configuration de PostgreSQL doit être
modifiée pour prendre en compte cet ajout de mémoire. Cependant, avec la
valeur que vous indiquez pour le shared_buffers, cela devrait bon, surtout vu
la taille indiquée ci-dessous pour la base de données.

> La base contient
> environ 300 tables et 850 fonctions. La taille du dossier qui contient la
> base est de 48 Mo mais je ne sais pas si cela correspond bien à la taille
> de la base. Concernant les opérations de maintenance, j'ai effectué un
> vacuum récemment mais sans amélioration significative.
>

De quel dossier parlez-vous ? J'ai un peu de mal à croire que vous n'avez que
48 Mo de données sur 300 tables.

> Autres informations, les processus du serveur web et de postgres utilise
> quasiment 100% du temps UC dès qu'une personne accède à l'application. Je
> pense que le problème vient de postgres parce que les temps de réponse
> sont beaucoup plus long lorsque l'on ouvre une page avec beaucoup
> d'informations contenu dans la base. Il semblerait même que se soit lors
> que l'on accède à une certaine page, y a-t-il un moyen de connaitre les
> requêtes effectuées lorsque cette page s'ouvre ?
>

Là, ça dépend de l'applicatif. Si vous voulez connaître la liste des requêtes
exécutées avec leur temps d'exécution, vous pouvez initialiser le paramètre
log_min_duration_statement à 0.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com