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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx www.2ndQuadrant.us
>
>
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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx www.2ndQuadrant.us
>
>
