From: Stephen Frost <sfrost@snowman.net>
To: John Vincent <pgsql-performance@lusis.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: SAN performance mystery
Date: Mon, 19 Jun 2006 11:04:25 -0400
Message-ID: <20060619150425.GS8588@kenobi.snowman.net> (raw)
In-Reply-To: <c841561b0606190559o386b89c6we7da959c4a586d14@mail.gmail.com>
References: <4491D61B.9040507@proximity.com.au>
<1150408614.26538.95.camel@state.g2switchworks.com>
<449677EB.50609@proximity.com.au>
<20060619124153.GQ8588@kenobi.snowman.net>
<c841561b0606190558r693b18c6rfbf2d688cf9d5d92@mail.gmail.com>
<c841561b0606190559o386b89c6we7da959c4a586d14@mail.gmail.com>
* John Vincent (pgsql-performance@lusis.org) wrote:
> >> I'd have to agree with you about the specific SAN/setup you're working
> >> with there. I certainly disagree that it's a general property of SAN's
> >> though. We've got a DS4300 with FC controllers and drives, hosts are
> >> generally dual-controller load-balanced and it works quite decently.
> >>
> >How are you guys doing the load balancing? IIRC, the RDAC driver only does
> >failover. Or are you using the OS level multipathing instead? While we were
> >on the 4300 for our AIX boxes, we just created two big RAID5 LUNs and
> >assigned one to each controller. With 2 HBAs and LVM stripping that was
> >about the best we could get in terms of load balancing.
We're using the OS-level multipathing. I tend to prefer using things
like multipath over specific-driver options. I havn't spent a huge
amount of effort profiling the SAN, honestly, but it's definitely faster
than the direct-attached hardware-RAID5 SCSI system we used to use (from
nStor), though that could have been because they were smaller, slower,
regular SCSI disks (not FC).
A simple bonnie++ run on one of the systems on the SAN gave me this:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
vardamir 32200M 40205 15 22399 5 102572 10 288.4 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 2802 99 +++++ +++ +++++ +++ 2600 99 +++++ +++ 10205 100
So, 40MB/s out, 102MB/s in, or so. This was on an ext3 filesystem.
Underneath that array it's a 3-disk RAID5 of 300GB 10k RPM FC disks.
We also have a snapshot on that array, but it was disabled at the time.
> >Indeed, the EMC SANs are generally the high-priced ones too, so not
> >> really sure what to tell you about the poor performance you're seeing
> >> out of it. Your IT folks and/or your EMC rep. should be able to resolve
> >> that, really...
> >
> >
> >The only exception I've heard to this is the Clarion AX150. We looked at
> >one and we were warned off of it by some EMC gearheads.
Yeah, the Clarion is the EMC "cheap" line, and I think the AX150 was the
extra-cheap one which Dell rebranded and sold.
Thanks,
Stephen
Attachments:
signature.asc (application/pgp-signature, 188B) download
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: sfrost@snowman.net, pgsql-performance@lusis.org
Subject: Re: SAN performance mystery
In-Reply-To: <20060619150425.GS8588@kenobi.snowman.net>
* 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