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: (view raw, whole thread or download thread mbox)
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/ being throttled to 200Mb/s on modern hardware seems 
unwise to me.



In response to


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-2017 The PostgreSQL Global Development Group