X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 1F34411F66E7 for ; Thu, 27 Apr 2006 23:31:07 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 51727-07 for ; Thu, 27 Apr 2006 23:30:55 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from linda-1.paradise.net.nz (bm-1a.paradise.net.nz [203.96.152.180]) by postgresql.org (Postfix) with ESMTP id 9916611F61F0 for ; Thu, 27 Apr 2006 23:30:53 -0300 (ADT) Received: from smtp-3.paradise.net.nz (tclsnelb1-src-1.paradise.net.nz [203.96.152.172]) by linda-1.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IYE003QQUZ8IK@linda-1.paradise.net.nz> for pgsql-performance@postgresql.org; Fri, 28 Apr 2006 14:30:44 +1200 (NZST) Received: from [192.168.1.11] (218-101-29-28.dsl.clear.net.nz [218.101.29.28]) by smtp-3.paradise.net.nz (Postfix) with ESMTP id AC4F1E342E9; Fri, 28 Apr 2006 14:30:43 +1200 (NZST) Date: Fri, 28 Apr 2006 14:30:36 +1200 From: Mark Kirkwood Subject: Re: Hardware: HP StorageWorks MSA 1500 In-reply-to: To: Alex Hayward Cc: Pgsql performance Message-id: <44517E4C.3090809@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit User-Agent: Thunderbird 1.5 (X11/20060417) References: <7F10D26ECFA1FB458B89C5B4B0D72C2B3E40AA@sesrv12.wirelesscar.com> <444D65EE.6040605@paradise.net.nz> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200604/657 X-Sequence-Number: 18741 Alex Hayward wrote: > > IO bound doesn't imply IO bandwidth bound. 14 disks doing a 1ms seek > followed by an 8k read over and over again is a bit over 100MB/s. Adding > in write activity would make a difference, too, since it'd have to go to > at least two disks. There are presumably hot spares, too. > Very true - if your workload is primarily random, ~100Mb/s may be enough bandwidth. > I still wouldn't really want to be limited to 200MB/s if I expected to use > a full set of 14 disks for active database data where utmost performance > really matters and where there may be some sequential scans going on, > though. > Yeah - thats the rub, Data mining, bulk loads, batch updates, backups (restores....) often use significant bandwidth. > Though, of course, these won't do many of the things you can do with a SAN > - like connect several computers, or split a single array in to two pieces > and have two computers access them as if they were separate drives, or > remotely shut down one database machine and then start up another using > the same disks and data. The number of IO operations per second they can > do is likely to be important, too...possibly more important. > SAN flexibility is nice (when it works as advertised), the cost and performance however, are the main detractors. On that note I don't recall IO/s being anything special on most SAN gear I've seen (this could have changed for later products I guess). > There's 4GB FC, and so presumably 4GB SANs, but that's still not vast > bandwidth. Using multiple FC ports is the other obvious way to do it with > a SAN. I haven't looked, but I suspect you'll need quite a budget to get > that... > Yes - the last place I worked were looking at doing this ('multiple attachment' was the buzz word I think) - I recall it needed special (read extra expensive) switches and particular cards... Cheers Mark