Re: random observations while testing with a 1,8B row table

Luke Lonergan wrote:
> Stefan,
>
> On 3/10/06 12:23 PM, "Stefan Kaltenbrunner" <stefan(at)kaltenbrunner(dot)cc> 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