Re: further testing on IDE drives - Mailing list pgsql-performance

From Bruce Momjian
Subject Re: further testing on IDE drives
Date
Msg-id 200310100018.h9A0ITZ21975@candle.pha.pa.us
Whole thread Raw
In response to Re: further testing on IDE drives  ("scott.marlowe" <scott.marlowe@ihs.com>)
Responses Re: further testing on IDE drives
List pgsql-performance
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@postgresql.org)
>

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

pgsql-performance by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: further testing on IDE drives
Next
From: Dror Matalon
Date:
Subject: Re: Speeding up Aggregates