Stefan,
On 3/10/06 12:23 PM, "Stefan Kaltenbrunner" <[EMAIL PROTECTED]> wrote:
> 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.
Wow - the ickiness of SAN fro a performance / value standpoint never ceases
to astound me.
>> 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.
So - you're getting 20MB/s on loading from a potential of 200MB/s?
>> I would expect some 10x this if configured well.
>
> see above ...
OTOH - configured well could include taking the disks out of the smart (?)
chassis, plugging them into a dumb chassis and deploying 2 dual channel U320
SCSI adapters - total cost of about $3,000.
> 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 ...
No problem - that's our job anyway - to make the case for Postgres' use in
typical large scale use-cases like the one you describe.
- Luke
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
