Windows System Resource Manager: Frequently Asked Questions

You use WSRM to manage CPU and memory use by process or by user. This means an administrator may safely run multiple applications on a server. WSRM helps prevent applications from consuming more than their allocated CPU and memory limits and thereby prevents an application from taking CPU and memory resources from other applications. Consequently, the end user will see a more consistent and predictable experience.

WSRM policies can be applied according to a time or date schedule. For example, you can focus CPU and memory resources on mission-critical applications during peak hours and use a different policy, freeing resources for maintenance applications, during non-peak hours.

With the accounting feature of WSRM administrators can generate, store, view, and export resource utilization reports for systems management, service level agreement (SLA) tracking, and billing purposes.

Windows System Resource Manager is not intended to handle other aspects of data center management such as:

Administrators use WSRM to address several scenarios when running multiple applications on a single server. Some scenarios include:

Yes. You can run the WSRM accounting function by using policy profiling.

When consolidating multiple applications on a single server, it is critical to allocate each application access to the system resources it requires. This regulation reduces the ability of applications to interfere with one another. This resource allocation allows multiple applications to be safely consolidated onto fewer larger servers, thus reducing operating costs.

Today administrators typically operate their servers at five to ten percent of total capacity. This ensures that there is spare capacity if applications require it. However, it also means that money has been spent on a system which is not fully used. With WSRM administrators can consolidate multiple applications in the way that they now have the ability to allocate system resources. When system resources are allocated, applications operate within a defined resource policy and within defined resource allotments on the system. With this granular control, servers can be safely operated at higher levels of capacity while still providing a consistent user experience.

Service level agreements are usually described using business metrics such as response time, number of users supported, and availability levels. OEMs, vendors, and enterprise IT groups are looking for tools that help them to prove that they are meeting their SLAs. The reporting features of WSRM help with reports on memory usage and CPU time that could support SLA metrics.

WSRM uses soft caps. It will enforce the caps if the system becomes resource constrained. However, an application may exceed its target and spike up if other processes are using less than their allocation. WSRM reallocates unused resources every few seconds determined by application demand.

An administrator can use WSRM to manage any non-operating system process.

This is because WSRM and the operating system (OS)are momentarily using the CPU or CPUs to perform the policy switch. Note that every process is using the same set of CPUs, so whenever any process that WSRM is not monitoring uses CPU time, the CPU percentage for the process you are monitoring will drop. Since wsrm.exe and other OS processes are in the exclusion list, they get as much CPU as they need to do important things, such as change a policy. This is expected behavior.

WSRM by itself is cluster unaware. Cluster requirements can be addressed in the following ways:

Yes. WSRM was designed and developed by Microsoft to be used with Windows Server 2003, Datacenter and Enterprise Editions.

The given values are disk spaces occupied after installation.

Notes:

No. WSRM manages individual computers and is not cluster aware, so cluster members are managed separately.

Yes, WSRM provides policy import and export functions. It may be easiest to use the same policy on each cluster node. This is not required however, and assigning different policies may be used to address some failover scenarios.

Windows Server 2003 includes new support and optimizations based on NUMA architectures. WSRM does not attempt to further optimize applications use of NUMA systems.

Because Terminal Server sessions correspond to processes spawned with the user's credentials, they can be managed by adding a user account name or security group name to the matching rule that matches an allocation to a process. An administrator has considerable flexibility in managing Terminal Services users by account and/or application either individually or by security group. This provides a consistent experience to users while preventing some users from monopolizing resources at the expense of other users.

Yes, but there are particular configurations of SQL Server that will result in the most effective management and particular WSRM features are not recommend for use with SQL Server.

Process Control does not exist in Windows Server 2003. However, if you upgrade from Windows 2000 Datacenter Server to Windows Server 2003 Datacenter Edition, Process Control will be left in place.

WSRM doesn't use job objects and is unable to manage processes that run in job objects. This scenario corresponds to multiple resource managers or in some cases a self-managed application.

Aurema's ARMTech is available for the Windows 2000 server family and Window Server 2003 products. Microsoft will continue to bundle ARMTech with Windows 2000 Datacenter Server. However, it will not be included with Windows Server 2003, which instead includes WSRM with the Enterprise and Datacenter Editions. Aurema will continue to improve their product giving our customers a range of choice in their resource management tools.

WSRM cannot properly manage a computer if any management application (such as an OEM tool) is dynamically modifying the parameters that WSRM uses for management. These parameters include: thread or process priority (used for CPU management), working set size (used for real memory management), and processor affinity (used for processcor affinity management).

Note: Placing a process into a job object has the effect of modifying these parameters. So any application that dynamically modifies these parameters for any process (including itself) will interfere with the ability of WSRM to manage the process.

No. Only a single manager at a time can be effective.

WSRM provides matching rules that scan the entire command line used to create each process. This allows processes to be distinguished by command line arguments in addition to executable name and path.

WSRM is provided automatically to purchasers of Windows Server 2003, Enterprise and Datacenter Editions on a separate CD. It is not available for Windows Server 2003 Standard Edition, or the Windows 2000 Server family.

No. Because WSRM only runs on Windows Server 2003 Enterprise and Datacenter Editions and is provided as part of those products, there is no need to purchase it separately.

WSRM is provided in the same languages as Windows Server 2003 Enterprise and Datacenter Editions with the exception of Czech, Dutch, Hungarian, and Turkish. Customers purchasing one of those language versions of Windows Server 2003 Enterprise or Datacenter Edition will receive the English version of WSRM.

WSRM is only available for Windows Server 2003, Datacenter and Enterprise editions. However, user interfaces for administering WSRM run on Windows XP Professional and all editions of Windows 2000 and Windows Server 2003.