Discussion :

[clavier12AZQSWX]

bonjour,

sur un serveur debian4 (etch) avec postgresql 8.1 et une application python (openerp tinyerp), nous avons souvent des messages d'erreur du type :

too many open connections: 64
Try increasing maximum number of physical connections when calling connect()

comment le résoudre ? car à chaque fois, on doit demander à tout le monde de fermer l'applicatif et redémarrer PG et openerp.

d'où vient ce chiffre de 64?
apparement ça vient pas du fichier de config de pg car dedans j'ai mis 80 (et j'ai déjà redémarré et reloadé la config mainte fois).
de même, j'ai déjà changé le shammax de notre serveur et redémarré et mis aussi dans le fichier en dur. j'ai mis 1432756224 sachant que nous avons 15 utilisateurs et un serveur dédié avec 4Go de mémoire.


Est-ce que ce 64 est un paramètre dans la debian ou dans une librairie python ?
Nos accès sont fait en xml-rpc si ça peut vous donner une piste....

est-il possible de lister ces connexions ? ou de réduire le délai de "mort automatique" avant une non-utilisation ?

mon petit doigt me dit que c'est une partie de l'application qui envoie plus de 64 requete xml-rpc, qui répondent vite mais qui reste donc morte allumées trop longtemps.

merci de votre aide.

[punkoff]

bonjour,

Vérifier déjà que votre applciation ferme correctement les connections après les avoir utilisées.

Sinon, postgres dispose effectivement d'un parametre de max connection http://wiki.postgresql.org/wiki/Tuni...tgreSQL_Server

Concernant les timeout regardez aussi du côté du driver jdbc utilisé pour ce connecter à la base de donnée

[estofilo]

Cette erreur ne vient pas de postgres mais du pool de connexions de psycopg.

Voir la fonction request_pgconn() dans:
http://src.gnu-darwin.org/ports/data....1.21/cursor.c

Ca se règle sûrement quelque part mais il faudrait voir dans la doc de psycopg-1.

A noter que psycopg-1 est obsolète de même que postgresql 8.1 de même debian etch.
Tout ça n'est plus supporté depuis des années.

[clavier12AZQSWX]

Cette erreur ne vient pas de postgres mais du pool de connexions de psycopg.

Voir la fonction request_pgconn() dans:
http://src.gnu-darwin.org/ports/data....1.21/cursor.c

Ca se règle sûrement quelque part mais il faudrait voir dans la doc de psycopg-1.

bravo pour avoir trouvé cette aiguille! comment avez-vous fait ? (déjà rencontré ce problème) ?
je vais enquêter la semaine prochaine là-dessus.

A noter que psycopg-1 est obsolète de même que postgresql 8.1 de même debian etch.
Tout ça n'est plus supporté depuis des années.

si c'était aussi simple de tout mettre à jour, je l'aurai déjà fait mais là il y a trop de couches dépendantes :
debian-->python2>>libxml>psyco pg>postgresql>openerp...