Re: Hot Standby performance issue

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: Hot Standby performance issue
Дата
Msg-id 5266BD42.2030303@fuzzy.cz
обсуждение исходный текст
Ответ на Re: Hot Standby performance issue  (sparikh <sparikh@ecotality.com>)
Ответы Re: Hot Standby performance issue  (sparikh <sparikh@ecotality.com>)
Список pgsql-performance
On 22.10.2013 02:00, sparikh wrote:
>> Do you suggest if I remove all the data files from /data/base folder
>> of standby and again rebuild using rsync from primary ? do you see
>> any issues there.? This is just to rule out any fragmentation on
>> standby side.
>
> The EXPLAIN really should not do much I/O. I doubt it has anything to do
> with fragmentation, so I doubt this is going to help.
>
> Actually I was referring to this in the context of addressing main
> underlying performance issue, not EXPLAIN. Sorry, I may not have
> communicated it correctly.
>
> Even strance does not seem to be installed.

It's 'strace' (aka syscall trace), not 'strance'. Please install both
perf and strace and try to collect some information about the backend
executing the slow query. We're mostly speculating and we need the data.

Try perf first - it's basically a profiler and the results are usually
understandable. Even a simple "perf top" can give us a hint.

Strace is much more low-level and much more difficult to analyze.

> The filesytem type it shows to me ext3.

OK. Not the best filesystem IMHO, but I doubt it's related to the issue
we're discussing here.

Tomas


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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Hot Standby performance issue
Следующее
От: Josh Berkus
Дата:
Сообщение: Logic of lowering seq_page_cost for SSD?