Luke Lonergan wrote:
> Stefan,
>
> On 3/10/06 11:48 AM, "Stefan Kaltenbrunner" <stefan@kaltenbrunner.cc> wrote:
>
>
>>2 HBAs in the server, 2x2 possible paths to each LUN.
>>6 disks for the WAL and 12 disks for the data
>
>
> So - you have 18 disks worth of potential bandwidth, not factoring loss due
> to RAID. That's roughly 18 * 60 = 1,080 MB/s. If we organized that into
> four banks, one for each CPU and made each one RAID5 and left two disks for
> spares, you'd have 12 disks working for you at 720MB/s, which is possibly
> double the number of active FC channels you have, unless they are all
> active, in which case you have a nicely matched 800MB/s of FC.
wrong(or rather extremely optimistic) the array itself only has two
(redundant) FC-loops(@2GB )to the attached expansion chassis. The array
has 2 active/active controllers (with a failover penalty) with two host
interfaces each, furthermore it has write-cache mirroring(to the standby
controller) enabled which means the traffic has to go over the internal
FC-loop too.
beside that the host(as I said) itself only has two HBAs @2GB which are
configured for failover which limits the hosts maximum available
bandwith to less than 200MB/S per LUN.
>
>
>>>So, from 15 MB/s up to about 20 MB/s.
>
>
> Gee - seems a long distance from 700 MB/s potential :-)
well the array is capable of about 110MB/s write per controller head (a
bit more half the possible due to write mirroring enabled which uses
delta-syncronisation).
WAL and data are on different controllers though by default.
>
>
>>the IO-System I use should be capable of doing that if pushed hard
>>enough :-)
>
>
> I would expect some 10x this if configured well.
see above ...
>
>
>>interesting to know, but still I'm testing/playing with postgresql here
>>not bizgres MPP ...
>
>
> Sure. Still, what I'd expect is something like 10x this update rate using
> the parallelism buried in your hardware.
>
> If you configure the same machine with 4 Bizgres MPP segments running on 4
> LUNs I think you'd be shocked at the speedups.
that might be true, though it might sound a bit harsh I really prefer to
spend the small amount of spare time I have with testing(and helping to
improve if possible) postgresql than playing with a piece of commercial
software I'm not going to use anyway ...
Stefan