Re: Would my postgresql 8.4.12 profit from doubling RAM?

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: Would my postgresql 8.4.12 profit from doubling RAM?
Дата
Msg-id CAOR=d=0Xq3N8kBZ=NC-qEsCrwMgLn1ZjYUkTKDfu4MBYXot-mA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Would my postgresql 8.4.12 profit from doubling RAM?  (Scott Marlowe <scott.marlowe@gmail.com>)
Ответы Re: Would my postgresql 8.4.12 profit from doubling RAM?  (Alexander Farber <alexander.farber@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Mike Christensen
Дата:
Сообщение: [FIXED] Re: Installing uuid-ossp on 9.2
Следующее
От: Bryan Keller
Дата:
Сообщение: Postgresql 9.2 OOM