leif3
1 Copper

TDEV vs META when size is less then 240GB

Jump to solution

I am looking for optimal performance out of our VMAX arrays when using thin provisioning.  We are trying to decide when creating larger lun sizes for any typical host/OS with a greater size then 100gb to use metas or single tdevs when size is less then 240GB.  In this example we will use Linux and the lun size is 204gb as their requirement.  Should we provide them single TDEVs at 204gb or Create a META consisting of 4 x 51gb TDEVS.  Please explain why one way may be better then the other and if there are any white papers to go with your findings would also be helpful.

Labels (1)
0 Kudos
1 Solution

Accepted Solutions
Quincy561
4 Tellurium

Re: TDEV vs META when size is less then 240GB

Jump to solution

https://community.emc.com/message/652057#652057

Some performance results from an Exchange test here.

0 Kudos
7 Replies
Quincy561
4 Tellurium

Re: TDEV vs META when size is less then 240GB

Jump to solution

If your LUN needs to do 100s of IOs/sec or 10s of MBs/sec then you probably do not need a meta for performance.

If your LUN needs to do 1,000s of IOs/sec or 100s of MBs/sec then you probably do need a striped meta for performance.

You can also create a striped logical volume on the host from multiple Symm volumes which does the same thing (gets more Symm volumes active)

Highlighted
leif3
1 Copper

Re: TDEV vs META when size is less then 240GB

Jump to solution

In this example lets also assume that LUN addressing has limitations so providing many smaller devices to the host is not an option. The application is looking to generate at peak levels 15k IOPS. I am just trying to understand is the overhead of a meta but having more available cache better then simply creating a single TDEV. Is there any supporting documentation by EMC that can give device characteristecs of a 200gb TDEV vs a 4 x 50gb (META) or even a 8 x 25gb (META). Everyone that I have spoken to EMC to date states that creating a single TDEV of that size is sufficient.. however I would like to see something in writing and that has been tested out.

0 Kudos
SamClaret
2 Iron

Re: TDEV vs META when size is less then 240GB

Jump to solution

For ‘normal’ levels of IO you won’t see much performance gain with stripped TDEVS. However under heavy IO stripped metas will give you a marginal performance boost.

Sam Claret TSE3

Global Technical Support – SSG Windows

EMC Corporation

Hours: 7:00 AM - 4:00 PM GMT Rotating Shift

Phone: 800-782-4362 ext 6461204

For a complete local country dial list [click here<http://www.emc.com/collateral/contact-us/h4165-csc-phonelist-ho.pdf>]

Email: sam.claret@emc.com

Quincy561
4 Tellurium

Re: TDEV vs META when size is less then 240GB

Jump to solution

It has nothing to do with the amount of cache, the meta and the non meta would have the same amount of cache available (with one exception of the max WP per logical)

I could send some examples of testing offline if you like.

0 Kudos
Quincy561
4 Tellurium

Re: TDEV vs META when size is less then 240GB

Jump to solution

https://community.emc.com/message/652057#652057

Some performance results from an Exchange test here.

0 Kudos
leif3
1 Copper

Re: TDEV vs META when size is less then 240GB

Jump to solution

Now that was very helpful Quincy! I am going to try creating the same test using a 200gb tdev, (4x50), and (8x25) meta on a Linux and Solaris host. If I can get any good results I will post them here. I must of misread somewhere that more cache per meta member becomes available.. Do you know the actual amount of WP that becomes available for each additional member or percentage?

0 Kudos
Quincy561
4 Tellurium

Re: TDEV vs META when size is less then 240GB

Jump to solution

Each Symmetrix device can consume 5% of writable cache.  That means that 20 volumes can consume all of writable cache.

In most cases this does not make any performance difference.  There are a few corner cases where a write burst could be absorbed by say 4 volumes, but not by one.

For read cache there is no difference.  1 volume can consume all of cache for reads.  Also as long as you are not close to WP limits, the write performance does not change because of the maximum cache that can be consumed, it changes because of the amount of concurrency possible to the host LUN.