Re: Hot Standby performance issue

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Hot Standby performance issue
Date: 2013-10-22 18:00:34
Message-ID: 5266BD42.2030303@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2013-10-22 18:56:14 Logic of lowering seq_page_cost for SSD?
Previous Message Tomas Vondra 2013-10-22 17:54:11 Re: Hot Standby performance issue