Re: data on devel code perf dip - Mailing list pgsql-hackers

From Mary Edie Meredith
Subject Re: data on devel code perf dip
Date
Msg-id 1125351397.30683.106.camel@localhost
Whole thread Raw
In response to Re: data on devel code perf dip  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Thanks, Tom for keeping on this.  I was on vacation last week.  Will try
the latest  ASAP.


On Mon, 2005-08-22 at 20:20 -0400, Tom Lane wrote:
> I wrote:
> > I've been sniffing around that patch and not really finding any smoking
> > gun about why it would make things slower when you're not using O_DIRECT.
> 
> While rewriting the patch to fit more naturally into xlog.c, I found a
> bug that might possibly be related to your performance issue.  The
> if-test in this fragment is wrong:
> 
>         /*
>          * If we just wrote the whole last page of a logfile segment,
>          * fsync the segment immediately.  This avoids having to go back
>          * and re-open prior segments when an fsync request comes along
>          * later. Doing it here ensures that one and only one backend will
>          * perform this fsync.
>          *
>          * This is also the right place to notify the Archiver that the
>          * segment is ready to copy to archival storage.
>          */
>         if (openLogOff + pages.size >= XLogSegSize && !ispartialpage)
>         {
>             XLogPageFlush(&pages, currentIndex);
>             issue_xlog_fsync();
>             ...
> 
> Because of the patch's logic changes, openLogOff is not the right thing
> to be examining here --- we have not yet done a seek to ensure that it
> matches the write start point.  (pages.offset + pages.size would have
> worked instead.)
> 
> The implication of this is that the code might either fail to do a write
> and fsync when it needs to, or do extra fsyncs that it doesn't need to
> do.  I am wondering if the latter could explain your issue.  Right
> offhand it doesn't seem like this would lead to enough extra fsyncs
> to account for the amount of slowdown you report --- but there just
> doesn't seem to be anything else in there that could account for it.
> 
> I've committed a patch that fixes this and makes some other minor
> improvements (which you probably won't notice given that you're using
> such a large wal_buffers setting).  You might like to update to CVS
> tip (make sure you get xlog.c 1.218 or later) and see if things are
> any better or not.
> 
>             regards, tom lane



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Performance gain from reduction of GROUP BY memory allocations
Next
From: Varun Kacholia
Date:
Subject: Re: Query Sampling