From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Nabil Servais <nabil(dot)servais(at)gmail(dot)com> |
Cc: | pgsql-fr-generale <pgsql-fr-generale(at)postgresql(dot)org> |
Subject: | Re: Thread et postgresql |
Date: | 2014-07-18 10:06:13 |
Message-ID: | m2zjg7ugkq.fsf@2ndQuadrant.fr |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
Nabil Servais <nabil(dot)servais(at)gmail(dot)com> writes:
> L'ORM que j'utilise à tendance à ne pas fermer les connexions clientes en
> tentant via un moteur de pool interne de réutiliser les connexions
> ouvertes, c'est un bug connu et signalé mais les développeurs ne veulent
> pas appliquer la solution car elle entraine trop de régression sur d'autres
> points.
Il faut les aider à comprendre que c'est essentiel, à mon humble avis.
> J'ai identifié plusieurs solutions :
>
> - Tunner postgresql pour accepter le maximum de clients, mais je crains que
> cette solution repousse le problème.
> - Utiliser pgbouncer ou pgpool, je serais très intéressé par les retours
> dans ce genre de cas.
> - Créer mon propre système de pool.
Utilise pgbouncer, ça marche vraiment très bien, c'est fait pour gérer
ce genre de situation. Attention toutefois, par défaut pgbouncer ne va
pas clore les sessions que l'ORM laisse traîner, il faut lui dire d'être
méchant avec le client en utilisant client_timeout.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
From | Date | Subject | |
---|---|---|---|
Next Message | Michel Payan | 2014-07-18 10:07:08 | Re: Thread et postgresql |
Previous Message | Nabil Servais | 2014-07-18 09:54:33 | Thread et postgresql |