On Fri, Jan 4, 2013 at 3:38 PM, nobody nowhere <devnull@xxxxxxx> 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 ;-) -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
