On Wed, May 22, 2013 at 9:18 AM, Greg Smith <greg@xxxxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
