How many meta sizes do you have in a VMAX thin environment?

So after posting, I ran some tests.  A 2 way meta shows 11% less IOPS on a SQLish IOmeter test than an 8 way of the same size and pool.

Just thought anyone reading this thread might want to know those results.

Kiranghag:

This must be the EMC company line.  I have been told the same.  My test results completely refute this. 

I'm sure EMC will say "it depends", and really it does.  But on a pure performance driven write heavy workload with multiple threads, the concurrency I get from striped helps quite a bit.  I doubt most people would ever run up against this limit, but there is a per device WP limit, which means you can run out of cache faster writing to a concurrent meta.  Read cache should be the same regardless. 

HTH,

Brandon

may be little out of topic, but i have been told that striped metas are no longer necessary for higher performance in vmax thin pools. concatenation provides necessary performance.

have you seen this behaviour?

Symmetrix engineering actually recommends Striped in most cases for Virtual Provisioning for a couple reasons one which Brandon mentioned. The technical note for Symmetrix VP notes this and can be found on Powerlink:

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/Technical_Documentation/300-006-718.pdhttp://powerlink.emc.com/km/live1/en_US/Offering_Technical/Technical_Documentation/300-006-718.pdf

Here is the relevant excerpt though:

In most cases, EMC recommends using striped rather than concatenated metadevices with Virtual Provisioning because they offer the following advantages:

1. With Synchronous SRDF®, Enginuity allows one outstanding write per thin device per path. With concatenated metadevices, this could cause a performance problem by limiting the concurrency of writes. This limit will not affect striped metadevices in the same way, however, due to the small size of the metavolume stripe (1 cylinderor 1920 blocks).
2. In Enginuity releases prior to 5875, the code allows eight read requests per path per thin device. This may limit the number of read requests that can be passed through to the thin pool regardless of the number of data devices it contains. This can cause slower performance in environments with a high read miss rate. A striped metadevice offers improved throughput, because each metamember is allowed to queue requests to the back end in parallel. Even with the limit removed in Enginuity 5875, there are still potential performance benefits to using striped thin metas instead of concatenated thin metas.
3. The Symmetrix Enginuity operating environment has a logical volume write pending limit to prevent one volume from monopolizing writeable cache. Because each metamember gets a small percentage of cache, a striped meta is likely to receive more writeable cache for the metavolume.

The "it depends" answer is usually right.  A striped meta will provide better performance than a concatenated however a concatenated is easier to expand.  Its also application dependent a striped meta can perform better but it doesn't mean that you will always see that.

I usually leave it at if performance is of greater concern stripe it, if being able to expand is a concern concatenate it.

The 2 member meta was the same size as the 8 member.  I didn't test a single member, but I would think it would have worse performance at the limits than the 2.  Again, these are IOMeter tests, and not really representative of a true workload.

So does it follow through that one large Tdev equal in size to the meta (8/2 member), both from same pool would have a worse performance than the thin meta ? (assuming dev size is not greater than 240GB)

A single TDEV device will have lower performance than a striped TDEV device.  The performance will improve as you add members with a plateau around 4 members, with 8 probably giving slightly more due to the standard distribution of IO.  Even with 100% cache operations (reads or writes).

When we implemented our first VMax about 2 years ago, the recommendation from EMC for meta devices was to just use concatenation for TDEVs since the thin pool itself is striped.

Since that time, EMC has discovered that striped metas can have performance advantages for high IOs because the IOs get to take advantage of the queue depths of all the devices.   In the EMC VMax performance class I took recently, the class instructor was still touting the old policy, but an EMC performance engineer in the class mentioned that he standard has changed.