How a workload is managed (controllers)

When a configuration is activated, WLM instantiates a controller for each SLO that has a performance goal or a usage goal. For SLOs with usage goals, WLM internally tracks the workload’s actual CPU usage versus its CPU allocation. With performance goals, controllers receive metric updates in the form of performance data from data collectors. The controllers then determine the CPU allocations to request to better achieve the desired usage or performance goals.

For an illustration showing controllers, see Figure 3-1 “WLM overview”.

For information on specifying usage and performance goals, see “Specifying a goal (optional)”.

For information on how to tune controllers, see:

SLO violations

For usage goals:
An SLO violation occurs if the CPU utilization is above the target utilization range. With usage goals, the goal is to keep CPU utilization (CPU used / CPU granted) within a certain range, 50% and 75% by default. When the workload goes above this range, giving it more CPU resources can bring it back into the range.
Going below this range is not considered an SLO violation because the situation cannot be improved by providing the workload with additional CPU resources.
For performance goals:
An SLO violation occurs when a workload’s performance varies from the goal in the wrong direction. Which direction is wrong depends on the goal definition. For example, if the goal is to keep response_time less than 5 seconds, a response_time value of 4.3 seconds varies from the goal in the right direction. However, a response_time value of 5.4 seconds varies in the wrong direction. Similarly, for a goal to have greater than 100 transactions/minute, a reported performance of 80 transactions/minute varies in the wrong direction.
Regardless of the direction of underperformance or overperformance, WLM adjusts CPU allocations to more closely match the SLO’s goal. In the case of an SLO violation, however, WLM also sets EMS resources to alert persons monitoring the system. For more information on EMS resources, see “What EMS resources are available?”.
You can also track SLO violations using wlminfo.

How conflicting SLOs are resolved (arbiter)

When CPU resources are insufficient to satisfy all SLO controller requests, WLM must decide how to distribute CPU resources among the workloads. In these cases, the WLM arbiter considers each controller’s prioritized requests for CPU resources and the associated workloads’ weights to decide the proper allocation of CPU resources.

For an illustration showing the arbiter, see Figure 3-1 “WLM overview”.

For information on priorities and weights, see “Specifying the priority (required)” and “Weighting a group so it gets more CPU resources (optional)”.

How a workload is managed (controllers)

Technical documentation

» Table of Contents

» Glossary

» Index

SLO violations

How conflicting SLOs are resolved (arbiter)