Group capacity limit is an extension of the defined capacity limit. It allows an installation to define a “soft cap” for multiple logical partitions of the same CPC (all running z/OS® V1R8 or later). The group limit is a defined capacity (soft cap) for all partitions defined in the group. The capacity group is defined on the Hardware Management Console (HMC). Each capacity group has a name and a defined capacity which becomes effective to all partitions in the group.
See PR/SM™ Planning Guide for more information about how to define a capacity group.
WLM uses the weight definitions of the partitions and
their actual demand to decide how much capacity may be consumed by
each partition in the group. In the following example a capacity group
is defined which consists of three partitions MVS1, MVS2 and MVS3.
The group limit is defined to 50 MSU and the weights of the partitions
are shown in Table 1: | Partition | Weight | Share (MSU) |
|---|---|---|
| MVS1 | 100 | 16,7 |
| MVS2 | 50 | 8,3 |
| MVS3 | 150 | 25 |
zEC12 (GA2) and later systems support the use of the
initial weight for sharing the group limit. If all partitions of the
capacity group are running on this hardware and if all of them also
have the required software support installed ( z/OS V2R1, z/OS V1R12/13
with OA41125), the initial weight will be used instead of the current
weight to calculate the share of the partitions.
The total weight of all partitions in the group is 300. Based on the weight definitions, each partition gets an entitled share of the group capacity of 50 MSU. The entitled share is important to decide how much MSU can be used by each partition if the 4-hour rolling average of the group exceeds the group capacity limit. The share is also shown in Table 1.
Figure 1 shows an example how the partitions use their entitled capacity. At 07:00 p.m. all three partitions are started. In the beginning, only partition MVS1 and MVS2 use approximately 60 MSU. No work is running on partition MVS3. Therefore its measured consumption is very small. WLM starts to cap the partitions when the 4-hour rolling average for the combined usage exceeds the 50 MSU limit. This happens around 09:00 p.m. At that point, MVS1 is reduced to about 30 MSU and MVS2 to about 20 MSU. MVS3 still does not demand much CPU. Therefore the available MSU of the group can be consumed by MVS1 and MVS2.
Around 11:00 p.m. work is started on MVS3. A small spike can be observed when WLM recognizes that the third partition starts to demand its share of the group. After that spike MVS3 gets up to 25 MSU of the group because its weight is half of the group weight. MVS1 is reduced to 16.7 MSU and MVS2 to 8.3 MSU. Based on variation in the workload the actual consumption of the partitions can vary but the group limit of 50 MSU is always met on average.
The work on MVS3 stops around 04:00 p.m. At that point, a small negative spike can be observed and afterwards the capacity is consumed again only by the partitions MVS1 and MVS2.
- Group capacity can be combined with an individually defined capacity for a partition. The partition will always honor the individually defined capacity.
- It is possible to define multiple capacity groups on a CPC. A partition can only belong to one capacity group at a given point in time.
- The partitions must not be defined with dedicated processors.
- The partitions must run with shared CPs and wait completion must be No.
- The operating system must be z/OS V1R8, or higher.
- A hardware cap (that is, Initial Capping checked on the Change Logical Partitions Controls panel) which limits the partition to its weight is not allowed for a partition being managed in a capacity group.
All partitions which do not conform to these rules are not considered part of the group. WLM will dynamically remove such partitions from the group and manage the remaining partitions towards the group limit.
Group capacity functions together with IRD weight management while the partitions in the group are not subject to capping. No weight moves take place for partitions as long as the group is being capped.
Group capacity does not work when z/OS is running as a z/VM® guest system.