Re: High SYS CPU - need advise

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Vlad <marchenko(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: High SYS CPU - need advise
Date: 2012-11-16 21:32:35
Message-ID: CAHyXU0wo7z7oj5ZaTGukWKz8-h8fM9kdkauYt3AWmb5u19aSFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Nov 16, 2012 at 3:21 PM, Vlad <marchenko(at)gmail(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message T. E. Lawrence 2012-11-17 14:08:32 9.2 streaming replication issue and solution strategy
Previous Message Vlad 2012-11-16 21:21:09 Re: High SYS CPU - need advise