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: