Skip site navigation (1) Skip section navigation (2)

Re: Hardware: HP StorageWorks MSA 1500

From: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
To: Mikael Carneholm <Mikael(dot)Carneholm(at)WirelessCar(dot)com>
Cc: Alex Hayward <xelah-pgsql(at)xelah(dot)com>, Pgsql performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Hardware: HP StorageWorks MSA 1500
Date: 2006-04-24 23:57:34
Message-ID: 444D65EE.6040605@paradise.net.nz (view raw or flat)
Thread:
Lists: pgsql-performance
Mikael Carneholm wrote:

> 
>> There are two SCSI U320 buses, with seven bays on each. I don't know
> what the overhead of SCSI is, but you're obviously not going to get >
> 490MB/s for each set of seven even if the FC could do it.
> 

You should be able to get close to 300Mb/s on each SCSI bus - provided 
the PCI bus on the motherboard is 64-bit and runs at 133Mhz or better 
(64-bit and 66Mhz give you a 524Mb/s limit).

> 
>> Of course your database may not spend all day doing sequential scans
> one at a time over 14 disks, so it doesn't necessarily matter...
> 

Yeah, it depends on the intended workload, but at some point most 
databases end up IO bound... so you really want to ensure the IO system 
is as capable as possible IMHO.

> 
> That's probably true, but *knowing* that the max seq scan speed is that
> high gives you some confidence (true or fake) that the hardware will be
> sufficient the next 2 years or so. So, if dual 2GBit FC:s still don't
> deliver more than 200Mb/s, what does?
> 

Most modern PCI-X or PCIe RAID cards will do better than 200Mb/s (e.g. 
3Ware 9550SX will do ~800Mb/s).

By way of comparison my old PIII with a Promise TX4000 plus 4 IDE drives 
will do 215Mb/s...so being throttled to 200Mb/s on modern hardware seems 
unwise to me.

Cheers

Mark

In response to

Responses

pgsql-performance by date

Next:From: Richard HuxtonDate: 2006-04-25 09:40:08
Subject: Re: security for row level but not based on Database user's
Previous:From: Steve AtkinsDate: 2006-04-24 23:40:16
Subject: Re: ip address data type

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group