Single large LUN or multiple smaller ones

by **rodak** » Sun, 13 Feb 2011 05:14:23 GMT

I have a Power7 model 770, connected to EMC DMX/Symmetrix SAN via 8GB
FC (using NPIV) to 2GB SAN fabric.

From an AIX performance standpoint, is there any advantage to creating
a volume group from several smaller LUNs versus a single large LUN?
We're talking about less than 1TB, total.  This is for Oracle 10g, if
that makes a difference (and my DBA has already said he wants standard
filesystems - he doesn't want to hassle with using raw logical disks).

by **Johnny Rebel** » Sun, 13 Feb 2011 06:01:24 GMT



I guess it depends on how the back end is configured.  A DMX I connect
to uses metaluns to put LUNs together in the Invista layer.  Testing for
me showed striping, mirroring etc.. anything on the AIX side greatly
reduced performance.  We moved from a striped VG, to a concatenated
(invista concatenation and then just built the vg using the LUNs with
nothing fancy) one.  The difference for me is invista, and/or how the
SAN storage is configured.  Ideally for Oracle of course (mine has
Oracle on it) you want R10 - wherever it may be.

Best bet if you are able is to test out various configurations with
iozone (this is how I found a SAN R10 bucket misconfiguration on the SAN
side... ).  I took a few days to do this and map it out, and it paid off.

 http://www.**--****.com/ 


	S.

-- 


--> GNU/Linux is user friendly... it's just picky about its friends.

by **Hank M. Higher** » Sun, 13 Feb 2011 15:59:51 GMT




raw disks are not recommended anymore by oracle, but are considered a
"historical anomaly" now.
BUT oracle ASM (automatic storage management) provides both filesystem
and volume manager functions taylored to the DBMSs needs (includes
striping with different strip sizes for different file categories as
well as the ability to configure preferred mirror copies for reading).
things you cannot do with jfs2 nor gpfs. If you're serious about oracle
performance, look at ASM. the DBA will need to brush up his skills
eventually.

H.

by **Uwe Auer** » Thu, 17 Feb 2011 03:47:03 GMT

Am 11.02.2011 21:14, schrieb rodak:

Hi,

still true: Use more smaller than few large disks and proper LV settings 
(maximum inter policy). Don't believe arguments telling "In nowadays SAN world 
LUN size doesn't matter". Bad experience, poor performance.
In your example of a 1 TB database I would accept 128 GB disks but our choice 
would be 64 GB disks.

Regards,
Uwe

by **Johnny Rebel** » Thu, 17 Feb 2011 11:08:57 GMT



While I would agree with you in most cases, I would argue against with
EMC invista - the testing I did showed using the tried and true way
(many smaller disks...) gave us a pretty {*filter*} hit on performance.
Using concatenated meta luns was far superior.  Old Shark on the other
hand, we were doing 35G luns (and lots of them). :)

	JR.

-- 


--> GNU/Linux is user friendly... it's just picky about its friends.

by **niella** » Fri, 11 Mar 2011 05:01:07 GMT



Absolutely. Using LUNS that are too large (or that are configured with
a too small queue depth settings) will result in queuing at the
logical disk level - you will observe non-zero values for sqfull in
the output of iostat -aD. For maximum performance, you should be using
scalable volume groups with smaller sized LUNS, say 64 - 128GB in
size.

Niel

Single large LUN or multiple smaller ones

Single large LUN or multiple smaller ones

Jump to:

Next

Single large LUN or multiple smaller ones

Re: Single large LUN or multiple smaller ones

Re: Single large LUN or multiple smaller ones

Re: Single large LUN or multiple smaller ones

Re: Single large LUN or multiple smaller ones

Re: Single large LUN or multiple smaller ones

Who is online