You can associate each DB2® service
class with a relative agent priority, which controls processor priority
on your data server. This priority is set for all agents that work
in a service class and is relative to the agent priority of all other DB2 agents.
If you do not specify the agent priority value for a service class,
all agents in that service class have the same priority as all other DB2 agents.
Setting
the agent priority for a DB2 service
class adjusts the priority of agents only for new work that enters
the service class. Non-agent threads running in the service class
do not use the agent priority value that you specify. DB2 workload management does not
assign service class agent priority to work being done within a fenced
mode process (FMP). Fenced procedures do not run their logic within
a service class. These fenced procedures run within the DB2 FMP and this work is not done by DB2 agents. As a reminder, DB2 WLM controls DB2 agents.
If you are integrating DB2 service
classes with an operating system workload manager such as AIX® Workload Manager or Linux workload management, you can use the
operating system workload manager to specify the processor priority
to be used for the operating system class (as processor shares), then
have the DB2 service class inherit
this value through the OUTBOUND CORRELATOR value of the DB2 service class. The processor priority that
you specify using the operating system workload manager controls the
priority for agents that run in the DB2 service
class, and any service class agent priority setting is ignored.
Note: You
cannot use agent priority to cap the amount of CPU used by a subset
of work on the system. Agent priority does bias CPU processing between
competing workloads when they need CPU resources, but, agent priority
does not explicitly allocate or manage CPU resources between competing
workloads. Therefore, under circumstances in which competing workloads
are not equally demanding CPU resources, agent priority appears to
be ineffective in those cases where the lower priority work makes
more requests to consume CPU resources than the higher priority work.
However, agent priority is effective if you have competing workloads
that are equally demanding CPU resources and you just want to bias
CPU consumption rather than explicitly throttle or control CPU consumption.
To apply more explicit control on CPU consumption, then Linux WLM integration or concurrency controls
are more effective options.
Important: Do not use the deprecated agentpri database
manager configuration parameter with DB2 workload
management. You can use this configuration parameter to set the absolute
processor priority of all agents in a DB2 instance
to a fixed value. However, if you set the absolute priority for an
agent by using agentpri, you cannot alter the
relative priority of the agent by setting the DB2 service class agent priority or by using
an operating system workload manager. If you set agentpri,
the service class agent priority and operating system workload manager
have no effect on the priority of agents.
On UNIX operating systems
and Linux, valid values are
DEFAULT and -20 to 20 (SQLSTATE 42615). Negative values denote a higher
relative priority. Positive values denote a lower relative priority.
On Windows operating systems,
valid values are DEFAULT and -6 to 6 (SQLSTATE 42615). Negative values
denote a lower relative priority. Positive values denote a higher
relative priority.
On AIX operating systems,
the instance owner must have CAP_NUMA_ATTACH and CAP_PROPAGATE capabilities
to set a higher relative priority for agents in a service class using
AGENT PRIORITY. To grant these capabilities, logon as root and run
the following command:
chuser capabilities=CAP_NUMA_ATTACH,CAP_PROPAGATE
On Solaris 10 or higher, the instance owner must have the proc_priocntl
privilege to set a higher relative priority for agents in a service
class using AGENT PRIORITY. To grant this privilege, logon as
root and
run the following command:
usermod -K defaultpriv=basic,proc_priocntl db2user
In
this example, proc_priocntl is added to the default privilege set
of user db2user.
Moreover, when DB2 is running
in a non-global zone of Solaris, the proc_priocntl privilege must
be added to the limit privilege set of the zone. To grant this privilege
to the zone, logon as
root and run the following
command:
global# zonecfg -z db2zone
zonecfg:db2zone> set limitpriv="default,proc_priocntl"
In
this example, proc_priocntl is added to the limit privilege set of
zone db2zone.
On Solaris 9, there is no facility for DB2 to raise the relative priority of agents.
Upgrade to Solaris 10 or higher to use the service class agent priority.
DB2 Version 10.1 for Linux, UNIX, and Windows