To: Brian Hurt <bhurt@janestcapital.com>
cc: Tim Allen <tim@proximity.com.au>, pgsql-performance@postgresql.org
Subject: Re: SAN performance mystery 
In-reply-to: <4491D8DC.4070906@janestcapital.com> 
References: <4491D61B.9040507@proximity.com.au>
	<4491D8DC.4070906@janestcapital.com>
Comments: In-reply-to Brian Hurt <bhurt@janestcapital.com>
	message dated "Thu, 15 Jun 2006 18:02:04 -0400"
Date: Thu, 15 Jun 2006 18:24:44 -0400
Message-ID: <1751.1150410284@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Brian Hurt <bhurt@janestcapital.com> writes:
> Tim Allen wrote:
>> To simplify greatly - single local SATA disk beats EMC SAN by factor 
>> of four.

> I'm actually in a not dissimiliar position here- I was seeing the 
> performance of Postgres going to an EMC Raid over iSCSI running at about 
> 1/2 the speed of a lesser machine hitting a local SATA drive.  That was, 
> until I noticed that the SATA drive Postgres installation had fsync 
> turned off, and the EMC version had fsync turned on.  Turning fsync on 
> on the SATA drive dropped it's performance to being about 1/4th that of EMC.

And that's assuming that the SATA drive isn't configured to lie about
write completion ...

I agree with Brian's suspicion that the SATA drive isn't properly
fsync'ing to disk, resulting in bogusly high throughput.  However,
ISTM a well-configured SAN ought to be able to match even the bogus
throughput, because it should be able to rely on battery-backed
cache to hold written blocks across a power failure, and hence should
be able to report write-complete as soon as it's got the page in cache
rather than having to wait till it's really down on magnetic platter.
Which is what the SATA drive is doing ... only it can't keep the promise
it's making for lack of any battery backup on its on-board cache.

So I'm thinking *both* setups may be misconfigured.  Or else you forgot
to buy the battery-backed-cache option on the SAN hardware.

			regards, tom lane