Re: Reponse lente de postgres

Bonjour,
> Avec 8 Go de mémoire, je verrais plutôt entre 10000 et 20000 pour
> commencer (ce qui ne représente que 80 à 160 Mo de mémoire... pensez à
> augmenter SHMALL et SHMMAX).
J'ai déjà mis 20000 mais aucune difference.

>> work_mem = 512
>
> La valeur par défaut est de 1024. Pourquoi l'avoir descendu ? on a
> généralement plutôt tendance à augmenter cette valeur (mais pas trop :) ).

En 1024 et shared_buffer=15000, la valeur du memoire partagé monte husqu'à
128M.

Ce qui m'inquiete aussi c'est que postgres bouffe trop de memoire. La taille
du memoire libre tourne autour de 20 Mo et ne depassant jamais les 256 Mo.
Et le systeme n'utilise jamais des swap.

cdt,
Hajatiana RAHOLIARIJAONA Administrateur réseaux et systèmes du centre de
traitement SAISIE.MG administrateur(at)saisie(dot)mg
----- Original Message -----
From: "Guillaume Lelarge" <guillaume(at)lelarge(dot)info>
To: "Hajatiana RAHOLIARIJAONA" <administrateur(at)saisie(dot)mg>
Cc: "Jean-Paul Argudo" <jean-paul(at)argudo(dot)org>;
<pgsql-fr-generale(at)postgresql(dot)org>
Sent: Tuesday, July 31, 2007 1:26 AM
Subject: Re: [pgsql-fr-generale] Reponse lente de postgres

> Hajatiana RAHOLIARIJAONA a écrit :
>> Bonjour Jean Paul,
>>
>>> - la version que vous utilisez de PostgreSQL ?
>>
>> Nous avons Postgresql 8.0.13
>>
>
> ... qui date de deux ans. Planifiez une mise à jour, c'est important
> pour les perfs comme pour vos données.
>
>>> - la liste de tous les paramètres du fichier postgresql.conf
>>> qui ne sont pas commentés
>>
>> max_connections = 500
>
> Vraiment utile, les 500 connexions simultanées possibles ?
>
>> shared_buffers = 2000
>
> Avec 8 Go de mémoire, je verrais plutôt entre 10000 et 20000 pour
> commencer (ce qui ne représente que 80 à 160 Mo de mémoire... pensez à
> augmenter SHMALL et SHMMAX).
>
>> work_mem = 512
>
> La valeur par défaut est de 1024. Pourquoi l'avoir descendu ? on a
> généralement plutôt tendance à augmenter cette valeur (mais pas trop :) ).
>
>> maintenance_work_mem = 131072
>
> Vous pouvez encore la doubler vu votre mémoire.
>
>> deadlock_timeout = 1000 # in milliseconds
>> max_locks_per_transaction = 64
>> log_min_messages = notice
>> log_min_error_statement = panic
>>
>>> La machine semble correcte, sans plus. Maintenant, je pressens soit un
>>> problème de configuration du serveur, soit l'absence de procédures de
>>> maintenance, soit un problème au niveau du code (utilisez-vous bien des
>>> BEGIN... END dans le code? Utilisez-vous des LOCK explicites, etc...)...
>> Pour la maintenance je fais un vacuum tous les jours sur crontab. La
>> taille de nos 3 bases de données est actuellement de 40 Go.
>>
>
> Dans ce cas, vous pouvez augmenter très sérieusement shared_buffers
> (30000 pour commencer). D'ailleurs, je me rends compte que vous n'avez
> pas parler de effective_cache_size qui devrait être de 2/3 sous Linux.
>
>> Notre verouillage : LOCK FOR UPDATE, les autres je ne sais pas.
>>
>
> Pourquoi des verrous explicites ? sont-ils vraiment nécessaires ?
>
>
> --
> Guillaume.
> <!-- http://abs.traduc.org/
> http://lfs.traduc.org/
> http://docs.postgresqlfr.org/ -->
>