Re: further testing on IDE drives

On Fri, 10 Oct 2003, Josh Berkus wrote:

> Bruce,
>
> > 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?
>
> Want me to test? I've got an ide-based test machine here, and the TPCC
> databases.

OK, I decided to do a quick dirty test of things that are big transactions
in each mode my kernel supports. I did this:

createdb dbname
time pg_dump -O -h otherserver dbname|psql dbname

then I would drop the db, edit postgresql.conf, and restart the server.

open_sync was WAY faster at this than the other two methods.

open_sync:

1st run:

real 11m27.107s
user 0m26.570s
sys 0m1.150s

2nd run:

real 6m5.712s
user 0m26.700s
sys 0m1.700s

fsync:

1st run:

real 15m8.127s
user 0m26.710s
sys 0m0.990s

2nd run:

real 15m8.396s
user 0m26.990s
sys 0m1.870s

fdatasync:

1st run:

real 15m47.878s
user 0m26.570s
sys 0m1.480s

2nd run:

real 15m9.402s
user 0m27.000s
sys 0m1.660s

I did the first runs in order, then started over, i.e. opensync run1,
fsync run1, fdatasync run1, opensync run2, etc...

The machine I was restoring to was under no other load. The machine I was
reading from had little or no load, but is a production server, so it's
possible the load there could have had a small effect, but probably not
this big of a one.

The machine this is one is setup so that the data partition is on a drive
with write cache enabled, but the pg_xlog and pg_clog directories are on a
drive with write cache disabled. Same drive models as listed before in my
previous test, Seagate generic 80gig IDE drives, model ST380023A.