Re: Rather large LA

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: Richard Shaw <richard(at)aggress(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Rather large LA
Date: 2011-09-05 11:16:45
Message-ID: 4E64AF9D.3060601@ringerc.id.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Andy Colson 2011-09-05 13:39:10 Re: Rather large LA
Previous Message Richard Shaw 2011-09-05 10:55:20 Re: Rather large LA