Updated: September 22nd 2015
Although it has been a while since I’ve written this article there’s still a lot of interest in the subject. Pretty much nothing has changed since I released it so it’s was also still valid, until yesterday. Community hero Andrew Morgan released a long awaited update for ThreadLocker. I’ve updated the Threadlocker part of this article and the conclusion.
If you are reading this you might also be interested in part 2 of the CPU scheduling and memory optimization solutions series.
For a while now customers and colleagues are asking me which tool to use when it comes to CPU scheduling and memory optimizations. We use several management products and end up with more than one product utilizing these tasks. Choice is good but do we just enable them all and if not what’s the best way to configure this?
When you look a little bit deeper then plain and simple marketing you’ll notice that the way the different products handle CPU scheduling is totally different and combining some of them will degrade system performance or simply don’t work for example Citrix CPU management does not start when Microsoft DFSS is enabled.
Before we start I’d like to thank Andrew Morgan for allowing me to re-use some information from his ThreadLocker topic.
To start off I will first try to explain how each product works and will then summarize and see if we can work through them and work to a proper advice.
Microsoft Windows 2008 R2 Dynamic Fair Share Scheduling (DFSS)
Fair Share CPU Scheduling is included in RDS since Windows Server 2008 R2. Fair Share CPU Scheduling dynamically distributes processor time across sessions based on the number of active sessions and load on those sessions by using the kernel-level scheduling mechanism included with Windows Server 2008 R2. On an RDS server, one user will not affect the performance of another user’s session, even if the RD Session Host server is under a high load. Enabled by default so no configuration needed.
DFSS works based on a filter driver which means that it will react instantly when a process is launched. Remember this when we get to the conclusion.
The downside of using DFSS is that each and every user is bound to the same default policy, so if you want certain users to be able to utilize more resources you can’t by default. To do this you need Windows System Resource Manager (Depreciated in Windows Server 2012) to be able to create profiles and attach those to AD groups. Although this is a free product and does the basic trick of configuring DFSS policies based on user groups it’s a lot of work to configure this on more than one system and requires Windows Internal Database.
Citrix CPU Utilization Management Only available with Citrix XenApp Enterprise and Platinum The Dynamic Fair Share Scheduling (DFSS) solution is incompatible with CPU utilization management.
The CPU utilization management feature can be used to improve the ability of a farm to manage resources and normalize CPU peaks when the farm’s performance becomes limited by CPU-intensive operations. When you enable CPU utilization management, the server manages the share of the CPU allocated to each user. By default, this is an equal share. This prevents one user from impacting the productivity of other users and allows more users to connect to a server. This feature allows you to control the share.
Fair sharing of CPU between sessions to allocate an equal share of the CPU to each user.
Preferential Load Balancing to allocate shares based on importance levels.
Citrix acts based on process spikes and process priority so although this might work well is means that it will start acting after a certain period of CPU usage. Remember this when we get to the conclusion.
The CPU utilization management feature ensures that CPU resources are equitably shared among users by having the server allocate an equal share of the CPU to each user.
RES One Workspace CPU Scheduling
CPU Optimization actively lowers the priority of processes with a sustained high CPU usage. This keeps the process running, but with a low priority so that other applications in the system are not affected anymore. When the process returns to a more acceptable level of CPU usage, its priority is changed back to the original level.
The configured thresholds are based on a single CPU/Core/vCPU this means that when the threshold is set to 90% on a dual CPU system the process will be noticed when it uses more than 45% of total CPU.
Although this does some kind of a trick it’s always reactive and you will still see issues caused by CPU spikes because it will only act after a configured time of usage.
ThreadLocker 2.0 by Andy Morgan
ThreadLocker 2.0 is a completely different product compared to 1.0 but what hasn’t changed is the purpose for why it’s build. Threadlocker has been completely rewritten in C++ instead of .Net and this is important because it gives us a more direct response without causing the tool itself to slow down the system.
Instead of what the other solutions are doing, by prioritizing rogue processes, Threadlocker assigns processes to a pre defined subset of CPU resources for rogue processes. By doing this it’s impossible for a rogue process to have an impact on a more well mannered processes. This will all only happen when a rogue process is consuming a high amount of CPU.
The brilliance in my opinion is that Threadlocker isn’t slowing down a rogue process, it’s just making sure it has no impact on other processes. When there are enough resources available the process will run just as fast.
This product does not replace or compete with any of the other products which will monitor all processes and when issues occur act accordingly.
Although this is still valid for Threadlocker 2.0, the need for other solutions has been taken away almost completely.
Unfortunately there is no one answer to the question “What should I use?” all of the products work in a different way and most likely will give different results in different situations depending on the type of process and the type of load it generates. For this conclusion my assumption is that all products are licensed for all CPU features mentioned in this article.
The first choice to make is between the Citrix and Microsoft solution as they are not compatible. Looking at both solutions a big difference I see is manageability of different load profiles which is implemented better at Citrix. If you don’t need it use Microsoft DFSS and if you do use the Citrix solution.
You might think that you are on the good side if you just go with Citrix each and every time, remember what I said about DFSS being filter driver based? In the end this will give you the best results so if you don’t need the extra management, use DFSS.
If we go ahead and take a look at RES CPU Management, would I use it INSTEAD of DFSS or Citrix CPU Management? No, the RES solution focusses on a single process, instead of a session, using more than a configured amount of CPU time and changes the priority for that process. This happens even when there are more than enough resources left.
RES Software hasn’t done any development on the CPU management functionality for years and it’s still a single CPU/threaded solution. Looking at the new functionality released with Threadlocker 2.0 this truly is a no brainer.
What about VDI
Do we need process monitoring on a VDI desktop? My first response would be “No of course not we don’t share anything”. When you think a bit more about this (Thanks Andy) that’s not entirely true because we are sharing the hypervisor, the better we handle resources the more sessions I get on a hypervisor machine.
Do you need it? It depends on applications and use case but if you do continue reading.
The question which product to use is easier for VDI because Microsoft DFSS and Citrix CPU Management are pure RDS solutions, so we are back to RES CPU Management vs ThreadLocker 2.0 and the same conclusion applies as stated before.