You can use the Windows System Resource Manager (WSRM) to limit the amount of CPU time and memory that an individual application, process, or service can consume. The WSRM also allows you to have fine granular control over the resources used by an individual application. There are also some built-in performance monitoring functions that will help you to fine-tune your resource management policies. Here's how to use these and other advanced features of WSRM.
To start the Windows Resource Monitor, click Start | All Programs | Administrative Tools | Windows System Resource Manager. If you select the Resource Monitor object in the console tree, you will see a graph that looks something like the one shown in Figure A. As you can see in the figure, this graph can be really hard to follow. Furthermore, there is no good documentation on how the graph works. Once you figure it out, it’s really quite simple though.
|The WSRM graph can be really hard to follow.|
There are several keys to being able to understand this graph. If you right-click in the legend and select the Properties command from the resulting shortcut menu, you will see a detailed description of each counter. You can also use this properties sheet to add and remove counters.
As you click on each entry, you will see the color that has been assigned to it. In Figure B, the first entry corresponds to System Managed CPU %. Although I have not been able to find any documentation on these counters, this counter appears to be the amount of CPU time that’s currently being used by the core operating system. You might notice that this counter is assigned the color red. However, if you look at Figure A, there are no red lines on the graph. That’s because this is the selected counter. Whichever counter is selected at any given time, the corresponding line on the graph will appear in black rather than in its assigned color.
|WSRM displays the currently selected counter in black regardless of its assigned color.|
The next four counters are:
- Managed CPU % (Critical)
- Process Count (Critical)
- Managed CPU % (Default)
- Process Count (Default)
Critical here refers to the criteria I defined earlier that I wanted to track. Both Managed CPU % and Process Count counters have Critical values and the Default values. This allows you to track your own settings versus a baseline of default applications. Although you can't see it in the figure, I selected different colors for each counter.
Therefore, the purple line in my graph tracks how many processes are running that belong to applications that I have assigned to the Critical process matching criteria. The Blue line displays the number of currently running processes that belong to default applications.
The yellow line on the graph shows how much CPU time is actually being used by critical applications, while the green line shows how much CPU time is being used by default applications. It is perfectly normal for Managed CPU % counters to spike to 100%. The problem is that this particular graph view makes it nearly impossible to tell how much CPU time is really being used by critical and by default applications. To get a better feel for the CPU resources being used, you can switch the graph to a histogram view by clicking the histogram button in the task bar above the graph. Upon doing so, you will see a graph similar to the one shown in Figure C.
|A histogram is much easier to read than a line graph.|
In the figure, the yellow bar, which represents the CPU utilization of critical applications is right around 40 percent. The green bar, representing the CPU utilization of default applications is at almost 70 percent. If I assigned 70 percent of the CPU utilization to critical applications and 30 percent to default applications, how can this be?
What’s happening is that at the moment in time when this screen capture was taken, the critical applications were not using all of their allotted CPU resources. The default applications needed more than 30 percent of the CPU time, so they borrowed unused CPU cycles from the critical applications.
It might be tempting to look at this graph and then change WSRM to only give 40 percent of the CPU time to critical applications and free the rest of the CPU time up for non-critical applications. Although the graph’s purpose is to help you to determine the optimum amount of CPU resources to assign to each process matching criteria, the graph only displays the CPU utilization for one moment in time. That one moment may not be representative of how the system regularly performs.
You might have noticed in Figure C that just above the graph’s legend, there is a set of values for last, average, minimum, maximum, and duration. These statistics apply to the currently selected counter. Therefore, if I really wanted to know how much CPU time my critical applications were really using, it would be necessary to either watch the counter for an extended period of time (especially during periods of peak activity), or to make a log of the performance data. Only when you understand how much CPU time your applications are really using can you define optimal resource allocation policies.
Another one of the advanced features that I wanted to show you is scheduling. Suppose that when I had initially set my server to use 70 percent of the CPU resources for critical applications and 30 percent for default applications that my guess had been exactly right and that the 70/30 ratio was absolutely perfect. Even if my guess had been dead on, there’s a good chance that these settings are not always appropriate.
For example, imagine that it’s Fourth of July weekend and everyone is out of the office except for about three people who are there to answer the phones. If my entire staff is gone, then there’s no way that my server is going to need all 70 percent of the CPU resources to run critical applications. I could therefore adjust the resource management to assign maybe 20 percent of my server resources to critical applications and 80 percent to default applications. This would free the server up for more entertaining uses, if you catch my drift. When Monday morning rolls around, the scheduler could put the normal schedule back into place and no one would be any the wiser that you and your buddies used a production server to play video games over a holiday weekend.
Even if you aren’t the type to waste precious server resources on video games, many companies have different needs depending on what shift is working. The day shift might use e-mail heavily, while the night shift does strictly data entry. Whether you are adjusting for a holiday weekend or adjusting for differences in the tasks done by different shifts, the scheduling feature allows WSRM to be flexible.
For the sake of demonstration, let’s set up a holiday schedule that only dedicates 20 percent of the CPU resources to critical applications. Let’s also set up a nighttime schedule that dedicates 50 percent of the CPU resources to critical applications. To do so, you would have to begin by creating a couple of new resource allocation policies. For demonstration purposes, I will call these policies Holiday and Night. My existing 70/30 is presently called Posey.
Once these policies are set up, you need to make WSRM aware that the Fourth of July should use the Holiday policy. To do so, right-click on the Calendar container and select the Enable command from the resulting shortcut menu. Next, right-click on the Calendar Events container and select the New Recurring Event command from the shortcut menu. You will now see a dialog box that asks you to fill in the date and time of the event, how often it should recur, and which policy should be used. As you can see in Figure D, I have told WSRM to use the Holiday policy on July 4th and that the recurrence should be annual.
|You can set up a recurring event for holidays.|
As different as night and day
Now, let’s look at setting up a day and nighttime schedule. To do so, right-click on the Schedules container and select the New Schedule command from the resulting shortcut menu. When you do, you will see the New Schedule dialog box. Right-click on an empty area of the dialog box and select the Add Schedule Item command from the shortcut menu. You will now see a dialog box that asks you what policy you want to assign and what the start and end time for the policy should be, as shown in Figure E. When you click OK, the daily schedule will be filled in, as shown in Figure F.
|Set the start and end time for your policy.|
|You can set different policies to account for each hour of the day.|
One last advanced concept that I want to discuss is the suballocation of resources. This is important because some of your critical applications are probably just a little more critical, or a little more resource-hungry than others. For example, I have allocated 70 percent of my CPU resources to critical applications. Those critical applications include Microsoft Exchange, GFI MailEssentials (antispam), and ViRobot Management Server (antivirus). The problem is that these three applications have all been lumped into the critical applications pool. Sure 70 percent of the CPU resources are being granted to the critical applications, but that 70 percent of the CPU time is being divided evenly among the various applications. This means that Exchange, GFI, and ViRobot are each getting about 23.3 percent of the available CPU time.
Each of my critical applications is fairly demanding, but Exchange tends to demand a lot more resources than GFI Mail Essentials or ViRobot Management Server. Therefore, it makes sense to give Exchange more CPU time than the other two applications. This is where suballocation of resources comes into play. Suballocating resources allows you to determine how much CPU time that an individual application (or group of applications) receives within the confines of the CPU time that has already been allocated.
For example, all of my critical applications collectively receive 70 percent of the CPU time. Suppose that of that 70 percent though, I wanted Exchange to get 50 percent of the CPU time with MailEssentials and ViRobot each getting 25 percent. Remember that I'm not really assigning Exchange 50 percent of the total available CPU time. I am assigning Exchange 50 percent of 70 percent of the available CPU time. This means that Exchange is actually getting about 35 percent of the total CPU time. The other two applications are each getting about 17.5 percent of the total available CPU time.
Before you can suballocate any of your critical applications, you must set up some additional process matching criteria. For example, if you were to create a process matching criteria for Exchange, it would include all of the various Exchange services. You could then set up ViRobot and MailEssentials criteria.
Once you have set up the various process matching criteria, you must create a new resource allocation policy. When creating this policy, you would begin by assigning the critical applications 70 percent of the CPU resources, just like before. Now, select the Critical Process matching criteria, and click the Edit button. When you do, you will see the Add or Edit Resource Allocation properties sheet. Select the Advanced tab and then click the Sub-allocate Resources button. You must now specify the amount of suballocation that you want to apply to the original allocation for each process matching criteria.
To do so, click the Add button, select the appropriate process matching criteria, enter the percentage of CPU time allocated to the process matching criteria, and click OK. When you are done, it will look something like what you see in Figure G.
|You can suballocate resources to individual applications.|
One of the things that you may notice when you look at Figure G is that I did not save any CPU time for default applications. Saving CPU time for default applications isn’t necessary since this is a suballocation of an already assigned resource.
Learning by doing
As you can see, the WSRM is easy to use immediately upon deployment. Even so, you will never get the maximum benefit from it until you learn how to track usage through resource monitoring and adjust your allocations accordingly. Over time you may find that usage of allocated resources varies depending on time of day or on the day of the week. In such cases it may be necessary to set up a schedule. If a particular application seems to be performing poorly, it may also be necessary to suballocate some CPU time to give the application a higher priority.