Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: Benchmark: Dell/Perc 6, 8 disk RAID 10


  • From: Greg Smith <gsmith(at)gregsmith(dot)com>
  • To: pgsql-performance(at)postgresql(dot)org
  • Subject: Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
  • Date: Thu, 13 Mar 2008 17:27:09 -0400 (EDT)
  • Message-id: <Pine(dot)GSO(dot)4(dot)64(dot)0803131710520(dot)5221(at)westnet(dot)com>

On Thu, 13 Mar 2008, Joshua D. Drake wrote:

Greg Smith <gsmith(at)gregsmith(dot)com> wrote:
wal_sync_method = open_sync

There was a bug report I haven't had a chance to investigate yet that
suggested some recent Linux versions have issues when using
open_sync. I'd suggest popping that back to the default for now
unless you have time to really do a long certification process that
your system runs reliably with it turned on.

Well the default would be ugly, that's fsync, fdatasync is probably a
better choice in that case.

I haven't found fdatasync to be significantly better in my tests on Linux but I never went out of my way to try and quantify it. My understanding is that some of the write barrier implementation details on ext3 filesystems make any sync call a relatively heavy operation but I haven't poked at the code yet to figure out why.

There are really some substantial gains for WAL-heavy loads under Linux just waiting for someone to dig into this more. For example, I have a little plan sitting here to allow opening the WAL files with noatime even if the rest of the filesystem can't be mounted that way, which would collapse one of the big reasons to use a separate WAL disk.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group