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?
|
Список | 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 по дате отправления: