Re: Would my postgresql 8.4.12 profit from doubling RAM? - Mailing list pgsql-general

From Scott Marlowe
Subject Re: Would my postgresql 8.4.12 profit from doubling RAM?
Date
Msg-id CAOR=d=0Xq3N8kBZ=NC-qEsCrwMgLn1ZjYUkTKDfu4MBYXot-mA@mail.gmail.com
Whole thread Raw
In response to Re: Would my postgresql 8.4.12 profit from doubling RAM?  (Scott Marlowe <scott.marlowe@gmail.com>)
Responses Re: Would my postgresql 8.4.12 profit from doubling RAM?  (Alexander Farber <alexander.farber@gmail.com>)
List pgsql-general
On Sat, Sep 29, 2012 at 4:21 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:

> Whoa aren't you running pg bouncer?  If so then leave pg alone, adjust
> pg bouncer.  Revert that db side change, examine pgbouncer config etc.

Let me expand a bit on that point.  The reason to use pgbouncer is
that you can have hundreds of connects (or more) from your apache/php
server to pgbouncer, while pgbouncer will funnel those connections
down to a dozen or so connections on the other side.  Since pgbouncer
can hold open those hundreds of connections on the app side cheaply,
you may as well use persistent php connections.  Meanwhile, since
pgbouncer is holding the much more expensive pgsql connections open so
they don't have to close / open each time you get good performance.
So it goes like this:

apache/php -> (500 persistent conns, cheap) -> pgbouncer -> (20
persistent pgsql conns, expensive) -> pgsql.

So you shouldn't need to reconfigure anything on the pg side, just on
the apache/php -> pgbouncer side.

Note that if your app is doing hinky things like not resetting
connections / transactions you might need to investigate taht.


pgsql-general by date:

Previous
From: Mike Christensen
Date:
Subject: [FIXED] Re: Installing uuid-ossp on 9.2
Next
From: Bryan Keller
Date:
Subject: Postgresql 9.2 OOM