Skip site navigation (1) Skip section navigation (2)

Re: inferior SCSI performance

From: Michael Adler <adler(at)pobox(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: inferior SCSI performance
Date: 2003-09-17 20:46:00
Message-ID: Pine.NEB.4.58.0309171522170.1444@reva.sixgirls.org (view raw or flat)
Thread:
Lists: pgsql-performance

On Wed, 17 Sep 2003, Tom Lane wrote:
> Michael Adler <adler(at)pobox(dot)com> writes:
> > I have been experimenting with a new Seagate Cheetah 10k-RPM SCSI to
> > compare with a cheaper Seagate Barracuda 7200-RPM IDE (each in a
> > single-drive configuration). The Cheetah definately dominates the generic
> > IO tests such as bonnie++, but fares poorly with pgbench (and other
> > postgresql operations).
>
> It's fairly common for ATA drives to be configured to lie about write
> completion (ie, claim write-complete as soon as data is accepted into
> their onboard RAM buffer), whereas SCSI drives usually report write
> complete only when the data is actually down to disk.  The performance
> differential may thus be coming at the expense of reliability.  If you
> run Postgres with fsync off, does the differential go away?

Yes, they both perform equally at about 190 tps with fsync off.

The culprit turns out to be write-caching on the IDE drive. It is enabled
by default, but can be disabled with "hdparm -W0 /dev/hdx". After it is
disabled, the tps are proportional to rpms.

There's an (2001) Linux thread on this if anyone is interested:
http://www.ussg.iu.edu/hypermail/linux/kernel/0103.0/0331.html

So the quesiton is whether it is ever sensible to use write-caching and
expect comparable persistence.

Thanks,

Michael Adler

In response to

Responses

pgsql-performance by date

Next:From: Josh BerkusDate: 2003-09-17 22:17:26
Subject: Re: Is there a reason _not_ to vacuum continuously?
Previous:From: Matt ClarkDate: 2003-09-17 20:24:37
Subject: Re: Is there a reason _not_ to vacuum continuously?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group