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

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: Re[2]: [PERFORM] SMP on a heavy loaded database
Дата
Msg-id CAGTBQpZvD1jm5PCoRcBJraRFWNsn1urRH2=SJ-byAiYr1ycjfg@mail.gmail.com
обсуждение исходный текст
Ответ на SMP on a heavy loaded database  (nobody nowhere <devnull@mail.ua>)
Список pgsql-performance
On Fri, Jan 4, 2013 at 3:38 PM, nobody nowhere <devnull@mail.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 ;-)


В списке pgsql-performance по дате отправления:

Предыдущее
От: Vitalii Tymchyshyn
Дата:
Сообщение: Re: Postgres delete performance problem
Следующее
От: Tom Lane
Дата:
Сообщение: Re: FW: performance issue with a 2.5gb joinded table