DMX-4 Large meta-lun performance

Dave,

Are you running 5773? If not, that should be your first step. 5773 introduced a front-end aware prefetch that knows what a meta volume is. Previous releases of Enginuity did not have meta aware prefetch.

I would suggest making logical volumes that will satisfy your host volume size with 4 or 8 meta members if possible. Fewer members, and fewer logicals in the box generally gives better overall performance.

Quincy,
when you say logicals I assume you are referring to the hypers?

So can I use ECC to change some of the 8gb hypers to larger sizes?


Alok Jain,
Host based lvm had crossed my mind but i would like to keep it simplier. Which LVM software do you use at the host level?

Looks like you have SQL Server. In which case, just use the Windows Disk Manager to create striped volumes with smaller striped Metas presented to the host. I have seen very good performance with using striped metas and then striping at the host level. It spread the load to many spindles in the back-end. Also make sure you are properly aligning the cylinder boundaries at the host by starting the partition at 64k boundary. I would still like to understand the metric used to determine spindle bottleneck? - Alok

Dave,

Are these striped meta LUNs? One thing to keep in mind is that more LUNs at the host level (as opposed to 1 large meta LUN) provide higher number of LUN queues that improve the performance. So presenting higher number of LUNs to host and then using a volume manager to stripe at the host level will provide better performance (at least in my experience)

BTW, what is the measurement (which metric and at host or at the array) that is showing disk contention?

Hi Quincy,
Yes I am running 5773.

the problem with using less members is the fact that our physical database is a specific size that needs to be minimum

DMX4 supports logical volumes of up to about a 60GB. With a logical volume that size, you would need about 8 members to get your required 500GB.

yeah i am running a sql server.

What you suggest would work for me, however I am reluctant to leave my data integrity up to windows.

Yes we are using 64k alignment.

The best approach for me I think is to change some of the unmapped 8gb hypers into 16 or 24gb hypers

I have run exchange servers with 30K users with SRDF on using windows striping on DMX2/3. No issues observed in last 3-4 years that I know of.
If single LUN at the host is the bottleneck, then having bigger hypers will not help. Check to make sure you are not hitting any target LUN queue depths because of single LUN. For databases it is advisable to have multiple LUNs to separate out the data/logs/indexs etc. You can try it out.

Your design obviously works well for you, however I am just saying even srdf does not protect against windows corrupting the striped luns

We are using seperate luns, logs,data and backup. The speed problem is because the dba's refuse to archive/split/reduce the size of databases, gradually larger and larger luns are required.

We have got to the point were the large luns are performing 5 times worse than the smaller luns attached to the same server. We know this from our benchmarking, but you guys have seen the same thing.

Increasing the hyper size sounds like it might be the workaround we need.

Quincy56, I always check (symdev show) to see what the physical underlying spindels are and I make sure I'm not including a single spindel in the same META twice. In the Symm Performance Workshop my instructor Desirée T. agreed with this aproach and so far I haven't seen performance issues. I have RAID5 META's as large as 32 members, where the 32 members each consist of 4 spindels (3RAID5, so 4 spindels per symdev) and 32 x 4 = 128 spindels, which (coincidence ?) is exactly the range of spindels I'm creating symdevs on So each member of this large META is on it's own set of 4 spindels and all 32 members of this META are on individual spindels.

I'm using my backend as good as possible, I think.

When I say logical, I mean a Symmetrix device (not meta volume). To me a hyper is a slice of a physical disk. So a RAID5 3+1 logical volume consists of 4 hypers on 4 different disks. A RAID1 logical volume has two hypers. A RAID5 7+1 volume has 8 hypers. So a 16 way RAID5 7+1 meta volume should touch 128 disks.

Wrapping on disks with meta volumes is generally not a good idea. It can create unnecessary head seeks.

Larger numbers of meta members in meta volumes does not cause problems by itself, but it can be difficult to get enough IOs queued to such a device to keep it busy. Also fewer, larger hypers and logical volumes create better overall system performance.

A hyper to me is exactly the same. In the ILT's I had they explained it to me the same way: a slice or hyper is 1 slice of 1 physical disk, so a 3RAID5 are 4 hypers. I get annoyed when people call a symdev a hyper, or - for that matter - call a storage array a SAN. C'mon !
But indeed: a 16 way 7RAID5 = 16 x 8 = 128 disks and a 32 way 3RAID5 = 32 x 4 = 128 disks as well. And if these 128 disks are unique disks, there's no wrapping.

I also agree with you on the larger symdevs, but perhaps on another level: if I/O is sequential and your META has a limited number of members, the chance of getting true sequential I/O per member is higher than when you'd have a large number of members per META, since chances are higher that an alien I/O (of another host) gets inbetween your I/O's and the sequence is broken..... If you catch my drift

Thanks for all the responses everyone.

After having this discussion I have decided it will be best if we change a section of unmapped logical symdev's from 8gb to 24gb or 32gb logicals.

How would I go about this.

The unmapped dev's are all linear, and I plan on using the last half of the remaining unmapped 8gb logicals.
Obviously I will have to use the "delete logical device". However I am not sure the best practise for creating them via ecc or solutions enabler.

I guess we'll soon post a new Message in Symmetrix and Symcli forums on delete/create of symdevs.
Don't hold your breath but keep an eye at messages