Re: more 10K disks or less 15K disks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
>
>

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux