On Wed, Mar 3, 2010 at 4:53 AM, Hannu Krosing <hannu@xxxxxxxxxxx> wrote: > On Wed, 2010-03-03 at 10:41 +0100, Yeb Havinga wrote: >> Scott Marlowe wrote: >> > On Tue, Mar 2, 2010 at 1:51 PM, Yeb Havinga <yebhavinga@xxxxxxxxx> wrote: >> > >> >> With 24 drives it'll probably be the controller that is the limiting factor >> >> of bandwidth. Our HP SAN controller with 28 15K drives delivers 170MB/s at >> >> maximum with raid 0 and about 155MB/s with raid 1+0. So I'd go for the 10K >> >> drives and put the saved money towards the controller (or maybe more than >> >> one controller). >> >> >> > >> > That's horrifically bad numbers for that many drives. I can get those >> > numbers for write performance on a RAID-6 on our office server. I >> > wonder what's making your SAN setup so slow? >> > >> Pre scriptum: >> A few minutes ago I mailed detailed information in the same thread but >> as reply to an earlier response - it tells more about setup and gives >> results of a raid1+0 test. >> >> I just have to react to "horrifically bad" and "slow" :-) : The HP san >> can do raid5 on 28 disks also on about 155MBps: > > SAN-s are "horrifically bad" and "slow" mainly because of the 2MBit sec > fiber channel. > But older ones may be just slow internally as well. > The fact that it is expensive does not make it fast. > If you need fast thrughput, use direct attached storage Let me be clear that the only number mentioned at the beginning was throughput. If you're designing a machine to run huge queries and return huge amounts of data that matters. OLAP. If you're designing for OLTP you're likely to only have a few megs a second passing through but in thousands of xactions per second. So, when presented with the only metric of throughput, I figured that's what the OP was designing for. For OLTP his SAN is plenty fast. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
