Overview of Resource Governor
Resource
Governor works by controlling the allocation of resources according to
workloads. When a connection request is submitted to the Database
Engine, the request is classified based on a classification function.
The classification function is a scalar function that you define via
T-SQL. The classification function evaluates information about the
connection (for example, login ID, application name, hostname, server
role) to determine how it should be classified. After the connection
request is classified, it is routed to a workload group defined for that
classification (or if the connection cannot be classified, it is routed
to the default workload group). Each workload group is associated with a
resource pool. A resource pool represents the physical resources of SQL
Server (currently in SQL Server 2008, the only physical resources
available for configuration are CPU and memory) and specifies the
maximum amount of CPU and/or memory resources that are to be allocated
to a specific type of workload. When a connection is classified and put
into the correct workload group, the connection is allocated the CPU and
memory resources assigned to it, and then the query is passed on to the
query optimizer for execution. This process is illustrated in Figure 1.
Resource
Governor is designed to address the following types of resource issues,
which are commonly found in a database environment:
Runaway queries— These resource-intensive queries can take up most or all of the server resources.
Unpredictable workload execution—
This situation occurs when you have concurrent applications on the same
server that are not isolated from each other, and the resulting
resource contention causes unpredictable performance.
Workload prioritization—
You might want to ensure that a critical workload is given priority to
the system resources so it can process faster than other workloads or is
guaranteed to complete if there is resource contention.
In addition to
enabling you to classify incoming connections and route their workloads
to a specific group, Resource Governor also enables you to do the
following:
Monitor resource usage for each workload in a group
Pool
resources and set pool-specific limits on CPU usage and memory
allocation, which can prevent or minimize the probability of runaway
queries
Associate grouped workloads with a specific pool of resources
Identify and set priorities for workloads
The current release of Resource Governor has the following limitations:
Resource allocation is
only for CPU and memory usage. There is no support for managing network
and disk I/O resource utilization.
Resource
Governor manages only resource consumption of the Database Engine. You
cannot use Resource Governor to manage workloads within SSAS, SSIS, or
SSRS.
In
the following sections, you learn how to set up and configure Resource
Governor for use, how Resource Governor works under the hood, and how
you can use Resource Governor to better prioritize and manage a SQL
Server’s workload.
Resource Governor Components
Resource Governor
consists of three main components: classification, workload groups, and
resource pools. Understanding these three components and how they
interact is important to understanding and using Resource Governor.
Classification
Classification
is the process of evaluating incoming user connections and assigning
them to a workload group. Classification is performed by logic contained
in a user-defined function. The function returns the workload group
name, which Resource Governor uses to route the sessions into the
appropriate workload groups.
When Resource Governor is configured, the login process for a session consists of the following steps:
1. | Login authentication
|
2. | LOGON trigger execution
|
3. | Classification
|
Workload Groups
Workload groups
are the containers for similar connections, which are grouped together
as similar according to the classification criteria applied to each
connection. A workload group also provides the mechanism for aggregate
monitoring of resource consumption.
Resource Governor
has two predefined workload groups: the internal group and default
group. The internal workload group is used solely by internal Database
Engine processes. You cannot change the classification criteria for the
internal group, and you also cannot classify any user requests for
assignment to the internal group. You can, however, monitor the internal
group.
Connection requests are automatically classified into the default group when the following conditions exist:
There are no criteria to classify a request.
There is an attempt to classify the request into a nonexistent group.
There is a general classification failure.
Resource governor supports a
total of 20 workload groups. Because two of them are reserved for the
internal and default workload groups, a total of 18 user-defined
workload groups can be defined.
Resource Pools
A resource pool, or pool, represents the allocation of physical resources of the SQL Server. A resource pool has two parts:
The first part specifies the minimum resource reservation. This part of the resource pool does not overlap with other pools.
The
other part specifies the maximum possible resource reservation for the
pool. The resource allocation is shared with other pools.
In SQL Server 2008 and SQL Server 2008 R2, the pool resources are set by specifying a MIN or MAX allocation for CPU and a MIN or MAX allocation for memory. The MIN setting specifies the minimum guaranteed resource availability of the pool. The MAX setting sets the maximum size of the pool for each of the resources.
Because there cannot be any overlap in the minimum resource reservation, the sum of the MIN
values across all pools cannot exceed 100% of the total server
resources. The ensures that each pool is guaranteed the specified
resource allocation.
The MAX value can be set anywhere in the range between the MIN value and 100% inclusive. The MAX
setting represents the maximum amount of resources a session can
consume, as long as the resources are available and not in use by
another pool that is configured with a nonzero MIN value. When a pool
has a nonzero MIN percentage defined, the effective MAX value of other pools is readjusted down, as necessary, to the existing MAX value minus the sum total of the MIN values of other pools.
For example, consider you have two user-defined pools. One pool, Pool1, is defined with a MIN setting of 20% and a MAX setting of 100%. The other pool, Pool2, is defined with a MIN setting of 50% and a MAX setting of 70%. The resulting effective MAX setting for Pool1 is 50% (100% minus the MIN 50% of Pool2). The effective MAX setting of Pool2, however, remains at 70% rather than 80% because 70% is the configured MAX value of Pool2.
The shared part of the pool (the amount between the MIN and effective MAX
values) is used to determine the amount of resources that can be
consumed by the pool if the resources are available and not being
consumed by another pool. When resources are consumed by a pool, they
are assigned to the specified pool and are not shared until processing
completes in that pool.
To illustrate this further, consider a scenario in which there are three user-defined resource pools:
PoolA is defined with a MIN % of 10 and MAX % of 100.
PoolB is defined with a MIN % of 35 and a MAX % of 90.
PoolC is defined with a MIN % of 30 and a MAX % of 80.
The effective MAX of PoolA would be calculated as follows:
| MAX % of PoolA | 100 |
| minus MIN % of PoolB | 35 |
| minus MIN % of PoolC | 30 |
| equals EFF MAX of PoolA | 35 |
The total Shared % of resources of PoolA would then be calculated as follows:
| Effective MAX % of PoolA | 35 |
| minus MIN % of PoolA | 10 |
| equals Shared % of PoolA | 25 |
Table 1 illustrates the calculated effective MAX and Shared % values for all pools in this configuration.
Table 1. Effective MAX and Shared % Values for Multiple Pools
| ResourcePool | MIN % | MAX % | Effective MAX % | Shared % |
|---|
| Internal | 0 | 100 | 100 | 100 |
| Default | 0 | 100 | 25 | 25 |
| PoolA | 10 | 100 | 35 | 25 |
| PoolB | 35 | 90 | 50 | 15 |
| PoolC | 30 | 80 | 35 | 5 |
To coincide with the
predefined workload groups, Resource Governor also has two predefined
resource pools: the internal pool and default pool.
The internal pool
represents the resources consumed by the internal processes of the
Database Engine. This pool always contains only the internal group, and
the pool is not alterable in any way. The Internal Pool has a fixed MIN % of 0 and a MAX %
of 100, and resource consumption by the internal pool is not restricted
or reduced by any settings in other pools. In other words, the
effective MAX of the Internal Pool is
always 100%. Any workloads in the internal pool are considered critical
for server function, and Resource Governor allows the internal pool to
consume 100% of available resources if necessary, even if it means the
violation of the resource requirements of the other pools.
The default pool is the first
predefined user pool. Prior to any configuration, the default pool
contains only the default group. The default pool cannot be created or
dropped, but it can be altered. The default pool can contain
user-defined groups in addition to the default group.
Now
that you have an understanding of the Resource Governor components,
let’s put them into use by enabling and setting up some resource groups.
