Understanding how WSRM works and what you gain from it

WSRM provides automatic resource management based on predefined or custom policies. You use WSRM to manage both CPU and memory resources. Of course, you can already manage storage resources using the quota system that has appeared in all versions of Windows Server. In many respects, WSRM follows the policy setup used by Windows security. The policy modifies how the system interacts with entities using the resource.

The policies used by WSRM don’t take effect until the server reaches 70 percent capacity in the affected area. For example, when the server is at only 20 percent CPU usage, the policy isn’t used. Microsoft never tells why it chose the 70 percent level, but anecdotal evidence suggests that contention becomes troublesome at that level on Windows servers. You use WSRM to manage resources in the following ways:

• Manage system resources on a constant or scheduled basis using predefined or custom policies.

• Use calendar rules to specify different policies at different times.

• Select the appropriate policy based on server properties, events, changes to the amount of memory installed, or changes to the number of available processors.

• Obtain resource usage data and store it locally or within a centrally located SQL Server database.

The biggest benefit of resource management is to help make the server available even under significant load. Although a server that has a single role probably won’t need WSRM, adding additional roles complicates the server setup and makes management valuable. In addition, using WSRM can help extend the useful life of older servers by reducing contention for valuable resources. Users tend to see slower, but consistent, response times with the appropriate policies in place. Processes don’t end up starved for resources, which makes the server more reliable.

The Resource Allocation Policies folder contains all the policies used to manage resources on the server. WSRM comes with four predefined policies. The following list describes these four policies:

• Equal_Per_Process: Each running process receives an equal portion of CPU and memory resources. This default policy limits each process to a maximum of 10 percent of the available resources while the resource usage remains above 70 percent (the contention level). This is the default managing policy. You normally use this policy for service-related servers, such as those that provide file and print services.

• Equal_Per_User: Each user receives an equal share of CPU and memory resources. For example, if the server is servicing ten users, each user receives 10 percent of the available resources while the resource usage remains above 70 percent. You normally use this policy for application servers.

• Equal_Per_IISAppPool: Each Internet Information Server (IIS) application pool receives an equal share of CPU and memory resources. Applications that aren’t part of an IIS application pool receive any resources that are left over from IIS activities. In some cases, this means that services and server-based applications won’t receive any resources while IIS is under heavy load. You normally use this policy for Web servers or for servers that provide Web services.

• Equal_Per_Session: Each session receives an equal share of the CPU and memory resources. For example, if the server is servicing ten sessions, each session receives 10 percent of the available resources while the resource usage remains above 70 percent. Because a user can have multiple sessions, this policy isn’t the same as the Equal_Per_User policy. Users with multiple sessions receive preferential treatment when using this policy. You normally use this policy for servers that support Terminal Services.

These default policies serve as a basis for common resource management scenarios, but may not meet your needs. For example, you may want to give a particular application preferential treatment to ensure that users can always access it — address this requirement using a custom policy.

Policies also have a scope. You can assign a policy at the system level so that it affects every application, session, or user on the system. As an alternative, you can create a conditional scope specifying that WSRM uses a policy to meet a specific need. Setting conditional policies can become quite complex and usually reflects a special setup on your server.

In some cases, the server doesn’t have the same load placed on it every day. A server may need to perform specific tasks based on calendar requirements. For example, an accounting computer may have to give priority to performing end-of-month calculations at the end of the month. To set a onetime or recurring policy event, choose the Calendar folder. This feature works precisely the same way as the Calendar feature in Outlook. Simply right-click the calendar area, choose the kind of event you want to create, and set the date and time parameters.

Source of Information : For Dummies Windows Server 2008 For Dummies