How WLM works

Sets initial resource allocations.

WLM sets resource allocations for your workloads based on metrics for the workloads. When you first start WLM however, there are no metrics for the workloads. So, WLM sets these initial allocations, in terms of shares, as follows:

CPU shares: Each workload gets 1/n of the total CPU resources, where n is the number of workloads

Memory shares: Each workload gets the default minimum memory allocation (although the group can use more if needed)

Disk bandwidth shares: Are set as indicated in the configuration file (if they are specified at all)

CPU shares are either relative or absolute. With relative shares, a workload’s number of shares relative to the total number of shares for all the workloads determines the group’s allocation. For example, if group A has 50 shares and the other groups in the configuration have 150 shares, group A has 50/200 or 25% of the CPU resources (cores). With absolute CPU shares, 100 shares represent one core. So, you only need to know how many shares a group has to determine its allocation. For example, assume group A has 50 shares again. This is an allocation of half of a core.

Accepts or calculates performance data.

For metric goals and shares-per-metric allocations, WLM accepts metrics from data collectors. For usage goals and fixed allocations, WLM calculates the metrics itself.

Compares performance data (reported performance) to stated goals (desired performance) for each active goal-based SLO.

Determines new CPU allocations so that reported performance converges on desired performance; also determines CPU allocations to satisfy requests for shares-per-metric allocations and fixed allocations.

Arbitrates between workloads when CPU resources are insufficient to meet the needs of all workloads.

When CPU resources are not sufficient, certain workloads necessarily will not be able to reach their desired performance levels. In these cases, WLM allocates resources to the associated workloads based on their SLOs’ assigned priorities—allowing the higher-priority SLOs to better meet their goals at the expense of the lower-priority SLOs not meeting their goals.

Determines memory allocations based on whether any workloads have become active or gone inactive.

Sends request to the WLM global arbiter to increase or decrease the number of cores in the current partition as appropriate.

You can use WLM within and across:

Assigns new CPU and memory shares.

Writes to log files.

If you enabled statistics logging with the wlmd -l option, at the end of each WLM interval, WLM adds data for the interval to the /var/opt/wlm/wlmdstats file.

Also, the WLM global arbiter writes to its own statistics log file if you enabled logging with the wlmpard -l option. At the end of each global arbiter interval, the global arbiter adds data for the interval to the /var/opt/wlm/wlmpardstats file.

Sets EMS resources for monitoring of SLO compliance.

Repeats tasks 2 through 10 the next WLM interval.

WLM adds messages, at any time, to its message log /var/opt/wlm/msglog. This log, which WLM automatically creates, informs you of the WLM daemon’s operations.

WLM and the global arbiter daemon generate audit data files, if enabled (using the -t option to wlmd and wlmpard when you activated your WLM configuration and global arbiter configuration).

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.

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.

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.

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.

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.

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.

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.

For managing resources within a single HP-UX instance, WLM then creates a new PRM configuration applying the new CPU shares and optional memory shares for the various workload groups.

For managing CPU resources (cores) across partitions, the WLM instance on each partition regularly requests from the WLM global arbiter a certain number of cores for its partition.

With WLM performing cross-partition management, this WLM process flow being described is duplicated in each partition. The WLM global arbiter takes the CPU resource requests from the WLM instance on each partition and then uses these requests to decide how to allocate cores to the partitions. Next, it adjusts a partition’s number of cores in an effort to better meet the SLOs in the partition.

	NOTE: For partitions, you can bypass creating workloads (workload groups), treating the partition itself as the workload. Par 2 and Par 3 show the scenario.