Defining resource groups

A resource group is an amount of processor capacity and/or memory. It is optional. Unless you have some special need to limit or protect processor capacity or memory for a group of work, you should skip defining resource groups and let workload management manage all of the processor and memory resource to meet performance goals. You use a resource group to:

Limit the amount of processor capacity available to one or more service classes.
Set a minimum for processor capacity for one or more service classes if the work is not achieving its goals.
Define a minimum and maximum amount of processor capacity sysplex-wide, or on a system level.
Specify whether capacity values of the resource groups apply to general purpose processors only or to general purpose and specialty processors.
Limit the amount of memory capacity that is available to one or more service classes on a system level.

You can specify a minimum and maximum amount of processor capacity and a maximum amount of memory to a resource group. You can assign only one resource group to a service class. You can assign multiple service classes to the same resource group. You can define up to 32 resource groups per service definition.

Keep in mind your service class goals when you assign a service class to a resource group. Given the combination of the goals, the importance level, and the resource capacity, some goals might not be achievable when capacity is restricted.

Setting a maximum processing capacity

If work in a resource group is consuming more processor resources than the specified maximum processor capacity, the system caps the associated work accordingly to slow down the rate of processor resource consumption. The system might use several mechanisms to slow down the rate of processor resource consumption, including swapping the address spaces, changing their dispatching priority, and capping the amount of processor service that can be consumed. Reporting information reflects that the service class might not be achieving its goals because of the resource group capping.

Setting a minimum processing capacity

By setting a minimum processing capacity, you create an overriding mechanism to circumvent the normal rules of importance. If the work in a resource group is not meeting its goals, then workload management attempts to provide the defined minimum amount of CPU resource to that work.

Setting a memory limit

By specifying a memory limit, you explicitly restrict the use of real memory of work that runs in address spaces that are associated with the resource group through classification. For a resource group with a memory limit, the system creates a memory pool. A memory pool does not reserve real memory for use by the pool, but rather tracks the aggregate usage in order to limit the total usage by address spaces connected to the pool.

An address space that is associated with the resource group through classification connects to the memory pool when the address space, or a new job, starts. In that case, all its frames are counted toward the pool limit. When a memory pool approaches its limit, the system takes actions such as initiating self-stealing to page out memory pool pages and thus free up memory pool frames. This protects the real memory allocation of other work that is running on the system.

An address space can be switched to another memory pool or back to system storage either by activating another service policy, or resetting it to another service class.

IBM recommends that you use memory pools only when it is required to limit the use of memory by workloads and for applications which provide guidance on how to operate them in a memory pool.

When you install and activate a service definition that deletes an existing resource group with a memory limit, the system defers deletion of the associated memory pool until all address spaces associated with the memory pool disconnect and end.

When a memory pool approaches its limit, address spaces starting up and connecting to the pool are deferred until enough frames are available through self-stealing from the pool.

Defining resource groups
Name Resource Group name Description Description of resource group Resource Group Type Description of resource group type Capacity Maximum Can be calculated in various ways, depending on which resource group is used, and is explained in the following. Capacity Minimum Can be calculated in various ways, depending on which resource group is used, and is explained in the following. Include Specialty Processor Consumption Specifies whether minimum and maximum capacity applies to the sum of general purpose processors and specialty processor consumption. Memory Limit Maximum amount of real memory the address spaces that are associated with the resource group through classification may use on the local system. The value has a system scope.

Defining resource groups

Name: Resource Group name
Description: Description of resource group
Resource Group Type: Description of resource group type
Capacity Maximum: Can be calculated in various ways, depending on which resource group is used, and is explained in the following.
Capacity Minimum: Can be calculated in various ways, depending on which resource group is used, and is explained in the following.
Include Specialty Processor Consumption: Specifies whether minimum and maximum capacity applies to the sum of general purpose processors and specialty processor consumption.
Memory Limit: Maximum amount of real memory the address spaces that are associated with the resource group through classification may use on the local system. The value has a system scope.

Name

Eight characters that identify the name of the resource group. Each resource group must be unique within a service definition.

Description

Up to 32 characters that describe the resource group.

Resource Group Type

Resource groups allow to define a guaranteed maximum and minimum CPU consumption for work on the sysplex and on each individual member of the sysplex. This allows to:

Prioritize work on a system-level basis.
Control the minimum and maximum resource consumption.

The following types of resource groups are valid:

Resource Group Type 1

The capacity is specified in unweighted CPU service units per second, the value must be between 0 and 99999999.

Start of change Minimum and maximum capacity applies sysplex-wide, that is, WLM ensures that the limits are met within the sysplex. End of change

The table in CPU capacity table shows the service units per second by CPU model.

Resource Group Type 2

The capacity is specified as a percentage of the LPAR share in the general purpose processor pool, the value must be between 0 and 99999. To accommodate specialty processor capacity, values greater than 100 may be specified. End of change

Minimum and maximum capacity has a system scope, that is, WLM ensures that the limits are met on each system within the sysplex. Refer to Calculating an LPAR share — Example 1 for a scenario showing how to calculate an LPAR share when using resource group type 2.

Resource Group Type 3

The capacity is specified as a number of general purpose processors (CPs), a number of 100 represents the capacity of 1 CP. The number should be between 0 and 999999. Start of change

To accommodate specialty processors that run at a different speed, a number greater than 100 must be specified to represent the capacity of one specialty processor. Refer to Specifying the capacity as a number of CPs — Example 2 for a scenario showing how to calculate a number of CPs when using resource group type 3. End of change

Minimum and maximum capacity has a system scope, that is WLM ensures that the limits are met on each system within the sysplex.

Resource Group Type 4

The capacity is specified in accounted workload MSU that is based on captured time. Minimum and maximum capacity is processor consumption that is expressed in million service units per hour and applies sysplex-wide, that is, WLM ensures that the limits are met within the sysplex. Minimum and maximum must be a value between 0 and 999999.

Resource group type 4 is intended to simplify the specification of a limit expressed in MSU. This limit only applies to captured TCB and SRB times. System management time, also known as uncaptured time, is not included. Furthermore, this limit is managed on a short interval. Thus, it is no four-hour rolling average MSU consumption.

The CPU capacity table shows the service units per second by CPU model. Also, refer to Large Systems Performance Reference for IBM Z at https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprindex Start of change to determine the MSU rating of your sysplex. End of change

Capacity

Identifies the amount of available capacity you want workload management to allocate to the resource group. Capacity includes cycles in both TCB and SRB mode. The table in CPU capacity table shows the service units per second by CPU model. Resource group minimum can equal resource group maximum.

Maximum: CPU service that this resource group might use. Maximum specified for this resource group applies to all service classes in that resource group combined. Maximum is enforced. There is no default maximum value. If specified, Maximum must be greater than 0.
Minimum: CPU service that should be available for this resource group when work in the group is missing its goals. The default is 0. If a resource group is not meeting its minimum capacity and work in that resource group is missing its goal, workload management attempts to give CPU resource to that work, even if the action causes more important work (outside the resource group) to miss its goal. If there is discretionary work in a resource group that is not meeting its minimum capacity, WLM attempts to give the discretionary work more CPU resource if that action does not cause other work to miss its goal.
The minimum capacity setting has no effect when work in a resource group is meeting its goals.
Memory Limit: Maximum amount of memory that address spaces that are associated with the resource group through classification might consume on the local system. The attribute is specified as absolute value in GB. The attribute value has system scope.
Include Specialty Processor Consumption: The attribute specifies whether capacity minimum and maximum apply not only to general purpose processors but also to specialty processors. The default is no, which ignores CPU consumption of specialty processors when managing the guaranteed minimum and maximum capacity. If yes is specified, the total CPU consumption on general purpose and specialty processors is applied.

Note:

You cannot assign a resource group to service classes representing transaction-oriented work, such as CICS or IMS transactions. The ISPF application notifies you with an error message if you attempt to do so. If you want to assign a minimum or a maximum processor capacity and a maximum amount of memory to CICS or IMS work, you can do so by assigning a resource group to their regions. For example, suppose that you have three service classes representing your CICS works: CICSTRN, CICSAORS, and CICSTORS. CICSTRN represents all of your online CICS transactions, and has one period with a short response time goal. CICSAORS and CICSTORS represent all of your CICS AOR and TOR regions, respectively, that process the online transactions. To assign a maximum processor capacity and a maximum amount of memory to your CICSTRN work, define a resource group, and assign it to the regions. So you assign the resource group to the CICSAORS and CICSTORS service classes.
Similarly, resource groups with a memory limit cannot be applied to enclave service classes. However, because enclave service classes can be used anywhere, unlike CICS or IMS transaction service classes, the ISPF application does not notify you with an error message if you attempt to do so. As for CICS or IMS, a resource group with a memory limit must be assigned to the service class of the address spaces that join the enclaves.
A memory limit overrules the storage critical attribute assigned in classification rules and also any protective storage target managed through SRM.
Resource group processor capacity capping is implemented by marking the work units that belong to resource group non-dispatchable for some time slices and dispatchable for the remaining time slices (awake slices). Depending on the configuration, it might not be possible to enforce very low resource group limits. The granularity to which a resource group limit can be managed depends on how much service the work can consume in a system or across the Sysplex, respectively, during one awake time slice. Beginning with z/OS V2.1 the granularity of awake slices is 1/256 of the time.
When resource groups are managed based on the general purpose processor service (the attribute, Include Specialty Processor Consumption, specifies no) the dispatchability attribute is also honored by zAAP and zIIP processors.
Resource group capping will not be enforced while system recovery boost is active in a partition.