HP-UX Workload Manager overview

10
Allocating CPU resources dynamically based on utilization
Consider an SLO with a usage goal. Usage goals do not require a metric value. WLM tracks the
metric itself. In this example, the workload (named Orders) is the collection of processes running in a
virtual partition. WLM adjusts the CPU allocation of the virtual partition based on the CPU utilization
of the workload within that partition. If the utilization is low (perhaps caused by fewer applications
running), the CPU allocation for the partition is reduced, making more resources available to other
partitions in the complex. If utilization is high, the partition receives a larger CPU allocation.
Regardless of utilization, this SLO ensures that the partition is allocated at least 200 shares but no
more than 800 shares, where 100 shares represents one core (when managing partitions, WLM
equates one core to 100 shares).
Workload: Orders
Priority: 1
Goal: Match CPU allocation to consumption
Minimum CPU: 200 shares
Maximum CPU: 800 shares
Controlling sharing and borrowing of excess CPU resources
Consider a workload with multiple SLOs, each SLO having a usage goal. The associated workload,
named Development, is owned by a department that funded 30% of the server. Consequently, that
department expects to get 30% of the server when needed. In the following SLOs, 100 CPU shares
represent the total CPU resources (cores) on the server. Therefore, 30% of the server is 30 CPU
shares. When the Development workload is not busy, excess resources are available for sharing, as
long as the Development workload is getting at least 15 shares. This condition is represented by the
following SLO:
Workload: Development
Priority: 1
Goal: Match CPU allocation to consumption
Minimum CPU: 15 shares
Maximum CPU: 30 shares
When the workload becomes very busy, the Development workload must borrow from other
workloads that might have excess resources. Based on usage patterns, the system administrator has
agreed to let the workload borrow up to an additional 20 shares, if available, which allows the
Development workload to access up to 50 CPU shares. The associated SLO is summarized as:
Workload: Development
Priority: 2
Goal: Match CPU allocation to consumption
Minimum CPU: 25 shares
Maximum CPU: 50 shares
Because this SLO is priority 2, it is met only after all priority 1 SLOs have been met.
Automatically resizing pSets
With multiprocessor systems, you can group processors together to form pSets. By creating pSets, you
isolate CPU resources for users and applications.
WLM enables you to define workloads based on pSets. If you then specify SLOs for the workloads,
WLM automatically adjusts the number of processors in the pSets based on progress toward the SLOs.
In this example, the pSet workload named Batch gets five processors, but only between 10:00 p.m.
and 4:00 a.m. At other times, Batch gets a default minimum of one processor. (Here, WLM is using
“absolute CPU units,” for which 100 shares represent one core.)
Workload: Batch
Priority: 1