With Windows Server 2008, it was possible to use Windows System Resource Manager’s (WSRM) Equal_Per_Session policy to control CPU allocation of sessions. This ensured that no session would hog CPU and affect the performance of other sessions on that server so that all sessions on a TS Server would get an equal share of CPU. However, in Windows 2008 it could take up to several seconds before a runaway process was throttled, meaning that users would be adversely impacted until this throttling occurred.
In Windows Server 2008 R2 Remote Desktop Services, we have added kernel-based dynamic fair share scheduling (DFSS) to control CPU allocation. This system is able to throttle runaway processes in a matter of milliseconds, ensuring that the impact of runaway processes on users is immediately minimized.
By default DFSS gives equal weights to all sessions, i.e. all sessions are given equal share of CPU.
But what if an administrator wants to give different CPU shares to different user sessions? For example, assume an RD Server running 50 sessions and every session is taking 2% of CPU (i.e. total CPU usage on the server is 100%) and the administrator wants to do some important maintenance work at that time. Because of the heavy load on the server, the admin will end up spending more time in doing this. This can be avoided if administrators are assigned Premium priority in WSRM’s “Weighted_Remote_Sessions” policy. Other scenarios can be: in an organization executives are given higher priority over other workers, or the Sales department has higher priority over the Manufacturing department, etc.
The administrator can allocate different CPU shares to different sessions using WSRM (Windows System Resource Manager). WSRM is an optional server feature used for managing system resource (processor and memory) usage. This feature has been part of the operating system since Windows Server 2008.
WSRM has a new built-in policy called “Weighted_Remote_Sessions”. This policy allows an administrator to categorize users into one of three priority groups: premium, standard and basic. WSRM ensures that users belonging to the premium group will get more CPU resources than those in standard, who will in turn get more CPU resources than users in basic.
You can use this feature by following the steps below.
PingBack from http://microsoft-sharepoint.simplynetdev.com/using-wsrm-to-control-rds-dynamic-fair-share-scheduling/
We've had some bad experience with WSRM, with the overhead of WSRM taking way too much cpu time, so we disabled it.. This was in VM's with one CPU, so we need to do some additional testing and with more CPU's in a VM.
My questions after reading this article are;
- can you say something about the recommended hardware configuration of Terminal server?
- are there methods of limiting the amount of overhead WSRM creates on CPU cycles? Like a method where WSRM shuts itself down if it takes too much?
- is WSRM recommended in a VM environment? Are there big differences between HyperV/VMware VM's in combination with WSRM? How does HyperV/WSRM handle VM's with WSRM? When HyperV handles/schedules the CPU load per VM and WSRM handles the priority within the VM, does that not create a CPU cycle war?
I am not sure if that is affecting you but WSRM had a performance bug in Windows Server 2008, which has been fixed in Windows Server 2008 R2. You can use Windows Server 2008 R2 RC build for your tests. Hardware requirement of Terminal Server depends upon the number of sessions you want to run on the server, please check if this link helps(http://technet.microsoft.com/en-us/library/cc786809(WS.10).aspx). You cannot control WSRM CPU usage. WSRM for CPU distribution (for non “Weighted_Remote_Sessions” policies) considers available CPU as 100% and then distributes that by continuously watching CPU usage of the running processes. So it doesn’t really matter how much % of CPU Hyper-V is giving to VM.
Fix for the above mentioned performance issue of WSRM in Windows Server 2008 is available. Follow this link for details