Skip site navigation (1) Skip section navigation (2)

Re: Big performance problem

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: "Damien Passot" <dpassot(at)novelane(dot)fr>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Big performance problem
Date: 2009-09-17 16:59:15
Message-ID: 200909171859.15606.guillaume@lelarge.info (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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

In response to

pgsql-fr-generale by date

Next:From: Florence CousinDate: 2009-09-18 18:25:54
Subject: Re: [pgsql-fr-generale] Paris PUG : rendez-vous mardi 22 septembre à 19h
Previous:From: Guillaume LelargeDate: 2009-09-17 05:13:10
Subject: Re: Big performance problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group