Re: further testing on IDE drives

scott.marlowe wrote:
> On Thu, 9 Oct 2003, Bruce Momjian wrote:
>
> > scott.marlowe wrote:
> > > I was testing to get some idea of how to speed up the speed of pgbench
> > > with IDE drives and the write caching turned off in Linux (i.e. hdparm -W0
> > > /dev/hdx).
> > >
> > > The only parameter that seems to make a noticeable difference was setting
> > > wal_sync_method = open_sync. With it set to either fsync, or fdatasync,
> > > the speed with pgbench -c 5 -t 1000 ran from 11 to 17 tps. With open_sync
> > > it jumped to the range of 45 to 52 tps. with write cache on I was getting
> > > 280 to 320 tps. so, not instead of being 20 to 30 times slower, I'm only
> > > about 5 times slower, much better.
> > >
> > > Now I'm off to start a "pgbench -c 10 -t 10000" and pull the power cord
> > > and see if the data gets corrupted with write caching turned on, i.e. do
> > > my hard drives have the ability to write at least some of their cache
> > > during spin down.
> >
> > Is this a reason we should switch to open_sync as a default, if it is
> > availble, rather than fsync? I think we are doing a single write before
> > fsync a lot more often than we are doing multiple writes before fsync.
>
> Sounds reasonable to me. Are there many / any scenarios where a plain
> fsync would be faster than open_sync?

Yes. If you were doing multiple WAL writes before transaction fsync,
you would be fsyncing every write, rather than doing two writes and
fsync'ing them both. I wonder if larger transactions would find
open_sync slower?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073