Soft CPU shares

The Db2® workload management dispatcher can manage CPU resources using shares-based entitlements that are assigned to service classes and databases. Soft CPU shares, when assigned to a service class or database by the administrator, give that service class or database the ability to consume more than its share of CPU resources if they are unused. When used in conjunction with other service classes or databases bounded by hard CPU shares, this provides preferential treatment for that service class or database with regards to CPU resources.

Introduction

Soft CPU shares can be assigned to any user and maintenance service class, but not to the system service class. After enabling the workload management dispatcher and monitoring your existing workloads to determine the extent of CPU resource consumption, you can assign soft CPU shares to the service classes that are deemed high priority. Soft CPU shares are most effective when used on high priority workloads, because they allow a workload to consume more than its specified entitlement if there are any idle CPU resources on the system. Use of soft CPU shares is not recommended when you want to constrain the CPU consumption of lower priority or high-impact work; in this case, use hard CPU shares instead.

Features and functions

When the host or logical partition (LPAR) is running at 100% CPU utilization, the allocation of CPU resources between service classes 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 is set to soft or hard CPU shares.

A service class with soft CPU shares assigned can 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. When two or more service classes have soft shares and unused CPU resources become available with enough CPU resource demand from each service class to consume the spare capacity, allocation of the CPU resources to the competing service classes is done proportionally according to the relative share of each active service class. The soft CPU shares setting is most effective for high-priority work that you want to be able to temporarily claim any spare CPU resources that become available. In addition, the soft CPU shares setting is most effective for workloads consisting of short queries that are expected to have a relatively modest impact on database resources, outside of their immediate CPU consumption.

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. You can assign and adjust soft CPU shares at the service class level, database level, or both:

Assign and adjust soft CPU shares at the service class level by using the CREATE SERVICE CLASS and ALTER SERVICE CLASS statements.
Assign and adjust soft CPU shares at the database level by using the wlm_cpu_shares and wlm_cpu_share_mode database configuration parameters.

For complete details about how to enable and set soft 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 scenario 1

In Figure 1 panel A, service classes A, B, 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 proportionally claimed by the competing service classes B and C based on their relative soft CPU shares assignments. Panel C depicts the proportional reallocation of CPU resources between service classes B and C, with service class B getting 7.5% (10% x (3000/4000)) and service class C getting 2.5% (10% x (1000/4000)) of the unused 10% relinquished by service class A.

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.

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.

Usage scenario 2

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, all service classes in both databases 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 that these active service classes are entitled to, within their respective database.

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 service classes B and C, based on their soft CPU shares assignment. The unused 2.5% of the CPU resources are distributed according to the service class shares:

Service class B has 3000 shares (compared to service class A's 1000 shares), so service class B can claim 75% of the 2.5% CPU resources, or 1.875%. Therefore, its total CPU usage entitlement increases from 7.5% to 9.375%
Service class C has 1000 shares (compared to service class B's 3000 shares), so service class B can claim 25% of the 2.5% CPU resources, or 0.625%. Therefore, its total CPU usage entitlement increases from 2.5% to 3.125%

Panel C shows the total reallocation of CPU resources to service classes B and C.

Soft CPU shares pie charts: Scenario 4 — Figure 2. Soft CPU shares pie charts: Scenario 2