Throughout this blog post, I’m going to be talking about Process Affinity and Process Priority. Understanding these definitions will help. I’m also only targetting server 2008 R2 and Windows 7 for this post.
An issue I see time and time again in Virtual Desktop Infrastructure and Server Based Computing environments is CPU spikes cause sessions to pause and stick. These CPU spikes can be caused by overcommitment or overzealous application usage and the vendors (Citrix, ThreadMaster, RES, Appsense, etc) have come to the rescue frequently with tools to reduce these events from occurring.
The problem with these solutions (Appsense excluded) is they are reactive, I.E. they take a number of seconds to identify a spike and respond by dropping the priority of the process or reducing the Users time on the processor.
These few seconds of high usage, reduce the amount of time the users applications and desktop session can spend on the processor, this reduction of resources cause the VDI desktop of the user to be completely unusable during the pause and ultimately resulting in complaining from the user community. Worse yet, if this is an SBC environment you now have all users on that server locked out!
And all this may sound a bit over the top, but its very easy to reproduce. For example, create a Microsoft Excel sheet and attempt to vlookup over a few thousand cells and watch the processor get chewed up. In this example, yes a vLookup across that many cells would be better served from a server based solution, but what’s stopping your users doing it?… Exactly.
Looking at SBC for a second:
With Server 2008 R2, the Fair Share CPU scheduling feature really is best (free) solution out there for CPU Utilisation management. The processor scheduling is far better than the Citrix equivalent and they also offer a feature (albeit, it feels unfinished) called Windows System Resource Manager to configure the processor affinity along with Process soft rules for performance management.
By setting these extremely intensive Multi-threaded applications to an affinity, we can “Lock” these processes to only run on certain processor cores, allowing the remaining cores to rebalance the rest of the workload. This ultimately, leaves the users session still responsive even if the application no longer responds. Allowing the user to continue working in other application until the intensive process is complete.
The problem with Windows System Resource Manager?
- It’s a pain to configure on more than one system
- It requires (yeuck) Windows Internal Database
- It has been marked as “Depreciated” in Server 2012
- If a user changes affinity, Resource manager doesn’t re adjust.
- It still suffers from “pauses” or sluggishness when the Cpu is really being hammered.
This was my dillema recently with both XenApp & Xendesktop. Ultimately not happy to Pay for a solution, embrace a depreciated tool, or wash my hands of the problem, I decided to write my own tool, complimenting fair share CPU scheduling but allowing affinity and priority locking.
ThreadLocker has been written to help you target known problematic processes and deal with them pro actively.
Threadlocker also has the added benefit of dropping the priority of known grunty processes to idle, meaning the process will use as much CPU as it can, but any other higher priority process can interupt without sluggishness or pauses.
With ThreadLocker you can target these processes and set their Affinity number of processors they can run on:
Or their Process Priority to drop them out of the normal running context:
- Threadlocker is light weight and scalable.
- Threadlocker works flawlessly with Cpu Fair Share Scheduling, so even if a process is “ThreadLocked” the users running those applications will fair share on the designated cores.
- Threadlockers configuration is xml based and can be copied down to the machine with Startup script or Group Policy preferences.
- Threadlocker can be used in VDI environments where no other free solution is available.
- Threadlocker will re-adjust priority, or affinity if the devious user tries to remove the restriction.
Threadlocker has been successfully tested on the following platforms:
- XenApp 6.5
- Windows Server 2008 R2 Service Pack 1
- Windows 7 x64 Service Pack 1
- Threadlocker Requires .Net Framework 3.5 sp1