This article has been reprinted from TechProGuild. If you find this article helpful, subscribe to TechProGuild to get access to all of our in-depth technical articles. Sign up now for a FREE 30-day trial. All the articles on our site that include a green $ icon are available only to TechProGuild members.
One of the most useful new tools that shipped with Windows Server 2003 (Enterprise and Datacenter editions) is the Windows System Resource Manager (WSRM).
With WSRM, you can optimize server performance, make users (and management) happy by prioritizing critical applications, foil resource hogs, and make your own life much easier by maintaining simple and effective control over resources.
Why WSRM is valuable
Specifically, WSRM can do the following:
- WSRM enables you to allocate your server’s processor and memory resources on a per-process basis for applications, based on your business priorities. You can combine processes to be managed and set targets and/or limits for resource usage. You can develop these requirements into policies that you can apply to applications or use to manage users—either individually or by security group—in a large Terminal Server environment. This allows admins to control would-be resource hogs.
- WSRM policies can be applied according to a time/date schedule. (So, for example, those noncritical tasks can use all the resources they want, but only when critical apps are not in use.)
- You can generate all the resource utilization reports you need for your own records, for management, for service level agreement (SLA) tracking, and for charge-back purposes.
Although some benefits are fairly obvious, you might still ask, “Do I really need all this control over processes? I don’t have SLA tracking to worry about, and I don’t run Terminal Services.” Well, if you consider that, according to Microsoft, administrators typically operate their servers at between 50 to 85 percent of utilization, then you’ll probably be interested in this tool. Essentially, there’s some extra capacity to be pulled out of your servers, and WSRM offers you the means to harness that capacity in order to provide optimum server utilization.
Also, by judiciously allocating resources, you can prevent applications from interfering with each other and with the system, thereby enhancing system stability.
You cannot use WSRM in conjunction with another (third-party) resource manager. If you attempt to do that, WSRM will not be able to manage system resources correctly.
WSRM can be installed on 32-bit or 64-bit versions of Windows Server 2003 Enterprise Edition and Datacenter Edition. It has a server as well as a client component. The latter can only be installed on x86-based computers and supports Windows XP, the Windows Server 2003 family, and Windows 2000 with Service Pack 2 or later.
For managing WSRM, you can use either the command-line interface (wsrmc.exe) or the Microsoft Management Console (see Figure A).
Once you’ve identified the applications you want to manage, you can create policies to control and allocate the CPU and memory resources for applications and services. Such a policy consists of one or more resource allocations, which, as they are used in WSRM, consist of a process matching criterion (the mechanism WSRM uses to match running processes to a resource allocation policy) and one or more of the following:
- An associated CPU target
- A memory limit
- A processor affinity
All of the processes matched by your criteria are assembled into a group. The group is allocated system resources, as specified in the resource allocation policy. If a CPU allocation is specified, the CPU resources are distributed evenly among all the processes in the group. If a memory limit is specified, the limit is applied on a per-process basis to all the processes in the group. WSRM then monitors and controls the resource usage of each managed process in the group. Now let’s take a closer look at process matching.
When an application starts, one or more processes are created. Each process is also linked to the user account of the person (or system account) that started the process. Using WSRM, you can change the priority of a process, which affects the schedule that determines which applications have access to CPU resources. There are four priority levels to which WSRM can change process priority:
- Above normal
- Below normal
Here’s how to create a process matching criterion:
- In the console tree of WSRM, right-click Process Matching Criteria and then click New Process Matching Criteria.
- In Criteria Name, type a descriptive name for the new process matching criterion, then click Add (see Figure B).
- On the Files Or Command Lines tab, you can specify a process manually by typing the file name or command-line path in Included Files Or Command Lines. You can also choose the process from a list by selecting Registered Service, Running Process, or Application, and then clicking Select.
- If you selected either Registered Service or Running Process, click the process you want to match, and then click OK. If you selected Application, type the path to the location of the application’s executable file, or browse to it and select it.
If you want to create a process matching criterion using user or group matching, you would choose the Users Or Groups tab after step 2 above. Then you would have the option to either include or exclude users and groups from matching. In Select Users Or Groups, type the user or group name, and then click OK.
You can use Task Manager to view the current process priority level of a managed process. Then you can use this information to help you change the priority according to business needs.
Now you can move on to create one or more resource allocation policies. Such a policy consists of one or more allocations: a process matching criterion and a resource allocation associated with that process matching criterion. You can use these policies to set a CPU consumption target, memory limit, processor affinity, or a combination of these.
A good starting point is to set CPU targets. You can then refine the resource allocation policy as necessary. Microsoft recommends this approach for the following reasons:
- CPU management is least likely to impact the application itself.
- It is easy to understand and perform.
- “Actual performance is easier to monitor than expected performance.”
- CPU management “is the most flexible of the management options available.”
Setting memory limits should be the next step “if CPU management is ineffective or the application to be managed has unique memory requirements that cannot be addressed through the standard memory allocation of the operating system,” according to Microsoft.
Examples of when a memory limit should be set include the following:
- When an application does not share memory with other applications
- When an application cannot use its full CPU allocation because it does not have enough memory
- When an application is leaking memory
Be careful with processor affinity. Microsoft recommends you use it only if CPU management was unsuccessful or if the application to be managed requires that an affinity be set to one or more processors.
Set the policy
Here’s how to create a resource allocation policy:
- In the console tree of the WSRM snap-in, right-click Resource Allocation Policies, then click New Resource Allocation Policy (see Figure C).
- In Policy Name, type a name for the new resource allocation policy, then click Add.
- On the General tab, in Process Matching Criteria, select a process matching criterion.
- In Percentage Of Processor Allocated For This Resource, type or select the value for the percentage of total CPU bandwidth to be allocated, and then click OK.
To set memory limits, after step 2 above, click the Memory tab. Select the Use Maximum Committed Memory For Each Process check box. In Maximum Committed Memory Limit Per Process, you can type a value in megabytes. In If Memory Is Surpassed, select either Stop The Application or Log An Event. Select the Use Maximum Working Set Limit For Each Process check box. In Maximum Working Set Limit Per Process, type a value in megabytes.
Assign the policy
Now you’re ready to set the new resource allocation policy to manage the computer. In the console tree, click Resource Allocation Policies. In the details pane, right-click the resource allocation policy you want to set, and then click either Set As Managing Policy or Set As Profiling Policy.
You can also create a calendar event or a schedule using your policy. In the console tree, double-click Calendar and then right-click Calendar Events to set your options, or right-click Schedules and choose New Schedule to schedule the policy. It can be a single or recurring event. Such a schedule can even be used to manage multiple resource allocation policies, activating different policies at different times.
Once you’ve set your policies, it’s time to ascertain if your resource management is working as expected. You can do this using System Monitor, which is included in the WSRM snap-in. It has three sets of its own performance counters:
- WSRM: Policy
- WSRM: Process
- WSRM: Process Matching Criteria
If you observe these and are happy that everything is working properly, it’s time to make use of WSRM’s accounting features to keep records of the behavior of managed processes. Data is logged to the accounting database at a default interval of 10 minutes. You can modify this interval. The accounting database enables you to easily generate reports of process-resource usage on a per-user, per-application, or other basis. You can use this data for charge-back purposes and SLAs. Use the WSRM information on memory usage and CPU time to support SLA metrics.
It’s important that you archive and delete accounting data and manage the size of the accounting database or you’ll risk running out of disk space. WSRM does not automatically overwrite old records or reuse storage space. You should also make regular backups of the accounting database. You have to stop the WSRM service before backing up the database.
The best way to get started with WSRM is to experiment with the samples included on the WSRM CD. There are four dummy applications (Bizcrit.exe, Batch.exe, Rogue.exe, and Leaky.exe) and some sample XML policies.
You first have to import the sample XML files. To do so, open the WSRM console (if it’s not already open), right-click Windows System Resource Manager, then click Import WSRM Information. In Location, type the path to the four sample XML files (the root of the Samples folder on the CD) and then click OK, or click Browse to select the folder containing them.
The following is some additional information about these sample policy files from the information provided in WSRM’s help files.
This includes the following resource allocation policies:
- Equal_Per_User: This is the policy that is included with Windows System Resource Manager. It implements the equal-per-user management rule and specifies a 99-percent CPU consumption target.
- DayTimePolicy: This policy is designed to manage two of the sample programs, Batch.exe and Bizcrit.exe. For Batch.exe, a CPU consumption target of 70 percent is specified. For Bizcrit.exe, a CPU consumption target of 25 percent is specified.
- NightTimePolicy: This policy is also designed to manage Batch.exe and Bizcrit.exe. For Batch.exe, a CPU consumption target of 60 percent is specified. For Bizcrit.exe, a CPU consumption target of 30 percent is specified.
- StopLeak: This policy is designed to end a program that has a memory leak when its memory consumption reaches a specified level.
This activates the default post-installation calendar settings. These settings are: calendar management, the calendar default policy set to WSRMDefault, and the managing policy set to WSRMDefault.
This includes the Equal_Per_User process matching criteria, which is included with Windows System Resource Manager. It matches all running processes not included on either the system-defined exclusion list or the user-defined exclusion list.
As far as the four sample programs—Bizcrit.exe, Batch.exe, Rogue.exe, and Leaky.exe—are concerned, Bizcrit represents an interactive workload that a business might depend on, such as customer service software or a Web site. Batch represents a non-interactive workload that consumes more resources when interactive workloads consume fewer resources. Rogue represents a CPU-intensive workload that has a low business priority, but that must still run, provided that it does not impact other running programs that are more important. Leaky represents a program with a memory leak.
You can copy them to a folder on your computer or run them from the CD. These samples provide you with a great way of comparing performance in the “managed” state and “unmanaged” state.
Once running, you can, for example, check their CPU usage with Resource Monitor. In Resource Monitor, select the Process performance object, and then select % Processor Time for each of the four to display the CPU usage. Just remember to switch off management when you want to see what performance is like in the unmanaged state, and to enable managing again to see performance in the managed state. To switch management on or off, right-click Windows System Resource Manager and click to toggle between Stop Managing and Start Managing in the drop-down menu.
Once you’ve seen what WSRM can do by using the samples, you can start experimenting with allocating resources to applications.
You should also be aware that if you uninstall WSRM, all resource allocation policies, process matching criteria, calendar data, and accounting data will be deleted as part of the uninstall process. To keep these files and data, you must copy them to another location before you do the uninstall.