Resource Governor – CPU Allocations Part 2

Microsoft in the News

Microsoft’s Cortana voice assistant has been a huge success among enterprises in North America and Europe. They can currently boast that 49% of enterprises in these regions use Cortana – not exclusively, but still.

Unfortunately, the story is very different in the consumer world. In that area, Cortana has struggled to compete with Alexa and Google Assistant and Siri and has so far only achieved 2% penetration of the global consumer market. It seems that the consumer market is the market that really counts and as a result, Microsoft is repositioning the role Cortana will play.

Instead of competing as a stand-alone assistant, Cortana will look to complement these other voice platforms. Microsoft has been pushing an open, cross-platform ecosystem where Cortana can assist instead of compete. In August of last year, Amazon joined with Microsoft to allow communication between Alexa and Cortana. Microsoft is pushing for a similar agreement with Xiamomi.

By allowing Alexa access to your Microsoft Office Suite, they are gaining access to Alexa that will allow Cortana to remain relevant, if only in the background.

Resource Governor – CPU Allocations, Continued

SQL Server Resource Governor allows you to split up your CPU resources in several ways. In my last blog we talked about allocating a percentage that is only enforced when sessions are competing. Here I will show you two more ways to allocate CPU resources.


There are scenarios where you would not want Accounting to periodically use more than 10% of the CPU resource. For example, some organizations allocate expenses to departments based on their use of resources. Accountants being accountants, they may want to restrict their expenses or at least have more predictable expenses. In this case, a hard limit on CPU resource allocation to Accounting can be done by applying this hard cap.


Using the AFFINITY command will allow you to differentiate resources according to NUMA nodes. This will isolate your CPU resources and allow you to dedicate 100% of a CPU core to a defined Group.

In our example, instead of Accounting taking up some of a CPU’s resources, that Group can be shunted to a completely different CPU core, leaving a CPU core 100% dedicated to the Production Group. With Accounting on a separate CPU core, the CAP or MAX percentage options can still be used to limit usage on that CPU.

By using the AFFINITY command, you are effectively running each group’s workload on two isolated virtual machines.

Another potential use for this is to map a TCP port to your Numa node and isolate the work load to that TCP port.  Details on how to do that use case can be found here:

In my next blog, I will talk about allocating memory.

Leave a Reply

Your email address will not be published. Required fields are marked *