Re: Hot Standby performance issue - Mailing list pgsql-performance

From Tomas Vondra
Subject Re: Hot Standby performance issue
Date
Msg-id 5266BD42.2030303@fuzzy.cz
Whole thread Raw
In response to Re: Hot Standby performance issue  (sparikh <sparikh@ecotality.com>)
Responses Re: Hot Standby performance issue  (sparikh <sparikh@ecotality.com>)
List 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 by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Hot Standby performance issue
Next
From: Josh Berkus
Date:
Subject: Logic of lowering seq_page_cost for SSD?