Re: Re[2]: [PERFORM] SMP on a heavy loaded database

On Fri, Jan 4, 2013 at 3:38 PM, nobody nowhere <devnull(at)mail(dot)ua> wrote:
>
> An unfiltered top or ps might give you a clue. You could also try
>
> Look at letter on the topic start.

It's filtered by -u postgres, so you can't see apache there.

> iotop, php does hit the filesystem (sessions stored in disk), and if
> it's on the same partition as postgres, postgres' fsyncs might cause
> it to flush to disk quite heavily.
>
> The question was "which PID is using that core?"
> Can you using top or iotop certanly answer on this question? I can't.

If you see some process hogging CPU/IO in a way that's consistent with
CPU14, then you have a candidate. I don't see much in that iotop,
except the 640k/s writes in pg's writer, which isn't much at all
unless you have a seriously underpowered/broken system. If all fails,
you can look for processes with high accumulated cputime, like the
"monitor" ones there on the first top (though it doesn't say much,
since that top is incomplete), or the walsender. Without the ability
to compare against all other processes, none of that means much - but
once you do, you can inspect those processes more closely.

Oh... and you can also tell top to show the "last used processor". I
guess I should have said this first ;-)