CPU limit

Introduction

A CPU limit can be assigned to any user and maintenance service class, but not to the system service class. After having enabled the workload management dispatcher and having monitored your existing workloads to determine the extent of CPU resource consumption, you can then assign CPU limits to the service classes that you want to be strictly limited in their CPU consumption.

CPU shares provide you with the ability to control the CPU resource entitlement of individual workloads when the overall workload of the host or LPAR is heavy and yet not waste CPU resources when the overall workload is light. However, there are workloads for which you always want to limit their CPU resource entitlement despite the light overall workload of the host or LPAR. For example, if multiple departments share the cost of purchasing a database server, each department might want to ensure that the other departments are not taking more than their allocated CPU resource entitlements, despite the possibility that the selected configuration can result in under-utilizing the CPU resources of the host or LPAR. CPU shares do not give you this level of control, whereas a CPU limit does.

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

Features and functionality

The CPU limit gives you the ability to place a fixed limit on the CPU resource entitlement by work in a service class. If a CPU limit is set on all service classes, you can reserve a portion of the CPU resources to perform work regardless of any other work running in the DB2 database manager. Configuring a CPU limit on a service class effectively provides a strictly-enforced sandbox for your workloads in which you can achieve fairness in CPU resource consumption between workloads, but at the expense of occasionally not achieving full utilization of the CPU resources.

The CPU limit is also useful when you have multiple DB2 instances on your host or LPAR. With the workload management dispatcher operating at the instance level, the CPU resource allocation of any service class is computed from the shares of that service class relative to the shares of all other service classes within the instance. A CPU limit, however, is expressed as a percentage of the CPU resources of the host or LPAR, regardless of how many DB2 instances exist on such a host or LPAR. By applying CPU limits to your superclasses and shares to your subclasses, you can use the CPU limit to control the absolute CPU resource entitlement of each superclass, and by extension the instance, and then use shares to control the relative CPU resource entitlements of service subclasses running within those superclasses.

A CPU limit can be configured both at the service superclass level, where it represents a percentage limit of CPU resource entitlement on the host or LPAR by all subclasses in that superclass, or at the subclass level, where it represents a percentage limit of CPU resource entitlement on the host or LPAR by that particular subclass.

To enable the CPU limit attribute, you must enable the workload management dispatcher by setting the value of the wlm_dispatcher database manager configuration parameter to ON. The default setting for this parameter is OFF. By enabling the workload management dispatcher, CPU resource control using the CPU limit attribute becomes available by default. You can assign and adjust CPU limits by using the CREATE SERVICE CLASS and ALTER SERVICE CLASS statements. For complete details about how to set CPU limits, see: Setting a CPU limit.

The workload management dispatcher always respects the most restrictive CPU limit or CPU shares assignments when allocating CPU resources to service classes. For example, when a CPU limit is set at both the superclass and subclass levels, the more restrictive CPU limit is honored. Likewise, if a service class reaches its CPU limit before it has fully utilized its shares-based CPU resource entitlement, the dispatcher respects the CPU limit.

Usage scenarios

CPU limit and multiple superclasses

This set of usage examples addresses CPU limit behavior in a multiple superclass environment.

Figure 1 shows a host or LPAR configured with two superclasses, A and B. For illustration purposes to help describe the basic concepts, assume that there is negligible work running in the default user, maintenance, and system service classes. For the following scenarios, there is only one DB2 instance with one database and only one member on this host or LPAR.

Figure 1. Data server configuration: Multiple superclasses

CPU limit and multiple superclasses: Scenario 1

In this example, Figure 2 panel A shows that service class A has a CPU limit of 30% and service class B has no CPU limit. At the start of this scenario, service class A has at least enough work to drive its CPU resource utilization to 30% and service class B has at least enough work to drive its CPU resource utilization to 70%. Service classes A and B both have 1000 soft CPU shares.

Figure 2. CPU limit and multiple superclasses: Scenario 1

Panel B shows that service class A has a reduction in CPU resource demand from 30% to 20%. Service class B has more than enough CPU resource demand to claim the CPU resources temporarily relinquished by service class A, as shown in panel C.

CPU limit and multiple superclasses: Scenario 2

In this example, Figure 3 panel A again shows that service class A has a CPU limit of 30% and service class B has no CPU limit. At the start of this scenario, service class A has at least enough work to drive its CPU resource utilization to 30% and service class B has at least enough work to drive its CPU resource utilization to 70%. Service classes A and B both have 1000 soft CPU shares.

Figure 3. CPU limit and multiple superclasses: Scenario 2

Panel B shows that service class B has a reduction in CPU resource demand from 70% to 50%. Due to its CPU limit, service class A cannot consume the 20% of the CPU resources that service class B temporarily relinquished. The total CPU utilization for the host or LPAR remains at 80%.

CPU limit and multiple superclasses: Scenario 3

In this example, Figure 4 panel A again shows that service class A has a CPU limit of 30% and service class B has no CPU limit. At the start of this scenario, service class A has at least enough work to drive its CPU resource utilization to 30% and service class B has at least enough work to drive its CPU resource utilization to 70%. Service classes A and B both have 1000 soft CPU shares.

Figure 4. CPU limit and multiple superclasses: Scenario 3

Panel B shows that service class B has a reduction in CPU resource demand from 70% to 0%. Due to its CPU limit, service class A cannot consume the 70% of the CPU resources that service class B temporarily relinquished. The total CPU utilization for the host or LPAR remains at 30%.

CPU limit and multiple subclasses

This next set of usage examples addresses CPU limit behavior in a multiple subclass environment.

Figure 5 shows a host or LPAR configured with two superclasses, A and B. Inside service superclass A are service subclasses A1 and A2. For illustration purposes to help describe the basic concepts, assume that there is negligible work running in the default user, maintenance, and system service classes. For the following scenarios, there is only one DB2 instance with one database and only one logical partition on this host or LPAR.

Figure 5. Data server configuration: Multiple subclasses

CPU limit and multiple subclasses: Scenario 1

In this example, Figure 6 panel A shows that service superclass class A has a CPU limit of 50% and service subclass A1 has a CPU limit of 20%. Service superclass B has no CPU limit. At the start of this scenario, service subclass A1 has at least enough work to drive its CPU resource utilization to 20% and service subclass A2 has at least enough work to drive its CPU resource utilization to 30%, giving service superclass A a total CPU resource utilization of 50%. Service superclass B has at least enough work to drive its CPU resource utilization to 50%. Service superclasses A and B both have 1000 soft CPU shares.

Figure 6. CPU limit and multiple subclasses: Scenario 1

Panel B shows that service subclass A1 has a reduction in CPU resource demand from 20% to 10%. Service subclass A2 and service superclass B each have more than enough CPU demand to claim the entire amount of unused CPU resources that service class A1 has temporarily relinquished. However, service subclass A2 is allocated all of the relinquished CPU resource and increases its CPU utilization from 30% to 40%, as depicted in panel C. This CPU resource allocation result is due to the service superclasses A and B already sharing the total CPU resources with a 50%/50% equal split resulting from the 1000 soft CPU shares assigned to each of the superclasses.

CPU limit and multiple subclasses: Scenario 2

In this example, Figure 7 panel A again shows that service superclass class A has a CPU limit of 50% and service subclass A1 has a CPU limit of 20%. Service superclass B has no CPU limit. At the start of this scenario, service subclass A1 has at least enough work to drive its CPU resource utilization to 20% and service subclass A2 has at least enough work to drive its CPU resource utilization to 30%, giving service superclass A a total CPU resource utilization of 50%. Service superclass B has at least enough work to drive its CPU resource utilization to 50%. Service superclasses A and B both have 1000 soft CPU shares.

Figure 7. CPU limit and multiple subclasses: Scenario 2

Panel B shows that service subclass A2 has a reduction in CPU resource demand from 30% to 20%. Due to service subclass A1 having a CPU limit of 20%, service subclass A1 cannot exceed its current 20% CPU utilization. Service superclass A drops its CPU utilization to a total of 40%. Service superclass B has enough CPU resource demand to claim the CPU resource that was temporarily relinquished by service subclass A2, increasing the CPU utilization of service superclass B from 50% to 60%, as shown in panel C.

CPU limit and multiple DB2 instances

This next set of usage examples addresses CPU limit behavior in a multiple DB2 instance environment.

Figure 8 shows a host or LPAR configured with two DB2 instances, instance A and instance B. Each instance contains one database, database 1 and database 2. Each database contains one service superclass, service superclass A and B. Inside service superclass A are service subclasses A1 and A2. Inside service superclass B are service subclasses B1 and B2. To keep the scenario simple, user requests for each database are routed to only the two service subclasses and no work is routed to the default service subclass. In addition, to help describe the basic concepts, assume that there is negligible work running in the default user, maintenance, and system service classes. For the following scenarios, there are two DB2 instances with one database in each instance and only one member on this host or LPAR.

Figure 8. Data server configuration: Multiple DB2 instances

CPU limit and multiple DB2 instances: Scenario 1

In this example, instance A is to receive no more than 50% of the total CPU resources of the host or LPAR and instance B is to receive no more than 50% of the total CPU resources of the host or LPAR. Within instance A, 80% of the instance CPU resources are to be allocated to service subclass A1 and 20% to service subclass A2 by assigning 8000 soft CPU shares to A1 and 2000 soft CPU shares to A2. When service subclass A1 does not consume its full 80%, we want service subclass A2 to claim any unused CPU resources, and vice versa, to maximize CPU utilization within instance A. Within instance B, 60% of the instance CPU resources are to be allocated to service subclass B1 and 40% to service subclass B2 by assigning 6000 soft CPU shares to B1 and 4000 soft CPU shares to B2. As with service subclasses A1 and A2, we want to maximize CPU utilization within instance B by having service subclass B1 claim any unused CPU resources when service subclass B2 does not use its full CPU resource entitlement, and vice versa.

To configure the appropriate conditions for this scenario as described in the preceding paragraph, limit the CPU resources for each instance by creating a CPU limit of 50% on service superclass A, in database 1, in instance A, and creating a CPU limit of 50% on service superclass B, in database 2, in instance B. When both instances are using all of their CPU resource entitlements, the host or LPAR as a whole is considered to have 100% CPU utilization. If either instance does not use its full CPU entitlement, the other instance cannot claim the unused CPU resources.

For each service superclass on each instance, the workload management dispatcher divides the available CPU resources among the subclasses using their relative soft CPU shares assignments. By using soft CPU shares assigned to the service subclasses, the only circumstance in which an instance does not make full use of their CPU resource entitlement occurs when every subclass in the instance does not have enough work running within it to achieve full CPU utilization of its entitlement.

Figure 9 panel A shows that service superclass class A has a CPU limit of 50% and service superclass B has a CPU limit of 50%. Service subclass A1 has 80% of the instance A CPU resources (40% of the host or LPAR CPU resources); service subclass A2 has the remaining 20% (10% of the host or LPAR CPU resources). Service subclass B1 has 60% of the instance B CPU resources (30% of the host or LPAR CPU resources); service subclass B2 has the remaining 40% (20% of the host or LPAR CPU resources). At the start of this scenario, service subclass A1 has at least enough work to drive its host or LPAR CPU resource utilization to 40% and service subclass A2 has at least enough work to drive its host or LPAR CPU resource utilization to 10%, giving service superclass A a total CPU resource utilization of 50%. Service subclass B1 has at least enough work to drive its host or LPAR CPU resource utilization to 30% and service subclass B2 has at least enough work to drive its host or LPAR CPU resource utilization to 20%, giving service superclass B a total CPU resource utilization of 50%.

Figure 9. CPU limit and multiple DB2 instances: Scenario 1

Panel B shows that service subclass A1 has a reduction in CPU resource demand from 40% to 30% and service subclass B1 has a reduction in CPU resource demand from 30% to 20%. Assuming service subclass A2 has enough work executing within it to claim any unused CPU resources that become available, A2 increases its CPU utilization from 10% to 20% because A2 has soft CPU shares assigned to it, as shown in panel C. The same applies to service subclass B2 which increases its CPU utilization from 20% to 30%, as shown in panel C.

Let's now consider the original start condition as described in panel A for a different example. If service subclass B1 reduces its CPU demand from 30% to 20% and service subclass B2 does not have enough work running within it to exceed a CPU demand of 20%, then service superclass B in instance B does not use its full CPU entitlement of 50% and remains at a CPU utilization of 40%, as shown in panel D. The result is that the host or LPAR has a CPU utilization of only 90% of the total CPU resources.

CPU limit and multiple DB2 instances: Scenario 2

This scenario example illustrates what happens when the sum of the CPU limits of the service subclasses does not exceed the CPU limit of the parent service superclass.

Using similar initial conditions as in "CPU limit and multiple DB2 instances: Scenario 1", let's just change the soft CPU shares assigned to service subclasses A1 and A2 into CPU limits of 40% and 10%, respectively, of the total CPU resources for the host or LPAR, as shown in Figure 10 panel A. When both service subclasses use the CPU resources up to their assigned CPU limits, the total CPU utilization is 50% for service superclass A, making redundant the additional constraint of a 50% CPU limit on service superclass A.

Figure 10. CPU limit and multiple DB2 instances: Scenario 2

Panel B shows that service subclass A1 has a reduction in CPU resource demand from 40% to 30% due to a decrease in the amount of work running in the service subclass. In this circumstance, the dispatcher cannot allocate the unused CPU resource, temporarily relinquished by service subclass A1, to service subclass A2. Service subclass A2 continues running workloads on its CPU limit of 10% of the CPU resources of the host or LPAR. This situation makes instance A unable to use its full CPU resource entitlement of 50%.

CPU limit and multiple DB2 instances: Scenario 3

This scenario example illustrates what happens when the sum of the CPU limits of the service subclasses exceed the CPU limit of the parent service superclass.

Using similar initial conditions as in "CPU limit and multiple DB2 instances: Scenario 1", let's just change the soft CPU shares assigned to service subclasses A1 and A2 into CPU limits of 40% and 40%, respectively, of the total CPU resources for the host or LPAR. In this example, the total of the assigned CPU limits for service subclasses A1 and A2 is 80% which exceeds the 50% CPU limit assigned to service superclass A. The workload management dispatcher prevents service superclass A from exceeding its 50% CPU limit. The amount of CPU resources that is allocated to each service subclass in superclass A is determined by the CPU shares that have been assigned to the subclasses. CPU shares were not explicitly assigned for service subclasses A1 and A2, but each of these subclasses has the 1000 soft CPU shares that were assigned when the subclasses were created, giving each subclass an equal CPU entitlement. The dispatcher allocates an equal division of the 50% of the total host or LPAR CPU resources entitled to service superclass A. The result is that 25% is allocated to service subclass A1 and 25% is allocated to service subclass A2, as shown in Figure 11 panel A.

Figure 11. CPU limit and multiple DB2 instances: Scenario 3

Panel B shows that service subclass A1 has a reduction in CPU resource demand from 25% to 5% due to a decrease in the amount of work running in the service subclass. Due to the soft CPU shares assignment, the dispatcher can allocate the unused CPU resource, temporarily relinquished by service subclass A1, to the point of 40% claimed by service subclass A2. Service subclass A2 is unable to exceed its CPU limit of 40% of the CPU resources of the host or LPAR. This situation makes instance A unable to use its full CPU resource entitlement of 50%.