Re: further testing on IDE drives

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Postgresql Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: further testing on IDE drives
Date: 2003-10-10 15:26:24
Message-ID: Pine.LNX.4.33.0310100926070.19052-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Nope, write-cache enabled by default.

On Thu, 9 Oct 2003, Bruce Momjian wrote:

>
> How did this drive come by default? Write-cache disabled?
>
> ---------------------------------------------------------------------------
>
> scott.marlowe wrote:
> > On Thu, 2 Oct 2003, 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.
> >
> > OK, back from testing.
> >
> > Information: Dual PIV system with a pair of 80 gig IDE drives, model
> > number: ST380023A (seagate). File system is ext3 and is on a seperate
> > drive from the OS.
> >
> > These drives DO NOT write cache when they lose power. Testing was done by
> > issuing a 'hdparm -W0/1 /dev/hdx' command where x is the real drive
> > letter, and 0 or 1 was chosen in place of 0/1. Then I'd issue a 'pgbench
> > -c 50 -t 100000000' command, wait for a few minutes, then pull the power
> > cord.
> >
> > I'm running RH linux 9.0 stock install, kernel: 2.4.20-8smp.
> >
> > Three times pulling the plug with 'hdparm -W0 /dev/hdx' resulted in a
> > machine that would boot up, recover with journal, and a database that came
> > up within about 30 seconds, with all the accounts still intact.
> >
> > Switching the caching back on with 'hdparm -W1 /dev/hdx' and doing the
> > same 'pgbench -c 50 -t 100000000' resulted in a corrupted database each
> > time.
> >
> > Also, I tried each of the following fsync methods: fsync, fdatasync, and
> > open_sync with write caching turned off. Each survived a power off test
> > with no corruption of the database. fsync and fdatasync result in 11 to
> > 17 tps with 'pgbench -c 5 -t 500' while open_sync resulted in 45 to 55
> > tps, as mentioned in the previous post.
> >
> > I'd be interested in hearing from other folks which sync method works
> > for them and whether or not there are any IDE drives out there that can
> > write their cache to the platters on power off when caching is enabled.
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> > (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
> >
>
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message scott.marlowe 2003-10-10 15:27:19 Re: further testing on IDE drives
Previous Message Thomas Swan 2003-10-10 12:59:49 Re: PostgreSQL vs MySQL