How do CPU Shares interact when defined on service super and sub classes?

An important point about CPU shares in DB2 workload management came up recently during a customer PoC so I thought I would share it here...

There was a bit of confusion about how CPU shares interact when they are defined at both the service superclass and subclass levels in an environment with multiple service classes defined.

The key rule about applying CPU shares is that shares on service subclasses are for controlling competition between subclasses of the same service super class while shares specified on at the service super class level are used to control competition between the different service super classes. Subclass shares are not compared across different service superclasses.

So, think of this as like-to-like competition:

  • subclasses under the same service superclass compete against each other
  • superclasses compete against other superclasses

CPU shares help you set rules and control the competition at the different levels.

As an example of how this works, assume you have 2 service superclasses (say with only the default service subclass in each). If you define hard CPU shares for the default subclass in each superclass and define soft CPU shares on the service superclasses themselves, then:

  • the hard shares will have no impact as there are no other competing subclasses in each superclass
  • the overall CPU will be divvied up between the super classes based on the soft shares values.


Hope this helps clarify things.

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