Minimum CPU resource utilization for service class to be considered active

When managing shares-based CPU resource allocations, the workload management dispatcher considers a service class to be active and factors its entire CPU shares assignment in the overall CPU resource scheduling allocation if any amount of the CPU resource is being used by database requests executing in that service class. In certain instances, it is desirable to have some control over how much service-class-generated CPU activity is needed for the workload management dispatcher to include the CPU shares of the service class during CPU resource scheduling.

In the example scenario depicted in Figure 1 panel A, service class A contains a high-priority transactional workload that runs only during the business day, while service class B and C contain ongoing day and night, low-priority batch jobs. Service class A is protected from interruption by assigning hard CPU shares to service classes B and C. At night when the transactional workload on service class A is not present (as shown in panel B), service classes B and C are able to make full use of the CPU resources and make much faster progress (as shown in panel C).

Figure 1. Minimum CPU utilization example: Hard and soft CPU shares

Let's now consider what happens if a small trickle of transactional work continues to occur at night on service class A. In this case, service class A is considered to be active by the workload management dispatcher, and the unused CPU resources temporarily relinquished by service class A are not available to service classes B and C. The CPU resource entitlements for service classes B and C are as shown in panel B with a small sliver of the CPU utilization pie representing the activity of service class A (not shown in the panel B pie chart). Much slower overnight progress is the result for service classes B and C than that made in the original scenario as shown in panel C.

Maximum user flexibility to manage their DB2® workloads is provided by the option to set a percentage of CPU utilization at or above which a service class is considered to be active on the host or LPAR. When a service class is considered to be inactive, its CPU shares assignment is not factored into CPU resource entitlement calculations, thereby allowing service classes, particularly those with assigned hard CPU shares, to claim the unused CPU resources. This minimum percentage of CPU utilization is specified by configuring the percentage value of the wlm_disp_min_util database manager configuration parameter. This configuration parameter can be set to a percentage value between 0 and 100, with a default value of 5. For this configuration parameter setting to be effective, the workload management dispatcher must be enabled by setting the value of the wlm_dispatcher database manager configuration parameter to YES.

Let's reconsider the small trickle scenario described earlier. With the percentage value of the wlm_disp_min_util database manager configuration parameter now set to a value slightly higher than the small sliver of overnight CPU utilization for service class A, we can be more confident that the progress of the overnight batch jobs of service classes B and C is much improved, similar to that of the original scenario in which the CPU utilization was as that shown in panel C.