On 5/09/2011 6:55 PM, Richard Shaw wrote:
Hi Craig,
Apologies, I should have made that clearer, I am using PgBouncer 1.4.1 in front of Postgres and included the config at the bottom of my original mail
Ah, I see. The point still stands: your hardware can *not* efficiently
do work for 1000 concurrent backend workers. Reduce the maximum number
of workers by setting a lower cap on the pool size and a lower
max_connections. This won't work (you'll run out of pooler connections)
unless you also set PgBouncer to transaction pooling mode instead of the
default session pooling mode, which you're currently using. It is
*important* to read the documentation on this before doing it, as there
are implications for apps that use extra-transactional features like
HOLD cursors and advisory locks.
See: http://pgbouncer.projects.postgresql.org/doc/usage.html
It may also be necessary to set PgBouncer to block (wait) rather than
report an error when there is no pooled connection available to start a
new transaction on. I'm not sure what PgBouncer's default behavior for
that is and didn't see anything immediately clear in the pgbouncer(5)
ini file man page.
--
Craig Ringer
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
