Re: SAN performance mystery - Mailing list pgsql-performance

From Tom Lane
Subject Re: SAN performance mystery
Date
Msg-id 1751.1150410284@sss.pgh.pa.us
Whole thread Raw
In response to Re: SAN performance mystery  (Brian Hurt <bhurt@janestcapital.com>)
Responses Re: SAN performance mystery
List pgsql-performance
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

pgsql-performance by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Optimizer internals
Next
From: "John Vincent"
Date:
Subject: Re: Optimizer internals