Date: Mon, 19 Jun 2006 11:04:25 -0400
From: Stephen Frost <sfrost@snowman.net>
To: John Vincent <pgsql-performance@lusis.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: SAN performance mystery
Message-ID: <20060619150425.GS8588@kenobi.snowman.net>
Mail-Followup-To: John Vincent <pgsql-performance@lusis.org>,
	pgsql-performance@postgresql.org
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="DgpHF3aoTWw+12pn"
Content-Disposition: inline
In-Reply-To: <c841561b0606190559o386b89c6we7da959c4a586d14@mail.gmail.com>
User-Agent: Mutt/1.5.11+cvs20060403


--DgpHF3aoTWw+12pn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

* 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

--DgpHF3aoTWw+12pn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFElrz5rzgMPqB3kigRAgtjAJ9ILzAoMVaXLbm2sA4aYb0Ll1AVOwCfSybk
kyVSHnI4dS4zC9yUWRv/Po4=
=Nf+A
-----END PGP SIGNATURE-----

--DgpHF3aoTWw+12pn--