On 05/22/2013 03:30 PM, Merlin Moncure wrote:
On Tue, May 21, 2013 at 7:19 PM, Greg Smith <greg@xxxxxxxxxxxxxxx> wrote:
On 5/20/13 6:32 PM, Merlin Moncure wrote:
[cut]
The only really huge gain to be had using SSD is commit rate at a low client
count. There you can easily do 5,000/second instead of a spinning disk that
is closer to 100, for less than what the battery-backed RAID card along
costs to speed up mechanical drives. My test server's 100GB DC S3700 was
$250. That's still not two orders of magnitude faster though.
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. Another point: that
5000k commit raid is sustained, whereas a raid card will spectacularly
degrade until the cache overflows; it's not fair to compare burst with
sustained performance. To hit 5000k sustained commit rate along with
good random read performance, you'd need a very expensive storage
system. Right now I'm working (not by choice) with a teir-1 storage
system (let's just say it rhymes with 'weefax') and I would trade it
for direct attached SSD in a heartbeat.
Also, note that 3rd party benchmarking is showing the 3700 completely
smoking the 710 in database workloads (for example, see
http://www.anandtech.com/show/6433/intel-ssd-dc-s3700-200gb-review/6).
[cut]
Sorry for interrupting but on a related note I would like to know your
opinions on what the anandtech review said about 3700 poor performance
on "Oracle Swingbench", quoting the relevant part that you can find here (*)
<quote>
[..] There are two components to the Swingbench test we're running here:
the database itself, and the redo log. The redo log stores all changes that
are made to the database, which allows the database to be reconstructed in
the event of a failure. In good DB design, these two would exist on separate
storage systems, but in order to increase IO we combined them both for this test.
Accesses to the DB end up being 8KB and random in nature, a definite strong suit
of the S3700 as we've already shown. The redo log however consists of a bunch
of 1KB - 1.5KB, QD1, sequential accesses. The S3700, like many of the newer
controllers we've tested, isn't optimized for low queue depth, sub-4KB, sequential
workloads like this. [..]
</quote>
Does this kind of scenario apply to postgresql wal files repo ?
Thanks
andrea
(*) http://www.anandtech.com/show/6433/intel-ssd-dc-s3700-200gb-review/5
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
