Home/Knowledge

WLM, performance index, R4HA and capping — explained

Vendor-neutral fundamentals, concisely presented. Exactly the part we start every results workshop with, so that everyone involved speaks the same language.

Basic terms

MSU, MIPS and CPU time

MSU stands for “millions of service units per hour”. It is the capacity and billing measure, normalised independently of the machine, and the basis for sub-capacity, capacity limits and group limits.

MIPS is a comparison and sizing figure for processor performance — not a billing basis.

CPU time is the actual measurement in the system and is recorded as service units. Via a system constant this becomes CPU time and finally MSU.

Rule of thumb: CPU time is measured, service units normalise it, MSU is what you are billed for.

Steering

How the Workload Manager operates

WLM distributes CPU capacity according to a policy. Only one policy is ever active; any number may be installed, for example for day and night operation. A policy consists of the service definitions (service classes with goals) and the classification rules (which workload ends up where).

  • Every 250 ms WLM collects measurements
  • Every 10 seconds it helps exactly one service class
  • It identifies the class doing worst — and gives resources to precisely that one
  • Receivers are served from high priority downwards, donors are drawn from low priority upwards
Capacity limit 00:0006:00 12:0018:00 24:00 MSU Rolling 4h average Consumption per interval monthly peak
Only the smoothed curve is cost-relevant — and of that, only the highest point of the billing period.

Cost mechanics

Why the four-hour average exists at all

Three reasons, all of them reasonable:

  • Smoothing. Short spikes from batch starts, backup runs or garbage collection do not hit the invoice directly.
  • Traceability. You pay for sustained usage across four hours — reproducibly measurable from operational data.
  • Controllability. The average reacts slowly and predictably and can therefore be limited deliberately.

The value is kept per partition, formed over 16 intervals of 15 minutes and always reported rounded down. WLM continuously compares it with the partition's capacity limit.

Terminology

Capping, defined capacity and capacity groups

Soft versus hard capping

Hard capping limits immediately and independently of the average — it caps every single dispatch decision. Soft capping only takes effect once the four-hour average exceeds the limit.

Hard capping caps the moment, soft capping caps the average. For cost control, soft capping is the instrument of choice.

Defined capacity

An MSU value set per partition that the rolling average must not exceed. It is set at the management console and can be changed during operation.

Set too tight it throttles the workload; set too generously it has no cost effect. The art lies exactly in between — and that can be measured.

Capacity groups

A group combines partitions of exactly one machine under a shared MSU limit. Each partition's guaranteed share derives from its share of the weights.

Unused shares move to the other partitions — as long as the sum stays below the group limit, nothing is capped.

Performance index

What the PI says — and what it does not

The performance index measures how well a service class meets its goal. PI < 1 means exceeded, PI = 1 exactly met, PI > 1 missed.

The most common fallacy

A PI of 0.5 looks excellent at first glance. In fact it means all transactions finish within half the target time — so the goal is set far too weakly. The consequence: the class becomes a resource donor and is the first to be throttled when capacity is scarce.

A good PI does not come from an easy goal but from a goal that matches the real work. Only then does WLM steer sensibly.

The reverse case

A class with high priority whose goal is never remotely met is equally a finding: WLM continuously pours CPU cycles into an unattainable target — at the expense of other classes that would actually have benefited.

For transactional goals the highest reported PI is arithmetically 4. If you see that value permanently, review the goal rather than the hardware.

Underrated

Report classes — low effort, high insight

Report classes make consumption visible without influencing steering: no effect on prioritisation, no goals of their own, virtually no overhead.

They turn questions that otherwise remain guesswork into measurable facts: how much does a single transaction monitor consume? How often does a transaction run and what does it cost? How much does application batch consume per month?

Use this option wherever you can.

Reading priority levels correctly

The priority level of a service class means time-critical or not time-critical — not important or unimportant. A business-critical report can legitimately run at a low level if it does not need a short response time.

Equally often misunderstood: WLM only steers when things actually get tight. Without genuine resource scarcity there is nothing to redistribute — and therefore no active steering.

This section is also available as a workshop.

We combine the fundamentals with your own data, turning theory into a basis for decisions.