Date: Fri, 30 Apr 2010 17:21:02 -0500 (CDT)
From: Scott Whitney <scott@journyx.com>
Reply-To: Scott Whitney <swhitney@journyx.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Scott Marlowe <scott.marlowe@gmail.com>, pgsql-admin@postgresql.org,
	Anj Adu <fotographs@gmail.com>, john@journyx.com,
	Scott Whitney <swhitney@journyx.com>
Message-ID: <28767388.332501272666062593.JavaMail.root@zimbra.int.journyx.com>
In-Reply-To: <4BDB5597.3040306@2ndquadrant.com>
Subject: Re: more 10K disks or less 15K disks
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_16626_4102431.1272666062589"

------=_Part_16626_4102431.1272666062589
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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 
> 
> 
------=_Part_16626_4102431.1272666062589
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'=
>A _very_ valid point which I omitted simply because it once again points t=
o 24 spindles<br>equating to a faster array than 12. The problem, as you so=
 easily summarize, is the fact<br>that once you put any decent RAID control=
ler into this, you've essentially added<br>a magic black box that does "bet=
ter" things for the underlying storage which you<br>simply cannot compute w=
ith these sorts of numbers.<br><br>ASSUMING that your raid controller is a =
good one (and Perc is), you should end<br>up with a scenario that simply bo=
ils down to "more spindles will be faster."<br><br>In theory.<br><br>In pra=
ctice, I find that theory holds up only erratically.<br><br>----- "Greg Smi=
th" &lt;greg@2ndquadrant.com&gt; wrote:
<br>&gt; Scott Whitney wrote:<br>&gt; &gt; On the 10k vs 15k rpm disks, the=
re's a _lot_ to be said about that. I don't want to start a flame war here,=
 <br>&gt; &gt; but 15k versus 10k rpm hard drives does NOT equivocate to a =
50% increase in read/write times, to say <br>&gt; &gt; the VERY least.<br>&=
gt; &gt; &nbsp; <br>&gt; <br>&gt; Your characterization is correct were the=
re only the drives involved <br>&gt; here, so no flames on your raw data.<b=
r>&gt; <br>&gt; Once you've introduced a battery-backed write cache into th=
e mix, this <br>&gt; whole area becomes impossible to compute that way thou=
gh, and it was <br>&gt; that context I was commenting from at least. &nbsp;=
Those are good at turning <br>&gt; random I/O into something more like sequ=
ential, as well as reducing the <br>&gt; number of times you pay for rotati=
onal latency in several common <br>&gt; database operations. &nbsp;The effe=
ctive impact is to significantly narrow <br>&gt; the difference between dri=
ves where the seek and rotation time are the <br>&gt; main differences in a=
 database context--even though the worst-case IOPS <br>&gt; doesn't really =
change. &nbsp;IOPS is an interesting number to compute, but <br>&gt; real-w=
orld database performance isn't linearly correlated with it. &nbsp;<br>&gt;=
 Maybe if your workload consists mainly of random, uncached index scans <br=
>&gt; system performance will scale just like IOPS, but that's pretty uncom=
mon.<br>&gt; <br>&gt; [Rant about making sure not to drink the storage vend=
or IOPS Kool-Aid <br>&gt; deleted]<br>&gt; <br>&gt; -- <br>&gt; Greg Smith =
&nbsp;2ndQuadrant US &nbsp;Baltimore, MD<br>&gt; PostgreSQL Training, Servi=
ces and Support<br>&gt; greg@2ndQuadrant.com &nbsp; www.2ndQuadrant.us<br>&=
gt; <br>&gt; </div></body></html>
------=_Part_16626_4102431.1272666062589--