On Fri, Nov 16, 2012 at 3:21 PM, Vlad <marchenko@gmail.com> 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
