Its shown as 383256 so we are well under.
Now, I can see Host Miss/sec as about approx 200 is this acceptable ??
Most of these misses are Sequential Read misses ... how can i improve the Read Misses ??
Its a concat meta of 1.90TB used for vmdk.
What is the overall read rate? 200 may be a very small percentage.
Why concat? Do you need to expand regularly? Striped does have a performance advantage, while concat has an expansion advantage.
Well with Thin LUNs they are spread over the all the disks in the group any way with 7680KB chunks. So will strip make any difference??
Yes, that seems to make logical sense, but even for 100% cached operations a striped meta on thin can have up to 2 times the performance of a concat meta.
A single Symm volume has structures that limit the concurrency on one device on a FA CPU. With multiple devices active on a LUN (striped meta) we can get more work done.
Are you saying , that concat meta is only addressed with meta head and 1 device is used completely till it fills up and other will wait.
In case of striped, all the members will be used from start and IO will be queued for all the DA of that meta members etc.??? In this case how exactly will the writes go for a thin striped meta considering it also has extent level stripes.
Say we have a 1TB concat meta made from four 240GB Symm volumes. If you place a database on it, the likelihood of all 4 Symm volumes being equally active at any point in time is slim to none. Almost all volumes have a locality of reference, and it is very likely that the active data will not span all 1TB of address space.
A striped meta will switch volumes every 960k, so even if only 10MB of data is very active on the meta volume, all 4 members will contribute to the activity.
The performance difference between concat and striped in a VP (thin) environment has nothing to do with the backend or how it is laid out over the disk, only on the FA.
Hope that is clearer.