DB2 10.5 for Linux, UNIX, and Windows

Soft CPU shares

The DB2® workload management dispatcher can manage CPU resources using shares-based entitlements that are assigned to service classes. Soft CPU shares, when assigned to a service class by the administrator, give that service class the ability to consume more than its share of CPU resources if they are unused. When used in conjunction with other service classes bounded by hard CPU shares, this provides preferential treatment for that service class 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.

The sections that follow describe the features and functionality of the soft CPU shares in more detail. A usage scenario section helps to illustrate the soft CPU shares features and functionality with a usage example.

Features and functionality

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 by using the CREATE SERVICE CLASS and ALTER SERVICE CLASS statements. For complete details about how to enable and set soft CPU shares, see: Enabling and setting CPU shares.

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, you can use the following formula to convert the number of CPU shares of a particular service superclass into a percentage of CPU resources allocated by the workload management dispatcher:

% CPU(superclass) = (Number of superclass shares / Total number of shares of all active superclasses) x 100

To determine the proportion of the CPU resources to which each service subclass is entitled, you can 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:

% CPU(subclass) = % CPU(superclass) x (Number of subclass shares / Total number of shares of all active subclasses in the superclass)

Note: The total number of CPU shares (both hard and soft) of all active superclasses are counted across all databases and all members on the host or LPAR.

Usage scenario

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.

Figure 1. Soft CPU shares pie charts

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.