Re: How to keep queries low latency as concurrency increases
От | Jeff Janes |
---|---|
Тема | Re: How to keep queries low latency as concurrency increases |
Дата | |
Msg-id | CAMkU=1z_NyKv-jMLC2-Xe5z+H2X-cm2a=8aJgrgUmcDRq6a8Uw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: How to keep queries low latency as concurrency increases (Marko Kreen <markokr@gmail.com>) |
Ответы |
Re: How to keep queries low latency as concurrency increases
Re: How to keep queries low latency as concurrency increases |
Список | pgsql-performance |
On Mon, Nov 5, 2012 at 2:58 PM, Marko Kreen <markokr@gmail.com> wrote: > On Sun, Nov 4, 2012 at 1:53 AM, Jeff Janes <jeff.janes@gmail.com> wrote: >> On a 4 CPU machine, if I run pgbench -c10 -j10 with dummy queries >> (like "select 1;" or "set timezone...") against 2 instances of >> pgbouncer, I get nearly twice the throughput as if I use only one >> instance. >> >> A rather odd workload, maybe, but it does seem to be similar to the >> one that started this thread. > > Every-connection-is-busy is pessimal workload for pgbouncer, > as it has nothing useful to contribute to setup, just overhead. It still has something to contribute if connections are made and broken too often (pgbench -C type workload), as seems to be the case here. If he can get an application-side pooler (or perhaps just a change in configuration) such that the connections are not made and broken so often, then removing pgbouncer from the loop would probably be a win. Cheers, Jeff
В списке pgsql-performance по дате отправления: