On Fri, Nov 16, 2012 at 3:21 PM, Vlad <marchenko@xxxxxxxxx> wrote: > what would pgbouncer do in my case? Number of connections will decrease, but > number of active clients won't be smaller. As I understand the latter ones > are that important. Well, one thing that struck me was how little spinlock contention there actually was. Yeah, backends are delaying here and there, which isn't great, but but a few dozen delays per second across several hundred backends doesn't seem like it should be pegging sys cpu%. This is all pointing to the problem not being in postgres, but in linux. pgbouncer would do two things: 1) perhaps guard you against some o/s issue 2) keep system more responsive during stall (since by controlling the pool you control the number of queries piling up). of course, this comes at the expense of some overhead. But, before going through all that, how about timing strace recorded calls (strace -T) both in stall and non-stall conditions. I was assuming select(), but maybe it's something else....for example the recently fixed lseek. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
