Could anyone share what they use for performance thresholds on a VMAX running FAST VP? Throughout our POC and now in production i'm seeing the BE Directors with 45-75% busy % across the array. According to the definition this doesn't seem like it's neccessarily a bad thing
100 - %idle
This metric is available only for Fibre Channel directors.
Is this a measure of CPU? I thought the CPU's for front end and back end were shared in the matrix?
The % busy on the ports is under 5 during this time.
What is everyone else seeing on their array's running FAST VP?
Solved! Go to Solution.
In VMAX, the back-end and front-end have their own CPU. The % busy metric is a measure of CPU busy and applies to back-end processors as well as front-end.
That's what it seems like (Front-end having different CPU's than back-end) but I though the whole point of the matrix was sharing resources like CPU. In the heatmap for each director it has a different % busy for the front-end than the back-end. The front-end busy % stays pretty low but the back-end % busy stays in the 45-75% range. I'm not sure if this is normal due to FAST VP constantly working or if this is higher than it should be.
The Matrix is the point-to-point connections between the directors and global memory.
Alas what is 'normal' encompasses a wide spectrum and depends very much on workload and configuration (6 back-end IO's required for a RAID-6 write for example). Certainly FAST will add to processor utilisation at the back-end as it executes the extent moves between tiers.
I expect FAST has not been enabled long since it's a POC, but the initially after enabling FAST there may be quite a number of moves to be done. You may want to adjust the fast relocation rate and observe the difference in CPU utilisation on the back-end.
Thanks guys that clears things up a bit.
I do believe relocation rate could be the factor here. I'd like for data to get to the appropriate tier as fast as possible so we have this set at 3 now to be slightly more conservative than setting it to 1. I read the whitepaper that showed the impact of adjusting the relocation rate with response time and time till data is moved, but I didn't think about what impact it would have to the CPU's. If it gets much higher i'll likely have to back it off a little.
We're past POC but these are all new provisions so data is still moving around quite a bit between the tiers. I suspect with the type of I/O our servers do we'll have a higher volume of data moves than a typical implementation, but time will only tell as we continue to add and migrate servers over.
Keeping an eye on this I noticed the max values seem pretty high. Spikes as high as 85% busy on about half of the directors and the other directors have spikes in the 70's. Since FAST VP will only move a max ammount of data in every interval is it safe to say that FAST VP CPU utilization levels off?
We have about 10 hosts and 46 metaluns so far and will be migrating 70 additional hosts in the several weeks. IOPS for the entire array currently only averages from 2000-4000 and our array was sized for 90K IOPS before we went from R5 to R1 on the FC tier. I'd like to keep the relocation rate on the fast side but i'm not sure if the array will be able to handle it once we get more hosts consuming I/O. In general our server owners would rather a slight uptick in response and get the data on a higher tier faster.
In 5876 there was a change in the way FAST VP background tasks are scheduled allowing more DA CPU utilization than before. A release of 5876 due out soon will reduce the DA utilization back to similar utilization as 5875,
You could disable FAST VP for some time to see if the DA utilization goes down or not.