From: Scott Whitney <scott@journyx.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Scott Marlowe <scott.marlowe@gmail.com>
Cc: pgsql-admin@postgresql.org, Anj Adu <fotographs@gmail.com>
Cc: john@journyx.com, Scott Whitney <swhitney@journyx.com>
Subject: Re: more 10K disks or less 15K disks
Date: Fri, 30 Apr 2010 17:21:02 -0500 (CDT)
Message-ID: <28767388.332501272666062593.JavaMail.root@zimbra.int.journyx.com> (raw)
In-Reply-To: <4BDB5597.3040306@2ndquadrant.com>
A _very_ valid point which I omitted simply because it once again points to 24 spindles
equating to a faster array than 12. The problem, as you so easily summarize, is the fact
that once you put any decent RAID controller into this, you've essentially added
a magic black box that does "better" things for the underlying storage which you
simply cannot compute with these sorts of numbers.
ASSUMING that your raid controller is a good one (and Perc is), you should end
up with a scenario that simply boils down to "more spindles will be faster."
In theory.
In practice, I find that theory holds up only erratically.
----- "Greg Smith" <greg@2ndquadrant.com> wrote:
> Scott Whitney wrote:
> > On the 10k vs 15k rpm disks, there's a _lot_ to be said about that. I don't want to start a flame war here,
> > but 15k versus 10k rpm hard drives does NOT equivocate to a 50% increase in read/write times, to say
> > the VERY least.
> >
>
> Your characterization is correct were there only the drives involved
> here, so no flames on your raw data.
>
> Once you've introduced a battery-backed write cache into the mix, this
> whole area becomes impossible to compute that way though, and it was
> that context I was commenting from at least. Those are good at turning
> random I/O into something more like sequential, as well as reducing the
> number of times you pay for rotational latency in several common
> database operations. The effective impact is to significantly narrow
> the difference between drives where the seek and rotation time are the
> main differences in a database context--even though the worst-case IOPS
> doesn't really change. IOPS is an interesting number to compute, but
> real-world database performance isn't linearly correlated with it.
> Maybe if your workload consists mainly of random, uncached index scans
> system performance will scale just like IOPS, but that's pretty uncommon.
>
> [Rant about making sure not to drink the storage vendor IOPS Kool-Aid
> deleted]
>
> --
> Greg Smith 2ndQuadrant US Baltimore, MD
> PostgreSQL Training, Services and Support
> greg@2ndQuadrant.com www.2ndQuadrant.us
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: scott@journyx.com, greg@2ndquadrant.com, scott.marlowe@gmail.com, fotographs@gmail.com, swhitney@journyx.com
Subject: Re: more 10K disks or less 15K disks
In-Reply-To: <28767388.332501272666062593.JavaMail.root@zimbra.int.journyx.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox