HP MSA 2050 intermittent problem

[ghaffar3]

We are having an intermittent problem with our MSA 2050 storage. We are using this storage in a broadcast facility where we record/copy media files onto this storage and use it as a playback (streams files/media) directly from the storage using a playout tool.

We are facing an issue here, when the data copy (media copied to storage, write) goes high we start seeing issues on the playback. Our playout tool vendor came back to us with the following points:

"There are no direct, obvious MSA logs or graphs for this condition, so further investigation and monitoring were needed to identify the underlying problem.
The stripe method has been changed in the New MSA; formerly, the MSA used a linear-stripe mechanism, which is now disabled from the MSA side and only permits a virtual-strip mechanism. Virtual-strip technology by itself wouldn't be problematic, but like with MSA, linear-strip block sizes on disk may range from 256K to 512K. The largest block size currently supported by the MSA is 64K.
For the aforementioned reason, a purge-on-the-fly operation is initiated automatically when the MSA have utilized 100% of (storage/LUN) for the first time. Since this process performs 4x–8x more transactions for the exact same I/O, it consumes progressively more CPU/ASIC resources."

1. I need someone help me understand. How going from 256/512k to 64K can decrease performance. 
2. Whats the purge on the fly operation? Is this part of the MSA behaviour. If yes, how it works and how does it effect CPU cycles.
3. How to get the CPU cycles history as graphs. Under the Performace - History, i can't see CPU. How do i get the CPU graphs.

Thank you very much for your help

P.S. Firmware for the storage controller is VL270P005

[support_s]

System recommended content:

1. HPE MSA 2050 User Guide

2. HPE MSA 2050 SAN Storage - Operations

Please click on "Thumbs Up/Kudo" icon to give a "Kudo".

Thank you for being a HPE valuable community member.

[ghaffar3]

Ive been through these documents, but it doesn't answer some of my questions, like how to get the CPU history in the form of graphs

[JonPaul]

@ghaffar3 
Performance issues are tricky, they usually end up being related to the configuration.  In your case, the tool vendor has looked at the chunk-size on the MSA which is being reported as 64k.  The chunk-size is how much data is on one disk before the RAID engine puts data on the next disk.  Aligning this to your workload, I/O pattern, can be benficial.  When working with media files, audio or video, the files tend to be large in size and using a larger chunk-size will often increase performance.  This may be part of the problem but the MSA virtual storage also aggregates data into 4MB pages which can have a big impact on performance.
The fact that the chunk-size is stating 64k points to the system is not using a 'Power of 2' number of data drives.  When the disk-group is using a 'Power of 2' disks the chunk-size will be 512k, as this aligns on one or multiple stripes to the 4MB page size.  When the disk-group is not using 'Power of 2' the system uses a 64k chunk-size to utilize as many stripes as possible to increase performance.  In most workloads this ends up with similar performance.  In most workloads, ....  one workload that does not have similar performance is a sequential WRITE workload.  Due to stripes being mis-aligned with the page size,  there is ALWAYs a READ-MODIFY-WRITE cycle when a new page is written.  These can induce significant performance drops in sequential WRITE.
Unfortunately, there are no quick fixes for changing to a Po2 number of data drives.  An option would be to engage HPE support about the performance problem and review the details of your configuration and possible options.
For more information on how the virtual storage works and best practices please see the Virtual Storage Technical brief:  https://www.hpe.com/psnow/doc/a00087404enw