pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Scott Marlowe <scott.marlowe@gmail.com>
To: Hannu Krosing <hannu@krosing.net>
Cc: Yeb Havinga <yebhavinga@gmail.com>
Cc: Francisco Reyes <lists@stringsutils.com>
Cc: Pgsql performance <pgsql-performance@postgresql.org>
Subject: Re: 10K vs 15k rpm for analytics
Date: Wed, 3 Mar 2010 11:32:50 -0700
Message-ID: <dcc563d11003031032l5541f1d0hdc327c2ba4ae9f29@mail.gmail.com> (raw)
In-Reply-To: <1267617205.5157.12.camel@hvost>
References: <cone.1267562557.293175.32557.1000@shelca>
	<4B8D7A6C.3010304@gmail.com>
	<dcc563d11003021334nc2e9505ued5d248562e70d1e@mail.gmail.com>
	<4B8E2EC1.2040100@gmail.com>
	<1267617205.5157.12.camel@hvost>

On Wed, Mar 3, 2010 at 4:53 AM, Hannu Krosing <hannu@krosing.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@gmail.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.



view thread (47+ messages)  latest in thread

Message-ID: <dcc563d11003031032l5541f1d0hdc327c2ba4ae9f29@mail.gmail.com>
Permalink:  ../dcc563d11003031032l5541f1d0hdc327c2ba4ae9f29@mail.gmail.com/
Also on:    postgresql.org/message-id/dcc563d11003031032l5541f1d0hdc327c2ba4ae9f29@mail.gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: scott.marlowe@gmail.com, hannu@krosing.net, yebhavinga@gmail.com, lists@stringsutils.com
  Subject: Re: 10K vs 15k rpm for analytics
  In-Reply-To: <dcc563d11003031032l5541f1d0hdc327c2ba4ae9f29@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox