Re: 10K vs 15k rpm for analytics

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.

In response to

Browse pgsql-performance by date

  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