On Wed, May 22, 2013 at 9:18 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> On 5/22/13 9:30 AM, Merlin Moncure wrote:
>>
>> That's most certainly *not* the only gain to be had: random read rates
>> of large databases (a very important metric for data analysis) can
>> easily hit 20k tps. So I'll stand by the figure.
>
>
> They can easily hit that number. Or they can do this:
>
> Device: r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
> sdd 2702.80 19.40 19.67 0.16 14.91 273.68 71.74 0.37 100.00
> sdd 2707.60 13.00 19.53 0.10 14.78 276.61 90.34 0.37 100.00
yup -- I've seen this too...the high transaction rates quickly fall
over when there is concurrent writing (but for bulk 100% read OLAP
queries I see the higher figure more often than not). Even so, it's
a huge difference over 100. unfortunately, I don't have a s3700 to
test with, but based on everything i've seen it looks like it's a
mostly solved problem. (for example, see here:
http://www.storagereview.com/intel_ssd_dc_s3700_series_enterprise_ssd_review).
Tests that drive the 710 to <3k iops were not able to take the 3700
down under 10k at any queue depth. Take a good look at the 8k
preconditioning curve latency chart -- everything you need to know is
right there; it's a completely different controller and offers much
better worst case performance.
merlin
