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.

0 Comments
Recent Stories
Verson 3.0.4 of IBM Graphical WLM tool now available in developerWorks

A quick summary of available Db2 controls for system resources

Managing resource consumption for multiple databases under the same DB2 instance