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.

The front end and back end CPUs are seperate.

Yes it is 5876.  Are there any issues that came up around this?

Is this 5876 by any chance?

Thanks for sharing that info Quiincy.  I'll keep an eye out for that release.  Do you think that release will be listed in the EMC Technical Advisory notification? 

I'm not worried about the CPU utilization today but if it gets any higher i'll probably have to trim back the relocation rate as a starting point. 

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.