Hard CPU shares

The Db2® workload management dispatcher can manage CPU resources using shares-based entitlements that are assigned to service classes and databases. Hard CPU shares, when assigned to a service class or database containing work viewed by the administrator as high impact or lower priority, prevents that service class or database from consuming more than its share of CPU resources whenever there is work in other service classes and databases running on the system.

Introduction

Hard CPU shares can be assigned to any user-defined service class, the default user service class, the default maintenance service class, or at the database level. However, hard CPU shares cannot be assigned to the system service class. After enabling the workload management dispatcher, monitoring your existing workloads to determine the extent of CPU resource consumption, and enabling the CPU shares attribute for service classes or databases, you can assign hard CPU shares to the service classes or databases that you consider to be running lower-priority or high-impact work. Using hard CPU shares ensures that the CPU consumption of these service classes or databases is limited in the presence of other workloads, both limiting their impacts on the system, and ensuring that the remaining CPU is reserved for other higher priority work.

The sections that follow describe the features and functionality of the hard CPU shares in more detail. A usage scenarios section helps to illustrate the hard CPU shares features and functionality with usage examples.

Features and functionality

When the host or logical partition (LPAR) is running at 100% CPU utilization, the allocation of CPU resources between service classes and databases simply reflects their relative share percentages. On the other hand, when the host or LPAR begins to run below full CPU utilization, the reallocation of CPU resources is complex and dependent on whether the CPU shares attribute on each active service class and database is set to soft or hard CPU shares.

A service class or database with hard CPU shares assigned cannot exceed its CPU resource entitlement, indicated by its CPU shares configuration, to consume any unused CPU resources that become available on the host or LPAR. The workload management dispatcher always respects the CPU resource entitlement, determined by the relative amount of hard CPU shares that were assigned, when work is still running in competing service superclasses or databases, or running in competing service subclasses within the same service superclass. If competing workloads are not present or a competing workload temporarily becomes totally idle, service classes and databases with hard CPU shares are able to claim unused CPU resources.

The hard CPU shares setting is most effective when used in cases where you want to strictly enforce the CPU resource entitlement on a service class to prevent work running in this service class from interrupting more important work running on the host or LPAR. Assign hard CPU shares to service classes that run complex or intensive queries that might otherwise degrade the performance of higher priority work due to contention on resources such as I/O, bufferpool, or CPU caches.

Hard CPU shares can also be set at the database level. User-defined CPU resource division between different databases allows strict enforcement of shares entitlement. Like hard CPU shares in service classes, you can set hard CPU shares at the database level to control work and prevent performance degradation.

To enable the CPU shares attribute, you must set the value of the wlm_disp_cpu_shares database manager configuration parameter to YES. The default setting for this parameter is NO. CPU shares are not supported in an environment where WLM Admission Control is enabled. WLM Admission Control is enabled when the database manager configuration parameter wlm_admission_ctrl is set to YES. After this parameter has been enabled, all existing and newly created service classes are assigned 1000 hard CPU shares by default to initially ensure an equal distribution of CPU resources. Similarly, all new databases are assigned 1000 hard CPU shares by default, so that CPU resources are initially distributed equally among databases. You can assign and adjust hard CPU shares:

At the service class level, use the CREATE SERVICE CLASS and ALTER SERVICE CLASS statements.
At the database level, use the wlm_cpu_shares and wlm_cpu_share_mode database configuration parameters.

For more information about how to enable and set hard CPU shares, see: Enabling and setting CPU shares.

Based on the number of shares that are assigned at the database level, the workload management dispatcher calculates the portion of CPU resources available to each database. To determine the portion of CPU resources for an individual database, use the following formula:

P_db = (N_db / N_alldb) x 100

where:

P_db = Percentage of the CPU for the database
N_db = Number of CPU shares of the database
N_alldb = Total number of CPU shares of all active databases

Based on the number of CPU shares assigned to a service class, the workload management dispatcher calculates the proportion of the CPU resources that each service class is entitled to use. To determine the proportion of the CPU resources to which each service superclass is entitled, use the following formula to convert the number of CPU shares of a particular service superclass into the percentage of the total CPU resources allocated by the workload management dispatcher:

P_sup = (N_sup / N_allsup) x 100

where:

P_sup = Percentage of the CPU for the superclass
N_sup = Number of CPU shares of the superclass
N_allsup = Total number of CPU shares of all active superclasses

To determine the proportion of the CPU resources to which each service subclass is entitled, use the following formula to convert the number of CPU shares of a particular service subclass into a percentage of CPU resources allocated by the workload management dispatcher:

P_sub = P_sup x (N_sub / N_allsub)

where:

P_sub = Percentage of the CPU for the subclass
P_sup = Percentage of the CPU for the superclass
N_sub = Number of CPU shares of the subclass
N_allsub = Total number of CPU shares of all active subclasses in the superclass

Usage scenarios

Scenario 1

In Figure 1 panel A, service class B has been assigned hard CPU shares and service classes A and C have been assigned soft CPU shares, the amounts of which are described in the figure legend. The pie chart represents the proportion of allocated CPU resources to which each of these active service classes are entitled and each service class is using their complete share of the CPU resources, therefore summing to 100% CPU utilization in this example. In panel B, service class A does not have enough work to fully use its CPU entitlement, dropping from 60% to 50% CPU utilization. The unused 10% of the CPU resources, temporarily relinquished by service class A, can be claimed by only the competing service class C based on its soft CPU shares assignment. Service class B cannot exceed its CPU resource allocation of 30% in this example because it has hard CPU shares assigned and there is enough work running in service classes A and C for those service classes to be considered active by the dispatcher. Panel C shows the total reallocation of CPU resources to service class C, increasing from 10% to 20% of the total available CPU resources.

If service class A experiences an increase in its workload, it effectively increases its demand on CPU resources. In this circumstance, service class C immediately relinquishes to service class A all of the claimed CPU resources, thereby restoring the state of CPU resource allocations to that which is depicted by the pie chart in panel A.

Note: When service classes compete to consume CPU resources, individual service class requests for CPU resources is handled by the workload management dispatcher in a first-come-first-served fashion. Due to typically frequent and short-lived requests for CPU resources on a busy host or LPAR, the reallocation of unused CPU resources over time results in a smooth redistribution of CPU resources which is in proportion to the relative CPU shares assignments.

Scenario 2

The use of hard shares can result in some portion of the CPU resources to remain under-utilized on the database server. Under-used CPU resources can occur in cases where the other service classes were not running a large enough workload to fully use their CPU resource allocations. Under-used CPU resources are desirable in cases where the hard shares are being used to limit an intensive workload that might otherwise interfere with the progress of other service classes, even when the CPU resources are below full utilization. This circumstance generally occurs due to contention on resources such as I/O or the CPU cache.

In Figure 2 panel A, service classes B and C have been assigned hard CPU shares and service class A has been assigned soft CPU shares, the amounts of which are described in the figure legend. The pie chart represents the proportion of allocated CPU resources to which each of these active service classes are entitled and each service class is using their complete share of the CPU resources, therefore summing to 100% CPU utilization in this example. In panel B, service class A does not have enough work to fully use its CPU entitlement, dropping from 60% to 50% CPU utilization. The unused 10% of the CPU resources, temporarily relinquished by service class A, cannot be claimed by the competing service classes B and C based on their hard CPU shares assignment. Service classes B and C cannot exceed their CPU resource allocations of 30% and 10%, respectively, in this example because they both have hard CPU shares assigned and there is enough work running in service class A for it to be considered active by the dispatcher (CPU utilization falls below the level configured for the wlm_disp_min_util database manager configuration parameter; default is 5%). Panel C shows that the unused CPU resources are not reallocated and the CPU resources remain under-utilized in this scenario.

Figure 2. Hard and soft CPU shares pie charts: Scenario 2

This scenario shows that you can protect the progress of work running in a high-priority service class from interruptions by work running in low-priority service classes.

Scenario 3

Hard CPU shares offer benefits over traditional fixed percentage CPU limits. In the absence of other workloads, the service class with hard CPU shares has the flexibility to claim unused CPU resources. Therefore, a service class with a hard CPU shares assignment is not artificially limited when other work is not present on the host or LPAR as that which occurs for a service class with fixed CPU limits.

In Figure 3 panel A, service classes B and C have been assigned hard CPU shares and service class A has been assigned soft CPU shares, the amounts of which are described in the figure legend. The pie chart represents the proportion of allocated CPU resources to which each of these active service classes are entitled and each service class is using their complete share of the CPU resources, therefore summing to 100% CPU utilization in this example. In panel B, service class A does not have any work to fully use its CPU entitlement, dropping from 60% to 0% CPU utilization. The dispatcher considers service class A as being inactive. The unused 60% of the CPU resources, temporarily relinquished by service class A, can now be claimed by the competing service classes B and C based on their hard CPU shares assignment and an inactive service class. Service classes B and C, in this circumstance, can exceed their CPU resource allocations of 30% and 10%, respectively, because they both have hard CPU shares assigned and there is not enough work running in service class A for it to be considered active by the dispatcher (CPU utilization falls below the level configured for the wlm_disp_min_util database manager configuration parameter; default is 1%). Panel C shows that service class B is allocated 75% ((3000 / (3000 + 1000)) x 100) of the CPU resources and service class C is allocated 25% ((1000 / (3000 + 1000)) x 100).

Figure 3. Hard and soft CPU shares pie charts: Scenario 3

If service class A experiences an increase in its workload, it effectively increases its demand on CPU resources. In this circumstance, service classes B and C immediately relinquish to service class A all of the claimed CPU resources, thereby restoring the state of CPU resource allocations to that which is depicted by the pie chart in panel A.

This scenario shows that although you can protect the progress of work running in high-priority service classes from interruptions by work running in low-priority service classes, when high-priority work is no longer present (such as during off-peak business hours), low-priority service classes with hard CPU shares still have the flexibility to claim the unused CPU resources.

Note: If either service class B or C does not use its full CPU resource allocation and is still considered by the dispatcher to be actively running work, the other service class with hard CPU shares cannot take advantage of it and use more than its allocation.

Scenario 4

This scenario is a variation of Scenario 1. It uses the same service class shares, but adds extra entitlement shares at the database level.

Database 1 has 25% CPU shares (1000 shares of 4000 shares total). Database 2 has 75% CPU shares (3000 shares of 4000 shares total).

Each database has the same number of service classes with the same configuration:

Three services classes each (A, B, and C in database 1; D, E, and F in database 2)
The largest service class is entitled to 6000 of 10000 CPU shares within its database
The medium-sized service class is entitled to 3000 of 10000 CPU shares within its database
The smallest service class is entitled to 1000 of 10000 CPU shares within its database

The exact CPU entitlement is calculated by factoring in the database's CPU entitlement:

Service class A (on database 1) is entitled to 15% CPU (6000 of 10000 service class shares x 1000 of 4000 database shares [or 60% x 25% x 100])
Service class B (on database 1) is entitled to 7.5% CPU (3000 of 10000 service class shares x 1000 of 4000 database shares [or 30% x 25% x 100])
Service class C (on database 1) is entitled to 2.5% CPU (1000 of 10000 service class shares x 1000 of 4000 database shares [or 10% x 25% x 100])
Service class D (on database 2) is entitled to 45% CPU (6000 of 10000 service class shares x 3000 of 4000 database shares [or 60% x 75% x 100])
Service class E (on database 2) is entitled to 22.5% CPU (3000 of 10000 service class shares x 3000 of 4000 database shares [or 30% x 75% x 100])
Service class F (on database 2) is entitled to 7.5% CPU (1000 of 10000 service class shares x 3000 of 4000 database shares [or 10% x 75% x 100])

In panel A, service class B is assigned hard CPU shares. Service classes A and C are assigned soft CPU shares, the amounts of which are described in the figure legend. The pie chart represents the proportion of allocated CPU resources within database 1 that these active service classes are entitled to.

In panel A, each service class is using their complete share of the CPU resources. CPU usage is at full capacity for database 1 and database 2.

In panel B, service class A does not have enough work to fully use its CPU entitlement, dropping from 15% to 12.5% CPU usage. The unused 2.5% of the CPU resources, temporarily relinquished by service class A, can be claimed by only the competing service class C based on its soft CPU shares assignment.

Service class B cannot exceed its CPU resource allocation of 7.5% in this example. Hard CPU shares are assigned to service class B. There is enough work running in service classes A and C for those service classes to be considered active by the dispatcher.

Panel C shows the total reallocation of CPU resources to service class C, increasing from 2.5% to 5% of the total available CPU resources.

Figure 4. Hard and soft CPU shares pie charts: Scenario 4