DB2 10.5 for Linux, UNIX, and Windows

Hard CPU shares

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

Introduction

Hard 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, monitoring your existing workloads to determine the extent of CPU resource consumption, and enabling the CPU shares attribute for service classes, you can assign hard CPU shares to the service classes that you consider to be running lower-priority or high-impact work. Using hard CPU shares ensures that these service classes will have their CPU consumption 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 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 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 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 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.

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. 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. You can assign and adjust hard CPU shares by using the CREATE SERVICE CLASS and ALTER SERVICE CLASS statements. For complete details about how to enable and set hard 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 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.

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

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.