Skip site navigation (1) Skip section navigation (2)

Re: SAN performance mystery

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brian Hurt <bhurt(at)janestcapital(dot)com>
Cc: Tim Allen <tim(at)proximity(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org
Subject: Re: SAN performance mystery
Date: 2006-06-15 22:24:44
Message-ID: 1751.1150410284@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Brian Hurt <bhurt(at)janestcapital(dot)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

In response to

Responses

pgsql-performance by date

Next:From: John VincentDate: 2006-06-15 23:23:39
Subject: Re: Optimizer internals
Previous:From: Jim C. NasbyDate: 2006-06-15 22:23:45
Subject: Re: Optimizer internals

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group