Good evening

Back in the day, there was a best practice in place which stated that more than five mdiskgrps in a given SVC cluster led to excessive cache partitioning and therefore, performance degradation. That number was raised to seven on DH8 or SV1 hardware. ¿does that BP still stand on SV2 and SV3 hardware? in case it does... ¿same limit?

Thanks and best regards.

------------------------------
Sergio Pardos
------------------------------

Hi Sergio, I hope you have found an answer in the meantime, but just to give my thoughts, I can not remember any specific documented best practice for SV2 and SV3 hardware regarding the exact number of mdiskgrps. As I am not a subject specialist I can only indicate the obvious in that performance considerations can be influenced by various factors, like workload types, system configuration, and specific use cases. In this case if you have not done that yet, I would surely reach out to IBM Support directly to obtain their specialist view on the subject.
Sorry I can not be of more help, but I hope the issue was answer somehow in the meantime.

Regards,
Mark

Thanks Mark

Hi Sergio,

In V8.5.0.x Configuration Limits and Restrictions for IBM System Storage SAN Volume Controller we can see that 1024 mdiskgrps is the maximum for SVC Code 8.5, however there is or was a table which shows how the cache is partioned if you have several pools. Newer Nodes have more Cache, but the Write Cache is still limited. I have SVC Clusters running fine with 10 and more Pools (Parents) on SV2 and SV3 Nodes. You schould consider IBM Storage Virtualize guideline values for key performance indicators - IBM Documentation for other performance indicators on your machines. Maybe not the answer expected, i hope that helps anyway.

Best regards,

Thanks Maik

Hej Sergio, don't know if it is still relevant but will try to give an answer anyhow.

There wasn't a limitation to the pools itself to the given number 5 or 7 (as it is 1024 as Maik already said) but there was/is a cache partitioning to avoid a full cache situation, if there are any slow draining arrays in the pool (like NL-SAS or such) using all the cache. This partitioning is/was not symmetric in a case that 2 pools may use 50% and 4 may use 25% by pool. Therefore if you have a large amount of pools with slow backend, still all slow pools could remove cache from others, and therefore affect them in caching and performance.

But I believe if this is still available in the code then it get irrelevant for "normal" installations, since the cache grew up and also the speed of the backend storage increased (are there still many NL-SAS behind SVCs?). Other improvements to the cache workflow also removed the urgency to this behavior.

Hope this helps.

Thanks Björn.