Terminal services administrators are faced with many challenges, none greater than supporting applications that attempt to monopolize the CPU resources on a given server. ThreadMaster provides a method to control a rogue application that is both easy and free.
Introduction
Many applications that are deployed via Terminal Services were just not written for a multi-user environment. Although there can be many different issues facing Terminal Server administrators, taming a CPU-intensive application can be one of the more interesting challenges. Tame it too much and the application performance can become too sluggish. Give it too much freedom and the performance for all users on the particular server could be affected. There are several third party tools and utilities available to address this concern; but ThreadMaster may be able to accomplish this without adding to the price tag of your Terminal Services deployment. This article demonstrates the use of ThreadMaster and the value this freeware utility could bring to your environment.
Installation of ThreadMaster
ThreadMaster can be freely downloaded from http://threadmaster.tripod.com. A single zip file will expand to reveal the files shown in Figure 1:
Figure 1
To install ThreadMaster simply execute the “Install.cmd” file. This will create 2 directories; %windir%\system32\ThreadMaster and %windir%\system32\ThreadMaster\log. Files will be copied to the “%windir%\system32\ThreadMaster” directory, and registry values will be created under HKLM\SYSTEM\CurrentControlSet\Services\ThreadMaster\Parameters. This is important to understand as there is no GUI management interface for this product; all configuration is done via your favorite registry editing tool. A service named “ThreadMaster” will be created, set to “Automatic” startup, and will be started automatically. This service immediately invokes ThreadMaster with the default settings. Be aware that the default installation will cause all processes to be capped at 15% of CPU utilization, excluding certain processes which you find in the HKLM\SYSTEM\CurrentControlSet\Services\ThreadMaster\Parameters\Exceptions subkey. These are critical Windows processes and clamping any of these could result in less than optimal results. If you wish to add other processes that should be exempt from ThreadMaster, simply add a REG_SZ registry value named the same as the process (including extension, such as .exe) to the HKLM\SYSTEM\CurrentControlSet\Services\ThreadMaster\Parameters\Exceptions subkey. You then must restart the ThreadMaster service for these changes to be in effect. Figures 2 and 3 below depict the files and registry settings installed by ThreadMaster.
Figure 2
Figure 3
In addition to process exceptions there are several other registry values used for controlling the behavior of ThreadMaster. Under HKLM\SYSTEM\CurrentControlSet\Services\ThreadMaster\Parameters you will find CPUThresholdPCT with a default value of 15%. This sets the maximum percentage of CPU utilization that any one process will receive. This is the default value for all processes (except those in the Exceptions registry subkey), but the default value can be overridden for specific processes. To set a non-default value for a specific process, simply add a REG_SZ value named the same as the process for which you wish to configure a different CPU Threshold value to the HKLM\SYSTEM\CurrentControlSet\Services\ThreadMaster\Parameters\Applications subkey and enter the value in percentage (0-100) for the specific process. ThreadMaster adds the “mfadmin.exe” process (Old Citrix MetaFrame Administration utility) by default and clamps it to 5% CPU utilization.
Moving back to the Parameters key we find MainSampleTime, which controls the sampling period for applying CPU clamping. The default value of 30 seconds lets you know a process must exceed the configured CPU utilization threshold for 30 seconds before clamping is applied. This makes sense to accommodate acceptable instantaneous spikes in CPU usage, however the 30 second default value may prove to be a little long. Consider changing this value to 15-20 seconds, but as always make sure you test these settings on a non-production server first. Two other registry values exist to provide the ability to cause an action to happen when CPU clamping in engaged, and a separate action when the clamping is disengaged. For example, a script could be executed to create an event log entry, or send an email to indicate ThreadMaster has sprung into action, and/or to indicate CPU clamping has ceased. Just remember the ThreadMaster service must be restarted after any changes to ThreadMaster registry settings are made in order for those changes to take effect.
ThreadMaster in Action
Let’s take a look at ThreadMaster in action on a Windows 2003 Terminal Server. A process named CPUHog.exe will be used to demonstrate the effect of a CPU intensive process allowed to run amuck; and then we will start the ThreadMaster service and observe the positive effect of this freeware utility. In Figure 4 below we see a graph depicting CPU utilization for a server with very little activity.
Figure 4
Figure 5 paints a different picture; excessive CPU utilization has now affected every user on this particular server.
Figure 5
A quick check of the processes in Figure 6 shows the culprit; CPUHog.exe.
Figure 6
The ThreadMaster service is then started, and within 30 seconds we see our CPU utilization graph in Figure 7 return to a much healthier state.
Figure 7
Figure 8 also shows the CPUHog.exe process now controls only 14% of the available CPU, not over 90% as before invoking ThreadMaster. The default setting of a maximum threshold of 15% has applied to the CPUHog.exe process.
Figure 8
Logging ThreadMaster Activity
ThreadMaster has provided the skeleton for a logging feature, evident by the log directory that is created at installation. Nothing is logged in this location by default, but certain data is tracked in the registry. The registry subkey HKLM\SYSTEM\CurrentControlSet\Services\ThreadMaster\Statistics\Count will contain a value for each process that ThreadMaster has clamped, along with a running total of the number of times CPU clamping has been invoked for that particular process. The HKLM\SYSTEM\CurrentControlSet\Services\ThreadMaster\Time subkey will contain the total amount of time in seconds that each individual process has been clamped.
In our example we can surmise that ThreadMaster clamped the process “CPUHog.exe” for a particular duration of time. In order to see the evidence of this we will need to open our favorite registry editor once again. Looking under the “HKLM\SYSTEM\CurrentControlSet\Services\
ThreadMaster\Statistics” registry key will reveal the CPUHog.exe has been clamped twice for a total of 53 seconds (in decimal). Although this is not a great deal of detail it does provide enough information to assist in uncovering CPU intensive applications. Figures 9 and 10 below show this data:
Figure 9
Figure 10
In addition to the “ThreadOverloadActionStart” and “ThreadOverloadActionStop” registry values, and the data provided under the “Statistics” registry key, ThreadMaster provides a sample batch file, ThreadLog.cmd. This batch file is a sample file designed to capture statistics and save them in a log file, which will be located in the ThreadMaster\Log directory. There is also a sample batch file, ThreadSaveLog.cmd that will save and rename an existing log file. These batch files do not provide logging capabilities in their default state, but do provide some example batch file code. If you want to create detailed logging of ThreadMaster activity, perhaps a better method would be to create a VBScript (or use another scripting language such as Pearl) that will extract data from the ThreadMaster “Statistics” registry location, and/or query process information via WMI. In most cases it is not required to have access to detailed logging information; as long as ThreadMaster does its job at keeping watch over valuable CPU cycles and helps to provide a positive user experience.
Conclusion
ThreadMaster does not stand alone with regards to utilities available on the market to address terminal server performance issues. There are many third party packages that address this very issue. Even Citrix Presentation Server includes a CPU utilization feature (licensed from Aurema). Some of these products contain very sophisticated GUI management utilities and provide very granular control. However, none are able to match the price of ThreadMaster; freely available to the public. As you can see from the demonstration presented in this article, the potential for ThreadMaster to successfully provide an effective way to control CPU utilization in Terminal Server environments makes it a very attractive option. Before you spend a significant amount on a purchased product, give ThreadMaster a try. Your terminal server users and your IT budget may both thank you in the end.
