Message-ID: <519DBDB2.2050106@opinioni.net>
Date: Thu, 23 May 2013 08:56:50 +0200
From: Andrea Suisani <sickpig@opinioni.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Merlin Moncure <mmoncure@gmail.com>
CC: Greg Smith <greg@2ndquadrant.com>, Tomas Vondra <tv@fuzzy.cz>,
	pgsql-performance@postgresql.org
Subject: Re: Reliability with RAID 10 SSD and Streaming Replication
References: 
 <CAAE-9WHMycEZOB5J6HKME5AZLEdL2hYF+FV8hzbLksJinq=EJg@mail.gmail.com>
	<51957499.6050905@fuzzy.cz> <519991EB.8010208@2ndQuadrant.com>
	<519A8E29.60702@fuzzy.cz>
	<CAHyXU0wvW-USgbkXAYEHLG2fHgj=UdZi1aCFoVWBMQEsOFZy+A@mail.gmail.com>
	<519C0EFD.9080002@2ndQuadrant.com>
	<CAHyXU0ymFT7Sqw77yPryGWKEpjV4Wv9Vkc21vGtPKo0GZWGg8A@mail.gmail.com>
In-Reply-To: 
 <CAHyXU0ymFT7Sqw77yPryGWKEpjV4Wv9Vkc21vGtPKo0GZWGg8A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 05/22/2013 03:30 PM, Merlin Moncure wrote:
> On Tue, May 21, 2013 at 7:19 PM, Greg Smith <greg@2ndquadrant.com> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance