DB2 10.5 for Linux, UNIX, and Windows

Integration of Linux workload management with DB2 workload management

On the Linux operating system, the optional integration between DB2® service classes and Linux classes (control groups) permits you to control the amount of processor resource allocated to each service class. If enabled, all threads running in a DB2 service class are mapped to a Linux class where they are subject to the processor resource controls you define.

To make use of Linux workload management support, you require a Linux kernel version 2.6.26 or later on a 64-bit system and the libcgroup library package.

Linux workload management supports a hierarchy of classes with superclasses and subclasses, with processor shares for subclasses divided in proportion to the shares of the parent class. These shares provide a method of control over processor resource such that all threads in the system will always run, but the amount of processor time each thread receives is dependent on the number of shares assigned to the Linux class.

Processor resource on the Linux operating system is assigned in shares relative to the Linux workload management default class, which by default has a processor share at a value of 1024. If you define no other Linux classes, all threads run in this default class. If you define a class that has a share value equal to 1024, then this class receives the same amount of processor resource as the Linux default class with the default processor share. Similarly, a class with a share of 2048 receives a target processor usage quota twice that of the default class. On more complex systems, you should consider raising the processor share of the Linux default class, which improves the granularity for shares across the system so that you can assign processor resources more accurately.

Recommended mappings between DB2 service classes and Linux classes

You should use a 1:1 mapping between DB2 service classes and Linux classes which permits you to adjust the Linux processor shares assigned to activities in each DB2 service class individually according to business priority. It is important that you associate every DB2 service class with a Linux WLM class, either by setting an outbound correlator for each service superclass and subclass, or through inheritance from the parent service class for subclasses. This includes the default SYSDEFAULTSYSTEMCLASS, SYSDEFAULTMAINTENANCECLASS and SYSDEFAULTUSERCLASS service classes.

The following figure shows how two DB2 service subclasses under the same user defined service superclass can get mapped 1:1 to Linux subclasses under a common superclass. In this example, the work identified and assigned by two workloads for each DB2 service subclass is subject to the processor resource controls imposed by the corresponding Linux subclasses (_DB2_SUBCLASSA, _DB2_SUBCLASSB). Also shown are three Linux classes that correspond to the default DB2 workload management service classes (_DB2_DEF_USER, _DB2_DEF_SYSTEM, _DB2_DEF_MAINT). If you integrate DB2 workload management with Linux workload management, you should always create these additional Linux classes to match the default DB2 service classes. To avoid any bottleneck, the Linux class corresponding to the DB2 default system class should receive more processor shares than any other Linux class that DB2 activities map to, whilst the Linux class corresponding to the default maintenance class should receive less processor shares.

Figure 1. Integration of DB2 workload management with Linux workload management

Defining mappings between DB2 service classes and Linux workload management classes

The steps for integrating DB2 workload management with Linux workload management, which runs as an operating system service, are as follows:

Define the Linux classes, class permissions, and processor shares by editing the /etc/cgconfig.conf control groups configuration file. What Linux classes you create depends on the conditions dictated by your business priorities for the work your data server performs. If you want to apply processor resource based on the source of certain work, for example, create a Linux class to match the DB2 service class that work is going to be assigned to by the workload identifying the work. Define an entry for each Linux class corresponding to the DB2 service class to be created that you want to use for the mapping. The following sections must be provided in the /etc/cgconfig.conf configuration file:
- group: The Linux class name. For example, if you specify group _class1, you create a superclass _class1. If you specify group _class1/_subclass1, you create the subclass _subclass1 under the superclass _class1.
  - perm: The permissions section that determines who can control what threads are assigned to a Linux class and who can change the processor shares of classes in the /etc/cgconfig.conf configuration file.
    - task: The user ID (uid) and group ID (gid) whose threads can run in the Linux workload management class. To enable Linux workload management to work with DB2 workload management, you should set uid to the DB2 instance owner user ID.
    - admin: The user ID (uid) and group ID (gid) that can change processor shares for a Linux workload management class.
  - cpu: The processor shares definition section
    - cpu.shares: The share assigned to this Linux class relative to the default class
  The /etc/cgconfig.conf configuration file must contain these sections in the following format:
```
# Superclass name
group _name
{
   perm
   {
      task
      {
         uid = db2inst1;
         gid = db2iadm1;
      }
      admin
      {
         uid = db2inst1;
         gid = db2iadm1;
      }
   }

   cpu
   {
      cpu.shares = 1024;
   }
}
```
Start the Linux workload management service daemon with the service cgconfig start command, then start your DB2 data server with the db2start command.
To map a DB2 service class to one of the Linux classes, include the Linux class name in the OUTBOUND CORRELATOR clause when you create or alter the service class, which associates threads from the DB2 service class with the external Linux class.
If you want to find out what threads are assigned to a particular Linux class, you can use the cat command on the /cgroup/class_name/tasks file, where class_name represents the name of the Linux class you are interested in. All threads that are not mapped to a user-defined Linux class are assigned to the Linux default class, which you can find at MOUNTPOINT/sysdefault, where MOUNTPOINT is defined in the cgconfig.conf configuration file.
To add or remove Linux classes, you must stop with the Linux workload management service with the service cgconfig stop command, make your changes, and then restart the service. Note that stopping the service affects the entire system, because all tasks are moved to the default class. If you used the /etc/init.d/cgred script to start the service daemon, issue /etc/init.d/cgred stop to stop it.

For the integration with DB2 workload management to work, you must ensure that the Linux workload management service is properly installed, configured, and active. If the DB2 data server cannot communicate with the Linux workload management service, a message is logged to the db2diag log files and DB2 administrator log. Database activities will continue to execute.

The DB2 data server cannot detect whether the outbound correlator that it passes to external workload managers is recognized by Linux workload management. You must verify that the OUTBOUND CORRELATOR value specified for a DB2 service class matches the Linux class name so that DB2 threads are mapped to the Linux class. If an outbound correlator is not recognized, database activities will continue to execute.

Example

The following example illustrates how you can make use of Linux workload management processor controls by integrating with DB2 workload management. In this example, we create two user-defined DB2 service classes, one for batch applications (BATCHAPPS) and one for online applications (ONLINEAPPS). For simplicity, this example does not show the default service classes, which should be included in an implementation that creates the recommended 1:1 mapping between DB2 service classes and Linux classes. Because response time is critical for the online applications, we want the ONLINEAPPS service class to receive three times the amount of processor shares relative to work that runs in the Linux default class (3 x 1024 = 3072 shares). Batch applications have a lower business priority, and the BATCHAPPS class should be assigned half the processor resource of work that runs in the Linux default class (1024 / 2 = 512 shares). All other work on the system will run in the Linux default class. Note that this example does not create Linux classes corresponding to the three default DB2 workload management service classes.

To create this setup, first create the two corresponding Linux classes _BATCHAPPS and _ONLINEAPPS and set their relative processor shares by editing the /etc/cgconfig.conf tasks file. After editing, the tasks file contains the following two entries, one for each Linux class:

# Superclass ONLINEAPPS
group _ONLINEAPPS
{
   perm
   {
      task
      {
         uid = db2inst1;
         gid = db2iadm1;
      }
      admin
      {
         uid = db2inst1;
         gid = db2iadm1;
      }
   }

   cpu
   {
      # 3 x 1024 = 3072 shares
      cpu.shares = 3072;
   }
}

# Superclass BATCHAPPS
group _BATCHAPPS
{
   perm
   {
      task
      {
         uid = db2inst1;
         gid = db2iadm1;
      }
      admin
      {
         uid = db2inst1;
         gid = db2iadm1;
      }
   }

   cpu
   {
      # 1024 / 2 = 512 shares
      cpu.shares = 512;
   }
}

The absolute processor time in percent assigned to each Linux class as processor shares is as follows:

Table 1. Processor shares and absolute processor time assigned to Linux classes
Linux class	Shares	Absolute processor time in percent
Default class	1024 (default)	1024 / 4608 = 22%
_ONLINEAPPS	1024 x 3 = 3072	3072 / 4608 = 67%
_BATCHAPPS	1024 x ½ = 512	512 / 4608 = 11%
	Total = 1024 + 3072 + 512 = 4608 shares

Once the Linux WLM classes are created, you can start the Linux workload management service:

service cgconfig start

Next, create the associated DB2 service classes with the following statements:

DB2 CREATE SERVICE CLASS BATCHAPPS OUTBOUND CORRELATOR '_BATCHAPPS'
DB2 CREATE SERVICE CLASS ONLINEAPPS OUTBOUND CORRELATOR '_ONLINEAPPS'

To find out which threads are running in a Linux class, issue the cat command. For the business critical _ONLINEAPPS Linux class, the command and output look as follows. You can see that there are six thread running in this Linux class:

cat /cgroup/_ONLINEAPPS/tasks

1056
1087
1107
985
1036
1205