WLM Dispatcher: Hard Shares, Soft Shares, who cares? You do! :)

As described in the  previous entry (WLM Dispatcher: Choosing between CPU shares and CPU limits),  CPU shares are a flexible form of CPU consumption control. The amount of CPU received by each service class is determined by the number of shares assigned to each individual service class relative to the total number of shares held by all currently active service classes.

As an example, if we give service class A 100 CPU shares and service class B 900 CPU shares, then, when both are active and competing for as much CPU as they can get, service class A will receive 10% of the CPU (100 / (100+900)) and service class B will receive 90% (900 / (100+900)).

So,  what should happen on your system when both service classes are not executing work or when one or the other does not need its full complement of allocated CPU?

To help allow you to express your wishes in these scenarios, the Workload Management Dispatcher  actually introduced two different types of CPU shares: hard and soft.


Soft CPU Shares

Soft CPU shares are shares which are only actively recognized (and enforced) when there is contention for CPU resource.

For example, if the CPU is at 95% utilization, the CPU allocations indicated by soft CPU shares are actively enforced and service classes are restricted to these amounts. But, if the CPU is only 35% utilized, then the soft share allocations are not enforced and service classes are free to acquire as much CPU as they like.

Both AIX WLM and Linux WLM have the same soft share concept available as a CPU control mechanism.


Hard CPU Shares

Hard CPU shares are new and unique to DB2 LUW workload management.

Hard CPU shares are enforced all the time as long as any other service class with active work is present on the system regardless of the CPU utilization rate.

If we reuse the previous example with service class A and B but define the shares given to service class A to be hard shares and those for service class B to soft shares (e.g. 100 hard shares for A and 900 soft shares for B), then service class A will be restricted to the relative limit of 10% as long as service class B has active work running on the system regardless of how much of its 90% allocation is actually being used. When service class B no longer has any active work, then service class A will be given full access to the system and will no longer be restricted to 10%.

In this scenario, what we gain is the ability to have the work in service class A take advantage of the absence of service class B to take advantage of all the CPU resource while respecting an absolute limit when any service class B work is present. This can't be done with soft shares even when CPU limits are introduced.


How to choose between them?

Actually, this is a bit of a trick question as we expect workload management configurations to use a mix of both hard and soft CPU share allocations.

You would use the hard share allocations to put a bound on the CPU consumption by lower priority work and the soft shares would be used on the higher priority work to allow them to maximize their CPU consumption. Such a configuration would allow higher priority work to grab more when CPU is not being used by the lower priority work while still maintaining control over the relative amounts consumed by both types of work during periods of high CPU utilization.

The use of hard CPU shares rather than CPU limits allows low priority work to expand its consumption during periods when the high-priority work is not present; remember, CPU limits do not dynamically react to the conditions around them but hard shares do!


A quick summary of the two share types:


  • Only effective when system is heavily loaded (i.e. when CPU contention exists)
  • Use soft shares for higher priority work to allow them to exploit unused capacity



  • Only effective when system is heavily loaded (i.e. when CPU contention exists)
  • Leverage hard shares to control the impact of low priority work


The main question you need to ask yourself is which set of work (i.e. which service class) do you want to allow to escape the CPU usage boundaries imposed on it when there is excess CPU available; this is the one that you control using soft CPU shares.


A simple example

Here is a simple example to re-emphasize some of the points made previously about hard and soft CPU shares. We will use a pie chart approach where the pie represents the entire CPU resource available to DB2.

In this example, we have given service class A 75 soft shares and service class B 25 hard shares. When they are both actively trying to consume as much CPU as possible, service class A is limited to 75% (75/100) and service class B to 25% (25/100) as seen in this figure.


As long as service class A has active work consuming CPU, service class B will still be restricted to its 25% because B is defined using hard shares. We see below that service class B is not taking advantage of the available CPU as long service class A is active.


If service class B should begin consuming less than its available 25%, service class A is allowed to exceed its 75% amount because it is defined using soft CPU shares which means it can take advantage of any available CPU. In this next figure, we see service class A expanding to consume available CPU resource when B is not using it.


If both service class A and service class B no longer need their full CPU allocation, then enforcement becomes inactive and the system proceeds as if no shares were active. There is no CPU contention, there is no need for active CPU controls.


Finally, as soon as service class A no longer has any need for CPU, service class B is given access to the full CPU amount (see below).


Recent Stories
How can I stay current on what fix packs are available for each Db2 release, what Hiper APARs might be out there, and if there are any security vulnerabilities that I should know about?

Things to consider when considering Db2 Native Encryption

An old Db2 Easter Egg: Setting the default isolation value for dynamic SQL