Yesterday, we discussed how Windows System Resource Manager (WSRM) lets you assign memory and CPU resources to...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
various applications. This free feature pack for Windows Server 2003 Enterprise Edition and Datacenter Edition is available at http://www.microsoft.com/windowsserver2003/downloads/wWSRM.mspx.).
At this point you have decided what percentage of the available CPU time you want to assign to mission-critical applications and what percentage should be assigned to non mission-critical applications.
Your next step: creating process matching criteria. Once you have created a named process matching criteria instance, you need to list all of the services, processes, and applications that fall within it.
For example, create a process matching criteria for your mission critical applications. You might call this instance Critical. Next, you must define the services, applications, and processes that should belong to critical. Assuming that you consider Exchange to be a mission critical application, you could list Program FilesExchsrvrbinevents.exe, Program FilesExchsrvrbinstore.exe, and the list goes on.
Once you have set up a process matching criteria, you must create a resource allocation policy. To do so, you would create a named instance of the policy (in my case, the policy is called Posey). Then you would input the name of the process matching criteria that you created earlier, and define the amount of CPU time that you would like to assign to the criteria.
By doing so, you have created a policy in which 70% of the available CPU time is split evenly among the services, applications, and processes that you have specified. This is almost always an improvement over the default resource usage, but if you really want to optimize Exchange you have to take things a step further.
Assume for a moment that each application or service that you have defined as being critical is using all of the CPU time that you have allocated to it. The problem is that Exchange Server is made up of about seven different services. This means that Exchange is potentially using up to seven times the amount of CPU time as another mission critical application.
Because of this, it is sometimes necessary to sub-allocate resources. This means that you must create more process matching criteria. For example, you might create a process matching criteria called Exchange that encompasses all of the Exchange services. You could then create a resource allocation policy that sub-allocates resources to the Exchange process matching criteria.
For example, let's assume that you consider Exchange to be a critical application and you want your critical applications to have 70% of the CPU time. However, you don't want Exchange to consume an excessive amount of the CPU time reserved for critical applications, so you sub-allocate it 10% of the CPU time given to critical applications. This means that 70% of the time, the CPU is servicing a critical application, and 10% of that time is spent servicing Exchange. This is different than giving Exchange 10% of the overall system resources. If you were to give Exchange Server 10% of the over all system resources, the CPU would spend 10% of its time servicing Exchange. Using sub- allocation in which only 10% of 70% of the CPU time is spent on Exchange means that the CPU is servicing Exchange about 7% of the time.
WSRM can also allocate memory to processes. Memory management is set at the resource allocation policy level. You can control the maximum committed memory and the maximum working set limit for each process. This is optional. I don't recommend regulating memory unless you have been having problems with the server running low on memory, or an application is known to have a memory leak.
As if being able to manage CPU time and memory weren't enough, you can also control the number of processors used by each application. This is also done through the Resource allocation policy and gives you even greater control over system resource usage.
To read the first part of this two-part series, click here
Brien M. Posey, MCSE, is a freelance technical writer who has written for companies and publications that include Microsoft, CNET, ZDNet, MSD2D, Relevant Technologies. He has also served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. Brien received Microsoft's MVP award for his work with Windows 2000 Server and IIS. You can visit his personal Web sites at www.brienposey.com and www.relevanttechnologies.com