Dispatch concurrency level

Features and functionality

The number of simultaneously executing agents managed by the workload management dispatcher should generally be a low multiple of the number of CPUs on the system. The goal is to establish a concurrency level just large enough to ensure that the CPU resources on the host or LPAR are fully utilized and no larger, while accounting for OS scheduling latencies as threads switch from being active to inactive and vice versa. This optimal value ensures maximum efficiency and gives the workload management dispatcher maximum control over CPU resource allocation. If the configured concurrency value is too small, there will not be enough work to fully utilize the available CPU resources. If the configured concurrency value is too large, the dispatcher will have less control over the work running on the system, which might add to resource contention.

By setting the wlm_disp_concur database manager configuration parameter, you can either specify how the DB2® database manager itself sets the concurrency level (COMPUTED), or you can manually set the concurrency level to a fixed value.

As a general guideline, the optimal dispatch concurrency level is four times the number of CPUs available on the server hardware. This guideline is typically sufficient for most platforms and is the level you get as the default (COMPUTED is the default setting for the configuration parameter). For complete details about how to set the dispatch concurrency level, see: Setting dispatch concurrency level.

The specified value of the wlm_disp_concur database configuration parameter applies to each host or LPAR. In multimember database environments, the specified concurrency level is shared between the members.

Tuning

After the workload management dispatcher has been enabled, monitor your system for a drop in throughput and CPU utilization. If a drop does occur in either metric, increase the value of the configuration parameter in increments of the number of available processors.