Luke Lonergan wrote: > 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.
Well while make it sound a bit like that, performance is not everything. One has to factor manageability,scalability (in terms of future upgrades using the same platform and such) and high-availability features in too. With that in mind a SAN (or a NAS - depends on the actual usecases) suddenly looks much more interesting than plain old DASD. > > >>>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? no - I can write 110MB/s on thw WAL LUN and 110MB/s on the other LUN concurrently. > > >>>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. as i said above even if that would work (it does not because the disks have FC-connectors) I would loose a LOT of features like being able to use the SAN for more than a single host (big one!) or doing firmware-upgrades without downtime, using SAN-replication, having cable-length exceeding 12m(makes it possible to place parts of the infrastructure at remote sites),out-of-band management,scriptable(!),... Beside that, sequential-io as you are propagating everywhere is NOT the holy grail or the sole solution to a fast database. While the SAN above really is not a screamer for that kind of application it is actually a very good performer(compared with some of the DASD based boxes) under heavy random-io and concurrent load. This has a direct measurable influence on the overall speed of our production applications which are mostly OLTP ;-) > > >>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. yep Stefan ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
