HP-UX Workload Manager User's Guide

How WLM manages workloads
How WLM works
Chapter 3116
Referring to Figure 3-1 on page 115, the main WLM functional flow is as
follows:
1. The WLM configuration file specifies the goal-based or shares-based
SLOs for each workload. This file also provides the pathnames for
data collectors. WLM reads the configuration file and starts the data
collectors.
2. For each application with a usage goal, WLM creates a controller (an
internal component of WLM). Each controller tracks its application’s
actual CPU usage (utilization of allocated CPU resources); no
user-supplied metrics are required. The controller requests an
increase or decrease to the workload’s CPU allocation to better
achieve the usage goal.
3. For each application with a metric goal, as the application runs, a
data collector for that application reports the application’s metrics.
The measurement, for example, might be transaction response times
for an online transaction processing (OLTP) application.
4. For each metric goal, WLM creates a controller (an internal
component of WLM). Each controller receives the metric from the
respective data collector. The metric is compared to the goal for that
metric to determine if the application is overperforming or
underperforming. The controller then requests more CPU shares for
a workload with underperforming applications or fewer CPU shares
for a workload with overperforming applications.
5. For applications without goals, WLM requests CPU resources based
on the CPU allocation request values set in the SLO definitions.
These requests could be for fixed allocations or for shares-per-metric
allocations, with the metric coming from a data collector.
6. The arbiter, an internal module of WLM, collects all the requests for
CPU shares. These requests come from controllers or, if allocations
are fixed, from the SLO definitions. The arbiter satisfies the requests
based on priority. If resources are insufficient for every application to
meet its goals, the arbiter satisfies the highest priority requests first.
If multiple SLOs at the same priority cannot be satisfied, WLM
raises the CPU allocation for each SLO’s associated workload to the
same level or to the SLO’s CPU request—whichever is smaller.
7. Optionally, with PRM resource management available for a single
HP-UX instance, WLM determines how much memory to distribute
to meet the minimum memory requests and then, if any memory
remains, divides it among the groups with active SLOs.