From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Hannu Krosing <hannu(at)krosing(dot)net> |
Cc: | Yeb Havinga <yebhavinga(at)gmail(dot)com>, Francisco Reyes <lists(at)stringsutils(dot)com>, Pgsql performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: 10K vs 15k rpm for analytics |
Date: | 2010-03-03 18:32:50 |
Message-ID: | dcc563d11003031032l5541f1d0hdc327c2ba4ae9f29@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Mar 3, 2010 at 4:53 AM, Hannu Krosing <hannu(at)krosing(dot)net> 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(at)gmail(dot)com> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-03-03 19:33:59 | Re: bgwriter, checkpoints, curious (seeing delays) |
Previous Message | Robert Haas | 2010-03-03 17:12:40 | Re: Estimation issue with partitioned tables |