Share via

How Windows System Resource Manager Works

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How Windows System Resource Manager Works

In this section

  • Terms and Definitions

  • Windows System Resource Manager Architecture

  • Windows System Resource Manager Processes and Interactions

Windows System Resource Manager (WSRM) is designed to manage multiple applications on a single computer or multiple users on a computer on which Terminal Services is in use. This supports a variety of scenarios, including consolidation, and can increase the efficiency with which physical hardware on a server is used by running applications.

Resource usage is controlled by using a dynamic process priority management algorithm that determines how to allocate system resources among multiple processes. You can administer resource policies and monitor resource usage with Windows System Resource Manager using Microsoft Management Console (MMC) or a command-line interface.

Windows System Resource Manager is available only on Microsoft Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition. The following condition increases the effectiveness of Windows System Resource Manager:

  • CPU consumption targets are more likely to be met if processes are contesting for CPU bandwidth. This is because there is more contention among processes for scarce CPU resources when the system is experiencing heavy load. Windows System Resource Manager does not enforce resource allocation policies until CPU consumption reaches 75 percent. Before this point, all running processes are already getting all the CPU resources they can use. Windows System Resource Manager is needed only if one or more running processes are unable to use CPU resources because of other running processes using too much CPU bandwidth.

The following restrictions must be considered before using Windows System Resource Manager:

  • Do not use Windows System Resource Manager in conjunction with another resource manager because neither resource manager is aware that the other is attempting to control system resources.

  • Do not use Windows System Resource Manager to manage applications or processes that modify their process priority, memory limits, or processor affinity dynamically because this can have an adverse effect on the application being managed. Instead, use the application’s own interface for controlling resources.

  • Processes running in job objects cannot be managed because job objects include a management layer. Instead, use the application that creates the job objects to control the resources allocated to processes in the job object.

  • The service component of Windows System Resource Manager can be installed only on the 32-bit and 64-bit versions of Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition.

  • The client component of Windows System Resource Manager can be installed only on all versions of Windows 2000 and Windows XP Professional, as well as the 32-bit versions of the Windows Server 2003 operating systems. The client component does not support the 64-bit versions of these operating systems.

Terms and Definitions

The following terms are associated with Windows System Resource Manager.

committed memory

Memory that either resides in the working set of a process or maps to a disk file, such as a page file or other memory-mapped file.

CPU consumption target or CPU allocation

Specifies a target CPU bandwidth for the resource allocation. Windows System Resource Manager uses a dynamic process priority management algorithm to try to limit the CPU usage of a process to the target specified in the matching resource-allocation policy of that process.

default group

Includes all running processes not matched by a specific process-matching criterion. Processes in the default group are allocated all of the managed CPU resources that are not allocated to processes matching the active resource-allocation policy.

managed CPU

The total CPU resources being used by managed processes.

managed process

All running processes, except those on the system-defined exclusion list or the user-defined exclusion list. They are managed by Windows System Resource Manager.

process

An object created by Windows to represent an executing program. This includes the virtual address space and the control information necessary for the program to run.

process-matching criterion

The mechanism Windows System Resource Manager uses to match running processes to a resource-allocation policy.

process priority

A value for each process that helps determine how CPU resources are used. Windows System Resource Manager dynamically changes the priority of a process so the CPU usage matches the targeted CPU allocation for that process.

processor affinity

On systems with more than one processor, processor affinity specifies the set of processors on which the process is exclusively allowed to run. Also known as CPU affinity.

resource allocation

The part of a resource-allocation policy that specifies the set of resources to be allocated to the processes matching to a single process-matching criterion.

resource-allocation policy

An ordered list of resource allocations that specifies the management behavior of Windows System Resource Manager at a given time.

sub-allocation

The process by which a resource allocation is divided by multiple child resource allocations.

system-defined exclusion list

The list of system processes that are excluded from management by Windows System Resource Manager. The system-defined exclusion list is built into Windows System Resource Manager and cannot be modified by users.

unmanaged process

A process on either the system-defined exclusion list or the user-defined exclusion list. Windows System Resource Manager never applies a resource-allocation policy to an unmanaged process, even if a resource-allocation policy would otherwise match.

user-defined exclusion list

A modifiable list of processes to be excluded from management by Windows System Resource Manager.

working set memory

For a process, the physical memory that is consumed during the time when the process is running and can be paged to disk.

Windows System Resource Manager Architecture

Windows System Resource Manager consists of two components: the service and the client. For the client, two administrative interfaces are provided: the command-line administration tool (Wsrmc.exe) and the WSRM snap-in available in Microsoft Management Console (MMC). The administrator creates resource-allocation policies and process-matching criteria to control how CPU and memory resources are allocated to applications, services, and processes. These policies are managed by the Windows System Resource Manager service, which then uses the memory manager and kernel scheduler to implement the policies.

The following figure illustrates the different components of Windows System Resource Manager and the interactions between the components.

Windows System Resource Manager Architecture

The following table describes the principal components related to Windows System Resource Manager architecture.

Components of Windows System Resource Manager Architecture

Component Description

Command-line Interface (Wsrmc.exe)

Provides administrative control of the Windows System Resource Manager service using the command-line interface. The command-line interface provides equivalent administrative control to the WSRM snap-in.

WSRM Snap-in (MMC interface)

Provides administrative control of the Windows System Resource Manager service using the MMC interface.

Distributed Common Object Model (DCOM) Interface

The remote application programming interface (API) through which the client and Windows System Resource Manager service communicate.

WSRM Service

Performs resource management by using logic components that interact with the operating system and running processes.

The service continually monitors the resource usage of each managed process in the group. If a process exceeds its resource allocation, the service attempts to bring the resource usage of the process back to its specified target.

Accounting Database

Stores information about managed processes on a per-process basis. Provides a mechanism through which data on the behavior of managed processes can be stored, grouped, and retrieved.

Policy Store

Stores all resource-allocation policies, process-matching criteria, and other related information.

WSRM Settings

Stores the current management settings.

Calendar

Stores all calendar-related information, such as calendar events and schedules.

Memory Manager

Allocates memory to running processes.

Kernel Scheduler

Determines when and for how long each process in the system is allowed to use the processors in the computer.

Windows System Resource Manager Processes and Interactions

This section describes the different processes and interactions of Windows System Resource Manager.

Windows System Resource Manager Service

The Windows System Resource Manager (WSRM) service monitors the state of managed processes and takes action when those processes do not meet their target CPU allocations. The service does the actual resource management work by using logic components that interact with the Windows scheduler and running processes.

Logic components are defined in the following table.

Logic Components

Logic Components Description

Exclusion logic

Matches all processes on either the user-defined or system-defined exclusion lists and marks them to be excluded from management by Windows System Resource Manager.

Matching logic

Examines all processes not on the exclusion lists and groups them by matching process-matching criterion for management.

Process priority logic

Implements the dynamic process priority management algorithm to raise and lower the priority of a running process. Changing the priority of a process affects how CPU resources are allocated among running processes.

Memory logic

Sets the memory limits specified in the associated resource allocation, if the limits are defined.

Affinity logic

When processor affinity is specified in the managing resource allocation policy, configures the process to run on the set of processors specified.

Job accounting logic

Periodically writes resource consumption statistics to a private job accounting database. Also, provides an interface for querying and exporting stored resource consumption statistics from the job accounting database. Job accounting logic is not included in the figures that appear later in this document because it does not apply to the interactions illustrated in those figures.

While management is active, the Windows System Resource Manager service continually monitors the resource usage of each managed process in the group. If a process momentarily exceeds its resource allocation, the service attempts to bring the resource usage of the process back to its specified target.

How the Service Matches Processes

A running process is matched when the Windows System Resource Manager service discovers it, or when the active resource-allocation policy is changed, which causes the service to re-poll all processes again. The system-defined exclusion list and the user-defined exclusion list are checked first and all matching processes are placed in the excluded processes group. Processes that do not match any process-matching criterion are automatically assigned to the default group. After a process is assigned to a group, the service enforces the associated resource allocation for the process by setting resource limits or modifying the priority of the process. No changes are ever made to processes in the system-defined exclusion list or the user-defined exclusion list.

The service makes no other changes to the process or the process-matching criterion unless the process-matching criterion or the resource-allocation policy is edited. Changes made to the user-defined exclusion list do not take effect until a new resource-allocation policy is set to manage, or the current resource-allocation policy is stopped and restarted. If either the process-matching criterion or the resource-allocation policy is edited, the service re-polls all of the processes running on the system following the standard allocation algorithm.

The Dynamic Process Priority Management Algorithm

During each poll, the service checks to determine whether the processes match their target allocations and whether any new processes have been created since the last poll.

If a process exceeds its target allocation, the service uses the dynamic process priority management algorithm to try to make the process conform to its target allocation. If changing the priority of the process does not make the CPU usage of the process conform to its target, the algorithm adjusts the target allocation of the process. It does so by using a process called re-allocation, which is described below.

If a new process is identified during the polling interval, the Windows System Resource Manager service takes the following steps to determine whether the new process should be managed:

  • The Windows System Resource Manager service matches the properties of the new process to each process-matching criterion in the managing policy. It does so in the order of the process-matching criteria that is specified in the resource-allocation policy.

  • When the properties of the new process are found to match a process-matching criterion, the new process is then grouped with other processes that have properties matching the same process-matching criterion. The new process is then subject to the resource allocations specified in the resource-allocation policy.

  • If the process does not match any of the process-matching criteria, it is added to the default group. Processes matching in the default group are given CPU bandwidth not allocated to other running processes. No memory limits are applied to processes in the default group.

Process-Matching Criterion

Process matching is the mechanism that Windows System Resource Manager uses to match processes and then aggregate them into groups to be managed.

A process-matching criterion creates an association between a group of one or more matched processes and a resource-allocation policy. Windows System Resource Manager then manages all of the matched processes using the resource allocations 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.

Windows System Resource Manager maintains the specified resource allocations until the managing policy is changed.

The following table defines the entries that each process-matching criterion can include.

Events for Process-Matching Criterion

Event Description

Included files or command lines

Lists wildcard or regular expression match strings.

Excluded files or command lines

Lists wildcard or regular expression match strings.

Included users or groups

Lists user account names or group account names.

Excluded users or groups

Lists user account names or group account names.

Windows System Resource Manager uses the following process to decide if a process matches a given process-matching criterion.

  • If the process-matching criterion has entries for included files or commands lines, Windows System Resource Manager attempts to match each match string against the process properties in the following order, stopping on the first match:

    1. Process file name

    2. Fully-qualified process path and file name

    3. Full process command line

  • If the process matches the included files or command-line entries, then Windows System Resource Manager attempts to match the entries for excluded files or command lines, if they are defined. The process for matching the excluded entries is identical to the process for included entries. If the process matches against the excluded entries, then the process is treated as one that does not match the process-matching criterion.

  • If the process-matching criterion has entries for included users or groups, Windows System Resource Manager matches each user or group name against the user account used to create the process, stopping on the first match. A user account matches if it is the same as the user account in the process. A group matches if the user account used to create the process is a member of the group. If the process matches against the excluded entries, then the process is treated as one that does not match the process-matching criterion.

  • If the process matches the included users or groups entries, then Windows System Resource Manager attempts to match the entries for excluded users or groups if they are present. The process for matching the excluded entries is identical to that of the included entries. If the process matches against the excluded users or groups entries, then the process is treated as one that does not match the process-matching criterion.

  • If both a files or command-line entry and user or group entry are provided, then both must match in order for the process to match the process-matching criterion.

Resource-Allocation Policies

A resource-allocation policy is the mechanism that specifies the resource usage for a managed process.

After a process-matching criterion is defined, it can be used by any number of resource-allocation policies. Only one resource-allocation policy can be in effect and managing at a time. The managing resource-allocation policy determines the resource usage for all managed processes, in other words, those processes not included in the system-defined or user-defined exclusion lists. A resource-allocation policy is an ordered list of resource allocations. Each resource allocation consists of a process-matching criterion and one or more allocations, such as a CPU consumption target, memory limit, or processor affinity. The allocations specified apply to all processes that match the process-matching criterion associated with the resource allocation.

The Default Group

All running processes that are not matched by any of the process-matching criteria in the managing resource-allocation policy are grouped in the default group.

The default group is allocated any CPU bandwidth that is unaccounted for by the managing policy. This bandwidth is distributed on an equal-shares basis. This ensures that all processes in the default group get an equal proportion of the total CPU bandwidth that is available to the default group. Windows System Resource Manager enforces this allocation, which prevents one or more applications in the default group from using more than their share of CPU bandwidth.

Exclusion Lists

While Windows System Resource Manager can effectively manage most applications, it is best not to use Windows System Resource Manager to manage processes that many applications depend on, such as Windows system services. This is likely to have adverse effects, so Windows System Resource Manager maintains a fixed list of Windows processes that should not be managed. This list is called the system-defined exclusion list. In addition, there is a user exclusion list intended for any other services or processes that might not behave properly under management. A process that is included on either of these lists is known as an unmanaged process.

The System-Defined Exclusion List

The system-defined exclusion list cannot be modified; however, you can exclude additional processes that you do not want Windows System Resource Manager to manage by manually adding them to the user-defined exclusion list.

To ensure that only designated system processes are excluded from being managed, the processes on the system-defined exclusion list are matched using the exact process path. This prevents other processes with similar names from being matched by mistake.

The following system processes are included by default on the system-defined exclusion list:

  • Csrss.exe

  • Dfssvc.exe

  • Dumprep.exe

  • Dwwin.exe

  • Llssrv.exe

  • Lsass.exe

  • Msdtc.exe

  • Smss.exe

  • Services.exe

  • Spoolsv.exe

  • System.exe

  • Taskmgr.exe

  • Winlogon.exe

  • Wmiprvse.exe

  • Wsrm.exe

  • Wsrmc.exe

The User-Defined Exclusion List

Processes on the user-defined exclusion list are either added manually or the system adds several processes by default. The processes included on the user-defined exclusion list by default are several Svchost.exe processes. Important operating system services run inside the Svchost.exe processes. To ensure that these processes have access to their required CPU bandwidth, they are excluded from management. It is not usually necessary to manage these processes; however, if one or more of these processes start to consume excessive CPU bandwidth, you can manage them by removing them from the user-defined exclusion list. This allows Windows System Resource Manager to control the CPU bandwidth usage of these processes.

Although it is rarely necessary, you can include processes on the user-defined exclusion list that do not respond well to management and any other processes that you do not want Windows System Resource Manager to manage. Processes that Windows System Resource Manager does not control are unmanaged and can, therefore, consume resources freely.

Because the behavior of unmanaged applications cannot be controlled, the effectiveness of Windows System Resource Manager can decrease if you include on the user-defined exclusion list multiple processes or processes that use resources intensively.

Calendar

The Windows System Resource Manager calendar schedules the automatic activation of resource-allocation policies. Policies can be activated on a one-time or recurring basis. Schedules provide flexibility to manage multiple resource-allocation policies and to activate various resource-allocation policies at different, predefined times over a 24-hour period.

When the calendar is enabled, and no policy is scheduled for the current time, the default calendar resource-allocation policy is in effect. The default calendar policy is configurable and can be a user-defined resource-allocation policy or the default calendar resource-allocation policy. The default calendar policy is configurable and can be set to any policy.

The following table describes the three types of calendar events you can use to schedule resource-allocation policies.

Types of Calendar Events

Type of Calendar Event Description

One time

Create a one-time calendar event to schedule one resource-allocation policy or schedule to run once. Requires a starting date and time and duration (or ending date and time), and a specified resource-allocation policy to run.

Recurring event

Create a recurring event to schedule one resource-allocation policy or schedule to run more than once. Requires a starting date and time and duration (or ending date and time), a recurrence pattern, a recurrence length, and a specified resource-allocation policy to run.

Schedule (day schedule applied to calendar dates)

Create a schedule to activate multiple resource-allocation policies to run over a 24-hour period. Policy schedules can be reused and applied to one or more dates on the calendar. You can change the date on which to apply the schedule without affecting the entire schedule.

Accounting

Windows System Resource Manager provides a mechanism to store and retrieve records of the behavior of managed processes. Accounting information is stored in an accounting database for easy administration and retrieval. This information is logged in the accounting database at a default interval of 10 minutes, which is configurable. The interval determines the frequency with which the data for all managed processes on the computer managed by Windows System Resource Manager is logged to the accounting database. With this information, process-resource usage reports can be generated on a per-user, per-application, or other relevant basis.

How CPU Resources Are Managed

CPU resources are represented as both a percentage of total CPU bandwidth and as a set of physical processors. These resources are controlled through the use of CPU consumption targets and processor affinity, respectively. Windows System Resource Manager uses the dynamic process priority management algorithm to determine how CPU bandwidth is allocated.

Managed CPU and Total CPU

CPU bandwidth targets in resource allocation policies are expressed as a percentage from 0 to 100. This represents the total managed CPU resources of the managed computer. The total bandwidth for both a one-processor system and an eight-processor system is 100 percent. The maximum CPU bandwidth percentage you can specify in a resource allocation, however, is 99 percent because a minimum of 1 percent is always reserved for the default group.

Managed CPU corresponds to the CPU bandwidth that is available to the processes Windows System Resource Manager is managing.

Total CPU corresponds to the total CPU bandwidth on the system. The total CPU resources available for Windows System Resource Manager to manage might not match the total CPU resources on the computer.

The difference between the managed CPU and the total CPU in a system is determined by how CPU is used by unmanaged and managed processes. Unmanaged processes can consume as much of the available CPU resources as needed. Windows System Resource Manager can manage only those CPU resources that are not being consumed by unmanaged processes. This means that the managed available CPU might be less than the total CPU available in the system. As the percentage of total CPU resources consumed by unmanaged processes increases, the ability of Windows System Resource Manager to meet target CPU allocations for managed processes decreases. Thus, if you limit the number of unmanaged processes in the system, you can maximize the accuracy of overall system resource management.

CPU Targets

To control the allocation of managed CPU, you can set CPU consumption targets for each resource allocation. The CPU consumption target is expressed as a percentage that corresponds to the total managed CPU available on the system when the resource allocation is created. After you create a CPU allocation, the consumption target percentage is deducted from the total available managed CPU resources. For example, if you create a resource allocation with 30 percent as the CPU consumption target, subsequent resource allocations will have only 69 percent available.

CPU consumption targets are applied to the group of processes matched by the resource allocation's associated process-matching criterion.

For example, if you create a resource allocation with a CPU consumption target of 10 percent CPU and a process-matching criterion that matches 10 processes, the 10 percent CPU is applied to the group of processes rather than to each process individually.

The distribution of CPU bandwidth among multiple processes in a group is controlled by the Management Rule property of each resource allocation. The Management Rule can take one of three possible values:

  • Standard. This is the default setting. It means that Windows System Resource Manager does not control the distribution of CPU bandwidth among processes in the group.

  • Equal per process. Windows System Resource Manager will manage individual processes in the group according to equal targets, each an equal share of the group's target.

  • Equal per user. Windows System Resource Manager will manage sub-groups of processes in the group, assigning equal shares according to the user that started the process.

Allocation

In order to manage processes toward their CPU allocation targets, Windows System Resource Manager samples the CPU consumption of all managed processes in the system and computes a moving average of each over the last few samples. The priorities of processes consuming above their targets are lowered to prevent the consumption of CPU bandwidth that is allocated to other processes. Similarly, processes consuming below their targets have their priorities raised to give them better access to CPUs in the system. Processes that are unable to consume their allocated CPU bandwidth, even after appropriate priority adjustments have been made to the priorities of other processes, will have their unconsumed allocation re-allocated to other processes. This occurs according to the proportions specified in the resource allocations.

Sub-allocation

A sub-allocation is a subdivision of a resource allocation. Each subdivided resource allocation is referred to as the parent allocation, and each of its sub-allocations is a child resource allocation. Sub-allocations can be further subdivided, so there is no effective limit to the size of the resource hierarchy. A sub-allocation behaves similarly to a resource allocation; however, its CPU percentage targets are interpreted as a percentage of its parent's CPU allocation, rather than a percent of the managed CPU of the whole machine.

In a sub-allocation, CPU resources are allocated first to the child resource-allocation policies, starting with the child that is at the bottom of the hierarchy. This last child in the hierarchy gets as close to its specified CPU allocation as possible. The remaining CPU resources that this last child does not use become available to its parent. The parent consumes bandwidth up to its specified CPU allocation. Any remaining CPU bandwidth then becomes available to its parent, if one exists. If a parent does not exist, the remaining CPU resources are allocated back to the default group.

The only relationship between an allocation and its parent or sub-allocation concerns CPU bandwidth. That is, although an allocation and its parent or sub-allocation share the same CPU bandwidth, the processes matched to these allocations are different.

Priority-order Chain

You can use resource sub-allocation to create a specific type of resource-allocation hierarchy called a priority-order chain.

You can configure a single resource allocation with multiple child resource allocations, each with its own relative allocation. Doing so, you can create a hierarchy.

To create the priority-order chain, you order the sub-allocations in increasing priority as you move down the hierarchy. That is, the lower priority resource allocation should be matched at the higher levels, and the higher-priority resource allocation should be matched at the lower levels of the hierarchy.

This is illustrated in the following example:

  • A resource-allocation named ra0 is created with a process-matching criterion named pmc0 and allocated 30 percent of CPU.

  • A sub-allocation named sub_ra1 is created for a different process-matching criterion, such as pmc1; it is allocated 20 percent of CPU.

  • In turn, sub_ra1 has a sub-allocation named sub_ra2 with a different process-matching criterion, such as pmc2, and is allocated 30 percent of CPU.

  • sub_ra2 has a sub-allocation named sub_ra3 with yet another process-matching criterion, such as pmc3, and is allocated 40 percent of CPU.

  • The resource sub-allocations are numbered in an increasing order that corresponds to their preferred relative priority. Each sub-allocation and associated process-matching criterion have a higher precedence than their associated parent resource allocation, which is described as follows:

    • sub_ra3 has the highest relative priority and will consume up to 40 percent of the total CPU bandwidth allocated in the policy.

    • sub_ra2 can consume 30 percent of the remaining total bandwidth allocated that was not consumed by sub_ra3.

    • sub_ra1 can consume 20 percent of the remaining total bandwidth allocated in the policy that was not consumed by sub_ra2 and sub_ra3.

    • ra0 has the lowest relative priority and will be able to consume only 10 percent of the total bandwidth allocated in the policy, assuming there is any that is unused by its sub-allocations, because the remaining 90 percent of the total bandwidth available to the entire resource allocation is allocated to its sub-allocations.

If any of the sub-allocations cannot use all of their allocation, the unused percentage is returned to the parent allocation. This process continues until either an allocation can use the unused allocation, or the parent allocation is the default group. In the latter case, the unused allocation is redistributed in the usual procedure as defined by the standard allocation algorithm.

Re-allocation

The amount of CPU bandwidth a process consumes does not always match its allocation. If a process cannot consume any part of its CPU bandwidth allocation, the unconsumed portion is re-allocated to other processes that can consume it. This is known as resource re-allocation.

The resource re-allocation sequence occurs as follows:

  • The unconsumed allocation is passed from the process to its parent process-matching criterion and any sibling process-matching criteria that might exist. Other processes matched by either the parent or sibling process-matching criteria can then try to use the unconsumed allocation. The unconsumed allocation is redistributed to the other processes in proportion to their CPU consumption targets, as specified in the resource-allocation policy. For example, if a policy has resource allocations with process-matching criterion A allocated 20 percent and B allocated 40 percent, it would also implicitly have the default group at 40 percent. If the default group is only able to consume 20 percent, but A and B could each consume more than their allocation, then the other 20 percent not used by default would be reallocated to A and B proportionally. Process-matching criterion A would get one-third of the 20 percent, and B would get the other two-thirds.

  • If the processes matched by either the parent or sibling process-matching are unable to use all of the unconsumed re-allocation, the remaining unused portion is passed to the parent of the parent process-matching criterion.

  • The re-allocation sequence continues until the re-allocation is consumed or the process-matching criterion has no parent. In the latter case, the unconsumed allocation is distributed among all top-level process-matching criteria, including the default group.

When a process attempts to use more than the allocated CPU bandwidth, Windows System Resource Manager lowers the priority of that process. This allows competing processes to use the CPU bandwidth equal to the difference between all remaining CPU bandwidth and the CPU bandwidth allocated to the process.

If a process is using less bandwidth than its allocated amount, the extra bandwidth is re-allocated to other managed processes. This occurs according to the default bandwidth allocation rules.

Because Windows System Resource Manager attempts to meet the CPU needs of running processes, it does not prevent an application from using unconsumed CPU bandwidth that no other process is using. Instead, a process is limited to its allocation only if there is not enough CPU bandwidth to satisfy the CPU demands of every running process.

CPU Consumption Target Interactions

In the following figure, a resource allocation policy is running and includes a CPU consumption target. To achieve the target CPU consumption, the Windows System Resource Manager service sends information to the kernel scheduler to control how managed processes are scheduled for CPU resources.

Interactions that Occur When a CPU consumption Target Is Set

Interactions When Setting CPU Consumption Target

How Memory Resources Are Managed

In Windows System Resource Manager, memory-allocation policies are configurable properties in a resource allocation. Memory-allocation policies limit the amount of working set memory and committed memory processes are allowed to consume.

Limits are applied on a per-process basis. For example, if you create a resource allocation that specifies a working set limit of 10 megabytes (MB) and a process-matching criterion that matches six processes, the limit of 10 MB is applied individually to each of the six processes.

Working Set Memory

You can set an upper limit on the process working set of the resource-allocation policy's process groups. Through the memory manager, Windows System Resource Manager prevents the working set of a process from exceeding the limit defined in the resource allocation. If the limit is reached, subsequent memory allocations do not fail, but existing pages in the working set of the process are replaced. This meets the memory limit without inducing any failures in the running application. Applications are generally unaware that the memory manager is reusing physical memory because applications are running in a virtual memory space.

Committed Memory

You can set an upper limit on the committed memory that a process consumes. Typically, if there is a constant increase in the committed memory a process consumes, it is due to a memory leak. By setting a limit on the amount of committed memory a process consumes, you can have Windows System Resource Manager intervene if a memory leak occurs. When the limit is reached, Windows System Resource Manager can either terminate the process or log an error in the event log.

The Windows System Resource Manager service maintains the committed memory limits in the current active resource allocation policy and actively monitors the committed memory usage of each matching process to determine when the limit is reached.

Memory Limit Interactions

Windows System Resource Manager enforces limits on committed memory and working set memory for processes. Windows System Resource Manager is not involved in the actual allocation of memory to a process, other than to signal the memory manager when there are memory limits in the currently active policy to be enforced. If the memory manager receives a signal from Windows System Resource Manager that a process is exceeding its memory limit, it will not allocate additional memory to a process.

In the following figure, a resource allocation policy is running and includes a memory limit.

Interactions That Occur When a Memory Limit Is Set

Interactions That Occur When a Memory Limit Is Set

Network Ports Used by Windows System Resource Manager

Windows System Resource Manager uses only the ports already used by the Distributed Common Object Model (DCOM) service running on the computer. For more information about the ports used by DCOM, see “Using Distributed COM with Firewalls” at the Microsoft Web site.