CPU limit
The Db2® workload management dispatcher can enforce fixed CPU limit entitlements that can be assigned to service superclasses, subclasses, and databases. By applying a CPU limit, you can limit the CPU that is consumed by a service class or database to a fixed amount on the system, regardless of any other work running in the Db2 database manager. This leaves the remaining portion of CPU resources available for other consumers to use. When CPU limits are used in conjunction with CPU shares, the most limiting or restrictive condition is always honored.
Introduction
A CPU limit can be assigned to a database or 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 for work in a database or service class. If a CPU limit is set on the database or on all service classes in the database, 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 database is computed from the shares of that database relative to the shares of all other databases 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 databases and shares to your superclasses and subclasses, you can use the CPU limit to control the absolute CPU resource entitlement of each database, and by extension the instance, and then use shares to control the relative CPU resource entitlements of service superclasses and subclasses running within those databases.
- The database level, where it represents a percentage limit of CPU resource entitlement on that database
- 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
- 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 at the database level by using the wlm_cpu_limit database configuration parameter. You can assign and adjust CPU limits at the service class level 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 a database or 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.
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.
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.
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.
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.
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.
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.
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.