From: | Scott Carey <scott(at)richrelevance(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Marti Raudsepp <marti(at)juffo(dot)org>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? |
Date: | 2010-11-17 23:20:15 |
Message-ID: | A66BB3B4-4621-4BAF-A360-0F0CF9B0061E@richrelevance.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Nov 17, 2010, at 1:24 PM, Greg Smith wrote:
> Scott Carey wrote:
>> Did you recompile your test on the RHEL6 system?
>
> On both systems I showed, I checked out a fresh copy of the PostgreSQL
> 9.1 HEAD from the git repo, and compiled that on the server, to make
> sure I was pulling in the appropriate kernel headers. I wasn't aware of
> exactly how the kernel sync stuff was refactored though, thanks for the
> concise update on that.
Thanks!
So this could be another bug in Linux. Not entirely surprising.
Since fsync/fdatasync relative performance isn't similar to open_sync/open_datasync relative performance on this test there is probably a bug that either hurts fsync, or one that is preventing open_sync from dealing with metadata properly. Luckily for the xlog, both of those can be avoided -- the real choice is fdatasync vs open_datasync. And both work in newer kernels or break in certain older ones.
> I can do similar tests on a RHEL5 system, but
> not on the same hardware. Can only make my laptop boot so many
> operating systems at a time usefully.
Yeah, I understand. I might throw this at a RHEL5 system if I get a chance but I need one without a RAID card that is not in use. Hopefully it doesn't turn out that fdatasync is write-cache safe but open_sync/open_datasync isn't on that platform. It could impact the choice of a default value.
>
> --
> Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
> PostgreSQL Training, Services and Support www.2ndQuadrant.us
> "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-17 23:21:18 | Re: Query Performance SQL Server vs. Postgresql |
Previous Message | Ivan Voras | 2010-11-17 22:53:58 | Re: Anyone seen this kind of lock pileup? |