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" <g...@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 
> g...@2ndquadrant.com www.2ndQuadrant.us 
> 
> 

Reply via email to