HP-UX Workload Manager

User’s Guide
Version A.03.02.02

Manufacturing Part Number: B8844-90014

January 2007

© Copyright 2000-2007 Hewlett-Packard Development Company, L.P.

 Publication history
Tenth edition
January 2007
B8844-90014
HP-UX 11i v3
Ninth edition
September 2006
B8844-90012
HP-UX 11i v1, HP-UX 11i v2, and HP-UX 11i v3
Eighth edition
March 2006
B8844-90010
HP-UX 11i v1 and HP-UX 11i v2
Seventh edition
May 2005
B8844-90008
HP-UX 11i v1 and HP-UX 11i v2
Sixth edition
March 2004
B8844-90006
HP-UX 11.0, HP-UX 11i v1, and HP-UX 11i v2
Fifth edition
June 2003
B8844-90005
HP-UX 11.0, HP-UX 11i v1, and HP-UX 11i v2
Fourth edition
June 2002
B8844-90003
HP-UX 11.0 and HP-UX 11i v1
Third edition
June 2001
B8844-90002
HP-UX 11.0 and HP-UX 11i v1
Second edition
December 2000
B8843-90004
HP-UX 11.0
First edition
April 2000
B8844-90001
HP-UX 11.0
Notice
 Copyright 2000-2006 Hewlett-Packard Development Company, L.P.
All Rights Reserved. Reproduction, adaptation, or translation without
prior written permission is prohibited, except as allowed under the
copyright laws.
The information contained in this document is subject to change without
notice.
Hewlett-Packard makes no warranty of any kind with regard to this
material, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. Hewlett-Packard
shall not be liable for errors contained herein or for incidental or
consequential damages in connection with the furnishing, performance
or use of this material.
Oracle is a registered trademark of Oracle Corporation, Redwood City,
California.
SAS and all other SAS Institute Inc. product or service names are
registered trademarks or trademarks of SAS Institute Inc. in the USA
and other countries.  indicates USA registration.
SAP is a registered trademark of SAP AG in Germany and several other
countries.
The SNMP Toolkit uses a library written by CMU:

 Copyright 1998 by Carnegie Mellon University

All Rights Reserved
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the previous copyright notice appear in all copies and
that both that copyright notice and this permission notice appear in
supporting documentation, and that the name of CMU not be used in
advertising or publicity pertaining to distribution of the software
without specific, written prior permission.
CMU disclaims all warranties with regard to this software, including
all implied warranties of merchantability and fitness, in no event
shall CMU be liable for any special, indirect or consequential
damages or any damages whatsoever resulting from loss of use, data
 or profits, whether in an action of contract, negligence or other
tortious action, arising out of or in connection with the use or
performance of this software.
BEA, Tuxedo, and WebLogic are registered trademarks and BEA
WebLogic Enterprise Platform, BEA WebLogic Server, BEA WebLogic
Integration, BEA WebLogic Portal, BEA WebLogic JRockit, BEA
WebLogic Platform, BEA WebLogic Express, BEA WebLogic Workshop,
BEA WebLogic Java Adapter for Mainframe, BEA Liquid Data for
WebLogic and BEA eLink are trademarks of BEA Systems, Inc.
HP-UX Workload Manager and JFreeChart:

Starting with version A.02.01, HP-UX Workload Manager uses

JFreeChart, an open source software package for displaying charts
and graphs. JFreeChart is licensed under the GNU Lesser General
Public License (LGPL). A copy of this license is available at
/opt/wlm/lib/mongui/LGPL.txt and at the following GNU Web site:
http://www.gnu.org/licenses/lgpl.txt.
The version of JFreeChart that Workload Manager uses is a modified
version of JFreeChart 0.9.4. For information on the modifications,
see /opt/wlm/lib/mongui/README. The latest version of JFreeChart
is available at the following Web sites:
http://www.object-refinery.com/jfreechart/
http://www.sourceforge.net.
HP-UX Workload Manager and libxml2:

Starting with version A.03.00, HP-UX Workload Manager uses

lilbxml2, the XML C parser and toolkit developed for the Gnome
project at MIT. Though it is written in the C language, a variety of
language bindings make it portable to other environments. It is
licensed under the agreement available at
/opt/wlm/lib/README.libxml2. The version of libxml2 that HP-UX
Workload Manager uses is libxml2 2.6.10.
 Contents

Preface
System platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Associated software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Document Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
New in this edition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Feedback to the HP-UX WLM team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Support and patch policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Notational conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Associated documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1. Introduction
Performance and resource management overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
What is workload management? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
What is HP-UX Workload Manager? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Workload management across partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Workload management within a single HP-UX instance . . . . . . . . . . . . . . . . . . . . . . 44
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Why use Workload Manager? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Service-level objectives (SLOs). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Prioritized SLOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
WLM and partitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
What is the ideal environment for WLM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Examples of solutions that WLM provides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
SLOs that ensure a specified amount of CPU shares for workloads . . . . . . . . . . . . . 52
Reserving CPU resources all of the time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Reserving CPU resources at specified times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Reserving CPU resources based on a condition or event . . . . . . . . . . . . . . . . . . . . 53
Ensuring resources in an HP Serviceguard failover . . . . . . . . . . . . . . . . . . . . . . . . 53
SLOs that dynamically allocate resources based on usage goals. . . . . . . . . . . . . . . . 54
Allocating CPU resources dynamically based on utilization . . . . . . . . . . . . . . . . . 54
Controlling the sharing and borrowing of excess CPU resources. . . . . . . . . . . . . . 54
Automatically resizing processor sets (PSETs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Automatically resizing virtual partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Automatically resizing nPartitions using Instant Capacity cores . . . . . . . . . . . . . 56
Optimizing use of Temporary Instant Capacity (TiCAP) and Pay per use (PPU) . 57

7
Contents

Using WLM on multiple servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Using WLM with HP Integrity Virtual Machines (Integrity VM) . . . . . . . . . . . . . . . . 58
WLM and Process Resource Manager (PRM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
WLM product directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

2. WLM quick start: the essentials for using WLM

Network operating environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
WLM shown in action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Where WLM is installed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Seeing how WLM will perform without actually affecting your system . . . . . . . . . . . 75
Starting WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Stopping WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Creating a configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
The easiest way to configure WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Where to find example WLM configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
How WLM controls applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
How to put an application under WLM control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Application records: Workload separation by binary name . . . . . . . . . . . . . . . . . . . . 83
User records: Workload separation by process owner UID . . . . . . . . . . . . . . . . . . . . 83
Unix group records: Workload separation by Unix group ID . . . . . . . . . . . . . . . . . . 84
Secure compartments: Workload separation by secure compartment . . . . . . . . . . . 85
Process maps: Workload separation using your own criteria. . . . . . . . . . . . . . . . . . . 85
prmrun: Starting a process in a workload group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
prmmove: Moving an existing process to a workload group. . . . . . . . . . . . . . . . . . . . 86
Default: Inheriting workload group of parent process . . . . . . . . . . . . . . . . . . . . . . . . 87
How to determine a goal for your workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Some common WLM tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Migrating cores across partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Providing a fixed amount of CPU resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Portions of processors (FSS groups) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Whole processors (PSETs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Providing CPU resources for a given time period . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Providing CPU resources as needed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Other functions WLM provides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Run in passive mode to verify operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Auditing and billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

8
 Contents

Optimize use of Temporary Instant Capacity (TiCAP). . . . . . . . . . . . . . . . . . . . . . . 102

Integrate with various third-party products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Status information WLM provides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Monitoring WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
ps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
wlminfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
wlmgui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
prmmonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
prmlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
GlancePlus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
wlm_watch.cgi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Status and message logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Event Monitoring Service (EMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

3. How WLM manages workloads

How WLM works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Shares-based SLOs vs goal-based SLOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
How WLM gets application data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
How a workload is managed (controllers). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
SLO violations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
How conflicting SLOs are resolved (arbiter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Allocating CPU resources: The rising tide model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Example of WLM in use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

4. How do I use WLM?

Phasing in your WLM implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Steps for using WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Reconfiguring WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Disabling WLM and its global arbiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5. Configuring WLM
Configuration file syntactic conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Using the WLM configuration wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Using the WLM GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Tips on using the WLM GUI’s tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

9
Contents

Controlling system resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Specifying the WLM parser version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Notification of ‘Instant Capacity needed’ / Pay per use optimization . . . . . . . . . . . . . 144
System-wide settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Defining the PRM components (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Defining PRM components using the WLM GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Specifying workload groups (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Reserved workload groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
The default PSET (PSET 0) and FSS groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Assigning users and user access to workload groups (optional) . . . . . . . . . . . . . . . 164
Assigning Unix groups to workload groups (optional) . . . . . . . . . . . . . . . . . . . . . . . 165
Assigning applications to workload groups (optional) . . . . . . . . . . . . . . . . . . . . . . . 166
Script example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Renamed application example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Assigning secure compartments to workload groups (optional). . . . . . . . . . . . . . . . 171
Specifying process maps to define your own criteria for workload separation (optional)
172
PID finder examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Specifying disk bandwidth shares (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Specifying a group’s minimum CPU resources (optional) . . . . . . . . . . . . . . . . . . . . 175
Specifying a group’s maximum CPU resources (optional) . . . . . . . . . . . . . . . . . . . . 177
Weighting a group so it gets more CPU resources (optional) . . . . . . . . . . . . . . . . . . 178
Interaction between weight and distribute_excess . . . . . . . . . . . . . . . . . . . . . . . . 181
Specifying a group’s minimum memory (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Specifying a group’s maximum memory (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Weighting a group so it gets more memory (optional) . . . . . . . . . . . . . . . . . . . . . . . 184
Defining SLOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Defining SLOs using the WLM GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Specifying the SLO name (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Specifying the priority (required). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Specifying the workload group to which the SLO applies (optional) . . . . . . . . . . . . 195
Specifying the lower and upper bound requests on CPU resources (optional) . . . . 196
Specifying a goal (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Goals vs stretch goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Specifying a fixed or additive allocation of CPU shares (optional) . . . . . . . . . . . . . 204
Specifying a shares-per-metric allocation request (optional) . . . . . . . . . . . . . . . . . . 205

10
 Contents

Specifying when the SLO is active (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Tuning the metrics and the SLOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Tuning WLM using the WLM GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Specifying a data collector (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Specifying the WLM interval (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Using absolute CPU units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Distributing excess CPU resources to your workloads (optional) . . . . . . . . . . . . . . 218
Refining granularity of CPU (and memory) allocation by increasing shares per core
(optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Temporarily removing groups with inactive SLOs (optional) . . . . . . . . . . . . . . . . . 220
Placement of processes for inactive FSS groups . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Placement of processes for PSET-based groups. . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Capturing your collectors’ stderr (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Smoothing metric values (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Controlling averaging in usage controllers (optional) . . . . . . . . . . . . . . . . . . . . . . . 223
Trimming the statistics log file automatically (optional) . . . . . . . . . . . . . . . . . . . . . 224
Tuning a workload’s SLO convergence:
cntl_kp (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Tuning a workload’s SLO convergence: cntl_convergence_rate (optional) . . . . . . . 229
Tuning the goal buffer (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Releasing cores properly (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Example configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Trying a configuration without affecting the system. . . . . . . . . . . . . . . . . . . . . . . . . . 236
Passive mode versus actual WLM management. . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
The WLM feedback loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Effect of mincpu and maxcpu values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Monitoring WLM in passive mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
The effect of passive mode on usage goals and metric goals. . . . . . . . . . . . . . . . . 240
Activating the configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Setting WLM to start automatically at reboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Setting WLM global arbitration to start automatically at reboot . . . . . . . . . . . . . . . . 242
Setting the WLM communications daemon to start automatically at reboot. . . . . . . 243
Securing WLM communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Enabling statistics logging at reboot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Disabling statistics logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
WLM and kernel parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

11
Contents

6. Auditing and billing

Example wlmaudit report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Audit data files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Enabling auditing at reboot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

7. Managing SLOs across partitions

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Recommendations, requirements, and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Setting up cross-partition management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Setting up your WLM configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Setting up your WLM global arbiter configuration file . . . . . . . . . . . . . . . . . . . . . . . . 265
par structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Using the WLM GUI to set up the global arbiter configuration file . . . . . . . . . . . . 267
Specifying the global arbiter interval (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Specifying the port (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Trimming the global arbiter statistics log automatically (optional) . . . . . . . . . . . . 272
Specifying the priority at which to use Temporary Instant Capacity or Pay per use
resources (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Specifying the reserve threshold that determines when WLM stops activating
temporary capacity resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

8. Management of nested nPars / vPars / workload groups

Setting up the various configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Managing FSS and PSET-based groups inside vPars inside nPars (Instant Capacity
available in the complex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Managing FSS and PSET-based groups inside vPars inside nPars (Instant Capacity
not available). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Managing FSS and PSET-based groups inside vPars . . . . . . . . . . . . . . . . . . . . . . . . . 282

9. Example configuration files

distribute_excess.wlm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
enabling_event.wlm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
entitlement_per_process.wlm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
fixed_entitlement.wlm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
manual_cpucount.wlm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
manual_entitlement.wlm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

12
 Contents

metric_condition.wlm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
par_manual_allocation.wlm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
par_manual_allocation.wlmpar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
par_usage_goal.wlm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
par_usage_goal.wlmpar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
performance_goal.template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
stretch_goal.wlm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
time_activated.wlm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
transient_groups.wlm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
twice_weekly_boost.wlm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
usage_goal.wlm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
usage_stretch_goal.wlm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
user_application_records.wlm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

10. Monitoring SLO compliance and WLM

Monitoring WLM with the wlminfo command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Monitoring WLM with the wlmgui command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Monitoring the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Monitoring the number of CPU resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Monitoring the workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Monitoring SLOs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Monitoring items you define . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Monitoring WLM with EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
What EMS resources are available? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
WLM status and time of last configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
SLO configuration data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
SLO status updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Metric status updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Configuring EMS notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

A. WLM command reference

wlmaudit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
wlmcert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
wlmcomd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
wlmcw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
wlmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

13
Contents

wlmgui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
wlminfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
wlmpard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
wlmrcvdc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
wlmsend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

B. WLM configuration file

syntax overview
Configuration file syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Configuration file example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

C. HP-UX command and system call support

D. Integration with other products

Integrating with Process Resource Manager (PRM) . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Integrating with processor sets (PSETs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Integrating with nPartitions (nPars) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Integrating with virtual partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Integrating with HP Integrity Virtual Machines (Integrity VM) . . . . . . . . . . . . . . . . 408
Running WLM on an Integrity VM Host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Running WLM within an Integrity VM (guest) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
For more HP Integrity VM information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Integrating with Temporary Instant Capacity (TiCAP)/ Pay per use (PPU) . . . . . . . 410
For more Temporary Instant Capacity / Pay per use information . . . . . . . . . . . . . . 411
Integrating with Security Containment (to form Secure Resource Partitions) . . . . . 412
Integrating with
OpenView Performance Agent (OVPA) / OpenView Performance Manager (OVPM) 413
Integrating with Serviceguard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Steps for integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Integrating with HP Systems Insight Manager (SIM) and Servicecontrol Manager
(SCM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
What WLM tasks are available through SIM / SCM? . . . . . . . . . . . . . . . . . . . . . . . 420
Workload Manager Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Activate WLM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Enable WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Disable WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

14
 Contents

Install WLM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

Restart WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Retrieve WLM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Rotate WLM Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Rotate Statistics Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Start WLM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Stop WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Syntax Check Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Syntax Check on CMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Truncate Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Truncate Statistics Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
View WLM Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
View Statistics Log Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Accessing the WLM tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
For more SCM information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Integrating with Oracle® databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Why use Oracle database metrics with WLM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Tools in the HP-UX WLM Oracle Database Toolkit (ODBTK). . . . . . . . . . . . . . . . . 428
What metrics are available?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
How do I get started with ODBTK? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
ODBTK examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
For more ODBTK information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Integrating with Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Why use ApacheTK? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Tools in ApacheTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
How do I get started with ApacheTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
For more ApacheTK information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Integrating with BEA WebLogic Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Why use WebLogicTK? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Tools in WebLogicTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
How do I get started with WebLogicTK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
For more WebLogicTK information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Integrating with SAP software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Why use SAPTK? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Tools in SAPTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
How do I get started with SAPTK? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439

15
Contents

For more SAPTK information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439

Integrating with SAS software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Why use SASTK? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Tools in SASTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
How do I get started with SASTK? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
For more SASTK information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Integrating with the HP-UX SNMP agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Why use SNMPTK? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Tools in SNMPTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
How do I get started with SNMPTK? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
For more SNMPTK information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

E. Useful PRM utilities

F. Understanding how PRM manages resources

Management of CPU resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Management of CPU resources for real-time processes . . . . . . . . . . . . . . . . . . . . . 448
Management of real memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Capping memory use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Management of locked memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Management of disk bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
How resource allocations interact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Management of applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
How application processes are assigned to workload groups at start-up . . . . . . . . 455
How child processes are handled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Pattern matching for file names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Pattern matching for renamed application processes. . . . . . . . . . . . . . . . . . . . . . . . 457
How the application manager affects workload group assignments . . . . . . . . . . . . 459

G. Migrating from PRM to WLM

H. Advanced WLM usage: Using performance metrics

Configuring WLM for metric-based SLOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Specifying a metric goal (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470

16
 Contents

Specifying a shares-per-metric allocation request (optional) . . . . . . . . . . . . . . . . . . 472

Providing CPU resources in proportion to a metric . . . . . . . . . . . . . . . . . . . . . . . 475
Specifying a data collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Capturing your collectors’ stderr (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Smoothing metric values (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Supplying data to WLM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
How applications can make metrics available to WLM . . . . . . . . . . . . . . . . . . . . . . 483
Time metrics from instrumentable applications . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Other data collection techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
What happens when there is no new data?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
I have this type of data—how do I send it to WLM? . . . . . . . . . . . . . . . . . . . . . . . . . 486
ARM transaction data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
GlancePlus application data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
GlancePlus global data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
GlancePlus PRM-specific application data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
GlancePlus PRM-controlled volume group data . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Oracle database data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Existing metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
What methods exist for sending data to WLM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Sending data from the command line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Sending data from a shell script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Sending data from a perl program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Sending data via stdout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Sending data from a collector written in C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Sending ARM transaction data from a modified C program . . . . . . . . . . . . . . . . 504
Sending ARM transaction data from a script with simulated transactions . . . . 509
Sending data with wlmsend and wlmrcvdc:
How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Handling signals in data collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

17
Contents

18
 Tables

Table 1-1. Performance and resource utilization monitoring methods . . . . . . . . . . . .34

Table 1-2. Performance controlling methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Table 1-3. WLM directories and files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Table 2-1. WLM installation directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Table 2-2. Example WLM configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Table 5-1. weight keyword example (weights take effect) . . . . . . . . . . . . . . . . . . . . .180
Table 5-2. weight example with distribute_excess = 0 (off) . . . . . . . . . . . . . . . . . . . .182
Table 5-3. weight example with distribute_excess = 1 (on) . . . . . . . . . . . . . . . . . . . .182
Table 5-4. memweight example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Table 5-5. Capturing remaining CPU resources with stretch goals . . . . . . . . . . . . .193
Table 10-1. Overview of WLM EMS resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .355
Table C-1. HP-UX commands/system calls that support workload groups. . . . . . . .401
Table C-2. WLM options in HP-UX commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . .402
Table D-1. ODBTK’s example WLM configuration files described . . . . . . . . . . . . . .429
Table D-2. wlmoradc example configuration files described . . . . . . . . . . . . . . . . . . .430
Table F-1. Resources managed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .447
Table F-2. Group assignments at process start-up. . . . . . . . . . . . . . . . . . . . . . . . . . .455
Table H-1. Type of data and its transport method . . . . . . . . . . . . . . . . . . . . . . . . . . .487
Table H-2. Available transport methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .494
Table H-3. ARM API routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .506

19
Tables

20
 Figures

Figure 3-1. WLM overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115

Figure 3-2. CPU allocation: the rising tide model . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Figure 3-3. Server without WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
Figure 3-4. Server with WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125
Figure 5-1. HP-UX WLM Configuration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Figure 5-2. HP-UX WLM GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
Figure 5-3. Workloads with SLOs at same priority . . . . . . . . . . . . . . . . . . . . . . . . . .194
Figure 5-4. Additional workload with same priority SLO . . . . . . . . . . . . . . . . . . . . .195
Figure 5-5. Usage goal conceptually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
Figure 5-6. Effect of the cntl_margin tunable parameter . . . . . . . . . . . . . . . . . . . . .232
Figure 5-7. Normal WLM operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
Figure 5-8. Passive WLM operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239
Figure 7-1. WLM managing partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256
Figure 8-1. Nested partitions to be managed (with Instant Capacity) . . . . . . . . . . .278
Figure 8-2. Nested partitions to be managed (without Instant Capacity) . . . . . . . .280
Figure 10-1. Monitoring a configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
Figure 10-2. Monitoring the number of CPU resources . . . . . . . . . . . . . . . . . . . . . . .349
Figure 10-3. Monitoring a workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .350
Figure 10-4. Items to graph when monitoring a workload . . . . . . . . . . . . . . . . . . . .351
Figure 10-5. Graphing SLOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352
Figure 10-6. Custom graphing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .353
Figure 10-7. Interaction between WLM and EMS . . . . . . . . . . . . . . . . . . . . . . . . . . .354
Figure D-1. WLM and Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .408
Figure D-2. WLM integration with Serviceguard . . . . . . . . . . . . . . . . . . . . . . . . . . .415
Figure F-1. Locked memory distribution by prm2d memory manager . . . . . . . . . . .451
Figure H-1. Interaction of WLM and ARM-instrumented applications . . . . . . . . . .505
Figure H-2. wlmrcvdc: command-pipe mode (wlmrcvdc command [args]) . . . . . . . .511
Figure H-3. wlmrcvdc: FIFO-file mode (wlmrcvdc) . . . . . . . . . . . . . . . . . . . . . . . . . .512
Figure H-4. wlmsend: command-output mode (command | wlmsend metric) . . . . .513
Figure H-5. wlmsend: single-value mode (wlmsend metric value) . . . . . . . . . . . . . .514

21
Figures

22
 Preface

This document describes the Version A.03.02.02 release of HP-UX

Workload Manager (HP-UX WLM).
The intended audience for this document is system administrators.

System platform
HP-UX WLM A.03.02 runs under the following HP-UX operating
systems and hardware:

Operating Systems Hardware

HP-UX 11i v1 (B.11.11) HP 9000 servers

HP-UX 11i v2 (B.11.23) HP 9000 servers and Integrity servers

HP-UX 11i v1 (B.11.11) and Servers combining HP 9000 partitions and HP

HP-UX 11i v2 (B.11.23) Integrity partitions (in such environments,
HP-UX 11i v1 (B.11.11) supports HP 9000
partitions only)

HP-UX WLM A.03.02.02 runs under the following HP-UX operating

system and hardware:

Operating Systems Hardware

HP-UX 11i v3 (B.11.31) HP 9000 servers, HP Integrity servers, and

servers combining HP 9000 partitions and HP
Integrity partitions

Associated software
Installing HP-UX Workload Manager ensures that the following software
is also installed:

• HP-UX WLM Toolkits (WLMTK) A.01.09 or later

WLMTK facilitates integrating HP-UX WLM with various
third-party products.
If the system already has the correct version installed, it will not be
modified.

23
 If you plan to use configuration files based on Process Resource Manager
(PRM), ensure that version C.03.00 or later of PRM is installed. To take
advantage of the latest updates to WLM, use the latest version of PRM
(C.03.02 or later). PRM is necessary for managing processor sets (PSETs)
or Fair Share Scheduler (FSS) groups, which are confined within a
specific instance of HP-UX. If you plan to use WLM to manage
host-based configurations only, PRM is not necessary. Host-based
configurations are designed for moving CPU resources (cores, which are
the actual data-processing engines within a processor; a processor might
have multiple cores, and a core might have multiple execution threads)
across virtual partitions and nPartitions; the configurations are not
confined within a specific instance of HP-UX as are PRM-based
configurations. For more information, see Chapter 7, “Managing SLOs
across partitions,” on page 255.
HP-UX WLM provides a method for collecting system and application
data from GlancePlus. You can use WLM with any HP-UX 11i version of
GlancePlus. On HP-UX 11i v1, be sure to install either the 11i
Enterprise Operating Environment or 11i Mission-critical Operating
Environment to ensure you have a GlancePlus version that is fully
compatible with WLM.

Document Structure
This document is organized as follows:

• Chapter 1 introduces the basic concepts of performance

management, workload management, and HP-UX Workload
Manager (WLM).

• Chapter 2 provides an overview of the techniques and tools available

for using WLM. It serves as a condensed version of the user’s guide,
introducing you to the essentials and allowing you to get started
using WLM.
• Chapter 3 describes how WLM manages workloads through
service-level objectives (SLOs). It discusses WLM’s two types of
SLOs: shares-based and goal-based SLOs.
• Chapter 4 discusses the basic steps you need to take to use WLM.
The remainder of the chapters in the book discuss these steps in
detail.

24
• Chapter 5 explains how to configure WLM. It describes the WLM
configuration file and the general syntactic conventions to use, and it
explains how to define the various WLM components. This chapter
also explains how to use the WLM graphical user interface to
configure WLM and how to activate the configuration file so that
WLM manages the system.
• Chapter 6 describes WLM auditing and billing. It explains how to
enable WLM to audit data and how you can display that data.
• Chapter 7 describes how WLM manages SLOs across virtual
partitions and nPartitions and explains how to configure
cross-partition management.
• Chapter 8 explains how to manage nested workloads.
• Chapter 9 presents example configuration files that are available
from WLM directories. These examples show how to use the syntax
discussed in Chapter 5.
• Chapter 10 explains how to monitor WLM SLO compliance and other
information.
• Appendix A is a command reference, describing the functions,
syntax, and arguments for each WLM command.
• Appendix B is a quick reference for the WLM configuration file
syntax, indicating the required and optional components.
• Appendix C lists standard HP-UX commands and system calls that
support WLM workload groups and allow you to use WLM more
efficiently. These commands are not shipped as part of the WLM
product.
• Appendix D describes how WLM integrates with other products to
provide better functionality.
• Appendix E lists PRM utilities that WLM users may find helpful.
These utilities are helpful only when the WLM configuration
includes a prm structure. For additional information, see the
manpages or to the Process Resource Manager User’s Guide
(available in /opt/prm/doc/).
• Appendix F describes how PRM manages resources. This appendix is
provided as background information, given that WLM uses some of
PRM resource management concepts and tools.

25
 • Appendix G explains how to convert PRM configuration files to WLM
configuration files if you want to migrate from PRM to WLM.
• Appendix H explains advanced WLM usage pertaining to metric
goals and collecting performance data.
• The Glossary defines key terms used in this document.

26
New in this edition
This section lists the new or changed functionality for WLM A.03.02 and
WLM A.03.02.02. WLM A.03.02 supports HP-UX 11i v1 (B.11.11) and
HP-UX 11i v2 (B.11.23). WLM A.03.02.02 supports HP-UX 11i v3
(B.11.31).

• WLM A.03.02.02 supports HP-UX 11i v3 (B.11.31).

• WLM A.03.02.02 supports the logical CPU (Hyper-Threading)
feature, which is available starting with HP-UX 11i v3 (B.11.31) for
processors designed to support the feature and that have the
appropriate firmware installed. A logical CPU is an execution thread
contained within a core. Each core with Hyper-Threading enabled
can contain multiple logical CPUs. WLM supports the
Hyper-Threading feature for PSET-based groups. WLM
automatically sets the Hyper-Threading state for the default PSET
to optimize performance. (The default PSET, also known as PSET 0,
is where all FSS groups reside.) When new PSETs are created, they
inherit the Hyper-Threading state that the system had before WLM
was activated (inheritance is based on the system state prior to WLM
activation because WLM may change the Hyper-Threading setting
for the default PSET to optimize performance). Cores can be moved
from one partition to another and will take on the Hyper-Threading
state of their destination PSET. You can override the default
Hyper-Threading state of cores assigned to a specific PSET group;
you can also modify the Hyper-Threading state of the system.
(Modifications to the Hyper-Threading state should not be made
while WLM is running.) For more information, see “Specifying
workload groups (optional)” on page 159 and wlmconf(4).
• When referring to hardware, CPUs are now referred to as cores in
the documentation and in WLM displays or data reports. A core is
the actual data-processing engine within a processor. A processor
might have multiple cores, and a core might support multiple
execution threads through Hyper-Threading. The term “CPU” is still
used when referring to concepts such as “CPU resources” or “CPU
utilization”; whenever the number of physical processing devices is
reported by WLM or discussed by the documentation, the number
will be stated explicitly in terms of cores. Note also that PSET sizes
and Instant Capacity (iCAP) partitions are now expressed in terms of
cores.

27
NOTE With Hyper-Threading disabled, each core is seen as a CPU. With
Hyper-Threading enabled, each core can be seen as multiple, logical
CPUs.

• The wlminfo par and wlminfo host commands now explicitly

display core statistics, such as in the following display for the
wlminfo par command:

Hostname Intended Cores Cores Cores Used Interval

• The wlminfo group command now displays memory utilization of all

groups in the current deployed configuration. In addition, this
command now supports the -v option to display each group’s
gmincpu, gmaxcpu, gminmem, and gmaxmem values, if they are
available in the current deployed configuration. This new option is
ignored if live data is not being displayed (for example, when the -o
option is being used). If memory management is not being used, a
dash (-) instead of a zero is displayed in the ‘Mem Shares’ column. If
a group’s gmincpu, gmaxcpu, gminmem, or gmaxmem value is not
assigned in the current configuration, a dash (-) is displayed in the
corresponding column.
For more information, see wlminfo(1M) or “Monitoring WLM with
the wlminfo command” on page 343.
• WLM supports the use of Extended Regular Expressions (EREs) for
defining alternate names for application records. This support
requires that PRM C.03.02 or later is running on the same system.
For more information, see “Assigning applications to workload
groups (optional)” on page 166 and “Pattern matching for renamed
application processes” on page 457.
• WLM supports placement of processes and assignment of user access
based on Unix groups. You can assign Unix groups to workload
groups by defining the uxgrp record in the prm structure. Processes
whose effective group ID (GID) matches a Unix group record will run
in the associated workload group. WLM supports Unix group records
only if PRM C.03.02 or later is running on the system. For more
information, see “Assigning Unix groups to workload groups
(optional)” on page 165.

28
• Temporary Instant Capacity (TiCAP) activates capacity in a
temporary “calling-card fashion,” such as in 20-day or 30-day
increments (where a day equals 24 hours for one core). With
Temporary Instant Capacity on the system, any number of Instant
Capacity cores can be activated as long as your prepaid temporary
capacity time has not expired. By default, if 15 or fewer processing
days are available, WLM stops activating Temporary Instant
Capacity. Beginning with this release of WLM, you can change this
default by setting the WLM global arbiter
utility_reserve_threshold keyword.
• The Pay per use Toolkit (PPUTK) and the utilitydc command are
no longer supported and have been removed from the product. Please
use the simpler and more robust Temporary Instant Capacity/Pay
per use solution available with wlmpard.
• The WLM installation script no longer detects whether the correct
version of the Java Runtime Environment (JRE) is running or
whether the correct version of PRM is running. To run the WLM GUI
(wlmgui) and the wizard (wlmcw) requires JRE version 1.4.2 or later.
For PRM-based configurations, PRM C.03.00 or later is required. To
take advantage of the latest updates to WLM, use the latest version
of PRM (C.03.02.02 or later).
• You can use WLM and PRM to manage resources on the same system
at the same time if the PRM configuration uses FSS groups only (no
PSET-based groups) and the WLM configuration is strictly
host-based. For more information, see “WLM and Process Resource
Manager (PRM)” on page 59.

Feedback to the HP-UX WLM team

If you would like to comment on the current HP-UX WLM functionality
or make suggestions for future releases, please send email to:
[email protected]
For a forum with other HP-UX WLM users, visit the IT Resource
Center’s forum for HP-UX Workload/Resource Management:
http://forums.itrc.hp.com/cm/

29
 Support and patch policies
The following Web site site provides information on WLM’s support
policy and patch policy:
http://www.hp.com/go/wlm
These policies indicate the time periods for which this version of WLM is
supported and patched.

Training
HP offers a course in HP-UX resource management using WLM. For
information, including a course outline, visit:
http://www.hp.com/education/courses/u5447s.html

Notational conventions
This section describes notational conventions used in this book.

bold monospace In command examples, bold monospace

identifies input that must be typed exactly as
shown.

monospace In paragraph text, monospace identifies

command names, system calls, and data
structures and types.
In command examples, monospace identifies
command output, including error messages.

italic In paragraph text, italic identifies titles of

documents.

italic In command syntax diagrams, italic

identifies variables that you must provide.

Brackets ( [ ] ) In command examples, square brackets

designate optional entries.
The following command example uses
brackets to indicate that the variable
output_file is optional:
command input_file [output_file]

30
 Curly brackets ({}), In command syntax diagrams, text
Pipe (|) surrounded by curly brackets indicates a
choice. The choices available are shown inside
the curly brackets, separated by the pipe sign
(|).
The following command example indicates
that you can enter either a or b:
command {a | b}

Horizontal ellipses In command examples, horizontal ellipses

(...) show repetition of the previous items.

wlminfo(1M) A manpage. The manpage name is wlminfo,

and it is located in Section 1M.

NOTE A note highlights important supplemental

information.

Associated documents
Associated documents include:

• HP-UX Workload Manager A.03.02.xx Release Notes for HP-UX 11i

v1, HP-UX 11i v2, and HP-UX 11i v3 (/opt/wlm/share/doc/)
• Workload Management home page
http://www.hp.com/go/wlm (white papers and case studies)
• wlm(5)
See this manpage for a list of all the other WLM manpages.
• wlmoradc(1M)
• wlmtk(5)
• ARM Working Group Home Page
(http://www.cmg.org/regions/cmgarmw)
• Using the Event Monitoring Service manual
• Process Resource Manager User’s Guide manual
(available at /opt/prm/doc/)
• HP-UX Workload Manager Toolkits User’s Guide manual (available
at /opt/wlm/toolkits/doc/WLMTKug.pdf)

31
 • Managing MC/ServiceGuard manual
• GlancePlus User’s Guide manual (available through the Help in the
gpm interface to GlancePlus)
• Managing Systems and Workgroups: A Guide for HP-UX System
Administrators manual
These manuals, along with many other Hewlett-Packard manuals, are
available at the following Web site:

http://docs.hp.com

NOTE WLM manpages are also available at the following Web site:
http://www.hp.com/go/wlm

32
1 Introduction

This chapter introduces the basic concepts of performance management,

workload management, and HP-UX Workload Manager (WLM). It
covers:

• Performance and resource management overview

• What is workload management?
• What is HP-UX Workload Manager?
• Why use Workload Manager?
• WLM and partitions
• Examples of solutions that WLM provides
• What is the ideal environment for WLM?
• Using WLM on multiple servers
• WLM and Process Resource Manager (PRM)
• WLM product directory structure

Chapter 1 33
Introduction
Performance and resource management overview

Performance and resource management

overview
Performance management is necessary to keep users satisfied and to
ensure that business-critical applications and transactions have the
resources they need. Resource management is necessary to help
companies use computing resources more efficiently and effectively, and
to reduce administration costs. Many companies want to consolidate (1)
their data centers onto fewer systems and (2) multiple applications onto
a single server. Managing both performance and system resources
requires maintaining a dynamic balance that optimizes resource
utilization while also maintaining performance goals, automatically
re-allocating resources in response to changing priorities and conditions.
Basically, performance and resource management requires:

• Monitoring the system to understand how the current combination of

system resources, applications, and users affects performance and
resource utilization
• Controlling performance by managing the system’s resources,
applications, and number of users
The methods to monitor and control performance and resource
utilization can vary greatly.
Table 1-1 explores advantages and disadvantages of several monitoring
methods.
Table 1-1 Performance and resource utilization monitoring methods

Method Advantages Disadvantages

Wait for users’ complaints • User-focused • Re-active (not

about performance pro-active)
• System configuration is
kept simple to reduce • Inexact
number of complaints
• Requires one
and speed resolution
application/server model
to keep number of calls
low

34 Chapter 1
 Introduction
Performance and resource management overview

Table 1-1 Performance and resource utilization monitoring methods

Method Advantages Disadvantages

Predict performance by • Detects faulty • End-to-end performance

monitoring a particular applications that are is not always tied to
application’s resource usage over-consuming resource consumption
resources
• Few options if problems
• Usage trends can be are detected (separate
used to predict future applications; buy more
loads servers)

Directly monitor through • Exact performance • Limited number of

performance metrics (for metrics applications are
example, response time or instrumented for
• Can be used pro-actively
throughput) obtained from tracking capabilities
to guarantee user’s
the application
satisfaction with • Application source code
performance may not be available for
instrumentation
• Performance
management is designed • Instrumenting source
into the application code can be
time-intensive
• Every different
application on the
system needs the
tracking capability

Directly monitor utilization • Detects applications • Not as accurate as

of CPU resources, that are over-consuming monitoring metrics
partitions, memory, disk resources
bandwidth, operating
• Detects resources that
system instances and the
are being over- or
demand imposed by users
under-consumed
and specific applications
• Can be used pro-actively
to guarantee optimal
resource utilization
• Monitoring is easier to
implement

Chapter 1 35
Introduction
Performance and resource management overview

After determining which methods you want to use for monitoring

performance and resource utilization, decide how to control performance
and resource utilization. Table 1-2 examines the advantages and
disadvantages of various control methods.
Table 1-2 Performance controlling methods

Method Advantages Disadvantages

One workload per server • Workloads do not • Server resources sit idle
compete for resources a large percentage of the
time

Multiple workloads: • Increased resource • Workloads compete for

No resource management usage resources
• Fewer servers needed • A single workload may
take over the server,
preventing other
workloads from getting
resources

Multiple workloads: • Workloads’ resource use • Performance may

Fixed resource allocation cannot exceed resource degrade when
allocations workloads cannot exceed
Example: resource allocations that
• A workload cannot take
PRM with capping enabled are set too low
over a server to the
detriment of other • Unused capacity cannot
workloads be shared optimally if
resource usage is capped
• Consistent performance
when work stays
constant in a workload
• Excess resources can
easily be tracked with
PRM and GlancePlus
tools

36 Chapter 1
 Introduction
Performance and resource management overview

Table 1-2 Performance controlling methods (Continued)

Method Advantages Disadvantages

Multiple workloads: • Workloads are • Workloads get

Variable resource guaranteed resource resources, but
allocations based on usage minimums and can performance can still be
borrow unused less than desired
Example: resources from other
• Over-performance
PRM without capping workloads
followed by typical
enabled
• Increased level of work performance can cause
is handled automatically complaints
• Excess resources can
easily be tracked with
PRM and GlancePlus
tools

Multiple workloads: • Consistent performance • Cannot be implemented

Variable resource levels are maintained immediately:
allocations based on actual, automatically application performance
reported performance must be assessed first
• Workloads can be
prioritized to ensure • Getting performance
Example: HP-UX WLM
that high-priority metrics for workloads
workloads are can be difficult; however,
guaranteed CPU WLM simplifies this
resources as needed task with a built-in data
collector
• Excess resources can
easily be tracked with
PRM and GlancePlus
tools so that
high-priority workloads
are guaranteed the
available resources

Chapter 1 37
Introduction
Performance and resource management overview

Table 1-2 Performance controlling methods (Continued)

Method Advantages Disadvantages

Multiple workloads: • Optimal resource • CPU resource

Variable resource utilization is maintained allocations are not made
allocations based on CPU automatically based on
utilization per workload application-specific
• Workloads can be
metrics
prioritized to ensure
Example: HP-UX WLM
that high-priority
workloads are
guaranteed CPU
resources as needed
• Excess resources can
easily be tracked with
PRM and GlancePlus
tools enabling reserve
capacity to be deployed
to save costs and
guaranteesing
high-priority workloads
the available resources,
as needed

The remainder of this document focuses on the last two rows of Table 1-2:
Automatically managing multiple, prioritized workloads on a single
server—possibly across partitions—based on reported performance
levels or usage goals. This strategy is commonly referred to as goal-based
workload management.
WLM implements this type of workload management allowing you to:

• Optimize your return on investment in servers

• Maintain multiple applications on a single server without increasing
performance problems
• Improve your ability to forecast capacity needs

38 Chapter 1
 Introduction
What is workload management?

What is workload management?

System management typically focuses on monitoring the availability of
systems. While system availability is certainly important, it often
neglects the complexity of modern systems and computing environments,
such as partitioning capabilities, utility pricing resources, and clustering.
System availability also neglects the importance of the applications
themselves and of the dynamic between (1) application performance as
seen by users and (2) resource management as seen by system
administrators and investors in computer resources.
To best serve financial investments and administration costs,
applications and workloads must be consolidated on fewer servers and
resources must be dynamically allocated as needed to provide expected
performance to high-priority applications. In addition, reserve capacity
should be deployable automatically to enable customers to pay for what
they need only when they need it and to make the resources available to
workloads that have the greatest demands at that time. In clusters,
higher utilization of resources can be maintained by managing failover of
workloads among servers and partitions.
To best serve end users, an application not only must be available but
must also provide its services in a timely manner with expected and
consistent levels of performance. For example, if a task is generally
expected to complete in less than 2 seconds, but takes 15, the service to
the end user is not adequate. Thus, system and application availability
do not guarantee the timeliness of a service.

Chapter 1 39
Introduction
What is workload management?

Workload management ensures a service’s availability through

service-level management. This type of management is based on the
following components:

Strategy for defining, controlling, and

IT service maintaining required levels of IT
management (Information Technology) service
to the end user.

Service-level SLAs define the service levels IT

agreements is expected to deliver to the end
(SLAs) user.

Derived from the SLAs.

Service-level Examples: utilization, availability,
objectives (SLOs)
performance, security, accuracy, and
recovery.

Goals for resource allocation, usage,

Goals or performance.

Now to explore these components in more detail:

• IT service management
A strategy driven by business requirements to provide, and in many
cases guarantee, levels of service from IT (Information Technology)
to end users. The needs of the end users are the primary driver for
the development of the IT infrastructure. The benefits of defining
this strategy are higher return on investment in IT expenditures and
also the proper setting of expectations for all organizations involved.

• Service-level agreements
Documents defining various service levels IT is expected to deliver to
the end user. These documents focus on individual applications and
the service levels required by the application users. SLAs can also be
used for budgeting, planning, and control purposes.

40 Chapter 1
 Introduction
What is HP-UX Workload Manager?

The following steps outline how to define a service-level agreement:

1. Establish an inventory of system resources (people, CPU

resources, disk space, and so forth) that serve the end users.
2. Determine how much of the inventory of system resources is
currently being consumed to support the present set of
applications.
3. Determine what the end users require to maintain the status quo
if they are already receiving acceptable service.
4. Determine what the end users require to improve their current
service if they are not receiving acceptable service.

• Service-level objectives
Objectives, derived from SLAs, explicitly describe the expected
utilization, availability, performance, security, accuracy, or recovery.
They can also describe expected response time, job duration, or
throughput.
SLOs lay the foundation for developing the actual utilization and
performance metrics that IT management must collect, monitor, and
report to determine whether the agreed-upon service levels are being
met.

• Goals
This data is used to ensure, and determine whether, an SLO is being
met.

What is HP-UX Workload Manager?

HP-UX Workload Manager (WLM) is a resource management tool that
assesses resource usage in real time and then automatically allocates
resources and manages application performance based on your preferred
service-level objectives (SLOs) and business priorities. WLM plays a key
role in the HP Adaptive Enterprise and virtualization strategies,
allowing hardware, software applications, and virtual server resources to
be pooled and shared to optimize utilization and meet demands
automatically. As a goals-based policy engine of the Virtual Server

Chapter 1 41
Introduction
What is HP-UX Workload Manager?

Environment (VSE), WLM integrates virtualization

techniques—including partitioning, resource management, clustering,
and utility pricing resources—and links them to the SLOs and business
priorities. WLM enables a virtual HP-UX server to grow and shrink
automatically based on the demands and SLOs for each application it
hosts. By optimizing resource utilization in accord with SLOs and
business priorities, WLM helps enterprises achieve greater return on
their IT investment while ensuring that end-users receive the service
and performance levels they expect. Some key uses of HP-UX WLM
include:

• Using excess server capacity by consolidating multiple applications

on fewer servers while ensuring that mission-critical applications
still get the resources they need in times of peak demand
• Automatically re-allocating system resources in response to changing
priorities or conditions, package movement in a cluster, resource
demand, and application performance
• Automating the deployment of reserve capacity so that customers
pay for what they need when they need it
• Enabling higher utilization in clusters by enabling you to define,
monitor, and enforce SLOs when a failure occurs, causing a workload
to fail over a server or partition already running other workloads
You can use WLM within a whole server that can be clustered in an HP
Serviceguard high availability cluster, Extended Campus Cluster,
Metrocluster, or Continentalcluster. You can also use WLM on an HP
Integrity Virtual Machines (Integrity VM) Host and within any
individual Integrity VM (guest). You can use WLM within nPartitions
and virtual partitions as well as across partitions.
WLM is most effective managing applications that are CPU-bound. It
adjusts the CPU allocation of the group of processes that constitute a
workload, basing adjustment on current needs and performance of that
workload’s applications.
CPU resources can be allocated in shares (portions or time slices) of
multiple cores or, when using WLM partition management or PSET
management, in whole cores. WLM supports the logical CPU
(Hyper-Threading) feature, which is available starting with HP-UX 11i
v3 (B.11.31) for processors designed to support the feature and that have
the appropriate firmware installed. A logical CPU is an execution thread
contained within a core. Each core with Hyper-Threading enabled can
contain multiple logical CPUs. WLM supports the Hyper-Threading

42 Chapter 1
 Introduction
What is HP-UX Workload Manager?

feature for PSET-based groups. WLM automatically sets the

Hyper-Threading state for the default PSET to optimize performance.
(The default PSET, also known as PSET 0, is where all FSS groups
reside.) When new PSETs are created, they inherit the Hyper-Threading
state that the system had before WLM was activated (inheritance is
based on the system state prior to WLM activation because WLM may
change the Hyper-Threading setting for the default PSET to optimize
performance). Cores can be moved from one partition to another and will
take on the Hyper-Threading state of their destination PSET. To
explicitly enable or disable Hyper-Threading for a PSET-based group,
thereby overriding the default state for cores assigned to that group,
specify the LCPU keyword with the PSET group definition in the prm
structure. You can also modify the Hyper-Threading state of the system.
For more information, see “Specifying workload groups (optional)” on
page 159 and wlmconf(4).

Workload management across partitions

WLM is optimized for moving cores across hosts such as nPartitions and
virtual partitions. Using hosts as workloads, WLM manages workload
allocations while maintaining the isolation of their HP-UX instances.
WLM automatically moves (or “virtually transfers”) cores among
partitions based on the SLOs and priorities you define for the workloads.
With virtual partitions, WLM can automatically balance resources across
the partitions. For example, if a processor is not being utilized within one
virtual partition, WLM can deallocate it and reassign it to an alternate
virtual partition that currently requires additional resources.
With nPartitions, the cores are not physically moved. Instead, HP
Instant Capacity software (formerly known as iCOD) simulates the
movement of cores between partitions by deactivating cores on one
nPartition, then activating cores on another nPartition. For information
on managing SLOs across partitions, see Chapter 7, “Managing SLOs
across partitions,” on page 255.
WLM can manage nested workloads (based on FSS groups and PSETs)
inside virtual partitions that are inside nPartitions. Information on
nested management is provided in Chapter 8, “Management of nested
nPars / vPars / workload groups,” on page 277.
For each host (nPartition or virtual partition) workload, you define one or
more SLOs in the WLM configuration file. WLM allows you to prioritize
the SLOs so that an SLO assigned a high priority is given precedence

Chapter 1 43
Introduction
What is HP-UX Workload Manager?

over SLOs with a lower priority. Once configured, WLM then

automatically manages CPU resources to satisfy the SLOs for the
workloads. In addition, you can integrate WLM with HP Serviceguard to
allocate resources in a failover situation according to defined priorities
(for more information on integrating with HP Serviceguard, see
“Integrating with Serviceguard” on page 414).

Workload management within a single HP-UX

instance
You can also use WLM to manage workloads to divide resources within a
single HP-UX instance by managing workloads based on Fair Share
Scheduler (FSS) groups or processor sets (PSETs). Such workloads are
usually referred to as workload groups.

NOTE The term workload is used in this document to refer to any collection of
processes running in a PSET, FSS group, nPartition, virtual partition, or
Integrity VM host that are managed as a single unit. The term workload
group pertains specifically to FSS or PSET-based groups. However, in
WLM interfaces (such as the WLM configuration wizard or wlminfo
displays), the term workload group is often used for both workload and
workload groups.

When you configure WLM, you define workload groups for the system or
partition and assign processes to the groups based on the specific
applications, users, or Unix groups the processes run under. You can also
create your own criteria for placing application processes in specified
workload groups by defining process maps. In a process map, you map
a group to a script or command and its arguments that gathers process
IDs and causes the identified processes to be placed in that group. WLM
spawns the command or script at 30-second intervals, and at each
interval, places the identified processes in the appropriate groups. In
addition, the WLM SAP Toolkit, in conjunction with HP Serviceguard
Extension for SAP (SGeSAP), takes advantage of process maps,
providing a script that enables you to place specified SAP processes in
specific workload groups managed by WLM. For more information, see
“Integrating with SAP software” on page 438.

44 Chapter 1
 Introduction
What is HP-UX Workload Manager?

You can assign secure compartments to workload groups, creating the

secure compartments with the HP-UX feature Security Containment.
Secure compartments isolate files and processes. WLM can then
automatically allocate resources for these secure compartments.
When you configure WLM, you define one or more SLOs for each
workload group and prioritize them. To satisfy the SLOs for the workload
groups, WLM will then automatically manage CPU resources and,
optionally, real memory and disk bandwidth (WLM management of
workload groups is confined within the HP-UX instance or partition; no
allocation is made across partitions.) If multiple users or applications
within a workload group are competing for resources, standard HP-UX
resource management determines the resource allocation within the
workload.
With real memory, WLM allows you to specify lower and upper limits on
the amount of memory a workload group receives. Disk bandwidth
shares can be statically assigned in the configuration file.

NOTE The WLM daemon is designed to use minimal system resources. All of
the daemon’s processes run in the PRM_SYS (ID 0) workload, as explained
in the section “Reserved workload groups” on page 163.

Summary
WLM can manage the following resources for your workloads:

• CPU (cores)
Arbitrates CPU resource requests to ensure that high-priority SLOs
meet their objectives. SLOs make CPU resource requests for
workloads (or workload groups). CPU resources can be allocated in:

— Time slices on several cores

— Whole cores used by PSET-based workloads
— Whole cores used by vPar-based workloads
— Whole cores used by nPartition-based workloads (with each
nPartition using Instant Capacity software)
A workload might not achieve its CPU request if CPU resources are
oversubscribed and the workload’s SLOs are low priority.

Chapter 1 45
Introduction
Why use Workload Manager?

• Disk bandwidth (within single HP-UX instances only)

Ensures that each workload group is granted at least its share of
disk bandwidth.
• Memory (within single HP-UX instances only)
Ensures that each workload group is granted at least its minimum,
but (optionally) no more than its capped amount of real memory.
In addition, WLM has an application manager that ensures that the
following specified processes run in the appropriate workload groups:

• Applications and their child processes

• User processes
• Secure compartment processes
• Any processes that meet criteria specified in a process map

Why use Workload Manager?

The traditional open systems usage model has been one application
running per server, which leads to surplus capacity per server and a
proliferation of servers with too many servers to manage. Typically, each
server is sized to provide headroom for peak capacity and future growth.
As servers are introduced into this traditional environment, surplus
capacity grows without providing any opportunity to share this excess
capacity among the applications.
WLM, in collaboration with other HP Virtual Server Environment tools,
significantly lessens the need to provide the same degree of surplus
capacity. WLM allows the surplus capacity to be shared among multiple
applications on the same system. You can configure WLM to ensure that
each application runs at the performance level required to meet your
business goals. By enabling you to consolidate your data centers and
multiple applications onto fewer servers, WLM significantly reduces
your administration and computer resource costs.
WLM provides you the ability to:

46 Chapter 1
 Introduction
Why use Workload Manager?

• Run multiple workloads on a single system and maintain

performance of each workload
• Prioritize workloads on a single system, adjusting the CPU
allocations based on each workload’s goals
• Ensure that critical workloads have sufficient resources to perform
at desired levels
• Manage by service-level objectives (SLOs) within and across virtual
partitions or nPartitions
• Adjust resource allocations by automatically enabling or disabling
SLOs based on time of day, system events, or application metrics
• Enable SLOs associated with an HP Serviceguard package failover
• Adjust the number of cores in a partition or a PSET to meet SLOs
• Grant a workload dedicated CPU and memory resources in the form
of a PSET
• Assign Secure Resource Partitions (created by the HP-UX Security
Containment feature) to workloads based on PSETs or FSS groups,
giving the workloads isolation and automatic resource allocation
• Grant a workload CPU resources in direct proportion to a metric,
such as number of processes in the workload
• Set minimum and maximum amounts of CPU resources available to
a workload’s applications
• Set minimum and maximum amounts of memory available to a
workload’s applications
• Set and manage user expectations for performance
• Monitor resource consumption by applications or users through HP
GlancePlus, WLM utilities, or PRM utilities
When configuring WLM, you define workloads, associate applications
with the workloads, and then delineate SLOs for each workload. The
SLOs specify a workload’s necessary usage and performance goals. WLM
helps the workloads meet the desired goals by dynamically allocating
resources based on workload performance, varying workloads, and
changing system conditions. Thus, WLM ensures that performance levels
are acceptable and business goals are achieved. Information about
configuring WLM is provided in Chapter 5, “Configuring WLM,” on

Chapter 1 47
Introduction
Why use Workload Manager?

page 135. Information about configuring WLM to manage resources and

application performance across partitions is provided in Chapter 7,
“Managing SLOs across partitions,” on page 255.

Service-level objectives (SLOs)

A key reason for using WLM is its ability to manage service-level
objectives. After defining a workload, you can specify one or more SLOs
for each workload. WLM allocates CPU resources to workloads based on
whether the application in the workload is underperforming, meeting, or
overperforming its SLOs.
SLOs can be shares-based or goal-based. With a shares-based SLO, WLM
tries to grant the associated workload a fixed amount of the CPU
resources by allocating CPU shares for the workload. (Each CPU share is
1/100 of a single core or 1/100 of total cores on a system, depending on
the WLM mode of operation, as explained in “Using absolute CPU units”
on page 217.)
With a goal-based SLO, WLM actively changes the CPU allocation of the
associated workload to best meet the SLO. Goal-based SLOs are based on
one of two types of goals:

• Usage Goals
Goals based on a workload’s utilization of its allocated CPU
resources. If the processes in a workload are not using a certain
amount of the workload’s allocation, the allocation is decreased; if
the processes are using a high percentage of the workload’s
allocation, the allocation is increased.
• Metric goals
Goals based on a metric, such as processing at least x transactions
per minute or a response time under y seconds. Metric goals are
based on performance data and require understanding of that data.
HP recommends using usage goals, as usage goals can be
implemented immediately without prior knowledge of workload
performance.
A goal-based SLO consists of:

• A workload
• A goal
• A priority ranking

48 Chapter 1
 Introduction
Why use Workload Manager?

• Optional conditions, such as time of day or a particular event

• Optional lower and/or upper bounds for CPU resources
A shares-based SLO consists of the same elements except it does not
include a goal but rather a shares allocation.
For more information comparing shares-based and goal-based SLOs, see
“Shares-based SLOs vs goal-based SLOs” on page 118.

Prioritized SLOs
Another important reason for using WLM is that it allows you to
prioritize the SLOs. When CPU resources are not sufficient to satisfy all
SLOs, WLM grants CPU resources to the highest priority SLOs first.
After the demands of the higher priority SLOs are satisfied, WLM grants
the lower priority SLOs any resources that remain available. Valid
priorities start at 1, with 1 being the highest priority.
SLO priorities do not have to be uniquely assigned—multiple SLOs can
be granted the same priority, allowing more than one workload’s
objective to be top priority. This can be beneficial when multiple
workloads are equally important. Typically, all the SLOs in a given
configuration should not be assigned the same priority; otherwise, under
a heavy system load, WLM may not be able to allocate CPU resources
effectively when there is not enough resources to satisfy all SLOs.
A single workload can have multiple SLOs, each with a different priority.
One SLO would be the high priority, “must meet” goal and the remaining
SLOs would be lower priority, “meet if possible” goals. For example, a
priority 1 goal might be associated with a virtual partition to maintain
an allocation of at least two cores. A priority 2 goal might be to allocate
three or four cores if available when the workload becomes very busy.
This lower priority goal (a “stretch goal”) is met only after the priority 1
SLOs for this workload and all other workloads are met.
For information on how WLM uses priorities, see “Allocating CPU
resources: The rising tide model” on page 122.

Chapter 1 49
Introduction
WLM and partitions

WLM and partitions

The HP Partitioning Continuum offers several forms of partitioning:
• Hard partitions
These partitions are electronically isolated through hardware
separation. One such partition is a complete server, which can be
clustered in an HP Serviceguard high availability cluster. The other
type of hard partition, called nPartition, is a portion of a single
server. For example, nPartitions are available on Superdome and
Keystone servers, which can support up to 16 nPartitions on one
server node with cell-based hardware isolation and complete
software isolation (each nPartition runs its own copy of HP-UX). The
isolation guarantees that an application running in one nPartition is
not affected by an application or hardware failure in another
nPartition.
• Virtual partitions
HP virtual partitions, which are implemented in software, offer a
unique granularity of partitioning for servers. You can create virtual
partitions consisting of one or more cores. Each virtual partition runs
its own instance of the HP-UX operating system. Complete software
isolation is provided between virtual partitions. Virtual partitions
can be used within hard partitions.
• Virtual machines
These partitions, much like virtual partitions, are created with
software. However, they emulate generic servers, and therefore can
offer sub-core and shared I/O capabilities. Each virtual machine runs
its own operating system. HP Integriy Virtual Machines can be used
within hard partitions.
• Resource partitions
These partitions are provided by the HP Process Resource Manager
(PRM) for managing PSETs or FSS groups. Granularity is defined
either by whole cores (by PSETs) or a percentage of a number of cores
(by FSS groups). Resource partitions enable you to partition system
resources (including memory and disk bandwidth) within a single

50 Chapter 1
 Introduction
What is the ideal environment for WLM?

instance of HP-UX and consolidate multiple workloads within that

instance. PRM can be used within, but not across, hard partitions
and virtual partitions.
You can use WLM to manage resource partitions (WLM creates and
manages its own PRM configuration, but PRM must be installed on the
same system). You can also use WLM across both hard partitions and
virtual partitions, automatically moving (virtually) cores among
partitions, based on SLOs in the partitions. You can use WLM to manage
resources within a virtual machine. On an Integrity VM host, you can
use WLM to manage resources across partitions; within an Integrity VM
guest, you can use WLM to manage the HP-UX resources but not using
Instant Capacity, Pay per use (PPU), or virtual partition integration. In
either case, WLM runs as an independent instance. For more
information on running WLM with virtual machines, see “Integrating
with HP Integrity Virtual Machines (Integrity VM)” on page 408.
For information on using WLM across partitions, see Chapter 7,
“Managing SLOs across partitions,” on page 255.

What is the ideal environment for WLM?

You will benefit most from WLM if your environment meets one or more
of the following conditions:

• You run more than one workload concurrently on a server. The

workloads may all run under one instance of HP-UX or in separate
partitions, each with its own instance of HP-UX. These workloads
could be multiple database servers, a database server and an
applications server, or any other combination of workloads, provided
that they are using HP 9000 servers running HP-UX 11i v1, or HP
9000 servers or HP Integrity servers running HP-UX 11i v1, HP-UX
11i v2, or HP-UX 11i v3.
• You have CPU-intensive workloads that can be prioritized.
• You have an important workload with end-user performance
requirements.
• You want consistent performance from applications under varying
application and system loads.

Chapter 1 51
Introduction
Examples of solutions that WLM provides

• You run Serviceguard and need to ensure proper prioritization of

workloads after a failover.
• You want more control over resource allocation than PRM provides.

Examples of solutions that WLM provides

The following sections provide examples of how WLM SLOs can provide
a wide variety of business solutions. The SLOs are outlined without
including the necessary configuration file syntax. For information on the
configuration file syntax, see Chapter 5, “Configuring WLM,” on
page 135.

SLOs that ensure a specified amount of CPU shares

for workloads
The solutions in this section illustrate shares-based SLOs. They grant a
workload a specified amount of CPU shares.

Reserving CPU resources all of the time

In this first example, the SLO requests a fixed allocation of CPU shares
for the Marketing workload, reserving a portion of the server’s available
CPU resources. The 300 CPU shares being reserved equate to 3 cores
(when managing SLOs for partitions, WLM equates each core to 100
shares). This SLO is priority 1 and is in effect at all times.
Workload. Marketing
Priority. 1
CPU shares. 300 shares

Reserving CPU resources at specified times

This SLO requests a fixed allocation of 800 CPU shares. However, the
associated workload contains a payroll application that only runs twice a
month. Consequently, the SLO is enabled only twice a month, on the
15th and 28th.
Workload. Payroll

52 Chapter 1
 Introduction
Examples of solutions that WLM provides

Priority. 1
CPU shares. 800 shares
Condition. 15th or 28th

Reserving CPU resources based on a condition or event

This SLO is enabled only part time and conditionally. Rather than
allocating CPU resources on a specific date or time, they are allocated
when a specified condition is met, in this case when the system
accounting program is running. When the SLO is active, it works to
ensure the system accounting program completes quickly by reserving
600 CPU shares for the associated workload. When the program is
completed, the SLO is disabled. At that point, the SysAcct workload gets
a specific percentage (usually 1%) of the total CPU resources, as
explained in the section “Specifying when the SLO is active (optional)” on
page 205.
Workload. SysAcct
Priority. 1
CPU shares. 600 shares
Condition. System accounting program is running

Ensuring resources in an HP Serviceguard failover

This SLO is enabled based on a conditional metric. This example
illustrates an SLO that is active only if the Serviceguard package pkgA
is active on the current server. WLM provides a utility that generates a
metric indicating whether a package is active. When the metric has
value 1, the package is active, thus enabling the SLO. The SLO then
causes WLM to attempt to allocate 300 CPU shares to the associated
workload.
Workload. Failover_pkgA
Priority. 1
CPU shares. 300 shares
Condition. pkgA is active on the current server

Chapter 1 53
Introduction
Examples of solutions that WLM provides

SLOs that dynamically allocate resources based on

usage goals
The solutions in this section illustrate SLOs based on usage goals. In
each case, resources are allocated dynamically, based on current demand
or utilization. When the demand is high enough, more resources are
allocated for the workload. When the demand falls below a certain point,
unused resources can be made available for other workloads.

Allocating CPU resources dynamically based on utilization

In this example, the workload (named Orders) is a 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), then the CPU allocation for the partition is
reduced, making more resources available to other partitions in the
complex. If utilization is high, the workload 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. (When
managing partitions, WLM equates 1 core to 100 shares.)
Workload. Orders
Priority. 1
Usage goal. Match CPU allocation to consumption
Min CPU. 200 shares
Max CPU. 800 shares

Controlling the sharing and borrowing of excess CPU resources

In this scenario, the workload Development has multiple SLOs, with
each SLO having a usage goal. The Development workload 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. So, 30% of the server is 30 CPU shares. (CPU units
based on a percentage of the system’s total CPU resources are known as
relative CPU units, which is the default for WLM; examples previous to
this one are based on absolute CPU units, which equate 100 shares to 1
core. For more information on using absolute and relative CPU units, see
“Using absolute CPU units” on page 217.)

54 Chapter 1
 Introduction
Examples of solutions that WLM provides

When the Development workload is busy, the following priority 1 SLO

ensures that the workload gets 30% of the server’s CPU resources (the 30
shares funded by Development). When the workload is not busy, excess
resources are available for sharing as long as the workload is getting at
least 15% of the resources.
Workload. Development
Priority. 1
Usage goal. Match CPU allocation to consumption
Min CPU. 15 shares
Max CPU. 30 shares
When the Development workload becomes very busy, the following
priority 2 SLO enables the workload to borrow from other workloads that
may have excess resources. Because this SLO is priority 2, it is met only
after all priority 1 SLOs have been met. Based on usage patterns, the
SLO lets the workload borrow up to an additional 20 shares if available.
This allows the Development workload to access up to 50 CPU shares.
Workload. Development
Priority. 2
Usage goal. Match CPU allocation to consumption
Min CPU. 25 shares
Max CPU. 50 shares

Automatically resizing processor sets (PSETs)

With multiprocessor systems, you can isolate CPU resources for users or
applications by grouping processors together to form PSETs. WLM
allows you to define workloads based on PSETs. If you then specify SLOs
for these workloads, WLM automatically adjusts the number of
processors in the PSETs based on progress toward the SLOs. In this
example, the PSET workload Batch gets five processors, but only
between 10pm and 4am. At other times, Batch gets a minimum of one
processor by default.
Workload. Batch
Priority. 1
Usage goal. 500 CPU shares (5 cores)

Chapter 1 55
Introduction
Examples of solutions that WLM provides

Condition. Time is between 10pm and 4am

Automatically resizing virtual partitions

WLM enables you to automate the resizing of partitions. You can adjust
the partition size by having cores dynamically added and removed in
response to varying demands.
Consider a system with two virtual partitions. The SLO for the Apps
workload in partition 1 has a higher priority than the SLO for the Dev
workload in partition 0. When CPU usage for Apps in partition 1 reaches
a certain point, WLM automatically migrates a core from partition 0 to
partition 1 to satisfy the higher-priority SLO. The following is an outline
of the partition 1 SLO for workload Apps:
Workload. Apps (partition 1)
Priority. 1
Usage goal. Match CPU allocation to consumption
The SLO for partition 0 (workload dev) follows:
Workload. Dev (partition 0)
Priority. 2
Usage goal. Match CPU allocation to consumption

Automatically resizing nPartitions using Instant Capacity cores

If you have the HP Instant Capacity software configured on each
nPartition, you can configure WLM to “move” cores to the partitions
where they are most needed. (Given the hardware isolation, the cores are
not literally moved: WLM deactivates cores on one partition, then
activates cores on another partition—giving the appearance of moving
cores without incurring a charge for an additional core.)
Consider a system with two nPartitions. nPartition 0 is running the
production, customer-accessible version of a shopping Web site, while
nPartition 1 runs the test version of this Web site. The SLO for the
Production workload on nPartition 0 has a higher priority than the SLO
for the Test workload on nPartition 1.
When CPU utilization for the Production workload reaches a certain
point, WLM automatically migrates a core from nPartition 1 to
nPartition 0 to satisfy the higher priority SLO. The SLO for the
Production workload in nPartition 0 is outlined as follows:

56 Chapter 1
 Introduction
Examples of solutions that WLM provides

Workload. Production (nPartition 0)

Priority. 1
Goal. Match CPU allocation to consumption
The SLO for the Test workload in nPartition 1 is outlined as follows:
Workload. Test (partition 1)
Priority. 2
Usage goal. Match CPU allocation to consumption

Optimizing use of Temporary Instant Capacity (TiCAP) and Pay

per use (PPU)
Temporary Instant Capacity activates CPU resource capacity in a
temporary “calling-card” fashion such as in 20-day or 30-day increments
(where a day equals 24 hours for one core). You purchase a TiCAP
codeword to obtain usage rights for a preset amount of days.. This
codeword is applied to a system so you can turn on and off any number of
Instant Capacity cores on the system as long as your prepaid temporary
capacity time has not expired. (To activate a core, you need a minimum
balance of 30 minutes of temporary capacity per core. Codewords must
be applied in the order in which they were obtained.)
If you have WLM on a supported Temporary Instant Capacity system,
you can configure WLM to minimize the costs of using these resources by
optimizing the amount of time the resources are used to meet the needs
of your workloads.
Similarly, HP offers a Pay per use (PPU) feature for customers interested
in leasing CPU capacity from HP Finance. Pay per use provides capacity
as needed but basing payment on actual metered or monitored use of
that capacity. Using WLM with a system running a supported version of
PPU, WLM increases or decreases the capacity automatically, allocating
the minimum number of cores needed to satisfy SLOs. By minimizing the
number of active cores, WLM reduces your costs.
After setting up your SLOs in the WLM configuration file as in some of
the previous examples, you then configure the WLM global arbiter
(wlmpard), setting the utilitypri keyword to control how Temporary
Instant Capacity or PPU adjusts CPU resource capacity as needed.
Using this keyword also ensures that WLM maintains compliance with
your Temporary Instant Capacity codeword: when your usage rights
expire, WLM no longer attempts to activate temporary resources. Note

Chapter 1 57
Introduction
Using WLM on multiple servers

also that by default WLM does not activate Temporary Instant Capacity
when 15 or fewer processing days of temporary capacity are available.
You can change this default by setting the WLM global arbiter
utility_reserve_threshold keyword. For more information on the
utilitypri and utility_reserve_threshold keywords, see “Setting
up your WLM global arbiter configuration file” on page 265 or see
wlmparconf(4).
For more information on configuring WLM to use Temporary Instant
Capacity or PPU, see Chapter 7, “Managing SLOs across partitions,” on
page 255. For more information on integrating WLM with Temporary
Instant Capacity and PPU, see “Integrating with Temporary Instant
Capacity (TiCAP)/ Pay per use (PPU)” on page 410.
Management of Temporary Instant Capacity and PPU is available on
standalone systems as well as across partitions.

Using WLM on multiple servers

WLM manages one or more workloads on individual servers. To manage
workloads on multiple servers, install and configure WLM on each of the
servers.

Using WLM with HP Integrity Virtual

Machines (Integrity VM)
You can run WLM on an HP Integrity Virtual Machine Host and within
any Integrity VM running on the server. You can run WLM both on the
Integrity VM Host and in an Integrity VM (guest), but each WLM runs
as an independent instance. Observe the guidelines described in
“Integrating with HP Integrity Virtual Machines (Integrity VM)” on
page 408.

58 Chapter 1
 Introduction
WLM and Process Resource Manager (PRM)

WLM and Process Resource Manager (PRM)

When managing PSETs or FSS groups, the Workload Manager (WLM)
and Process Resource Manager (PRM) products both work by modifying
and enabling a PRM configuration. WLM uses PRM when a prm
structure is included in the WLM configuration. With such
configurations, you can use PRM’s informational and monitoring
commands such as prmlist and prmmonitor. You can also use the
prmrun and prmmove commands, among others. If you use the prmconfig
command, invoke it with no options or the -u (unlock) option—do not use
the -r (reset) option.
Ordinarily, WLM and PRM should not be used to manage resources on
the same system at the same time. In some cases, this might cause
inconsistent behavior and undesirable performance. However, you can
use both products at the same time if the PRM configuration uses FSS
groups only (no PSET-based groups) and the WLM configuration is
strictly host-based. A strictly host-based configuration is one that does
not include a prm structure; it is designed exclusively for moving cores
across HP-UX Virtual Partitions or nPartitions, or for activating
Temporary Instant Capacity (TiCAP) cores or Pay per use (PPU) cores.
For information on the advantages of using WLM and PRM
simultaneously, see “Integrating with Process Resource Manager (PRM)”
on page 404.

NOTE As of WLM A.03.01, PRM is no longer included with the bundle. If PRM
C.03.00 or later is already installed on the machine on which you install
or upgrade WLM, you can continue to manage FSS and PSET-based
workload groups just as if PRM had been installed with WLM—when
you purchase WLM, you receive a PRM license that enables you to
continue to use PRM.
If you install WLM for the first time on a machine, you can use a strictly
host-based configuration (no FSS or PSET-based workload groups).
However, to manage FSS or PSET-based workload groups, you must
install PRM (C.03.00 or later) separately.

Chapter 1 59
Introduction
WLM product directory structure

WLM product directory structure

The WLM directories and files included in the product installation are
described in Table 1-3. The table is not a full listing, but presents the
most important files.

NOTE In addition to the WLM-specific files, the WLM installation ensures that
the HP-UX WLM Toolkits (WLMTK) A.01.10.xx are installed. For
information on the WLMTK files, see the HP-UX Workload Manager
Toolkits User’s Guide (/opt/wlm/toolkits/doc/WLMTKug.pdf).

Table 1-3 WLM directories and files

Directory/file Description

/opt/wlm/bin/wlmaudit Command for viewing audit data

files

/opt/wlm/bin/wlminfo Monitoring utility

/opt/wlm/bin/wlmgui Graphical interface for specifying

a WLM configuration and
monitoring SLOs

/opt/wlm/bin/wlmcert Utility for managing security

certificates

/opt/wlm/bin/wlmcw The WLM configuration wizard

/opt/wlm/bin/wlmd The WLM daemon

/opt/wlm/bin/wlmpard The WLM global arbiter daemon

/opt/wlm/bin/wlmprmconf Script for converting PRM

configuration files to WLM
configuration files

/opt/wlm/lbin/wlmrcvdc Built-in WLM data collector

60 Chapter 1
 Introduction
WLM product directory structure

Table 1-3 WLM directories and files (Continued)

Directory/file Description

/opt/wlm/bin/wlmsend Command-line/scripting
interface for sending metric data
to WLM

/opt/wlm/bin/wlmcomd Communications daemon

/opt/wlm/lbin/coll/glance_app Command used with wlmrcvdc to

extract GlancePlus application
metrics

/opt/wlm/lbin/coll/glance_gbl Command used with wlmrcvdc to

extract GlancePlus global system
metrics

/opt/wlm/lbin/coll/glance_prm Command used with wlmrcvdc to

extract GlancePlus PRM-specific
application metrics

/opt/wlm/lbin/coll/glance_prm_byvg Command used with wlmrcvdc to

extract GlancePlus metrics on
PRM-managed volume groups

/opt/wlm/lbin/coll/glance_tt Command used with wlmrcvdc to

extract GlancePlus application
transactions metrics

/opt/wlm/lbin/coll/glance_tt+ Command used with wlmrcvdc to

extract GlancePlus application
transaction metrics for use in
generating new metrics

/opt/wlm/lbin/coll/sg_pkg_active Command used with wlmrcvdc to

determine the status of a
Serviceguard package

/opt/wlm/lbin/scm/ Directory for Servicecontrol

Manager (SCM) tool definitions
and subtools

/opt/wlm/lbin/wlmemsmon WLM EMS monitor

/opt/wlm/newconfig/etc/opt/resmon/dictionary/wlm.dict EMS dictionary file

Chapter 1 61
Introduction
WLM product directory structure

Table 1-3 WLM directories and files (Continued)

Directory/file Description

/sbin/init.d/wlm Start/stop script

/etc/rc.config.d/wlm File to set environment variables

used by the start/stop script

/opt/wlm/lib/libwlm.sl WLM library that provides the

API for data collectors to send
data to WLM

/opt/wlm/include/wlm.h Header file for data collectors

/opt/wlm/share/man/man1m.Z/ Contains manpages on the WLM

daemon (wlmd), the EMS monitor
(wlmemsmon), wlmaudit,
wlminfo, wlmgui, wlmcert,
wlmcomd, wlmsend, wlmrcvdc,
wlmpard, wlmprmconf, and the
glance_* and sg_pkg_active
scripts

/opt/wlm/share/man/man3.Z/libwlm.3 Manpage for the WLM API

/opt/wlm/share/man/man4.Z/wlmconf.4 Manpage that provides syntax

information for the WLM
configuration file

/opt/wlm/share/man/man4.Z/wlmparconf.4 Manpage that provides syntax

information for the WLM global
arbiter configuration file

/opt/wlm/share/man/man5.Z/wlm.5 Manpage that gives an overview

of WLM

/opt/wlm/share/doc/ Contains the WLM user’s guide

and release notes

62 Chapter 1
 Introduction
WLM product directory structure

Table 1-3 WLM directories and files (Continued)

Directory/file Description

/opt/wlm/share/doc/howto/ Contains white papers on how to

perform WLM tasks, including:

• perfmon.html
Writing a Better WLM data
collector
• config.html
Configuring HP-UX
Workload Manager A.02.00
(although this paper was
written for an older version
of WLM, it may still be
relevant for certain
environments)
• tuning.html
Tuning HP-UX Workload
Manager
• flexcap.html
Using HP-UX Workload
Manager to Achieve Flexible
Capping

/var/opt/wlm/msglog WLM log file—created when

WLM runs

/var/opt/wlm/wlmdstats Optional statistics log

file—created by activating a
WLM configuration with the -l
option to wlmd

/var/opt/wlm/wlmpardstats Optional global arbiter statistics

log file—created by activating a
WLM global arbiter
configuration with the -l option
to wlmpard

Chapter 1 63
Introduction
WLM product directory structure

Table 1-3 WLM directories and files (Continued)

Directory/file Description

/opt/wlm/config/tunables Master tunables file (read-only:

do not edit)

/opt/wlm/examples/wlmconf/READMEa Information text file for the

wlmconf directory

/opt/wlm/examples/wlmconf/a Example WLM configuration

files

/opt/wlm/examples/dsi/wlmdstats/READMEa Information text file for the

DSI-wlmdstats example
directory; the
/opt/wlm/examples/dsi/wlmdstats
directory provides information
on how to collect statistics from
wlmd to feed into HP
MeasureWare

/opt/wlm/examples/perl/scripts/simple_perfmon.pla Example perl-based data

collector; the
/opt/wlm/examples/perl/scripts
directory includes a script that
shows how to collect data using
perl

/opt/wlm/toolkits/ Various WLM Toolkit products

for integrating WLM with
third-party applications

a. Read the file /opt/wlm/examples/DISCLAIMER regarding items in the

/opt/wlm/examples directory.

64 Chapter 1
 WLM quick start: the essentials for using WLM

2 WLM quick start: the essentials

for using WLM

This chapter presents an overview of the techniques and tools available

for using WLM. It serves as a condensed version of this entire user’s
guide, exposing you to the essentials and allowing you to quickly get
started using WLM. The terminology of WLM as well as WLM concepts
and the syntax of the WLM configuration files are not covered here. That
information is discussed in the remainder of the book.
The chapter first discusses the network operating environment and then
gives an overview of a WLM session. Then, it provides background
information on various ways to use WLM, including how to complete
several common WLM tasks. Lastly, it discusses how to monitor WLM
and its effects on your workloads.

Chapter 2 65
WLM quick start: the essentials for using WLM
Network operating environment

Network operating environment

WLM’s network interfaces are designed to operate correctly to defend
against attacks in a moderate to high threat environment, such as a
DMZ. You may use network protections, such as firewalls, to provide an
additional level of defense and to give you additional time to react when
a security loophole is found.

NOTE As of A.03.01, WLM enables secure communications by default when you

start WLM using the /sbin/init.d/wlm script. (If you are upgrading WLM,
secure mode might not be the default. Ensure that the appropriate
secure mode variables in /etc/rc.config.d/wlm are set correctly. For more
information on these variables, see “Securing WLM communications” on
page 244.) You also must distribute security certificates to all systems or
partitions being managed by the same WLM global arbiter (wlmpard).
For more information on using security certificates and other tasks
necessary to enable secure communications, see wlmcert(1M). This
manpage is also available at the following Web site:
http://www.hp.com/go/wlm

The WLM wlmpard and wlmcomd daemons use the following port
numbers by default:
wlmpard 9691
wlmcomd 9692
Make sure these ports are kept open. To change these port numbers, see
wlmpard(1M) and wlmcomd(1M).

66 Chapter 2
 WLM quick start: the essentials for using WLM
WLM shown in action

WLM shown in action

This section provides a quick overview of various commands associated
with using WLM in a PRM-based configuration (using FSS or
PSET-based workload groups and confined to a single instance of
HP-UX). For information on using WLM in host-based configurations
designed for moving cores across virtual partitions and nPartitions, see
Chapter 7, “Managing SLOs across partitions,” on page 255. To become
familiar with how WLM moves cores across partitions, see the
par_usage_goal.wlm and par_usage_goal.wlmpar configuration files in
/opt/wlm/examples/wlmconf/ and also included in Chapter 9, “Example
configuration files,” on page 283. The files includes steps to take for
implementing migration across partitions.
This chapter takes advantage of some of the configuration files and
scripts available in the directory /opt/wlm/examples/userguide/ as well as
at the following Web site:
http://www.hp.com/go/wlm

NOTE You can define FSS or PSET-based workload groups and use WLM
partition management in the same WLM configuration. Certain
software restrictions apply to using PSET-based groups with virtual
partitions (vPars), Instant Capacity, and Pay per use. For more
information, see the WLM Release Notes (/opt/wlm/share/doc/Rel_Notes).
On HP-UX 11i v1 (B.11.11) systems, you must install PSET (PROCSET)
software to obtain PSET functionality; see the HP-UX WLM Release
Notes. PSET functionality comes with HP-UX 11i v2 (B.11.23) and
HP-UX 11i v3 (B.11.31) systems.

To become familiar with WLM, how it works in PRM-based

configurations, and some related commands, complete the following
procedure:

NOTE For this procedure to work, PRM must be installed on your system.

Step 1. Log in as root.

Chapter 2 67
WLM quick start: the essentials for using WLM
WLM shown in action

Step 2. Start WLM with an example configuration file:

# /opt/wlm/bin/wlmd -a /opt/wlm/examples/userguide/multiple_groups.wlm

The example configuration file is multiple_groups.wlm, which does the

following:

1. Defines two workload groups: g2 and g3.

2. Assigns applications (in this case, perl programs) to the groups.

(With shell/perl programs, give the full path of the shell or perl
followed by the name of the program.) The two programs loop2.pl and
loop3.pl are copies of loop.pl. The loop.pl script (available in
/opt/wlm/examples/userguide/) runs an infinite outer loop, counts in
the inner loop, and shows the time spent counting:
#!/opt/perl/bin/perl -w
#
# Name:
# loop.pl
#
# Version information:
#
# $Revision: 1.4 $

$maxcount = 3000000;

# Here is an infinite loop

while (1) {
$count = 1;
$start = time();
while ($count <= $maxcount) {
$count++;
}
$end = time();
printf (“loop.pl: Elapsed time=%.2f seconds\n”, $end-$start);
}

3. Sets bounds on CPU usage. The number of CPU shares for the
workload groups can never go below the gmincpu or above the
gmaxcpu values. These values take precedence over the minimum
and maximum values that you can optionally set in the slo
structures.

4. Defines an SLO (service-level objective) for g2. The SLO is priority 1

and requests 15 CPU shares for g2.

68 Chapter 2
 WLM quick start: the essentials for using WLM
WLM shown in action

5. Defines a priority 1 SLO for g3 that requests 20 CPU shares.

# Name:
# multiple_groups.wlm
#
# Version information:
#
# $Revision: 1.10 $
#
#
# Dependencies:
# This example was designed to run with HP-UX WLM version A.01.02
# or later. It uses the cpushares keyword introduced in A.01.02
# and is, consequently, incompatible with earlier versions of
# HP-UX WLM.
#
# Requirements:
# To ensure WLM places the perl scripts below in their assigned
# workload groups, add “/opt/perl/bin/perl” (without the quotes) to
# the file /opt/prm/shells.

prm {
n groups = g2 : 2,
g3 : 3;

o apps = g2 : /opt/perl/bin/perl loop2.pl,

g3 : /opt/perl/bin/perl loop3.pl;

p gmincpu = g2 : 5, g3 : 5;
gmaxcpu = g2 : 30, g3 : 60;
}
q
slo test2 {
pri = 1;
cpushares = 15 total;
entity = PRM group g2;
}
r
slo test3 {
pri = 1;
cpushares = 20 total;
entity = PRM group g3;

Chapter 2 69
WLM quick start: the essentials for using WLM
WLM shown in action

Step 3. See what messages a WLM startup produces. Start another session to
view the WLM message log:

# tail -f /var/opt/wlm/msglog
08/29/06 08:35:23 [I] (p6128) wlmd initial command line:
08/29/06 08:35:23 [I] (p6128) argv[0]=/opt/wlm/bin/wlmd
08/29/06 08:35:23 [I] (p6128) argv[1]=-a
08/29/06 08:35:23 [I] (p6128) argv[2]=/opt/wlm/examples/userguide/multiple_gro
ups.wlm
08/29/06 08:35:23 [I] (p6128) what: @(#)HP-UX WLM A.03.02 (2006_08_21_17_04_11)
hpux_11.00
08/29/06 08:35:23 [I] (p6128) dir: @(#) /opt/wlm
08/29/06 08:35:23 [I] (p6128) SLO file path: /opt/wlm/examples/userguide/multipl
e_groups.wlm
08/29/06 08:35:26 [I] (p6128) wlmd 6128 starting

The text in the log shows when the WLM daemon wlmd started, as well
as what arguments it was started with—including the configuration file
used.

Step 4. See that the workload groups are in effect.

The prmlist command shows current configuration information, as in

the following example. (This PRM, or Process Resource Manager,
command is available because WLM uses PRM to provide some of the
WLM functionality. For more information about the prmlist command,
see “prmlist” on page 108.)

70 Chapter 2
 WLM quick start: the essentials for using WLM
WLM shown in action

# /opt/prm/bin/prmlist
PRM configured from file: /var/opt/wlm/tmp/wmprmBAAa06335
File last modified: Thu Aug 24 08:35:23 2006

PRM Group PRMID CPU Upper LCPU

Entitlement Bound Attr
-------------------------------------------------------------------
OTHERS 1 65.00%
g2 2 15.00%
g3 3 20.00%

PRM User Initial Group Alternate Group(s)

--------------------------------------------------------------------------------
root (PRM_SYS)

PRM Application Assigned Group Alternate Name(s)

--------------------------------------------------------------------------------
/opt/perl/bin/perl g2 loop2.pl
/opt/perl/bin/perl g3 loop3.pl

Starting with WLM A.02.00, a web interface to the prmlist command is

available. For information, see wlm_watch(1M).

In addition, you can use the wlminfo command, which shows

CPU Shares and utilization (CPU Util) for each workload group, and
starting with WLM A.03.02, also shows the memory utilization, as in the
following example (because memory records are not being managed for
any of the groups in this example, a “-” is displayed in the ‘Mem Shares’
and ‘Mem Util’ columns):

# /opt/wlm/bin/wlminfo group
Thu Jun 29 08:36:38 2006

Workload Group PRMID CPU Shares CPU Util Mem Shares Mem Util State
OTHERS 1 65.00 0.00 - - ON
g2 2 15.00 0.00 - - ON
g3 3 20.00 0.00 - - ON

Step 5. Start the scripts referenced in the configuration file.

Chapter 2 71
WLM quick start: the essentials for using WLM
WLM shown in action

a. WLM checks the files /etc/shells and /opt/prm/shells to ensure one of

them lists each shell or interpreter, including perl, used in a script. If
the shell or interpreter is not in either of those files, WLM ignores its
application record (the workload group assignment in an apps
statement).
Add the following line to the file /opt/prm/shells so that the
application manager can correctly assign the perl programs to
workload groups:
/opt/perl/bin/perl
b. The following two scripts produce output, so you may want to start
them in a new window. Start the two scripts loop2.pl and loop3.pl as
follows:
# /opt/wlm/examples/userguide/loop2.pl &
# /opt/wlm/examples/userguide/loop3.pl &
These scripts start in the PRM_SYS group because you started them as
the root user. However, the application manager soon moves them
(within 30 seconds) to their assigned groups, g2 and g3. After waiting
30 seconds, run the following ps command to see that the processes
have been moved to their assigned workload groups:
# ps -efP | grep loop
The output will include the following items (column headings are
included for convenience):
PRMID PID TTY TIME COMMAND
g3 6463 ttyp1 1:42 loop3.pl
g2 6462 ttyp1 1:21 loop2.pl

Step 6. Manage workload group assignments:

a. Start a process in the group g2:

# /opt/prm/bin/prmrun -g g2 /opt/wlm/examples/userguide/loop.pl
b. Verify that loop.pl is in g2 with the ps command:
# ps -efP | grep loop
The output will confirm the group assignment:
g2 6793 ttyp1 0:02 loop.pl
c. Move the process to another group.

72 Chapter 2
 WLM quick start: the essentials for using WLM
WLM shown in action

Use the PID for loop.pl from the last step to move loop.pl to the
group g3:
# /opt/prm/bin/prmmove g3 -p loop.pl_PID
In this case, loop.pl_PID is 6793.

Step 7. Verify workload group assignments:

For verifying workload group assignments, the ps command has two

options related to WLM:

-P Shows PRM IDs (workload group

IDs) for each process

-R workload_group Shows ps listing for only the

processes in workload_group

Looking at all the processes, we get output including the items shown in
the following example (column headings are included for convenience):

# ps -efP | grep loop

PRMID PID TTY TIME COMMAND
g3 6793 ttyp1 1:52 loop.pl
g3 6463 ttyp1 7:02 loop3.pl
g2 6462 ttyp1 4:34 loop2.pl

Focusing on the group g3, we get the following output:

# ps -R g3
PID TTY TIME COMMAND
6793 ttyp1 1:29 loop.pl
6463 ttyp1 6:41 loop3.pl

Step 8. Check CPU usage.

The wlminfo command shows CPU usage (utilization) by workload

group. The command’s output, which may be slightly different on your
system, is shown in the following example.

# /opt/wlm/bin/wlminfo group
Workload Group PRMID CPU Shares CPU Util Mem Shares Mem Util State
OTHERS 1 65.00 0.00 - - ON
g2 2 15.00 14.26 - - ON
g3 3 20.00 19.00 - - ON

Chapter 2 73
WLM quick start: the essentials for using WLM
WLM shown in action

This output shows that both groups are using CPU resources (cores) up
to their allocations. If the allocations were increased, the groups’ usage
would probably increase to match the new allocations.

Step 9. Stop WLM:

# /opt/wlm/bin/wlmd -k

Step 10. See what messages a WLM shutdown produces:

Running the tail command again, you will see messages similar to
those shown in the following example:

# tail -f /var/opt/wlm/msglog
08/29/02 09:06:55 [I] (p6128) wlmd 6128 shutting down
08/29/02 09:06:55 [I] (p7235) wlmd terminated (by request)

Step 11. Stop the loop.pl, loop2.pl, and loop3.pl perl programs.

74 Chapter 2
 WLM quick start: the essentials for using WLM
Where WLM is installed

Where WLM is installed

The following table shows where WLM and some of its components are
installed.
Table 2-1 WLM installation directories

Item Installation path

WLM /opt/wlm/

WLM Toolkits /opt/wlm/toolkits/

Manpages for WLM and its /opt/wlm/share/man/

Toolkits

If you are using WLM configurations that are based on the Process
Resource Manager (PRM) product, you must install PRM at:
/opt/prm/

Seeing how WLM will perform without

actually affecting your system
WLM provides a passive mode that allows you to see how WLM will
approximately respond to a given configuration—without putting WLM
in charge of your system’s resources. Using this mode, enabled with the
-p option to wlmd, you can gain a better understanding of how various
WLM features work. In addition, you can check that your configuration
behaves as expected—with minimal effect on the system.

Chapter 2 75
WLM quick start: the essentials for using WLM
Seeing how WLM will perform without actually affecting your system

For example, with passive mode, you can determine:

• How does a cpushares statement work?

• How do goals work? Is my goal set up correctly?
• How might a particular cntl_convergence_rate value or the values
of other tunables affect allocation change?
• How does a usage goal work?
• Is my global configuration file set up as I wanted? If I used global
arbitration on my production system, what might happen to the CPU
layouts?
• Is a user’s default workload group set up as I expected?
• Can a user access a particular workload group?
• When an application is run, which workload group does it run in?
• Can I run an application in a particular workload group?
• Are the alternate names for an application set up correctly?
For more information on how to use the WLM passive mode, as well as
explanations of how passive mode does not always represent actual
WLM operations, see “Trying a configuration without affecting the
system” on page 236.
Activate a configuration in passive mode by logging in as root and
running the following command, substituting your configuration file’s
name for config.wlm:
# /opt/wlm/bin/wlmd -p -a config.wlm
The WLM global arbiter, wlmpard, also provides a passive mode. The
WLM global arbiter is used for managing SLOs across virtual partitions
and nPartitions as well as for optimizing Temporary Instant Capacity (v6
or later) and Pay per use (v4, v7, or later). For more information on the
WLM global arbiter, see Chapter 7, “Managing SLOs across partitions,”
on page 255.

76 Chapter 2
 WLM quick start: the essentials for using WLM
Starting WLM

Starting WLM
Before starting WLM (activating a configuration), you may want to try
the configuration in passive mode, discussed in “Seeing how WLM will
perform without actually affecting your system” on page 75. Otherwise,
you can activate your configuration by logging in as root and running the
following command, substituting your configuration file’s name for
config.wlm.:
# /opt/wlm/bin/wlmd -a config.wlm
When you run the wlmd -a command, WLM starts the data collectors
you have specified in the WLM configuration.
Although data collectors are not necessary in every case, be sure to
monitor any data collectors you do have. Because data collection is a
critical link in the effective maintenance of your configured service-level
objectives, you need to be aware when a collector exits unexpectedly. One
method for monitoring collectors is to use wlminfo slo.
For information on creating your WLM configuration, see the section
“Creating a configuration file” on page 78.
WLM automatically logs informational messages to the file
/var/opt/wlm/msglog. In addition, WLM can log data that allows you to
verify WLM management as well as to fine-tune your WLM
configuration file. To log this data, use the -l option. This option causes
WLM to log data to /var/opt/wlm/wlmdstats. The following command line
starts WLM, logging data for SLOs every third WLM interval:
# /opt/wlm/bin/wlmd -a config.wlm -l slo=3
For more information on the -l option, see the wlmd(1M).

Stopping WLM
With WLM running, stop it by logging in as root and running the
command:
# /opt/wlm/bin/wlmd -k

Chapter 2 77
WLM quick start: the essentials for using WLM
Creating a configuration file

Creating a configuration file

The WLM configuration file is simply a text file.
To create your own WLM configuration file, use one or more of the
following techniques:

• Determine which example configurations can be useful in your

environment and modify them appropriately. For information on
example configurations, see “Where to find example WLM
configurations” on page 79.
• Create a new configuration using:

— vi or any other text editor

— the WLM configuration wizard, which is discussed in the section
“The easiest way to configure WLM” on page 79
— the WLM graphical user interface, wlmgui
Using the wizard, the configuration syntax is almost entirely hidden.
With wlmgui, you need to be familiar with the syntax.

NOTE Usage of either the WLM graphical user interface or the wizard
requires Java Runtime Environment version 1.4.2 or later. For
PRM-based configurations, PRM C.03.00 or later is required. (To
take advantage of the latest updates to WLM, use the latest version
of PRM available.)

• Enhance your configuration created from any of the previous

methods by modifying it based on ideas from the following sections:

— “How to put an application under WLM control” on page 81

— “Some common WLM tasks” on page 89
For configuration file syntax, see wlmconf(4).

78 Chapter 2
 WLM quick start: the essentials for using WLM
The easiest way to configure WLM

The easiest way to configure WLM

The easiest and quickest method to configure WLM is to use the WLM
configuration wizard.

NOTE Set your DISPLAY environment variable before starting the wizard.
Usage of the wizard requires that the appropriate version of PRM is
installed on your system.

To start the wizard, run the following command:

# /opt/wlm/bin/wlmcw
The wizard provides an easy way to create initial WLM configurations.
To maintain simplicity, it does not provide all the functionality available
in WLM. Also, the wizard does not allow you to edit existing
configurations. Running the wizard requires Java Runtime Environment
version 1.4.2 or later and, for PRM-based configurations, PRM C.03.00 or
later. (To take advantage of the latest updates to WLM, use the latest
version of PRM available.)

Where to find example WLM configurations

WLM and its toolkits come with example WLM configuration files. These
files are located in the directories indicated in the following table.
Table 2-2 Example WLM configurations

See example WLM configurations

For
in the directory

Examples showing a range /opt/wlm/examples/wlmconf/

of WLM functionality

Examples used in this /opt/wlm/examples/userguide/

chapter

Chapter 2 79
WLM quick start: the essentials for using WLM
How WLM controls applications

Table 2-2 Example WLM configurations (Continued)

See example WLM configurations

For
in the directory

Using WLM with /opt/wlm/toolkits/apache/config/

Apache web servers

Using WLM to /opt/wlm/toolkits/duration/config/

manage job duration

Using WLM with /opt/wlm/toolkits/oracle/config/

Oracle databases

Using WLM with /opt/wlm/toolkits/sap/config/

SAP software

Using WLM with /opt/wlm/toolkits/sas/config/

SAS software

Using WLM with /opt/wlm/toolkits/snmp/config/

SNMP agents

Using WLM with BEA /opt/wlm/toolkits/weblogic/config/

WebLogic Server

These configurations are also available on the following Web site from
the “case studies / example configurations” page:
http://www.hp.com/go/wlm

How WLM controls applications

WLM controls your applications after you isolate your applications in
workloads based on:

• nPartitions that use Instant Capacity

• HP-UX virtual partitions
• Resource partitions (also known as workload groups), which can be:

80 Chapter 2
 WLM quick start: the essentials for using WLM
How to put an application under WLM control

— Whole-core: HP-UX processor sets (PSETs)

— Sub-core: Fair Share Scheduler (FSS) groups
To have resources migrated among workloads as needed, you create one
or more SLOs for each workload. (In the case of nPartitions, which
represent hardware, the core movement is simulated using Instant
Capacity to deactivate one or more cores in one nPartition and then
activate cores in another nPartition.) In defining an SLO, you specify the
SLO’s priority. You can also specify a usage goal to attain a targeted
resource usage. Or, if a performance measure (metric) is available, you
can specify a metric goal. As the applications run, WLM compares the
application usage or metrics against the goals. To achieve the goals,
WLM automatically adjusts CPU allocations for the workloads.
For workload groups (which share the resources of a single HP-UX
instance), WLM can manage each group’s real memory and disk
bandwidth resources in addition to its CPU allocation.

NOTE WLM adjusts only a workload group’s CPU allocation in response to SLO
performance. Thus, WLM SLO management is most effective for
workloads that are CPU-bound.

How to put an application under WLM control

This section applies only to workloads that divide PRM-based resources
within a single HP-UX instance. If you are not going to use WLM in this
way, you can skip the rest of this section and go to “How to determine a
goal for your workload” on page 87.
WLM can treat an nPartition or virtual partition as a workload. The
workload consists of all the processes running in the operating system
instance on the partition. WLM also allows you to divide the resources of
a single operating system into PSETs or FSS groups. When dividing the
resources of a single operating system, the workloads are known as
workload groups.
When a system is divided into workload groups, each application must go
into a workload group. By default, processes run by root go into the
PRM_SYS group, and processes run by nonroot users go into the OTHERS

Chapter 2 81
WLM quick start: the essentials for using WLM
How to put an application under WLM control

group. However, you can change the workload group in which a

particular user’s processes run by adding user records to the WLM
configuration file. You can add Unix group records to the configuration
file so that the processes running in a specified Unix group are placed in
a specific workload group. Furthermore, you can specify the workload
groups in which processes run by adding application records to your
WLM configuration, or defining secure compartments that isolate the
processes in specified workload groups. You can even define process maps
that include your own criteria for the placement of processes in workload
groups.
When determining the workload groups where particular processes
should be placed, the assignments specified in application records take
precedence over user records, and user records take precedence over
Unix group records. For example, if the same process is identified in both
application records and user records, the process is placed in the
workload group assigned to it by the application record. If you define
secure compartments, compartment records take precedence over
application, user, and Unix group records. If you define process maps,
they take precedence over all the WLM records. Note also that you can
alter the workload group of an application by using the prmmove and
prmrun utilities, which are discussed in the subsections to follow.
WLM provides several methods for placing processes in workload groups.
It is important to understand these methods, as they form the basis of
the workload separation.
First, we define the workload groups for the workloads. The following
snippet from a WLM configuration file creates three workload groups:
servers_grp, apache_grp, and OTHERS. (The OTHERS group is a reserved
workload group and must have ID 1. If you do not explicitly create this
group, WLM creates it for you.)
prm {
groups = OTHERS : 1,
servers_grp : 2,
apache_grp : 3;
}
Note that each workload group is given a name and a number. Following
sections of the WLM configuration file assign resources to the groups.
Processes within the groups then share the resources allocated to that
group.
With the workload groups defined, the remainder of this section explores
how processes can be placed in the workload groups.

82 Chapter 2
 WLM quick start: the essentials for using WLM
How to put an application under WLM control

Application records: Workload separation by binary

name
One mechanism for separating workloads is the apps statement. This
statement simply names a particular application binary and the group in
which it should be placed. You can specify multiple binary-workload
group combinations, separated by commas, in a single apps statement.
In the following prm structure, the apps statement causes the PRM
application manager to place any newly running
/opt/hpws/apache/bin/httpd executables in the group apache_grp.
prm {
groups = OTHERS : 1,
servers_grp : 2,
apache_grp : 3;

apps = apache_grp : /opt/hpws/apache/bin/httpd;

}
For more information on setting up application records, see “Assigning
applications to workload groups (optional)” on page 166.
NOTE on polling: It is important to realize that the process is not placed
in the workload group immediately after starting. Rather, the PRM
application manager periodically polls for newly started processes that
match records in the apps statement. Each matched process is placed in
its designated workload group. For more information, see the section
“Management of applications” on page 454.

User records: Workload separation by process owner

UID
You can place processes in workload groups according to the UIDs of the
process owners. You specify your user-workload group mapping in the
users statement. Here is an example:
prm {
groups = OTHERS : 1,
testers : 2,
coders : 3,
surfers : 4;

users = moe : coders surfers,

Chapter 2 83
WLM quick start: the essentials for using WLM
How to put an application under WLM control

curly : coders surfers,

larry : testers surfers;
}
Besides the default OTHERS group, this example has three groups of
users: testers, coders, and surfers. The user records cause processes
started by users moe and curly to be run in group coders by default, and
user larry’s processes to be run in group testers by default. Each user is
also given permission to run jobs in group surfers if they wish, using
the prmrun or prmmove commands mentioned in sections to follow. Users
not belonging to any of the specified groups are placed in OTHERS by
default. For more information on setting up user records, see “Assigning
users and user access to workload groups (optional)” on page 164.

Unix group records: Workload separation by Unix

group ID
You can place processes in workload groups according to the Unix groups
the processes run in. You specify your Unix group-workload group
mapping in the uxgrp statement. Here is an example:
prm {
groups = OTHERS : 1,
testers : 2,
coders : 3,
surfers : 4;

uxgrp = sports : surfers,

shoes : coders,
appliances : testers;
}
Besides the default OTHERS group, this example has the three workload
groups testers, coders, and surfers. The Unix group records cause
processes running in Unix group sports to be placed in workload group
surfers, while processes running in Unix group shoes are placed in
workload group coders, and processes in Unix group appliances are
placed in workload group testers. Processes not running in any of the
specified Unix groups are placed in OTHERS by default.
WLM supports Unix group records only if PRM C.03.02 or later is
running on the system. For more information on setting up Unix group
records, see “Assigning Unix groups to workload groups (optional)” on
page 165.

84 Chapter 2
 WLM quick start: the essentials for using WLM
How to put an application under WLM control

Secure compartments: Workload separation by secure

compartment
You can place processes in workload groups according to the secure
compartments the processes run in. The HP-UX feature Security
Containment, available starting with HP-UX 11i v2, allows you to create
secure compartments. You specify your mapping between secure
compartments and workload groups in the scomp statement. Here is an
example:
prm {
groups = OTHERS : 1,
database : 2,
webapp : 3;

scomp = db_comp : database,

wa_comp : webapp;
}
Besides the default OTHERS group, two workload groups are defined in
this example: database and webapp. Processes running in the db_comp
secure compartment are placed in workload group database, while
processes running in secure compartment wa_comp are placed in
workload group webapp. Processes not running in any of the two secure
compartments defined in this example are placed in OTHERS by default.
For more information on setting up secure compartment records, see
“Assigning secure compartments to workload groups (optional)” on
page 171.

Process maps: Workload separation using your own

criteria
Using the procmap statement, you define your own criteria for placing
processes in workload groups. You establish your criteria by specifying a
particular workload group plus a script or command and its arguments
that gathers and outputs PIDs of processes to be placed in that group.
WLM spawns the command or script periodically at 30-second intervals.
At each interval, WLM places the identified processes in the specified
group. You can use process maps to automatically place processes that
you might otherwise have to move manually by using the prmmove or
prmrun commands.

Chapter 2 85
WLM quick start: the essentials for using WLM
How to put an application under WLM control

In the prm structure that follows, the procmap statement causes the
PRM application manager to place in the sales group any processes
gathered by the ps command that have PIDs matching the application
pid_app. The application manager places in the mrktg group any
processes gathered by the external script pidsbyapp that have PIDs
matching the application mrketpid_app.
prm {
groups = OTHERS : 1,
sales : 2,
mrktg : 3;

procmap = sales :
/bin/env /UNIX95= /bin/ps -C pid_app -o pid=,
mrktg : /scratch/pidsbyapp mrketpid_app;
}
For more information on setting up process maps, see “Specifying process
maps to define your own criteria for workload separation (optional)” on
page 172.

prmrun: Starting a process in a workload group

You can explicitly start processes in particular workload groups using
the prmrun command. Given the groups and users statements shown in
“User records: Workload separation by process owner UID” on page 83,
user larry running the following command would cause his job to be run
in group testers:
# my_really_big_job &
However, user larry also has permission to run processes in the group
surfers. Thus, larry can use the following prmrun command to run his
process in the group surfers:
# /opt/prm/bin/prmrun -g surfers my_really_big_job &

prmmove: Moving an existing process to a workload

group
Use the prmmove command to move existing processes to a different
workload group. If larry from the previous example has a job running
with process ID (PID) 4065 in the group testers, he could move that
process to group surfers by running the command:

86 Chapter 2
 WLM quick start: the essentials for using WLM
How to determine a goal for your workload

# /opt/prm/bin/prmmove surfers -p 4065

Default: Inheriting workload group of parent process

If a process is not named in an apps statement, a users statement, a
uxgrp statement, or an scomp statement, or if it is not identified by a
procmap statement, or has not been started with prmrun or moved with
prmmove, it simply starts and runs in the same group as its parent
process. So for a setup like the following example, if user jdoe has an
interactive shell running in group mygrp, any process spawned by that
shell process would also run in group mygrp because its parent process
was there.
prm {
groups = OTHERS : 1,
mygrp : 2;
}
Simple inheritance is the mechanism that determines where most
processes run, especially for short-lived processes.

How to determine a goal for your workload

NOTE Be aware of the resource interaction for each of your workloads. Limiting
a workload’s memory allocation can also limit its CPU use. For example,
if a workload uses memory and CPU resources in the ratio of 1:2,
limiting the workload to 5% of the memory implies that it cannot use
more than 10% of the CPU resources —even if it has a 20% CPU
allocation.

To characterize the behavior of a workload, use the following example

WLM configuration (to see the contents of the configuration file, see
“manual_entitlement.wlm” on page 298):
/opt/wlm/examples/wlmconf/manual_entitlement.wlm

Chapter 2 87
WLM quick start: the essentials for using WLM
How to determine a goal for your workload

Using this configuration, you can directly set an entitlement (allocation)

for a workload using the wlmsend command. By gradually increasing the
workload’s allocation with a series of wlmsend calls, you can determine
how various amounts of CPU resources affect the workload and its
performance with respect to some metric that you may want to use in an
SLO for the workload.

NOTE This configuration file is only for PRM-based configurations. PRM must
be installed on your system. For a similar configuration file that
demonstrates WLM’s ability to migrate cores across partitions, see the
par_manual_allocation.wlm and par_manual_allocation.wlmpar
configuration files in /opt/wlm/examples/wlmconf/ and also included in
Chapter 9, “Example configuration files,” on page 283.

In addition, you can compare this research with similar data for the
other workloads that will run on the system. This comparison gives you
insight into which workloads you can combine (based on their needed
CPU resources) on a single system and still achieve the desired SLOs.
Alternatively, if you cannot give a workload its optimal amount of CPU
resources, you will know what kind of performance to expect with a
smaller allocation.
Once you know how the workload behaves, you can decide more easily
the type of goal, either metric or usage, you want for it. You may even
decide to just allocate the workload a fixed amount of CPU resources or
an amount that varies directly in relation to some metric. For
information on the different methods for getting your workload CPU
resources, see the section “SLO TYPES” in wlm(5).
Similar to the manual_entitlement.wlm configuration, the
/opt/wlm/toolkits/weblogic/config/manual_cpucount.wlm configuration
allows you to adjust a workload group’s CPU allocation with a series of
wlmsend calls. (To see the contents of this configuration file, see
“manual_cpucount.wlm” on page 296.) However, manual_cpucount.wlm
uses a PSET as the basis for a workload group and changes the group’s
allocation by one whole core at a time.

88 Chapter 2
 WLM quick start: the essentials for using WLM
Some common WLM tasks

Some common WLM tasks

WLM is a powerful tool that allows you to manage your systems in
numerous ways. The following sections explain some of the more common
tasks that WLM can do for you.

Migrating cores across partitions

WLM can manage SLOs across virtual partitions and nPartitions.
You must use Instant Capacity cores (formerly known as iCOD CPUs) on
the nPartitions for WLM management. WLM provides a global arbiter,
wlmpard, that can take input from the WLM instances on the individual
partitions. The global arbiter then moves cores between partitions, if
needed, to better achieve the SLOs specified in the WLM configuration
files that are active in the partitions. These partitions can be
nested—and even contain FSS and PSET-based workload groups.
(wlmpard can be running in one of the managed partitions or on a
supported platform with network connectivity to the managed
partitions.)
HP-UX Virtual Partitions are software-based virtual systems, each
running its own instance of the HP-UX operating system. WLM can
move processors among these virtual systems to better achieve the SLOs
you define using WLM within each virtual system.
nPartitions (nPars) are hardware-based partitions, each running its own
instance of the HP-UX operating system. Using Instant Capacity
(formerly known as iCOD) software, WLM can manage your SLOs across
nPartitions by simulating the movement of processors among
nPartitions. (The processor movement is simulated by deactivating cores
on one nPartition and activating cores on another nPar.)
Configuring WLM to manage SLOs across virtual partitions and
nPartitions requires the following steps. For details and restrictions, see
Chapter 7, “Managing SLOs across partitions,” on page 255.

Step 1. (Optional) Set up secure WLM communications.

Follow the procedure HOW TO SECURE COMMUNICATIONS in

wlmcert(1M)—skipping the step about starting/restarting the WLM
daemons. You will do that later in this procedure.

Chapter 2 89
WLM quick start: the essentials for using WLM
Some common WLM tasks

Step 2. Create a WLM configuration file for each partition.

Each partition on the system must have the WLM daemon wlmd running.
Create a WLM configuration file for each partition, ensuring each
configuration uses the primary_host keyword to reference the partition
where the global arbiter is running. For information on the
primary_host syntax, see “Setting up your WLM configuration file” on
page 264.

Step 3. (Optional) Activate each partition’s WLM configuration in passive mode.

WLM operates in “passive mode” when you include the -p option in your
command to activate a configuration. With passive mode, you can see
approximately how a particular configuration is going to affect your
system—without the configuration actually taking control of your
system.

Activate each partition’s WLM configuration file configfile in passive

mode as follows:

# wlmd -p -a configfile

For information on passive mode, including its limitations, see “Passive

mode versus actual WLM management” on page 238.

Step 4. Activate each partition’s WLM configuration.

After verifying and fine-tuning each partition’s WLM configuration file

configfile, activate it as follows:

# wlmd -a configfile

To use secure communications, activate the file using the -s option:

# wlmd -s -a configfile

The wlmd daemon runs in secure mode by default when you use the
/sbin/init.d/wlm script to start WLM. (If you upgraded WLM, secure
mode might not be the default. Ensure that the appropriate secure mode
variables in /etc/rc.config.d/wlm are set correctly. For more information
on these variables, see “Securing WLM communications” on page 244.)

Step 5. Create a configuration file for the global arbiter.

On the system running the global arbiter, create a configuration file for
the global arbiter. (If this system is being managed by WLM, it will have
both a WLM configuration file and a WLM global arbiter configuration

90 Chapter 2
 WLM quick start: the essentials for using WLM
Some common WLM tasks

file. You can set up and run the global arbiter configuration on a system
that is not managed by WLM if needed for the creation of fault-tolerant
environments or Serviceguard environments.)

This global arbiter configuration file is required. In the file specify the:

• Global arbiter interval

• Port used for communications between the partitions

• Size at which to truncate wlmpardstats log file

• Lowest priority SLO at which Temporary Instant Capacity (v6 or

later) or Pay per use (v4 , v7, or later) resources are used

NOTE Specifying this priority ensures WLM maintains compliance with

your Temporary Instant Capacity usage rights. When your prepaid
amount of temporary capacity expires, WLM no longer attempts to
use the temporary resources.

When 15 or fewer processing days (the default) of temporary capacity

are available, WLM stops activating Temporary Instant Capacity; in
this case, you must purchase extra capacity. Before you add the
capacity, stop wlmpard (using the -k option). For information about
how to stop wlmpard, see Appendix A, “WLM command reference,” on
page 363.

You can change the 15-day default by setting the WLM global arbiter
utility_reserve_threshold keyword. For more information, see
“Specifying the reserve threshold that determines when WLM stops
activating temporary capacity resources” on page 274 or see
wlmparconf(4).

For information on the syntax of this file, see the section “Setting up your
WLM global arbiter configuration file” on page 265 or see wlmparconf(4).

Step 6. (Optional) Activate the global arbiter configuration file in passive mode.

Similar to the WLM passive mode, the WLM global arbiter has a passive
mode (also enabled with the -p option) that allows you to verify wlmpard
settings before letting it control your system.

Chapter 2 91
WLM quick start: the essentials for using WLM
Some common WLM tasks

Activate the global arbiter configuration file configfile in passive mode

as follows:

# wlmpard -p -a configfile

Again, to see approximately how the configuration would affect your

system, use the WLM utility wlminfo.

Step 7. Activate the global arbiter.

Activate the global arbiter configuration file as follows:

# wlmpard -a configfile

To use secure communications, activate the file using the -s option:

# wlmpard -s -a configfile

The global arbiter runs in secure mode by default when you use the
/sbin/init.d/wlm script to start WLM. (If you upgraded WLM, secure
mode might not be the default. Ensure that the appropriate secure mode
variables in /etc/rc.config.d/wlm are set correctly. For more information
on these variables, see “Securing WLM communications” on page 244.)

Providing a fixed amount of CPU resources

WLM allows you to give a workload a fixed amount of CPU resources.
In the following graphic (created using the HP PerfView product), the
workload receives a constant 15 CPU shares.

92 Chapter 2
 WLM quick start: the essentials for using WLM
Some common WLM tasks

Within a single HP-UX instance, WLM allows you to allocate a fixed

amount of CPU resources using:

• portions of processors (FSS groups)

• whole processors (PSETs)
You can also allocate a fixed amount of CPU resources to virtual
partitions and nPartitions. HP recommends omitting from WLM
management any partitions that should have a constant size. In such
cases, WLM’s capability of migrating cores across partitions is not
needed.

Portions of processors (FSS groups)

One method for providing a fixed amount of CPU resources is to set up
an SLO to give a workload group a portion of each available processor. To
set up this type of SLO:

Chapter 2 93
WLM quick start: the essentials for using WLM
Some common WLM tasks

NOTE PRM must be installed on your system for WLM to be able to manage
FSS groups.

Step 1. Define the workload group and assign a workload to it.

In your WLM configuration file, define your workload group in a prm

structure using the groups keyword. Assign a workload to the group
using the apps keyword.

The following example defines a group named sales.

prm {
groups = sales : 2;

apps = sales : /opt/sales/bin/sales_monitor;

}

The sales_monitor application is placed in the sales workload group

using the apps statement. For other methods for placing a workload in a
certain group, see “How to put an application under WLM control” on
page 81.

Step 2. Define a fixed-allocation SLO for the workload group.

In the slo structure, use the cpushares keyword with total to request
CPU resources for the workload group. The following SLO requests 15
CPU shares for the workload group sales. Based on SLO priorities and
available CPU resources, WLM attempts to meet the request.
slo fixed_allocation_example {
pri = 2;
entity = PRM group sales;
cpushares = 15 total;
}

Step 3. Activate the configuration as in the following example, substituting your

configuration file’s name for config.wlm:

# /opt/wlm/bin/wlmd -a config.wlm

94 Chapter 2
 WLM quick start: the essentials for using WLM
Some common WLM tasks

Whole processors (PSETs)

Another method for providing a workload group with a fixed amount of
CPU resources is to define the group based on a PSET. The PSETs
feature is available for HP-UX 11i v1 (B.11.11) by downloading software
from the following Web site free of charge:
http://www.hp.com/go/wlm
Select the Patches/support link and search for “processor sets”.
PSETs are included starting with v2 (B.11.23) of HP-UX 11i.
As in the previous case, the workload requires a constant amount of CPU
resources. Placing the workload in a workload group based on a PSET,
the workload has sole access to the processors in the PSET.

NOTE PRM must be installed on your system for WLM to be able to manage
workgroups based on PSETs.

To place an application in a workload group based on a PSET:

Step 1. Define the workload group based on a PSET and assign a workload to it.

In your WLM configuration file, define your workload group in a prm

structure using the groups keyword. Assign an application to the group
using the apps keyword. Use the gmincpu statement to set the minimum
CPU usage.

The following example shows the sales group as a PSET that is

assigned two cores through a gmincpu statement. (When using gmincpu
for a group based on a PSET, 100 represents a single core. Thus, 200
represents two cores.) The application sales_monitor is assigned to the
group:
prm {
groups = sales : PSET;

apps = sales : /opt/sales/bin/sales_monitor;

gmincpu = sales : 200;

}

Chapter 2 95
WLM quick start: the essentials for using WLM
Some common WLM tasks

NOTE When WLM is managing PSETs, do not change PSET settings by using
the psrset command. Only use WLM to control PSETs.

Step 2. Activate the configuration as in the following example, substituting your

configuration file’s name for config.wlm:

# /opt/wlm/bin/wlmd -a config.wlm

Providing CPU resources for a given time period

For workloads that are only needed for a certain period of time, whether
it is once a day, week, or any other period, WLM provides the condition
keyword. This keyword is placed in an slo structure and enables the
SLO when the condition statement is true.
By default, when the SLO is not enabled, its workload group gets its
gmincpu value. If this value is not set, the workload group gets the
minimum allocation possible. For FSS groups, this is 1% of the total CPU
resources in the default PSET (the default PSET—also referred to as
PSET 0—is discussed in “The default PSET (PSET 0) and FSS groups”
on page 163). If the tunable extended_shares is set to 1, the minimum
is 0.2% (with incremental allocations of 0.1%). For more information on
the extended_shares tunable, see “Refining granularity of CPU (and
memory) allocation by increasing shares per core (optional)” on page 219.
Setting the transient_groups keyword to 1 also changes the allocation
behavior. For more information on this, see “Temporarily removing
groups with inactive SLOs (optional)” on page 220.
The following figure shows a workload group with an SLO that is
disabled initially. With the SLO disabled, the group is given its gmincpu
value, which in this case is 5 shares. The SLO is enabled at 15:38, when
an application is started, and the workload group eventually receives 50
CPU shares.

96 Chapter 2
 WLM quick start: the essentials for using WLM
Some common WLM tasks

SLO is enabled

SLO is disabled; workload

gets its gmincpu

To provide a workload group with CPU resources on a schedule:

NOTE This procedure applies only to PRM-based configurations (confined

within a single instance of HP-UX). PRM must be installed on your
system for WLM to be able to manage PRM-based workloads.
You can achieve similar functionality for configurations managing
nPartitions and virtual partitions by using a condition keyword similar
to the one shown in Step 2. For information on configuring WLM for
migrating cores across partitions, see Chapter 7, “Managing SLOs across
partitions,” on page 255.

Step 1. Define the workload group and assign a workload to it.

In your WLM configuration file, define your workload group in a prm

structure using the groups keyword. Assign a workload to the group
using the apps keyword.

In this example, the sales group is the group of interest again.

Chapter 2 97
WLM quick start: the essentials for using WLM
Some common WLM tasks

prm {
groups = sales : 2;

apps = sales : /opt/sales/bin/sales_monitor;

}

Step 2. Define the SLO.

The SLO in your WLM configuration file must specify:

• A priority (pri) for the SLO

• The workload group to which the SLO applies (entity)

• Either a cpushares statement or a goal statement so that WLM

grants the SLO’s workload group some CPU resources

The condition keyword determines when the SLO is enabled or

disabled.

The following slo structure shows a fixed-allocation SLO for the sales
group. When enabled, this SLO requests 25 CPU shares for the sales
group. Based on the condition statement, the SLO is enabled between
8pm and 11pm every day.
slo condition_example {
pri = 1;
entity = PRM group sales;
cpushares = 25 total;
condition = 20:00 - 22:59;
}

Whenever the condition statement is false, the SLO is disabled and

does not make any CPU resource requests for the sales group. When a
group has no enabled SLOs, it gets its gmincpu value (if set); if this value
is not set, a group gets the minimum allocation possible. For FSS groups,
this is 1% of the CPU resources of the default PSET (the default
PSET—also referred to as PSET 0—is discussed in “The default PSET
(PSET 0) and FSS groups” on page 163). If the extended_shares tunable
is set to 1 and absolute CPU units are being used, this minimum is 0.2%
(with incremental allocations of 0.1%). For more information on the
extended_share tunable, see “Refining granularity of CPU (and
memory) allocation by increasing shares per core (optional)” on page 219.

You can use times, dates, or metrics to enable or disable an SLO.

98 Chapter 2
 WLM quick start: the essentials for using WLM
Some common WLM tasks

For information on the syntax for the condition keyword, see

wlmconf(4).

Step 3. Activate the configuration as in the following example, substituting your

configuration file’s name for config.wlm:

# /opt/wlm/bin/wlmd -a config.wlm

Providing CPU resources as needed

To ensure a workload gets the CPU resources it needs—without
preventing other workloads access to unused CPU resources—WLM
allows you to define usage goals. A major advantage with usage goals is
that you do not need to track and feed a metric to WLM.
The following figure shows a workload that initially is using 20 CPU
shares. The usage goal for the workload is to use between 60% and 90%
of its allocation. With its beginning allocation at 32 shares, the workload
is using 20/32 or 62.5% of its allocation. Later, the workload settles to
using around 8 or 9 shares. WLM responds by reducing its allocation to
10 shares, still meeting the usage goal as long as usage stays between 6
and 9 shares.

Chapter 2 99
WLM quick start: the essentials for using WLM
Some common WLM tasks

Here, WLM adjusts the allocation so

that the workload always uses at least
60% but never more than 90% of it

With a usage goal, you indicate for a workload how much of its CPU
allocation it should use. If a workload is not consuming enough of its
current allocation, the workload’s CPU allocation is reduced, allowing
other workloads to consume more CPU resources if needed. Similarly, if
the workload is using a high percentage of its allocation, it is granted
more CPU resources.
To define a usage goal for a workload group:

NOTE This procedure applies only to PRM-based configurations (confined

within a single instance of HP-UX). For information on configuring WLM
for migrating CPU resources across partitions, see Chapter 7, “Managing
SLOs across partitions,” on page 255.
PRM must be installed on your system for WLM to be able to manage
PRM-based workloads.

Step 1. Define the workload group and assign a workload to it.

100 Chapter 2
 WLM quick start: the essentials for using WLM
Some common WLM tasks

In your WLM configuration file, define your workload group in a prm

structure using the groups keyword. Assign a workload to the group
using the apps keyword.

The following example shows the prm structure for the sales group.
prm {
groups = sales : 2;

apps = sales : /opt/sales/bin/sales_monitor;

}

Step 2. Define the SLO.

The SLO in our WLM configuration must specify:

• A priority (pri) for the SLO

• The workload group to which the SLO applies (entity)

• A usage goal statement

The following slo structure for the sales group shows a usage goal
statement:
slo usage_example {
pri = 1;
mincpu = 20;
maxcpu = 60;
entity = PRM group sales;
goal = usage _CPU 80 90;
}

With usage goals, WLM adjusts the amount of CPU resources it grants a
workload group so that the group uses between 50% and 75% of its
allocated CPU resources by default. In the previous example though,
with the values of 80 and 90 in the goal statement, WLM would try to
increase or decrease the CPU allocation for the workload group until the
group is using between 80% and 90% of the allocated share of CPU
resources. However, in attempting to meet the usage goal, the new CPU
allocations to the workload group will typically be within the
mincpu/maxcpu range.

Step 3. Set your interval to 5.

With a usage goal, you should typically set wlm_interval to 5.

Chapter 2 101
WLM quick start: the essentials for using WLM
Other functions WLM provides

tune {
wlm_interval = 5;
}

Step 4. Activate the configuration as in the following example, substituting your

configuration file’s name for config.wlm:

# /opt/wlm/bin/wlmd -a config.wlm

Other functions WLM provides

Run in passive mode to verify operation

WLM provides a passive mode that allows you to see how WLM will
approximately respond to a given configuration—without putting WLM
in charge of your system’s resources. Using this mode, you can check that
your configuration behaves as expected and with minimal effect on the
system. Besides being useful in understanding and experimenting with
WLM, passive mode can be helpful in capacity-planning activities.

Auditing and billing

When you activate a WLM configuration or a WLM global arbiter
configuration, you have the option of generating audit data. You can use
the audit data files directly or view them using the wlmaudit command.
For more information, see wlmaudit(1M), wlmd(1M), and wlmpard(1M).

Optimize use of Temporary Instant Capacity (TiCAP)

Temporary Instant Capacity activates capacity in a temporary
“calling-card” fashion such as in 20-day or 30-day increments (where a
day equals 24 hours for one core). With this option, you can activate and
deactivate processors as needed. You purchase a TiCAP codeword to
obtain usage rights for a preset amount of days. The Temporary Instant
Capacity codeword is applied to a system so you can turn on and off any
number of Instant Capacity cores on the system as long as your prepaid
amount of temporary capacity has not expired.

102 Chapter 2
 WLM quick start: the essentials for using WLM
Status information WLM provides

If you have WLM on a Temporary Instant Capacity system (using v6 or

later), you can configure WLM to minimize the costs of using these
resources. You do so by optimizing the amount of time the resources are
used to meet the needs of your workloads.
For more information on this feature, see “Integrating with Temporary
Instant Capacity (TiCAP)/ Pay per use (PPU)” on page 410 and
wlmparconf(4) and wlmpard(1M).

Integrate with various third-party products

HP has developed a number of toolkits to assist you in quickly and
effectively deploying WLM for use with your key applications. The freely
available WLM Toolkits product consists of several toolkits, each with
example configuration files. Toolkits are currently available for:

• Oracle Databases
• HP-UX Apache-based Web Server software
• BEA WebLogic Server
• SNMP agents
• SAP software
• SAS software
WLM Toolkits are included with WLM. They are also freely available on
the following Web site:
http://www.hp.com/go/softwaredepot
For more information on the toolkits, see the HP-UX Workload Manager
Toolkits User’s Guide on http://docs.hp.com/hpux/netsys/ or wlmtk(5).

Status information WLM provides

WLM has three log files to keep you informed:

• /var/opt/wlm/msglog

Chapter 2 103
WLM quick start: the essentials for using WLM
Status information WLM provides

WLM prints errors and warnings about configuration file syntax on

stderr. For messages about ongoing WLM operations, WLM logs
error and informational messages to /var/opt/wlm/msglog, as shown
in the following example:
05/07/02 14:12:44 [I] (p13931) Ready to forward data for metric
"m_apache_access_2min"
05/07/02 14:12:44 [I] (p13931) Using "/door00/wlm_cfg/apache_access.pl"
05/07/02 14:12:44 [I] (p13932) Ready to forward data for metric
"m_list.cgi_procs"
05/07/02 14:12:44 [I] (p13932) Using "/door00/wlm_cfg/proc_count.sh"
05/07/02 14:12:44 [I] (p13930) Ready to forward data for metric
"m_apache_access_10min"
05/07/02 14:12:44 [I] (p13930) Using "/door00/wlm_cfg/apache_access.pl"
05/07/02 14:12:44 [I] (p13929) Ready to forward data for metric "m_nightly_procs"
05/07/02 14:12:44 [I] (p13929) Using "/opt/wlm/lbin/coll/glance_prm"
05/07/02 14:12:44 [I] (p13921) wlmd 13921 starting
05/31/02 03:42:10 [I] (p13921) /var/opt/wlm/wlmdstats has been renamed to
/var/opt/wlm/wlmdstats.old.
• /var/opt/wlm/wlmdstats
WLM can optionally produce a log file that includes data useful for
verifying WLM management or for fine-tuning your WLM
configuration. This log file, /var/opt/wlm/wlmdstats, is created when
you start the WLM daemon with the -l option, as in the following
example:
# /opt/wlm/bin/wlmd -a config.wlm -l slo
For information on the -l option, see wlmd(1M).
Here are some lines from a wlmdstats file:
1024328341 SLO=s_nice_xtra_min sloactive=1 goaltype=nogoal goal=nan goalsatis=1
met=nan metfresh=0 mementitl=0 cpuentitl=20 clipped=0 controlling=0
1024328341 SLO=s_team_playground_xtra_min sloactive=1 goaltype=nogoal goal=nan
goalsatis=1 met=nan metfresh=0 mementitl=0 cpuentitl=5 clipped=0 controlling=1
• /var/opt/wlm/wlmpardstats
The WLM global arbiter can optionally produce a statistics log file.
The global arbiter is used for managing SLOs across virtual
partitions and nPartitions as well as for optimizing Temporary
Instant Capacity (v6 or later) and Pay per use (v4, v7, or later). This
log file, /var/opt/wlm/wlmpardstats, is created when you start the
WLM global arbiter daemon with the -l option, as in the following
example:

104 Chapter 2
 WLM quick start: the essentials for using WLM
Monitoring WLM

# /opt/wlm/bin/wlmpard -a config.wlm -l vpar

For information on the -l option, see wlmpard(1M).

Monitoring WLM
Several methods available for monitoring WLM are described in this
section.

ps
The following ps command has options specific to PRM that WLM uses
to define workload groups when dividing resources within a single
HP-UX instance:
ps [-P] [-R workload_group]

• -P
Adds the column PRMID, showing the workload group for each
process.
# ps -P
PRMID PID TTY TIME COMMAND
g3 6793 ttyp1 1:52 loop.pl
g3 6463 ttyp1 7:02 loop3.pl
g2 6462 ttyp1 4:34 loop2.pl
• -R workload_group
Lists only the processes in the group named by workload_group.
Here is output showing processes in the workload group g3:
# ps -R g3
PID TTY TIME COMMAND
6793 ttyp1 1:29 loop.pl
6463 ttyp1 6:41 loop3.pl

Chapter 2 105
WLM quick start: the essentials for using WLM
Monitoring WLM

wlminfo
The wlminfo command, available in /opt/wlm/bin/, displays information
about SLOs, metrics, workload groups, virtual partitions or nPartitions,
and the current host. To display information about workload groups,
specify the group keyword as in the following example. Note that as of
WLM A.03.02 you can use the -v option with the wlminfo group
command to display gmincpu, gmaxcpu, gminmem, and gmaxmem values, if
they are assigned in the active configuration file).
# wlminfo group
Workload Group PRMID CPU Shares CPU Util Mem Shares Mem Util State
OTHERS 1 65.00 0.00 6.00 2.10 ON
g2 2 15.00 0.00 64.00 32.43 ON
g3 3 20.00 0.00 30.00 9.17 ON

To display information about partitions, specify the par keyword. In the

following example, the ‘Intended Cores’ column shows the number of
CPU resources (cores) that WLM wants to allocate to the partition, while
the ‘Cores’ column shows the current number of active cores. The number
of intended and active cores is usually the same except when WLM is in
the process of modifying a partition or is operating in passive mode. (In
passive mode, the intended core allocation is not made; the partition
retains the current number of active cores.) The ‘Cores Used’ column
shows the CPU (core) utilization of the partition. The ‘Interval’ column
shows the WLM interval—the frequency at which WLM checks for new
performance data for the workload and then adjusts core allocations.
# /opt/wlm/bin/wlminfo par

Hostname Intended Cores Cores Cores Used Interval

north 2 2 1.3 6
south 3 3 2.1 6
east 1 1 0.4 6
west 2 2 1.7 6
northwest 3 3 2.3 6
northeast 2 2 1.4 6

The wlminfo host command displays information pertaining to the local

host (default) or a specified host, including the number of CPU resources
(cores) on the host and the number being used as well as the WLM
interval, as in the following example (for local host west):

106 Chapter 2
 WLM quick start: the essentials for using WLM
Monitoring WLM

# /opt/wlm/bin/wlminfo host

Hostname Cores Cores Used Interval

localhost 2 1.7 6

For more information on the use of the wlminfo command, see

Appendix A, “WLM command reference,” on page 363 and wlminfo(1M).

wlmgui
The wlmgui command, available in /opt/wlm/bin/, graphically displays
information about SLOs, metrics, workload groups, partitions, and the
current host.

prmmonitor
The prmmonitor command, available in /opt/prm/bin/, displays current
configuration and resource usage information, as in the following
example. The ‘CPU Entitle’ column indicates the CPU entitlement
(allocations) for the group. The ‘Upper Bound’ column indicates the
per-group consumption cap; the column is blank for each group because
the CPU consumption cap is not available with WLM. The ‘LCPU State’
column indicates the Hyper-Threading setting (ON or OFF) for
PSET-based groups. The column is blank if the system does not support
Hyper-Threading or if a group is not a PSET-based group.

PRM configured from file: /var/opt/wlm/tmp/wmprmBAAa06335

File last modified: Tue Sep 26 08:35:23 2006

HP-UX vpar02 B.11.31 U ia64 09/26/06

Tue Sep 26 08:43:16 2006 Sample: 1 second

CPU scheduler state: Enabled
CPU Upper CPU LCPU
PRM Group PRMID Entitle Bound Used State
____________________________________________________________
(PRM_SYS) 0 0.00%
OTHERS 1 12.50% 0.00%
grp2 65536 12.50% 0.00% OFF
grp3 131072 25.00% 0.00% ON
grp4 196608 50.00% 0.00 ON
PRM application manager state: Enabled (polling interval: 30 seconds)

Chapter 2 107
WLM quick start: the essentials for using WLM
Monitoring WLM

prmlist
The prmlist command, available in /opt/prm/bin, displays current CPU
allocations plus user and application configuration information. The
‘Upper Bound’ column indicates the per-group consumption cap; the
column is blank for each group because the CPU consumption cap is not
available with WLM. The ‘LCPU Attr’ column indicates the
Hyper-Threading setting (ON or OFF) for a PSET-based group; the
column is blank if the system does not support Hyper-Threading or the
group is not a PSET-based group.
PRM configured from file: /var/opt/wlm/tmp/wmprmBAAa06228
File last modified: Thu Aug 24 08:35:23 2006

PRM Group PRMID CPU Upper LCPU

Entitlement Bound Attr
-------------------------------------------------------------------
OTHERS 1 65.00%
g2 2 15.00%
g3 3 20.00%

PRM User Initial Group Alternate Group(s)

--------------------------------------------------------------------------------
root (PRM_SYS)

PRM Application Assigned Group Alternate Name(s)

--------------------------------------------------------------------------------
/opt/perl/bin/perl g2 loop2.pl
/opt/perl/bin/perl g3 loop3.pl

GlancePlus
The optional HP product GlancePlus allows you to display resource
allocations for the workload groups as well as list processes for
individual workload groups.

wlm_watch.cgi
This CGI script, available in /opt/wlm/toolkits/apache/bin/, allows you to
monitor WLM using a web browser interface to prmmonitor, prmlist,
and other monitoring tools.
For information on setting up this script, see wlm_watch(1M).

108 Chapter 2
 WLM quick start: the essentials for using WLM
Monitoring WLM

Status and message logs

WLM provides the following logs:

• /var/opt/wlm/msglog
• /var/opt/wlm/wlmdstats
• /var/opt/wlm/wlmpardstats
For information on these logs, including sample output, see the section
“Status information WLM provides” on page 103.

Event Monitoring Service (EMS)

EMS (Event Monitoring Service) polls various system resources and
sends messages when events occur. The WLM wlmemsmon command
provides numerous resources for event monitoring. For information on
these resources, see wlmemsmon(1M).

Chapter 2 109
WLM quick start: the essentials for using WLM
Monitoring WLM

110 Chapter 2
3 How WLM manages workloads

This chapter discusses how workloads can be managed through

service-level objectives. It also discusses two types of WLM SLOs:
shares-based and goal-based.
These topics are covered in the following sections:

• How WLM works

• Shares-based SLOs vs goal-based SLOs
• How WLM gets application data
• SLO violations
• How a workload is managed (controllers)
• How conflicting SLOs are resolved (arbiter)
• Allocating CPU resources: The rising tide model
• Example of WLM in use

Chapter 3 111
How WLM manages workloads
How WLM works

How WLM works

The following tasks outline how WLM works:

1. 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.
2. 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.
3. Compares performance data (reported performance) to stated goals
(desired performance) for each active goal-based SLO.
4. 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.

112 Chapter 3
 How WLM manages workloads
How WLM works

5. 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.
6. Determines memory allocations based on whether any workloads
have become active or gone inactive.
7. 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:

• Virtual partitions
• nPartitions that use Instant Capacity software (formerly known
as iCOD software)
8. Assigns new CPU and memory shares.
9. 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.
10. Sets EMS resources for monitoring of SLO compliance.
11. Repeats tasks 2 through 10 the next WLM interval.
12. 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.
13. 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).
Figure 3-1 on page 115 illustrates how WLM works.

Chapter 3 113
How WLM manages workloads
How WLM works

For more information on the components shown in the figure, see the
following sections:

• Types of SLOs
“Shares-based SLOs vs goal-based SLOs” on page 118
• Metric data collectors
“Supplying data to WLM” on page 482
• WLM daemon
“wlmd” on page 374
• WLM configuration file
Chapter 5, “Configuring WLM,” on page 135
• WLM global arbiter
Chapter 7, “Managing SLOs across partitions,” on page 255
• PRM
Appendix F, “Understanding how PRM manages resources,” on
page 447
• EMS
Chapter 10, “Monitoring SLO compliance and WLM,” on page 343
Figure 3-1 provides an overview of WLM functional flow. It shows WLM
running in each partition on the system. If you are using WLM on a
system without partitions, focus on Par 0 to understand how WLM
controls resources on your system to ensure SLOs are met. If you want to
understand how WLM manages resources across partitions, consider Par
0 as one of four partitions along with Par 1, Par 2, and Par 3; the WLM
global arbiter (defined in the partition for Par 0) determines resource
allocations for each of the four partitions. Detailed descriptions of the
functional processes illustrated in Figure 3-1 are provided after the
figure.

114 Chapter 3
 How WLM manages workloads
How WLM works

Figure 3-1 WLM overview

Define WLM Event Monitoring WLM monitoring tools

workloads configuration Service (EMS) (wlminfo or wlmgui)
and SLOs file
SLO stats
(pass/fail)
Message log
WLM daemon (wlmd) /var/opt/wlm/msglog
Workload Grp A
(metric goal) Usage Data Controller
Collector

Statistics log (optional)

Workload Grp B Usage Data /var/opt/wlm/wlmdstats
(usage goal) Controller
Collector
Arbiter

Workload Grp C Fixed Audit data files (optional)

(no goal) Allocation /var/opt/wlm/audit/

Workload Grp D Metric Data Shares-per-metric

(no goal) Collector Allocation Global arbiter statistics
log (optional)
/var/opt/wlm/wlmpardstats

PRM
Workload groups get
new CPU allocations
better suited to their SLOs WLM global arbiter
WLM creates a new PRM configuration daemon (wlmpard)

WLM
global arbiter
configuration
file

Par 0

WLM can manage

vPars, nPars,
WLM EMS WLM EMS or a combination
wlminfo/ wlminfo/
WLM EMS configuration configuration
wlminfo/ wlmgui wlmgui
configuration file file
wlmgui vPars get
file
Log Log cores added
Grp A WLM WLM or removed
Log files files
Grp B WLM files to better
Grp C suit the SLOs
App1 App2 App3 App1 App2 App3
With nPars, a
PRM core is
deactivated
Par 1 Par 2 Par 3 on one nPar, then
a core on
another nPar
is activated

HP-UX server

Chapter 3 115
How WLM manages workloads
How WLM works

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.

116 Chapter 3
 How WLM manages workloads
How WLM works

8. 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.
9. 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.

The monitoring and logging processes shown in Figure 3-1 include the
following:

• The status of the SLOs and information about the performance of

WLM are sent to the Event Monitoring Service (EMS). Using an
EMS client such as System Administration Manager (SAM) or
System Management Homepage (SMH), which is an enhanced
version of SAM, a system administrator can choose from a number of
notification methods (such as email, SNMP traps, TCP, UDP, and
OPC Messaging) for receiving events of specific interest.
• The WLM monitoring tools wlminfo and wlmgui allow you to get a
variety of types of WLM information.
• WLM keeps you up to date on the operations of its daemon by
updating the message log /var/opt/wlm/msglog.
• WLM adds data to the statistics log /var/opt/wlm/wlmdstats if
enabled through the wlmd -l option. The data collectors continue to
feed application metrics to WLM, which at intervals calculates new
resource allocations and performs any needed PRM reconfiguration.
• With the WLM configuration file activated using the -t option to
wlmd, WLM produces audit data in the /var/opt/wlm/audit/ file.

Chapter 3 117
How WLM manages workloads
Shares-based SLOs vs goal-based SLOs

• With the WLM global arbiter configuration file activated using the
-l option to wlmpard, the global arbiter adds data to the
/var/opt/wlm/wlmpardstats/ statistics log file.

Shares-based SLOs vs goal-based SLOs

WLM supports two types of SLOs:

• Shares-based SLOs
A shares-based SLO allows you to specify either a fixed allocation of
shares or a shares-per-metric allocation for a workload. A
shares-per-metric allocation is of the form “x shares of the CPU
resources for each metric y”.
A shares-based SLO has a priority. It may also have maximum and
minimum CPU request bounds and an explicit shares request.
However, it does not have an explicit goal.
• Goal-based SLOs
A goal-based SLO has a specified performance or usage goal.
WLM automatically changes CPU allocations for an SLO’s associated
workload based on the:

— Performance or usage (utilization) of the workload in the group

— SLO’s priority
— Available resources
A workload’s performance is tracked by a data collector and reported
to WLM, as explained in the section “How WLM gets application
data” on page 119. For an SLO with a usage goal, WLM tracks the
data itself.
You can simultaneously use an SLO with a fixed shares allocation and
goal-based SLOs on the same workload.

118 Chapter 3
 How WLM manages workloads
How WLM gets application data

How WLM gets application data

You use a data collector for each workload that has a performance goal.
You can use one of the WLM-provided data collectors or you can make
your own. These collectors report their data to WLM on a regular basis.
This data updates the values of metrics used in the WLM configuration.
Once every interval (the default is 60 seconds), WLM checks the metric
values and adjusts resource allocations to better achieve the SLOs, if
needed.
For an illustration showing the role of data collectors in WLM operations,
see Figure 3-1 on page 115.
For information on writing data collectors, see “Supplying data to WLM”
on page 482.
For information on changing the WLM interval, see “Specifying the
WLM interval (optional)” on page 215.

Chapter 3 119
How WLM manages workloads
How a workload is managed (controllers)

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 on page 115.
For information on specifying usage and performance goals, see
“Specifying a goal (optional)” on page 199.
For information on how to tune controllers, see:

• “Tuning a workload’s SLO convergence: cntl_kp (optional)” page 224

• “Tuning a workload’s SLO convergence: cntl_convergence_rate
(optional)” page 229
• “Tuning the goal buffer (optional)” on page 231

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

120 Chapter 3
 How WLM manages workloads
How a workload is managed (controllers)

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?” on page 354.
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 on page 115.
For information on priorities and weights, see “Specifying the priority
(required)” on page 193 and “Weighting a group so it gets more CPU
resources (optional)” on page 178.

Chapter 3 121
How WLM manages workloads
Allocating CPU resources: The rising tide model

Allocating CPU resources: The rising tide

model
If all workloads’ demand for CPU resources can be met with current
resources, WLM satisfies that demand. If however, demand exceeds
supply, WLM uses the “rising tide” model to allocate CPU resources: At a
given priority, WLM attempts to raise the allocation of the workload with
the lowest CPU allocation to the level of the next lowest allocation. If
CPU resources remain, WLM then raises the allocations for those two
groups to the level of the third lowest group. This process continues at
the current priority until all CPU resource requests have been met or all
resources have been distributed. If requests have been met and resources
remain, WLM continues with the next priority.
Consider Figure 3-2 on page 123 with groups A, B, and C. All groups start
with 1 CPU share. At priority 1, only groups A and B are requesting CPU
resources. Their requests of 15 and 25 shares are easily satisfied. WLM
meets the lowest request first, granting 14 additional shares to both
groups. WLM then grants an additional 10 shares to group B to meet its
higher request. Group C and the default group OTHERS (not shown) both
receive 1 share. After satisfying those CPU resource requests, 58 shares
are left.
At priority 2, groups A B, and C all request 60 shares. These requests, of
course, sum to 180 shares—exceeding the available 100 shares. With the
58 remaining shares, WLM can meet only one of the SLOs. With all three
SLOs at the same priority, WLM attempts to satisfy them all as much as
possible—rather than meet one SLO at the expense of the other two. The
strategy of meeting each SLO as much as possible is similar to a rising
tide lifting all boats: All workloads are raised to the same CPU
allocation.
Group C starts with 1 share. WLM first grants group C an additional 14
shares, raising its allocation to match the allocation for group A. WLM
then adds 10 shares to the allocations for both A and C, matching that of
group B. Now each group has 25 shares. The 24 remaining shares are
distributed evenly among the three groups. The last share is still being
used by the group OTHERS (not shown).

122 Chapter 3
 How WLM manages workloads
Allocating CPU resources: The rising tide model

Figure 3-2 illustrates the rising tide model. Moving from left to right
within a single priority shows how WLM grants additional CPU
resources to the workloads.

Figure 3-2 CPU allocation: the rising tide model

Group OTHERS (not shown)
Priority 1 CPU requests Rising tide has the minimum 1 CPU share
Group A 15
Group B 25

25
15 +10

➜ +14 +14 ➜ 15 15

A B C A B C A B C

Priority 2 CPU requests

Group A 60
Group B 60
Group C 60

60 60 60

+8 +8 +8
+10 +10
25 25 ➜ 25 25 25
15 +14 ➜ 15 15

A B C A B C A B C

Chapter 3 123
How WLM manages workloads
Example of WLM in use

Example of WLM in use

Consider a server that runs two workloads:

• Accounts payable
• Accounts receivable
The accounts payable and accounts receivable workloads run constantly.
Without WLM, the performance of these workloads varies greatly
throughout the day, based mainly on the amount of work competing
workloads have at any given time. Consequently, the server might be
overloaded with accounts payable processing, greatly slowing the
accounts receivable processing. Figure 3-3 illustrates this scenario.

Figure 3-3 Server without WLM

Response time in seconds

1 Accounts payable (AP)

Accounts receivable (AR)

Number of transactions

By using WLM, you can define SLOs for the workloads to specify their
desired performance levels. For example, the accounts payable workload
can be assigned a goal of paying out money in less than 2.5 seconds,
while the accounts receivable workload is assigned a goal of depositing
the incoming money in less than 1 second. WLM uses data from data
collectors to determine how much a workload is underachieving or
overachieving its desired performance level. WLM then automatically
adjusts the CPU allocation, based on priorities, for workloads that are
underachieving or overachieving. Figure 3-4 shows how the workloads
are controlled under WLM.

124 Chapter 3
 How WLM manages workloads
Example of WLM in use

Figure 3-4 Server with WLM

Accounts payable (AP)
Response time in seconds

Accounts receivable (AR)

4

3
AP goal
2

1 AR goal

Number of transactions

In this example, the accounts receivable workload has priority 1 and a

response time goal of less than 1 second. The accounts payable workload
has priority 2 and a response time goal of less than 2.5 seconds. When
resources are not sufficient to meet the SLOs for both workloads, the
accounts receivable workload is favored over the accounts payable
workload. For another example, see “Specifying the priority (required)”
on page 193.

Chapter 3 125
How WLM manages workloads
Example of WLM in use

126 Chapter 3
4 How do I use WLM?

This chapter the basic steps needed to use WLM. The remaining
chapters explain these steps in detail.

The WLM configuration allows you to:

• Treat an entire vPar or nPar as a workload

• Create workloads based on PSETs or FSS groups to share a system
or partition among several workloads
You then assign shares-based or goal-based SLOs to the workloads.
Optionally, you indicate when each SLO is active.
If your configuration has workloads with performance goals, you can also
specify a means for collecting the performance data of those workloads.
Your performance collecting programs then use a utility called wlmrcvdc
or an API to provide the data to WLM. The utility and the API are
included with WLM and are explained in the section “What methods
exist for sending data to WLM?” on page 493. For more details about
using WLM with performance metrics, see Appendix H, “Advanced WLM
usage: Using performance metrics,” on page 467.
Next, WLM compares, at every interval, the reported and desired
performance levels for each SLO. WLM then adjusts, if needed, CPU
resources for the SLOs’ associated workloads based on the resources
needed to satisfy the SLOs and their assigned priorities.
Also, WLM generates SLO status information that is made available
through EMS.

Phasing in your WLM implementation

This section suggests one way in which to implement WLM. This is only
a suggestion and may not be appropriate in all situations.

Step 1. Implement a static configuration with usage goals.

A static implementation has a set number of workloads that are active at

all times. One way to implement such a configuration is to set up usage
goals for the workloads.

Chapter 4 127
How do I use WLM?
Steps for using WLM

Evaluate the system and workload performance under this configuration

from one to seven days and fine-tune the configuration.

Step 2. Implement a configuration with metric goals for the workloads.

Again, evaluate the system and workload performance under the

configuration from one to seven days and fine-tune the configuration.

Step 3. If applicable, implement a time-based configuration with goals.

Use the condition and exception keywords to indicate times when

SLOs are active. These keywords are explained in the section “Specifying
when the SLO is active (optional)” on page 205.

Set mincpu to 0 and maxcpu to 100. Monitor the system for one to two
weeks to determine:

• How often are the goals met?

• Do the workloads ever reach the mincpu or maxcpu values?
• Do the mincpu and maxcpu values need adjusting?
For more information on mincpu and maxcpu, see “Specifying the lower
and upper bound requests on CPU resources (optional)” on page 196.

Steps for using WLM

The following steps outline how to configure WLM. Syntax information is
available in Chapter 5, “Configuring WLM,” on page 135.
If you prefer not to work directly with a configuration file, use the WLM
Configuration Wizard, invoked by the command /opt/wlm/bin/wlmcw, to
create configurations. The wizard does not provide all the functionality
available through a configuration file, but it does greatly simplify the
process of creating a configuration. After creating a configuration file
using the wizard, you can view the file to learn, and become more
comfortable with, the syntax and possibly create more complex
configurations.

128 Chapter 4
 How do I use WLM?
Steps for using WLM

NOTE Running the wizard requires Java Runtime Environment version 1.4.2
or later and, for PRM-based configurations, PRM C.03.00 or later. (To
take advantage of the latest updates to WLM, use the latest version of
PRM available.)

The WLM GUI, at /opt/wlm/bin/wlmgui, also allows you to configure

WLM without directly editing a configuration file; however, you do need
to be familiar with the configuration file syntax.
In addition, WLM provides a number of example configurations in
/opt/wlm/examples/wlmconf/ that you can modify to fit your environment.
Also, the WLM Toolkits provide numerous example configurations. For
pointers to those configurations, see wlmtk(5).
To use WLM:

Step 1. Identify the workloads to run on a given system.

Each workload can consist of one or more applications and multiple

users.

Step 2. Separate the workloads into three types:

• Workloads without goals (shares-based)

• Workloads with CPU usage goals (goal-based)

• Workloads with performance goals (goal-based)

For information on the types of workloads and their associated SLOs, see
“Shares-based SLOs vs goal-based SLOs” on page 118.

Start a WLM configuration file using a text editor. Define your

workloads.

Step 3. For workloads without goals, add shares-based SLOs to your

configuration.

Determine the amount of CPU resources each workload requires so that

you can set appropriate CPU shares requests. One method for
determining CPU needs is illustrated in the example configuration file
“manual_entitlement.wlm” on page 298.

Chapter 4 129
How do I use WLM?
Steps for using WLM

For information on the types of SLOs, see “Shares-based SLOs vs

goal-based SLOs” on page 118.

Step 4. For workloads with CPU usage goals, add goal-based SLOs to your
configuration. For information on usage goals, see “Specifying a goal
(optional)” on page 199.

Step 5. For workloads with performance goals, add goal-based SLOs to your
configuration, as explained in “Configuring WLM for metric-based SLOs”
on page 467.

Step 6. (Optional) Tune the controllers’ behavior.

Consider tuning controllers if your workload performance is not

responding to load changes quickly enough or if workload performance is
erratic.

Step 7. (Optional) For notification of SLO status changes, monitor the WLM
EMS resources.

For information on EMS, see Chapter 10, “Monitoring SLO compliance

and WLM,” on page 343.

Step 8. (Optional) Activate the configuration in passive mode.

WLM operates in “passive mode” when you include the -p option in your
command to activate a configuration. With passive mode, you can see
approximately how a particular configuration is going to affect your
system—without the configuration actually taking control of your
system.

For information on passive mode, including its limitations, see “Passive

mode versus actual WLM management” on page 238.

Activate the WLM file configfile in passive mode as follows:

# wlmd -p -a configfile

To see approximately how the configuration would affect your system,

use the WLM utility wlminfo.

For wlmd syntax information, see “wlmd command syntax” on page 363.

Step 9. Activate the configuration.

130 Chapter 4
 How do I use WLM?
Steps for using WLM

NOTE When you start WLM by using the /sbin/init.d/wlm script, WLM runs in
secure mode by default. However, if you are upgrading WLM and the
/etc/rc.config.d/wlm script had been modified prior to the upgrade, ensure
that the secure mode variables discussed in “Securing WLM
communications” on page 244 are enabled. You also must have set up
security certificates and distributed them to all systems or partitions
being managed by the same WLM global arbiter (wlmpard). HP
recommends using secure mode. If you choose not to use secure mode,
use global arbitration only on trusted local area networks. For
information on securing communications, see the section HOW TO
SECURE COMMUNICATIONS in wlmcert(1M).

Activate your configuration—putting WLM in control of your system’s

resources—as follows:

# wlmd -a -s configfile

To generate audit data (-t) and log statistics (-l all), use the following
command:

# wlmd -t -a -s configfile -l all

Step 10. Monitor SLO compliance.

Using wlmgui or wlminfo with its slo command allows you to monitor
your SLOs.

Also, the WLM EMS monitor makes various status data available to
EMS clients. Check this data to verify SLO compliance.

For more information on this topic, see Chapter 10, “Monitoring SLO
compliance and WLM,” on page 343.

Step 11. Monitor data collectors.

Data collection is a critical link in the effective maintenance of your

configured service-level objectives. When a data collector dies, each SLO
that uses the data from the dead collector is affected. Consequently,
monitor your data collectors so you can be aware when one dies.

When using wlminfo slo, there are two columns that can indicate the
death of a data collector process: State and Concern. For more
information on these columns, see wlminfo(1M).

Chapter 4 131
How do I use WLM?
Steps for using WLM

Alternatively, configure EMS monitoring requests that notify you on the

death of a data collector.

The SLO’s EMS resource:

/applications/wlm/slo_status/SLONAME

changes to:

WLM_SLO_COLLECTOR_DIED (5)

Use the EMS configuration interface (available in the SAM or SMH

“Resource Management” application group) to set up monitoring
requests to watch for this situation. For information about using SMH,
see “Configuring EMS notification” on page 360.

Step 12. (Optional) Configure global arbitration across partitions.

You can set up WLM to automatically move cores between virtual

partitions or nPartitions in response to the service-level objectives of the
workloads in the partitions. The workloads would be specified workloads
inside the partitions or the partitions themselves if you did not define
workloads in the partitions.

NOTE By default, WLM global arbitration runs in secure mode when you use
the /sbin/init.d/wlm script to start WLM. However, if you are upgrading
WLM and the /etc/rc.config.d/wlm script had been modified prior to the
upgrade, ensure that the secure mode variables discussed in “Securing
WLM communications” on page 244 are enabled. You also must have
performed the required steps to set up security certificates and distribute
them. HP recommends using secure mode. If you choose not to use secure
mode, use global arbitration only on trusted local area networks.

For more information on the global arbiter, including its passive mode,
see the chapter Chapter 7, “Managing SLOs across partitions,” on
page 255.

Step 13. (Optional) Set up WLM to automatically start its wlmd and wlmpard
daemons at reboot.

132 Chapter 4
 How do I use WLM?
Reconfiguring WLM

Edit the /etc/rc.config.d/wlm file as explained in the sections “Setting

WLM to start automatically at reboot” on page 242 and “Setting WLM
global arbitration to start automatically at reboot” on page 242. You can
also set variables in /etc/rc.config.d/wlm to start logging statistics and
generating audit data automatically at reboot.

Reconfiguring WLM
To fine-tune an existing configuration, follow these steps:

Step 1. Edit the WLM configuration file.

For information on the configuration file, see Chapter 5, “Configuring

WLM,” on page 135.

Step 2. (Optional) Activate the configuration in passive mode:

# wlmd -p -a configfile

With passive mode, you can see approximately how a particular

configuration is going to affect your system—without the configuration
actually taking control of your system. To see how the configuration
would affect your system, use the WLM utility wlminfo.

For wlmd syntax information, see “wlmd command syntax” on page 363.

Step 3. Activate the configuration:

# wlmd -a configfile

It is not necessary to shut WLM down before activating a new

configuration.

Chapter 4 133
How do I use WLM?
Disabling WLM and its global arbiter

Disabling WLM and its global arbiter

If you want to temporarily return control of your system to the regular
HP-UX resource scheduling, enter the following command to kill the
WLM daemon:
# wlmd -k
After a de-activation, you can restart WLM using the last active
configuration with the command:
# wlmd -A
To prevent WLM from starting automatically at reboot, set the
WLM_ENABLE variable in the file /etc/rc.config.d/wlm to 0:
WLM_ENABLE=0
To stop the WLM global arbiter, enter the command:
# wlmpard -k
You can restart the arbiter using the last configuration with the
command:
# wlmpard -A
To prevent the global arbiter from starting automatically at reboot, set
the WLMPARD_ENABLE variable in the file /etc/rc.config.d/wlm to 0:
WLMPARD_ENABLE=0

134 Chapter 4
5 Configuring WLM

This chapter introduces the WLM configuration file and how to activate
the configuration so that WLM manages the system. It covers the
creation and activation of the WLM configuration file.
The WLM configuration file is the main user interface for controlling
WLM. This file is an ASCII file that you can edit with a text editor.
WLM does not have a default configuration file.

NOTE WLM and PRM have separate configuration files, each with its own
syntax. While WLM and PRM configuration files can define an
equivalent configuration, the files cannot be interchanged. For
information on converting an existing PRM configuration file to a WLM
configuration file, see Appendix G, “Migrating from PRM to WLM,” on
page 465.

A WLM configuration file consists of:

• The version keyword

• The icod_thresh_pri keyword
• The icod_filter_intervals keyword
• The primary_host keyword, discussed in Chapter 7, “Managing
SLOs across partitions,” on page 255
• System-wide settings
• Zero or one prm structures
• slo structures
• tune structures

Chapter 5 135
Configuring WLM
Configuration file syntactic conventions

For information on these items, see the following sections:

• “Specifying the WLM parser version” on page 144

• “Defining the PRM components (optional)” on page 149
• “Defining SLOs” on page 186
• “Tuning the metrics and the SLOs” on page 210

Configuration file syntactic conventions

The following syntactic conventions are used in the WLM configuration
file:

• SLOs, tunables, and PRM information are represented as structures.

You can list these structures in any order.
• A structure is an unordered list of keyword/value pairs.
• Unless otherwise specified, white space is ignored.
• The semicolon character (;) is used as a separator between
keyword/value pairs.
• The equal character (=) is used to separate a keyword from its value.
• Curly brackets ({ and }) are used to delimit the specification of a
structure.
• Some keywords are global and can only be defined outside the scope
of a structure (outside curly brackets).
• Any keyword can appear at most once in a structure.
• The hash character (#) comments out the rest of the line, unless
quoted as part of a name.
• Floating-point numbers cannot be expressed using scientific
(exponent) notation.
• An unquoted number cannot be a name.

136 Chapter 5
 Configuring WLM
Configuration file syntactic conventions

• The names you supply can consist of:

— Uppercase letters (A-Z)

— Lowercase letters (a-z)
— Digits (0-9)
— The underscore character (_)
Do not use an underscore (_) to start the name of a workload
group, an slo structure, or a metric.
— The plus character (+)
— The hyphen character (-)
— The forward slash (/)
Do not use slashes in the names of slo structures or metrics.
— The period (.)
— Quoted characters
Use any printable characters (except white space, <, >, &, ’, ", \,
and =) by enclosing them in double quotes (for example: groups
= “my@group”:2;). You cannot use the slash character (/) in the
names of slo structures or metrics, even when quoted.

Chapter 5 137
Configuring WLM
Using the WLM configuration wizard

Using the WLM configuration wizard

If you prefer not to work directly with a configuration file, use the WLM
Configuration Wizard. Invoke the wizard using the following command:
# /opt/wlm/bin/wlmcw
The wizard does not provide all the functionality available through a
configuration file, but it does greatly simplify the process of creating a
configuration. After creating a configuration file using the wizard, you
can view the file to learn, and become more comfortable with, the syntax
and possibly create more complex configurations.

NOTE Running the wizard requires Java Runtime Environment version 1.4.2
or later and, for PRM-based configurations, PRM C.03.00 or later. (To
take advantage of the latest updates to WLM, use the latest version of
PRM available.)

The following figure shows one of the Wizard’s screens. The left pane
shows the steps the Wizard guides you through.

138 Chapter 5
 Configuring WLM
Using the WLM configuration wizard

Figure 5-1 HP-UX WLM Configuration Wizard

Chapter 5 139
Configuring WLM
Using the WLM GUI

Using the WLM GUI

The WLM graphical user interface, or GUI, allows you to edit existing
configurations and create new ones. You can then deploy the
configurations locally or remotely. The GUI also provides current and
historical data. However, using the GUI does require you to use
configuration file syntax. To configure WLM using the GUI, use the
Modify tab to create a file then go to the Deploy tab to activate the
configuration.
The following is WLM GUI’s initial screen. The GUI has three tabs,
allowing you to monitor your SLOs, modify configurations, and deploy
configurations. For tips on using these tabs, see “Tips on using the WLM
GUI’s tabs” on page 141.

Figure 5-2 HP-UX WLM GUI

140 Chapter 5
 Configuring WLM
Using the WLM GUI

Tips on using the WLM GUI’s tabs

Here are some tips to get you started using the various tabs.

• Monitoring (Monitor tab)

Select a configuration to monitor by:

— Selecting the [Add] button to specify the host running the

configuration you want to monitor
or
— Selecting the [Load] button to load a definition file that you
saved from a previous monitoring session
• Modifying (Modify tab)
The Modify tab allows you to

— Import a configuration that you have been monitoring so that

you can modify it
— Open a configuration file saved on the hard drive of an HP-UX
system
— Create a new configuration
Although you save files in the Deploy tab, you name them in the
Modify tab. Selecting a partition in the left pane changes the top,
right pane to include a Filename field where you name the file. Be
sure to select the [Commit changes] button and then the
[Validate] button for a configuration before you go to the Deploy tab.
• Deploying (Deploy tab)
You deploy a configuration you validated in the Modify tab by:

1. Selecting the [Import] button to bring the configuration into the

Deploy tab
2. Selecting the [Save & Activate] button

Chapter 5 141
Configuring WLM
Using the WLM GUI

Controlling system resources

Using the WLM GUI, configure WLM to control resource allocation as
follows:

1. Select the Modify tab.

2. Import an existing configuration (one that you had been monitoring),
open a configuration file from the disk, or create a new one.
3. Make any desired changes.
4. Select the [Commit changes] button if you have made any
modifications to the configuration.
5. Select the [Validate] button.
6. Select the Deploy tab.
7. Select the [Import] button.
8. Select the [Save & Activate] button.
See the online help for information on using the WLM GUI to accomplish
the following tasks:

• Reserve a portion of a system all the time

• Reserve a portion of a system at specified times
• Reserve a portion of a system based on an event
• Allocate CPU resources as used (set a utilization goal)
• Allocate CPU resources per some metric
• Automatically resize PSETs
• Automatically resize vPars
• Automatically resize nPars
• View the configuration being modified
• Run an application in a certain workload group
• Define your own criteria for workload separation
• Map a secure compartment to a certain workload group
• Monitor the applications (workload groups)
• Monitor WLM operations

142 Chapter 5
 Configuring WLM
Using the WLM GUI

• Start WLM
• Stop WLM
• Try WLM without it taking control of my system

Chapter 5 143
Configuring WLM
Specifying the WLM parser version

Specifying the WLM parser version

Use the optional version keyword at the beginning of your configuration
file to specify which version of the WLM configuration file parser to use
with a particular configuration file.
This keyword is useful when future versions of the parser are not able to
maintain backward-compatibility. However, WLM will be able to parse
all configuration files properly once the correct parser version is known.
By using the version keyword, you are telling WLM which parser to use
for the configuration file.
The default and only valid value is 0:
version = 0;
Specify the version keyword at most once in any configuration, at the
beginning of the configuration file, outside any prm, slo, and tune
structures.

Notification of ‘Instant Capacity needed’ / Pay

per use optimization
Use the optional icod_thresh_pri keyword to request notification of
when Instant Capacity (formerly known as iCOD) or Pay per use (PPU)
reserves could help you meet your SLOs.

NOTE This notification is supported with PPU (v4, v7, or later) and with any
version of Instant Capacity.
If you plan on using Instant Capacity in combination with WLM vPar
management, use vPars A.03.01 or later.

144 Chapter 5
 Configuring WLM
Notification of ‘Instant Capacity needed’ / Pay per use optimization

WLM does not enable Instant Capacity or Pay per use (PPU) reserves. It
merely informs you that the reserves could help you meet your SLOs;
manually activate the reserves if you feel it is appropriate. (Independent
of this keyword though, you can use wlmpard to automate activation of
these reserves.)
To enable notification, use the icod_thresh_pri keyword in your WLM
configuration. This is a global keyword—it should be outside all prm, slo,
and tune structures. The syntax for icod_thresh_pri is:
icod_thresh_pri = integer;
where
icod_thresh_pri
Is an optional keyword. Specifying this keyword allows
you to use an EMS resource to notify you when
Instant Capacity reserves could help meet SLOs.
integer
Is an integer value greater than or equal to 1. If Instant
Capacity reserves exist, they are considered needed
whenever SLOs with a priority from 1 to integer are
failing. If an SLO with a priority in this range is failing,
notification that Instant Capacity reserves are needed
is sent using an EMS resource.
Notification is made through the following EMS resource:
/applications/wlm/icod_reserves_needed
When Instant Capacity reserves are not available or are not required,
the EMS resource is set to:
ICOD_NEEDED_FALSE (0)

Chapter 5 145
Configuring WLM
Notification of ‘Instant Capacity needed’ / Pay per use optimization

When Instant Capacity reserves exist and are needed, the EMS resource
is set to:
ICOD_NEEDED_TRUE (1)
In this case, it may be possible to reduce SLO failures by activating some
Instant Capacity reserves.
When using icod_thresh_pri, you can also use
icod_filter_intervals, another global keyword that must be outside
all prm, slo, and tune structures. The syntax is:
icod_filter_intervals = integer;
where
icod_filter_intervals
Is an optional keyword. It allows you to ignore
short-term fluctuations in the conditions that affect the
EMS resource.
integer
Is an integer value greater than or equal to 1. This
value indicates the number of consecutive WLM
intervals over which Instant Capacity reserves must be
needed before the EMS resource is changed to
ICOD_NEEDED_TRUE. Similarly, it is the number of
intervals over which Instant Capacity reserves are not
required before the EMS resource is changed to
ICOD_NEEDED_FALSE.
For background information on Instant Capacity and PPU, see
“Integrating with Temporary Instant Capacity (TiCAP)/ Pay per use
(PPU)” on page 410.

146 Chapter 5
 Configuring WLM
System-wide settings

System-wide settings
Use one or more of the following keywords outside all structures in your
configuration to set values for the host (typically a virtual partition or
nPartition).
To specify the minimum number of CPU shares a host receives, use the
hmincpu keyword and the following syntax:
hmincpu = min;
where
hmincpu Is an optional keyword.
You cannot specify this keyword in a configuration that
includes a prm structure.
min Is the host’s minimum number of CPU shares. The
value must be an integer between 0 and the host’s
hmaxcpu value, inclusive.
min is out of the total CPU resources, which is 100
multiplied by the number of cores (absolute CPU units
are implied). The default value is 0.
To specify the maximum number of CPU shares a host receives, use the
hmaxcpu keyword and the following syntax:
hmaxcpu = max;
where
hmaxcpu Is an optional keyword.
You cannot specify this keyword in a configuration that
includes a prm structure.
max Is the host’s maximum number of CPU shares. The
value must be an integer between the host’s hmincpu
value and the system’s total CPU resources, inclusive.
Total CPU resources is 100 multiplied by the number of
cores (absolute CPU units are implied).

Chapter 5 147
Configuring WLM
System-wide settings

NOTE For information on the effect of the hmincpu and hmaxcpu keywords in
passive mode, see “Passive mode versus actual WLM management” on
page 238.

The larger a host CPU weight value you assign a host, the more CPU
resources it receives when not enough CPU resources are available to
satisfy all requests at a given priority level. A larger host CPU weight
value also gets a host more CPU resources when all SLOs can be
satisfied and excess CPU resources are available for distribution.
To specify a host’s CPU weight, use the hweight keyword and the
following syntax:
hweight = wt;
where
hweight Is an optional keyword.
You cannot specify this keyword in a configuration that
includes a prm structure.
wt Is the host’s CPU weight. The value must be an integer
greater than or equal to 1. The default weight for a host
is 1.

148 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

Defining the PRM components (optional)

Use a prm structure to define Process Resource Manager, or PRM,
components—excluding the CPU allocations. The CPU allocations are
controlled by WLM, as determined by the entries in the slo structures.

NOTE If you plan on managing only virtual partitions or nPartitions—with no

FSS groups or PSETs inside them, you need not specify a prm structure.
You can go immediately to the section, “Defining SLOs” on page 186.
Likewise, if you plan to run WLM on an HP Integrity Virtual Machines
Host, you can go immediately to the section just indicated. To run WLM
on an Integrity VM Host, WLM must use a strictly host-based
configuration (a configuration for moving cores across nPartitions or
activating Instant Capacity or Pay per use cores). WLM runs inside an
Integrity VM (guest) but will not support Pay per use, vPar, and Instant
Capacity integration. However, an Integrity VM will take advantage of
cores added to the VM host by Pay per use (PPU), Instant Capacity
(iCAP), and Temporary Instant Capacity (TiCAP).

WLM replaces any existing PRM configuration on the system with the
PRM items specified in the prm structure. For example, if a system was
using PRM before starting the WLM daemon, any PRM groups,
application records, user records, and Unix group records defined in
PRM must be defined in this structure as well, or they will not be in force
when WLM takes control of the system.
Defining a prm structure consists of the following tasks:

• Specifying workload groups (optional)

• Assigning users and user access to workload groups (optional)
• Assigning Unix groups to workload groups (optional)
• Assigning applications to workload groups (optional)
• Assigning secure compartments to workload groups (optional)
• Specifying process maps to define your own criteria for workload
separation (optional)
• Specifying disk bandwidth shares (optional)

Chapter 5 149
Configuring WLM
Defining the PRM components (optional)

• Specifying a group’s minimum CPU resources (optional)

• Specifying a group’s maximum CPU resources (optional)
• Weighting a group so it gets more CPU resources (optional)
• Specifying a group’s minimum memory (optional)
• Specifying a group’s maximum memory (optional)
• Weighting a group so it gets more memory (optional)
A prm structure takes the following form:
prm {
groups = { FSS_group_def | PSET_group_def [: LCPU = {ON | OFF} ][, ...];
[ users = user : init_group [alt_group1 alt_group2 ...] [, ...]; ]
[ uxgrp = uxgrp_name : group [, ...]; ]
[ apps = group : application [alt_name1 alt_name2...] [, ...]; ]
[ scomp = compartment : group [, ...]; ]
[ procmap = group : PID_finder [, ...]; ]
[ disks = group : volume ent [, ...]; ]
[ gmincpu = group : min [, ...]; ]
[ gmaxcpu = group : max [, ...]; ]
[ weight = group : wt [, ...]; ]
[ gminmem = group : min [, ...]; ]
[ gmaxmem = group : max [, ...]; ]
[ memweight = group : wt [, ...]; ]

}
where
FSS_group_def has the syntax:
group : group_ID
PSET_group_def has the syntax:
group : PSET

150 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

Here is an example prm structure:

prm {
groups = finance : 2,
sales : 3,
marketing : PSET : LCPU = ON;

users = jdoe : finance,

pdoe : sales,
admin : finance sales marketing;

apps = finance : /bin/dbase “dbase*Finance”,

sales : /bin/dbase “dbase*Sales”;

procmap = finance :
/bin/env/ UNIX95= /bin/ps -C pid_app -o pid=,
sales : /scratch/pidsbyapp salespid_app,
marketing : /scratch/pidsbyapp mrketpid_app;

gmincpu = finance : 20,

sales : 10;

gmaxcpu = sales : 20;

gminmem = finance : 30,

sales : 10,
marketing : 20;

disks = OTHERS : /dev/vg01 1,

finance : /dev/vg01 35,
sales : /dev/vg01 35;

Defining PRM components using the WLM GUI

In addition to defining the PRM components using a text editor, you can
use the WLM Configuration Wizard (/opt/wlm/bin/wlmcw). Alternatively,
you can use the WLM GUI (/opt/wlm/bin/wlmgui). For information on
using the WLM GUI to accomplish various tasks, see its online help.
Running the WLM GUI requires Java Runtime Environment version
1.4.2 or later and, for PRM-based configurations, PRM C.03.00 or later.
(To take advantage of the latest updates to WLM and the GUI, use the
latest version of PRM available.)
The following steps show how to define a workload group using the GUI.

Step 1. Set your DISPLAY environment variable.

Step 2. Start the GUI:

Chapter 5 151
Configuring WLM
Defining the PRM components (optional)

# /opt/wlm/bin/wlmgui

Step 3. Select the Modify tab.

Step 4. Select the [New] button to start a new configuration. The left and right
panes change as shown in the next step.

152 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

Step 5. Select the [Add] button. A new host name appears in the right pane and
in the left pane.

Chapter 5 153
Configuring WLM
Defining the PRM components (optional)

Step 6. Select the name of the new host, wlmhost0 in this case, in the left pane.
The right pane changes, allowing you to set the configuration elements
you would like to see in the new configuration. (The fields listed in the
top of the right pane are used when you want to open an existing
configuration; that is, for “Hostname” you would enter the name of the
host on which the configuration file resides, for “Port” you would enter
the port to use when connecting to the host, and so on.)

Check the “PRM” box in the right pane.

154 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

Step 7. Click “PRM” in the left pane. This changes the right pane to show a
“Workload groups” item. Check the “Workload groups” box.

Chapter 5 155
Configuring WLM
Defining the PRM components (optional)

Step 8. Select the “Workload groups” item in the left pane. The right pane
changes, allowing you to add a group.

156 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

Step 9. Select the [Add group] button. A new dialog appears. Accept the default
(FSS workload group) by selecting the [OK] button.

Chapter 5 157
Configuring WLM
Defining the PRM components (optional)

Step 10. The right pane changes again, with the GUI starting to define a
workload group for you. The GUI fills in the required fields for you,
although you can change the values if you like. Fill in other fields if you
like.

Step 11. Select the [Commit changes] button to save the current configuration
in memory. To save changes to disk, go to the Deploy tab. (The file is
saved to the file specified in the Filename field in the Modify tab when
the system is selected in the left pane.)

The previous steps highlight only one use of the WLM GUI. For
additional information, see the GUI’s online help.

158 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

Specifying workload groups (optional)

A workload group can be one of two types: FSS or PSET.
An FSS group is allocated CPU resources by the Fair Share Scheduler
(FSS) in the HP-UX kernel. WLM can automatically adjust the CPU
allocation for an FSS group based on the group’s progress toward an
SLO. You can define multiple SLOs for a single FSS workload group.
A PSET group is based on a processor set. A PSET group’s CPU
resources are determined by the number of cores assigned to the PSET
group. With PSET groups, you can define one or more slo structures per
group, but it is not required. If a PSET group has an SLO, WLM uses
absolute CPU units. With these units, 100 represents one core. For more
information on absolute CPU units, see the section “Using absolute CPU
units” on page 217.
Processes in either type of group have equal access to the CPU resources
allocated to their group. Within a group, the HP-UX standard scheduler
is used.
Define these groups using the groups keyword. The groups keyword
must appear exactly once in a configuration.
Specify workload group names and their IDs in the prm structure using
the following syntax:
groups = { FSS_group_def | PSET_group_def [: LCPU = {ON | OFF} ]} [, ...];
An FSS_group_def has the following syntax:
group : group_ID
where
group Is the workload group name. Use names that are less
than eight characters long for proper display by the
ps -P command. Do not start the name with an
underscore (_).
The PRM_SYS group is the default group for processes
run by the root user. You can specify PRM_SYS as an
FSS group (group_ID must be 0) and use it with the
apps, user, scomp, or procmap keywords in a prm
structure. You cannot, however, use it with the
gminmem, gmaxmem, or memweight keywords, in an slo
structure, or as a PSET group.

Chapter 5 159
Configuring WLM
Defining the PRM components (optional)

NOTE Use PRM_SYS only as needed. Do not load processes in

PRM_SYS indiscriminately.

The OTHERS group is the default group for users who

are not assigned to groups. It is also the default group
for applications that are not assigned to groups or are
started by users who do not have assigned groups. You
can specify OTHERS as an FSS group (group_ID must be
1), but not as a PSET group. It does not require an slo
structure, but you can create one or more for it if you
wish.
If you specify gminmem, gmaxmem, or memweight for any
group in your configuration, be sure to specify a
gminmem for any group, including OTHERS, for which 1%
of the memory is not sufficient for its users and
applications (or if the tunable extended_shares is
enabled, for which 0.2% of the memory is not
sufficient).
After WLM allocates CPU resources to groups with
SLOs, OTHERS by default receives any remaining CPU
resources. You can change this default with the
distribute_excess tunable, explained in
“Distributing excess CPU resources to your workloads
(optional)” on page 218.
For any other FSS group you define, define an slo
structure that references that group.
group_ID Is the workload group ID. These IDs must be uniquely
assigned integer values from 0 to 63 (inclusive) or 0 to
255 (inclusive) starting with HP-UX 11i v2 Update 2,
as explained in “Refining granularity of CPU (and
memory) allocation by increasing shares per core
(optional)” on page 219. ID 0 is reserved for the
PRM_SYS group. ID 1 is for the user default group
OTHERS. If the PRM_SYS and OTHERS groups are not
specified, they are created automatically.
A PSET_group_def has the syntax:
group : PSET [: LCPU = {ON | OFF} ]

160 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

where
group
Is the workload group name. Use names that are less
than eight characters long for proper display by the
ps -P command. Do not start the name with an
underscore (_).
group cannot be either the PRM_SYS or OTHERS group.

NOTE If you specify gminmem, gmaxmem, or memweight for any

group in your configuration, be sure to specify a
gminmem for any group, including OTHERS, for which 1%
of the memory is not sufficient for its users and
applications (or if the tunable extended_shares is
enabled, for which 0.2% of the memory is not
sufficient).

With PSET groups, you can define one or more slo

structures per group, but it is not required.
PSET
Indicates the group is to be based on a PSET.
LCPU = {ON | OFF}
Specifies the optional logical CPU (Hyper-Threading)
state for cores assigned to the specified PSET-based
group, where:
LCPU = ON Explicitly enables Hyper-Threading.
LCPU = OFF Explicitly disables Hyper-Threading.
The Hyper-Threading feature is available starting with
HP-UX 11i v3 (B.11.31) for processors designed to
support the feature and that have the appropriate
firmware installed. A logical CPU is an execution
thread contained within a core. With Hyper-Threading
enabled, each core can contain multiple logical CPUs.
WLM automatically sets the Hyper-Threading state for
the default PSET to optimize performance. (The default
PSET, also known as PSET 0, is where all FSS groups

Chapter 5 161
Configuring WLM
Defining the PRM components (optional)

reside.) When new PSETs are created, they inherit the

Hyper-Threading state that the system had before
WLM was activated (inheritance is based on the
system state prior to WLM activation because WLM
may change the Hyper-Threading setting for the
default PSET to optimize performance). Cores can be
moved from one partition to another and will take on
the Hyper-Threading state of their destination PSET.
You can modify the Hyper-Threading state of the
system by using the kctune command. For example, to
enable Hyper-Threading on the system, use the
following command:
# kctune lcpu_attr=1
For more information about this command, see
kctune(1M). Do not use this command to modify a
PSET while WLM is running. Whenever possible, use
WLM to control PSETs.
The WLM PSET LCPU keyword enables you to
override the default Hyper-Threading state for cores
assigned to a specific PSET group. The LCPU keyword
is based on an attribute value that can also be
examined and set with the psrset -t command. For
more information about this command, see psrset(1M).
Do not use this command to modify a PSET while WLM
is running. Whenever possible, use WLM to control
PSETs.
The PRM configuration generated by the WLM
configuration file reflects the per-PSET
Hyper-Threading attribute currently specified for the
affected workload groups.

NOTE You can define FSS or PSET-based workload groups and use WLM
partition management (by specifying the primary_host keyword) in the
same WLM configuration. Certain software restrictions apply to using
PSET-based groups with virtual partitions (vPars), Instant Capacity, and
Pay per use. For more information, see the WLM Release Notes
(/opt/wlm/share/doc/Rel_Notes). On HP-UX 11i v1 (B.11.11) systems, you

162 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

must install PSET (PROCSETS) software to obtain PSET functionality;

see the HP-UX WLM Release Notes. PSET functionality comes with
HP-UX 11i v2 (B.11.23) and later.

NOTE It is possible to create a WLM configuration that has more PSET-based

workload groups than the underlying system has cores. However, if all
the groups are active at the same time, some groups will necessarily not
have a core assigned and their processes would be placed in OTHERS.
Furthermore, if there are more PSET-based groups than cores and
transient_groups is not set to 1, the allocation of cores to the
PSET-based groups will never change. As a result, the extra groups do
not add any value as they will never get any cores.

Reserved workload groups

The PRM_SYS workload group (ID 0) is the default workload group for
system processes. It is created automatically, but you can specify it in
your configuration. You cannot however reference PRM_SYS outside a prm
structure. Also, PRM_SYS cannot be created as a PSET group.
The OTHERS workload group (ID 1) is the default workload group for all
nonsystem processes. It is also created automatically, but you can
explicitly specify it in your configuration file if you would like to assign
applications, users, Unix groups, or secure compartments to it or have
WLM manage its resources. If specified, this workload group does not
have to be referenced in an slo structure.
OTHERS cannot be created as a PSET group.
Any workload group name starting with an underscore (_) is reserved for
WLM use.
For information on slo structures, see “Defining SLOs” on page 186.

The default PSET (PSET 0) and FSS groups

With PRM-based configurations, WLM uses processor sets (PSETs) for
allocating dedicated CPU resources to designated applications and users.
At system initialization time, the default PSET is created. The default
PSET, when created at system initialization, consists of all of your
system’s processors. Afterward, the default PSET consists of all the
processors that were not assigned to other PSET groups. All FSS groups
reside in the default PSET, where all FSS group CPU allocation occurs.
The system administrator can create additional PSET groups and assign

Chapter 5 163
Configuring WLM
Defining the PRM components (optional)

processors, applications, and users to those groups. Once processors are

assigned to a PSET workload group, they cannot be used by another
group until a new configuration is loaded.
Applications and users that are assigned to a PSET group have
dedicated CPU resources from the CPU resources assigned to the group.
Competition for CPU resources within the processor set are handled
using the HP-UX time-share scheduler.

Assigning users and user access to workload groups

(optional)
If the server where WLM runs is going to host users, you can specify the
workload groups in which the users’ processes (including their shells)
run. You can also specify any other workload groups the users should be
able to access.
Assign users to workload groups by defining the users keyword in the
prm structure. The users keyword can appear, at most, once in a
configuration.
WLM supports the use of netgroups (network-wide groups) to identify
users. For more information on netgroups, see netgroup(4).
To specify the workload groups to which a user or netgroup member
should be assigned, use the following syntax:
users = user : init_group [alt_group1 alt_group2 ...] [, ...];
where
user Is either an individual user’s login name or a string
that begins with the plus character (+) followed by a
netgroup name, such as +netgroupname. (Netgroups
are defined in the file /etc/netgroup.)
If a netgroup is specified, then at configuration time,
any member of that netgroup who is not listed
individually assumes the init_group and
alt_groupXs that the netgroup is assigned.
WLM ignores any line in /etc/netgroup that has an
empty user field.

164 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

init_group Is the name of the initial workload group for the user or
netgroup. This is the group login chooses when
launching the user’s login shell, and the group cron
chooses when scheduling jobs for that user.
For information on a user’s group placement when the
user belongs to multiple netgroups, see the Process
Resource Manager User’s Guide.
alt_groupX (Optional) Is the name of one of the alternate workload
groups for the user or netgroup. Alternate groups are
groups other than the initial group in which the user or
netgroup members are allowed to run processes.

NOTE A process may start in a workload group other than its assigned group
due to its inheriting the group of the process that started it. However,
WLM will eventually move the process to the workload group specified in
its user record.

When determining the workload group assignment for a process

identified by multiple records, WLM gives highest precedence to
assignments defined in process maps (or to assignments made using the
prmmove or prmrun commands). The precedence given to the various
records that define workload group placement is described in “How the
application manager affects workload group assignments” on page 459.

Assigning Unix groups to workload groups (optional)

When the number of users in an organization or enterprise is
substantial, users might be assigned to Unix groups to simplify
permissions assignments and other management tasks. You can assign
Unix groups to workload groups. Processes whose effective group ID
(GID) matches a Unix group record will run in the associated workload
group. WLM supports Unix group records only if PRM C.03.02 or later is
running on the system.
You can assign a Unix group to one workload group only; however,
multiple Unix groups can be assigned to the same workload group. If a
user should be given access to more than one workload group, it might be
simpler to use the user record instead of the Unix group record to assign
users to workload groups.

Chapter 5 165
Configuring WLM
Defining the PRM components (optional)

Place Unix groups in workload groups by defining the uxgrp keyword in

the prm structure. The uxgrp keyword can appear, at most, once in a
configuration.
To assign Unix groups to workload groups, use the following syntax:
uxgrp = uxgrp_name : group [, ... ];
where
uxgrp_name
Is the name of a Unix group.
group
Is the name of the workload group in which the Unix
group should be placed. A Unix group can be assigned
to one workload group only.

NOTE A process may start in a workload group other than its assigned group
due to its inheriting the group of the process that started it. However,
WLM will eventually move the process to the workload group specified in
its Unix group record.

When determining the workload group assignment for a process

identified by multiple records, WLM gives highest precedence to
assignments defined in process maps (or to assignments made using the
prmmove or prmrun commands). The precedence given to the various
records that define workload group placement is described in “How the
application manager affects workload group assignments” on page 459.

Assigning applications to workload groups (optional)

Each workload group defines a workload. You can optionally assign one
or more applications to a workload group using the apps keyword.
However, because you can place applications in workload groups using
prmrun and prmmove, you are not required to assign applications to
workload groups with the apps keyword.

166 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

NOTE The system is polled every 30 seconds to ensure that processes are
running in the appropriate workload groups. If a process forks child
processes and immediately exits, the polling will likely miss the parent
process. As a result, the parent process is never placed in its workload
group. When the child processes are found during polling, WLM will not
be able to determine the parent of the processes. Then, instead of being
placed in the parent’s assigned group, the child processes are placed in
the group of the invoking user or in the OTHERS group. To avoid this
condition, be sure parent processes exist for at least 30 seconds (the
default polling interval). In various shells, you can use the wait
command in a script to prevent the process from exiting immediately.
(Placement of a process family can take up to two polling intervals: The
parent process is moved to its assigned group in the first interval, while
the child processes are moved to the group in the second interval.)

The apps keyword can appear, at most, once in a configuration.

Assign applications to workload groups in the prm structure using the
following syntax:
apps = group : application [alt_name1 alt_name2...] [, ... ];
where
group
Is the name of the workload group in which the
application should run.
application
Is the full path of the application, starting with a
slash (/). The pathname must be to a binary or
shell/interpreter.
You can use wildcards ([, ], ?, *) to specify the file
name, but not the directory name. If you use wildcards
in a file name, enclose the full pathname in quotes. For
information on wildcards, see the PATTERN
MATCHING NOTATION section in regexp(5).

Chapter 5 167
Configuring WLM
Defining the PRM components (optional)

If you specify an application file name using wildcard

characters, all valid executables—without explicit
application records—that match the pattern assume
the group for the application.
For information on how to specify scripts in an apps
statement, see the “Script example” on page 169.
alt_nameX
(Optional) Is an alternate name the application is
assigned when executed. This is common for complex
programs such as database programs that launch
many processes and rename them. It is also common
for shells and interpreters used in scripts; the names of
the scripts are considered alternate names.
Using alternate names, you can place the various
processes of a single application in different workload
groups.
Wildcards ([, ], ?, *) can be used when specifying
alternate names. If using wildcards, enclose the
alternate name in quotes. For information on
wildcards, see the PATTERN MATCHING NOTATION
section in regexp(5).
You can also use an Extended Regular Expression, or
ERE, as the alternate name in an application record.
(For more information, refer to the EXTENDED
REGULAR EXPRESSION section in regexp(5)). If you
do so, the ERE should be the only alternate name in
the record, and it should be within single quotes. For
an example using an ERE with the alternate name in
an application record, see “Renamed application
example” on page 170.
Other records can still have non-ERE alternate names
for the same application. For information on pattern
matching for alternate names, see “Pattern matching
for renamed application processes” on page 457.

168 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

If alt_nameX is not specified for an application, that

application’s group assignment is used for all processes
with a file ID that matches the file ID of application.
(The file ID is based on the file system device and the
inode number.)
For an example showing how to specify scripts in an
apps statement, see the “Script example” on page 169.
For an example showing how to specify an application
that renames itself, see the “Renamed application
example” on page 170. This section also includes an
example using an Extended Regular Expression.

NOTE Beginning with WLM A.03.01, you can use wildcards in both the file
name and the alternate name in a single application record.

NOTE A process may start in a workload group other than its assigned group
due to its inheriting the group of the process that started it. However,
WLM will eventually move the process to the workload group specified in
its application record.

When determining the workload group assignment for a process

identified by multiple records, WLM gives highest precedence to
assignments defined in process maps (or to assignments made using the
prmmove or prmrun commands). The precedence given to the various
records that define workload group placement is described in “How the
application manager affects workload group assignments” on page 459.

Script example
To place a script in a workload group using an apps statement:

Step 1. Specify the full path of the shell or interpreter used in the script as the
application.

Step 2. Specify the name of the script (just the name—no path) as the alt_name.

Chapter 5 169
Configuring WLM
Defining the PRM components (optional)

NOTE Because the full pathname is not required for the script, a rogue user can
get access to workload groups—that would otherwise not be
accessible—by using the name of the script for new scripts or wrappers.

Step 3. Ensure the shell or interpreter is listed in either /etc/shells or

/opt/prm/shells.

For example, for a perl script named myscript.pl and using

/opt/perl/bin/perl, the apps statement to place the script in group
scripts_grp would be:
apps = scripts_grp : /opt/perl/bin/perl myscript.pl;

Renamed application example

To place a renamed application in a workload group using an apps
statement:

Step 1. Specify the full path of the application as the application.

Step 2. Specify the new name the application takes once it is running as the
alt_name.

For example, here is an apps statement for an Oracle database with two
instances:
apps = Finance : /opt/oracle/bin/oracle "ora*Finance",
Sales : /opt/oracle/bin/oracle "ora*Sales";
The Oracle database executable is the same in both cases; however, the
alternate names specify different patterns to match. (Given the use of
wildcards, the alternate names are quoted.) The patterns are based on
the instance names. Consequently, processes starting with “ora” and
ending with “Finance” are placed in the Finance workload group.
Similarly, processes matching the pattern “ora*Sales” go into the
workload group Sales.
The following is an apps statement using an ERE with the alternate
name field:
apps = Finance_Sales : /opt/oracle/bin/oracle 'ora.*(Finance|Sales)';
The ERE expression is enclosed in single quotes. Any processes
beginning with the string “ora” followed by any strings that include
“Finance” or “Sales” are placed in the workload group Finance_Sales.

170 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

Assigning secure compartments to workload groups

(optional)
The HP-UX feature Security Containment, available starting with
HP-UX 11i v2, allows you to create secure compartments, which provide
file and process isolation. You can place one or more secure
compartments in a single workload group. After creating your secure
compartments, you can place them in workload groups using the scomp
keyword.
The scomp keyword can appear, at most, once in a configuration.
Assign secure compartments to workload groups using the following
syntax in the prm structure:
scomp = compartment : group [, ... ];
where
compartment
Is the name of a secure compartment you have already
created using Security Containment or the
/opt/prm/bin/srpgen utility.
group
Is the name of the workload group in which
compartment should be placed.

NOTE A process may start in a workload group other than its assigned group
because it inherits the group of the process that started it. However,
WLM will eventually move the process to the workload group specified in
its compartment record.

When determining the workload group assignment for a process

identified by multiple records, WLM gives highest precedence to
assignments defined in process maps (or to assignments made using the
prmmove or prmrun commands). The precedence given to the various
records that define workload group placement is described in “How the
application manager affects workload group assignments” on page 459.

Chapter 5 171
Configuring WLM
Defining the PRM components (optional)

Specifying process maps to define your own criteria

for workload separation (optional)
You can define process maps that specify your own criteria for placing
application processes in workload groups. Define process maps with the
procmap keyword. Criteria defined in this manner supercede WLM’s
default criteria defined by the users, uxgrps, apps, and scomp
keywords).
The procmap keyword can appear, at most, once in a configuration.
Use your own criteria to assign processes to workload groups in the prm
structure using the following syntax:
procmap = group : PID_finder [, ... ];
where
group
Is the name of the workload group in which the
processes defined by PID_finder should run.
PID_finder
Is the absolute path to a script or command and its
arguments that gathers and outputs the process
identifiers (PIDs) for processes that are to be placed in
group. The command line can specify, for example, a ps
command, Oracle script, or SAP script. To separate
arguments in the command line, use white space. Use
double quotes to form single arguments to an option or
when using special characters such as commas,
semicolons, and pound (#) characters.
The expected output is a list of PIDs, separated either
by a space or newline delimiter. WLM gathers the
PID_finder stdout and places the processes in the
group in the order defined by PID_finder. Any stderr
is ignored. Note that processes invoked by PID_finder
run in PRM_SYS by default.
The command or script is spawned periodically, at the
interval defined by the application manager's current
polling interval (by default, 30 seconds). Ensure that
the operation completes in a short time relative to this
interval.

172 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

You can specify more than one PID_finder for a group,

but specify each PID_finder in a separate group :
PID_finder statement.
Wildcards specified in the string are not expanded.

NOTE The PID_finder is a single command. Pipes are not

directly supported unles embedded in a shell command.
See the third example in “PID finder examples” on
page 173.

For information on how to specify PID_finder scripts

or commands in a procmap statement, see the “PID
finder examples” on page 173.

NOTE A process may start in a workload group other than its assigned group
due to its inheriting the group of the process that started it. However,
WLM will eventually move the process to the workload group specified in
its process map.
If a PID is specified by multiple PID_finder scripts or commands, the
process’s assignment might change from group to group with each
successive spawning of the PID_finder.

Process maps take precedence over WLM’s standard criteria for process
placement (compartment, application, user, and Unix group records).
The precedence given to the various records that define workload group
placement is described in “How the application manager affects
workload group assignments” on page 459.

PID finder examples

To follow are examples showing three different ways of specifying
PID_finder, from the most desirable method to the least. All three
specifications provide similar functionality.

1. Run the ps command in an appropriate environment to gather PIDs

matching the application pid_app. This method of specifying
PID_finder is the best because it does not mask the functionality
and does not fork additional shells.

Chapter 5 173
Configuring WLM
Defining the PRM components (optional)

procmap = sales : /bin/env UNIX95= /bin/ps -C pid_app -o pid=;

2. Gather PIDs inside an external script named pidsbyapp. This is less
desirable than the previous example because it masks the
functionality of what is being run; however, you might find this
method more useful because it facilitates specifying multiple or
complex PID selection criteria.
procmap = sales : /scratch/pidsbyapp pid_app;
3. Run a ps command with a pipe within a shell. This is least desirable
because it spawns multiple shells.
procmap = sales : /usr/bin/sh -c "ps -efxP | grep pid_app | awk '{print $3}'";

Specifying disk bandwidth shares (optional)

NOTE To take advantage of disk bandwidth shares, your disks must be

mounted and under the control of Logical Volume Manager (LVM). For
information on LVM, see “Management of disk bandwidth” on page 452.

WLM does not dynamically allocate disk bandwidth shares to workload

groups. To ensure that a workload receives a sufficient amount of
bandwidth, assign the workload’s group a bandwidth share using the
disks keyword.
The disks keyword can appear, at most, once in a configuration.
If you want to use disk bandwidth shares, then for each FSS group
specified using the groups keyword, assign the group a disk bandwidth
share using the disks keyword. In other words, there must be a
one-to-one correspondence between the defined FSS groups and the
groups that receive disk bandwidth shares.

NOTE If you use the disks keyword, you must explicitly create the OTHERS
workload group and assign it a disk bandwidth share.

Specify disk bandwidth shares for logical volume groups in the prm
structure using the following syntax:
disks = group : volume shares [, ...];

174 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

where
group Is the workload group name.
You cannot specify a PSET group in a disks statement.
volume Names a logical volume group. volume must begin with
/dev/v to be recognized.
shares Is an integer value greater than or equal to 0. shares
translates to a percentage of the disk bandwidth when
dividing it by the number of disk bandwidth shares
assigned to all the workload groups for the given
volume group.
If one FSS workload group has disk shares for a volume
group, then all FSS workload groups must have disk
shares for that volume group.
Here is an example disks statement:
disks = OTHERS : /dev/vg01 1,
finance : /dev/vg01 35,
sales : /dev/vg01 35,
marketing : /dev/vg01 29;

Specifying a group’s minimum CPU resources

(optional)
You can assign workload groups a minimum number of CPU shares. This
minimum is a hard lower limit (assuming the sum of the gmincpu values
is less than or equal to the total CPU resources); the group receives less
than this minimum only if it has no active SLOs and transient_groups
is set to 1. (However, if the group is associated with a process map, it
remains active and continues to receive the minimum shares even if it
has no active SLOs.) This hard limit is different from the mincpu value in
slo structures, which merely specifies the minimum CPU request the
SLO controller can make.
To specify the minimum number of CPU shares a group receives, use the
gmincpu keyword in the prm structure, according to the following syntax:
gmincpu = group : min [, ...];
where
group Is the workload group name.

Chapter 5 175
Configuring WLM
Defining the PRM components (optional)

min Is group’s minimum number of CPU shares. The value

must be an integer between 0 and the group’s gmaxcpu
value, inclusive.
min is out of the total CPU resources, which is 100
multiplied by the number of cores (if you set the
tunable absolute_cpu_units to 1 or it is implied by
other elements in your configuration)—or just 100 by
default.
To have a minimum of 2 cores on an 8-core system with
absolute_cpu_units enabled
(absolute_cpu_units = 1), you would specify:
gmincpu = 200;
If you specify a min greater than the total CPU
resources, WLM treats it as equal to the total CPU
resources.
By default, the implicit minimum CPU allocation for
an FSS group is 1% of the total CPU resources in the
default PSET; if the tunable extended_shares is set to
1, the minimum is 0.2% (with incremental allocations
of 0.1%). The implicit minimum allocation for a PSET
group is one core. (If the transient_groups keyword
is set to 1, some FSS groups may be deleted
temporarily and therefore use no resources during that
time. The implicit minimum CPU allocation for PSET
groups becomes 0. However, groups associated with
process maps are not deleted even if the groups are
associated with inactive SLOs.)
If you specify a min value that is less than the
minimum CPU allocation, the group receives the
implicit minimum. For example, with
absolute_cpu_units enabled and extended_shares
disabled in the WLM configuration on an 8-core system
with no PSETs, the system’s total CPU resources can
be divided into 800 shares (100 for each core). A min
value of 7 would be less than 1%, so WLM would
automatically allocate at least 8 shares of CPU
resources to the group.

176 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

With extended_shares enabled in this scenario, the

minimum allocation value would be 6.4 or 7.2, which
are the two nearest multiples of .8.
For more information on absolute CPU units, see the
section “Using absolute CPU units” on page 217.
If the sum of all the gmincpu values is greater than the
system’s total CPU resources, the values are treated as
CPU resource requests that are to be met before any
other requests are considered. weight values do apply.
When configuring WLM on a partition, be sure to select
a value for min that makes sense in terms of the limits
placed on the partition when it was created—namely
its minimum and maximum number of CPU resources
(cores).

NOTE For information on the effect of this keyword in passive mode, see
“Passive mode versus actual WLM management” on page 238.

Specifying a group’s maximum CPU resources

(optional)
You can assign workload groups a maximum number of CPU shares.
This maximum is a hard upper limit; the group will never receive more
than this maximum, as opposed to the maxcpu value in slo structures,
which merely specifies the maximum CPU request the SLO controller
can make. (The OTHERS group may receive more than its maximum if
other groups have received their maximum CPU resources and there are
still CPU resources left.)
To specify the maximum number of CPU shares a group receives, use the
gmaxcpu keyword in the prm structure, according to the following syntax:
gmaxcpu = group : max [, ...];
where
group Is the workload group name.

Chapter 5 177
Configuring WLM
Defining the PRM components (optional)

max Is group’s maximum number of CPU shares. The value

must be an integer greater than or equal to the group’s
gmincpu value.
max is out of the total CPU resources, which is 100
multiplied by the number of cores (if you set the
tunable absolute_cpu_units to 1 or it is implied by
other elements in your configuration)—or just 100 by
default.
If you specify a max greater than the total CPU
resources, WLM treats it as equal to the total CPU
resources.
To have a maximum of 4 cores on an 8-core system with
absolute_cpu_units enabled
(absolute_cpu_units = 1), you would specify:
gmaxcpu = 400;
For more information on absolute CPU units, see the
section “Using absolute CPU units” on page 217.
There is no default gmaxcpu value for a group. If you do
not specify a gmaxcpu value, WLM takes the system’s
total CPU resources, in shares, as the gmaxcpu value.
When configuring WLM on a partition, be sure to select
a value for max that makes sense in terms of the limits
placed on the partition when it was created—namely
its minimum and maximum number of CPU resources.

NOTE For information on the effect of this keyword in passive mode, see
“Passive mode versus actual WLM management” on page 238.

Weighting a group so it gets more CPU resources

(optional)
The larger a CPU weight value you assign a group, the more CPU
resources it receives when not enough CPU resources are available to
satisfy all requests at a given priority level. A larger weight value also
gets a group more CPU resources when all SLOs can be satisfied and
excess CPU resources are available for distribution. To enable these

178 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

extra CPU resources to go to your workload groups, set the

distribute_excess tunable in your configuration file. This tunable is
described in the section “Distributing excess CPU resources to your
workloads (optional)” on page 218. If you do not set this tunable, all the
excess CPU resources go to the default workload group OTHERS.
To specify a group’s CPU weight, use the weight keyword in the prm
structure, according to the following syntax:
weight = group : wt [, ...];
where
group Is the workload group name.
wt Is group’s CPU weight. The value must be an integer
greater than or equal to 1. The default weight for a
group is 1.

NOTE Weighting a group is beneficial only if the group is going to have an

active SLO.

When resources are insufficient to satisfy a demand at a given priority,

WLM uses weighting to determine how to distribute CPU resources
among the requests at that priority. WLM attempts to allocate resources
so that the weight-to-allocation ratio is the same for all the groups.
However, to determine the CPU allocations, WLM first observes the
following constraints:

• A group’s CPU allocation must not exceed the SLO request unless all
SLOs at the same priority are satisfied.
• Any CPU allocation mandated by a group’s higher-priority SLO is
always retained (it is never reduced to achieve a weight-to-allocation
ratio that equals that of the other groups at the same priority level,
as sought under normal circumstances).
This policy for determining allocations also applies to CPU demand that
is not a direct result of a prioritized SLO, such as gmincpu values and
distribution of excess (when the distribute_excess tunable is set). The
ultimate consequence of this policy is that, in the absence of other SLO
requests, two requests at the same priority level that are not fully
satisfied will have the same ratio between their respective allocations as

Chapter 5 179
Configuring WLM
Defining the PRM components (optional)

between their respective weights (in other words, the ratio of group A’s
allocation to group B’s allocation equals the ratio of group A’s weight to
group B’s weight).

NOTE WLM uses this same policy for using weight to determine CPU
allocations across partitions. For more information on how WLM
manages CPU allocations across partitions, see Chapter 7, “Managing
SLOs across partitions,” on page 255.

Consider the following example. The Allocation column represents the

allocations resulting from higher priority levels. The Requested
allocation column represents the allocations the SLOs at the current
priority are requesting.
In this example, 40 CPU shares (or 40% of the total CPU resources) are
allocated to the groups listed in column 1. Thus, WLM has 60% of the
CPU resources to distribute among groups. WLM takes this amount of
CPU resources and begins allocating it according to the weights.
Table 5-1 weight keyword example (weights take effect)

Requested Final
Group Allocation Weight
allocation allocation

A 10 5 15 15

B 20 2 60 20

C 10 5 70 25

OTHERS 0 8 80 40

The sum of the weights assigned to the groups is 20. Groups A and C both
have equal weights (5) and allocations (10). Therefore, WLM attempts to
allocate 25% (5/20) of the total CPU resources to these groups. This
translates to 15 additional CPU shares each. Similarly, groups B and
OTHERS, with weights of 2 and 8 respectively, should get 10% (2/20) and
40% (8/20) of the total CPU resources.
However, before distributing the CPU resources, WLM must observe the
policy mentioned previously. Group B already has more shares than it is
entitled to—it has 20% of the CPU allocation while its weight is only 10%
(2/20) of the total weight. Consequently, B gets no more CPU resources.

180 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

Recall that WLM attempts to equally satisfy all SLOs at a given priority
by allocating CPU in the same weight-to-allocation ratio. With B
satisfied, we focus on groups A, C, and OTHERS. The weight-to-allocation
ratio for A and C is 5/10, or 1/2. The ratio for OTHERS is undefined because
it currently has no allocation. Consequently, WLM first allocates shares
to OTHERS to bring its weight-to-allocation ratio in line with the ratios of
A and C. To match the ratio of 1/2, WLM grants OTHERS 16 shares so that
its ratio is 8/16, or 1/2, as well.
This leaves 44 excess shares for groups A and C. WLM allocates 5 each to
groups A and C, then another 8 to OTHERS to maintain the
weight-to-allocation ratio. At this point, both A and B have 15 shares each
and OTHERS has 24 shares. Group A’s SLO request is now satisfied. So,
group A will not be allocated more shares until the other SLO requests
are fulfilled.
Because the CPU allocations for groups C and OTHERS remain less than
their requested allocations, WLM will attempt to allocate more CPU
resources to these two groups. WLM allocates the remaining 26 shares to
groups C and OTHERS based on their weights. Thus, C gets an additional
10 and OTHERS gets 16 for a total of 25 and 40 shares, respectively.

Interaction between weight and distribute_excess

Now consider how the weight keyword and the distribute_excess
tunable interact. When set, the distribute_excess tunable causes
excess CPU resources to go to the workload groups you define, as
opposed to the default workload group OTHERS. In our example in
Table 5-1 in the previous section, there is not enough CPU resources to
satisfy all the requests. As such, there are no extra CPU resources to
distribute—and specifying distribute_excess would not affect the
outcome.
Consider the example in Table 5-2. The requested allocation for each
group is 20, and there are no allocations from SLOs at higher priorities.
Based on the weights, the allocations would be 50, 25, and 25 for A, B,
and C, respectively. However, whenever the weight-based allocations are

Chapter 5 181
Configuring WLM
Defining the PRM components (optional)

larger than the requests, the requests are used first. Thus, A, B, and C all
receive a CPU allocation of 20. That leaves 40% of the CPU resources
unallocated. With distribute_excess not set, all 40% goes to OTHERS.
Table 5-2 weight example with distribute_excess = 0 (off)

Requested Final
Group Weight
allocation allocation

A 2 20 20

B 1 20 20

C 1 20 20

OTHERS 1 (default) 1 (default) 40

Table 5-3 shows the same example, but with distribute_excess set.
(This discussion assumes extended_shares is not set.) Again, A, B, and
C all receive a CPU allocation of 20, leaving 40% of the CPU unallocated.
This time though, distribute_excess is set. Consequently, the
remaining 40% (less the 1% default to OTHERS) goes to A, B, and C—based
on their weights. Dividing the weight of A (2), by the sum of the weights
(4), A gets 50% of the total CPU resources, while B and C get 25%. WLM
removes 1% from B to give to OTHERS so that it maintains the minimum
CPU percentage required for all groups.
Table 5-3 weight example with distribute_excess = 1 (on)

Requested Final
Group Weight
allocation allocation

A 2 20 50

B 1 20 24

C 1 20 25

OTHERS 1 (default) 1 (default) 1

182 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

Specifying a group’s minimum memory (optional)

You can assign workload groups a minimum percentage of the system’s
memory. This minimum is a hard lower limit; the workload group
receives less than this minimum only if it has no active SLOs, is not
associated with a process map, and transient_groups is set to 1.

NOTE When specifying a workload group’s minimum memory, be very careful of

resource interactions, which are explained in “How resource allocations
interact” on page 453. In particular, be sure the workload groups get the
memory they need. (When setting values for gminmem, gmaxmem, and
gmemweight, ensure that the groups get sufficient memory even when all
groups are active.)

To specify the minimum percentage a group receives, use the gminmem

keyword in the prm structure, according to the following syntax:
gminmem = group : min [, ...];
where
group Is the workload group name.
If you specify gminmem, gmaxmem, or memweight for any
group in your configuration, be sure to specify a
gminmem for any group, including OTHERS, for which 1%
of the memory is not sufficient for its users and
applications (if the tunable extended_shares is set to
1, specify a gminmem for which 0.2% of the memory is
not sufficient).
You cannot specify the PRM_SYS group in a gminmem
statement.
min Is group’s minimum percentage of memory. The value
must be an integer between 1 and the group’s gmaxmem
value, inclusive.
The default min value is 1.

Chapter 5 183
Configuring WLM
Defining the PRM components (optional)

Specifying a group’s maximum memory (optional)

You can assign workload groups a maximum percentage of memory. This
maximum is a hard upper limit, except for the OTHERS group. (The
OTHERS group may receive more than its gmaxmem if all other groups have
received their gmaxmem and there is still memory left.)

NOTE When specifying a workload group’s maximum memory, be very careful

of resource interactions, which are explained in “How resource
allocations interact” on page 453. In particular, be sure the workload
groups get the memory they need. (When setting values for gminmem,
gmaxmem, and gmemweight, ensure that the groups get sufficient memory
even when all groups are active.)

To specify the maximum percentage of memory a group receives, use the

gmaxmem keyword in the prm structure, according to the following syntax:
gmaxmem = group : max [, ...];
where
group Is the workload group name.
You cannot specify the PRM_SYS group in a gmaxmem
statement.
max Is group’s maximum percentage of memory. The value
must be an integer between the group’s gminmem value
and 100, inclusive.
The default max value is 100.

Weighting a group so it gets more memory (optional)

The larger a memory weight value you assign a group, the more memory
it receives when there is not enough memory to satisfy all gmaxmem
requests.
To specify a group’s memory weight, use the memweight keyword in the
prm structure, according to the following syntax:
memweight = group : wt [, ...];
where

184 Chapter 5
 Configuring WLM
Defining the PRM components (optional)

group Is the workload group name.

You cannot specify the PRM_SYS group in a memweight
statement.
wt Is group’s memory weight. The value must be an
integer greater than or equal to 1. If you do not specify
a memory weight, WLM uses the group’s CPU weight,
which defaults to 1 if not specified.

NOTE Assigning a memweight to a PSET workload group is not useful because

WLM grants the group memory when the configuration is activated, but
never adjusts its memory allocation.

Consider the following example. We have four groups, with one being a
PSET group. The gminmem serves as an allocation for the groups because
each group gets the amount of memory represented by its gminmem value.
Table 5-4 memweight example

Allocation Final
Group Weight
(gminmem) allocation

A (PSET) 10 Unspecified 10

B 30 3 42

C 20 2 28

OTHERS 20 1 20

First, A gets its gminmem because it is a PSET group. That leaves 90% of
the memory to distribute. Next, OTHERS is granted its memory. It has a
memweight of 1, and the sum of the memweight values is 6. As a result,
OTHERS gets 1/6 * 90, or 15%. However, 15 is less than its gminmem, so it
gets its gminmem of 20 instead. Now there is 70% left. However, WLM
guarantees the gminmem for the groups B and C, 30 and 20 respectively.
So, there is only 20% to distribute between the two groups B and C. This
20% is distributed so that the groups’ final allocations are proportional to
their weights.

Chapter 5 185
Configuring WLM
Defining SLOs

Defining SLOs
Use slo structures to specify your service-level objectives and assign
priorities to those objectives.
You define slo structures for a host partition or based on the workload
groups you defined in the prm structure. For information on specifying
the prm structure, see “Defining the PRM components (optional)” on
page 149.
Defining an slo structure consists of the following tasks:

• Specifying the SLO name (required)

• Specifying the priority (required)
• Specifying the workload group to which the SLO applies (optional)
• Specifying the lower and upper bound requests on CPU resources
(optional)
• Specifying a goal (optional)
• Specifying a fixed or additive allocation of CPU shares (optional)
• Specifying a shares-per-metric allocation request (optional)
• Specifying when the SLO is active (optional)
An slo structure can take one of two forms. Both forms require a
priority. The first form may or may not have a goal.
slo slo_name {
pri = priority;
[ entity = PRM group group_name; ]
[ mincpu = lower_bound_request; ]
[ maxcpu = upper_bound_request; ]
[ goal = goal_expression; ]
[ condition = condition_expression; ]
[ exception = exception_expression; ]
}
The second form of an slo structure uses the cpushares statement. This
statement cannot be used with a goal statement.
slo slo_name {
pri = priority;
[ entity = PRM group group_name; ]

186 Chapter 5
 Configuring WLM
Defining SLOs

[ mincpu = lower_bound_request; ]
[ maxcpu = upper_bound_request; ]
cpushares = value { more | total } [ per metric met [ plus offset ] ];
[ condition = condition_expression; ]
[ exception = exception_expression; ]
}
Here are several example slo structures:
slo buying {
pri = 1;
mincpu = 50;
maxcpu = 200;
goal = metric stock_price_1 < 50;
condition = 09:00 - 16:00;
exception = Sat - Sun;
}

slo selling {
pri = 1;
mincpu = 50;
maxcpu = 300;
goal = metric stock_price_2 > 75;
condition = 09:00 - 16:00;
exception = Sat - Sun;
}

Defining SLOs using the WLM GUI

In addition to defining an SLO using a text editor, you can use the WLM
Configuration Wizard (/opt/wlm/bin/wlmcw). Alternatively, you can use
the WLM GUI (/opt/wlm/bin/wlmgui).
The following steps show how to define an SLO with a usage goal for an
existing workload group using the GUI. It is assumed you went through
the procedure on in the section “Defining PRM components using the
WLM GUI” on page 151 to create a workload group. For more
information on using the WLM GUI, see its online help.

Step 1. Select the name of the host, wlmhost0 in this case, in the left pane. The
right pane allows you to set the type of configuration elements you would
like to see in the new configuration.

Chapter 5 187
Configuring WLM
Defining SLOs

Select the “Service-level Objectives (SLOs)” box in the right pane.

188 Chapter 5
 Configuring WLM
Defining SLOs

Step 2. Select the “Service-level objectives” item in the left pane.

Chapter 5 189
Configuring WLM
Defining SLOs

Step 3. Select the [Add SLO] button. A new dialog appears. The default option
is “Varies with the group’s usage”. This option is the usage goal. Select
the [OK] button.

190 Chapter 5
 Configuring WLM
Defining SLOs

Step 4. The right pane changes, allowing you to define the SLO. The goal field
defines the usage goal.

Chapter 5 191
Configuring WLM
Defining SLOs

Step 5. Fill in the fields as desired.

Step 6. Select the [Commit changes] button to save the current configuration
in memory. To save changes to disk, go to the Deploy tab. (The file is
saved to the file specified in the file name field in the Modify tab when
the system is selected in the left pane.)

The previous steps highlight only one use of the WLM GUI. For
additional information, see the GUI’s online help.

Specifying the SLO name (required)

The SLO name can consist of the following characters:

• Uppercase letters (A-Z)

• Lowercase letters (a-z)
• Digits (0-9)

192 Chapter 5
 Configuring WLM
Defining SLOs

• The underscore character (_), as long as it is not the first character

• The hyphen character (-)
• The period (.)
• Quoted characters
Any characters not listed here (except the double quote) can be used
as long as they are enclosed in double quotes. The slash character (/)
is not allowed, even when quoted.
The SLO name cannot exceed 216 characters.

Specifying the priority (required)

WLM uses SLO priorities to determine CPU allocation when the
combined CPU resource requests of all SLOs exceed 100%. In these
cases, SLOs with higher priorities (priorities closer to 1) are granted
CPU resources first. Use the pri keyword to assign priorities.
The pri keyword is required.
Specify an SLO’s priority using the following syntax:
pri = priority;
where
priority Is an integer greater than or equal to 1. The value of 1
is highest priority.
If there are any CPU resources remaining after WLM has met all the
requests, the remainder is given to the OTHERS group by default. You can
ensure that this remainder is given to more critical workloads by using
stretch goals—assigning a high and a low priority to each workload and
setting the low priority SLO to be more aggressive than the high priority
SLO. Consequently, the low priority SLOs seek out the excess CPU
resources. For more information on stretch goals, see “Goals vs stretch
goals” on page 203.
Table 5-5 illustrates the idea.
Table 5-5 Capturing remaining CPU resources with stretch goals

Workload SLO priority

Sales 1

Chapter 5 193
Configuring WLM
Defining SLOs

Table 5-5 Capturing remaining CPU resources with stretch goals

Workload SLO priority

Finance 2

Finance 3

Sales 4

Sales and Finance are the only workloads in the configuration. After
the priority 1 and 2 SLOs are met, the remaining CPU resources go to
Finance. If there are any CPU resources left at that point, it goes to
Sales.
You can also use any remaining CPU resources by setting the
distribute_excess tunable, as explained in the section “Distributing
excess CPU resources to your workloads (optional)” on page 218.
You can assign multiple slo structures the same priority. However, if all
the SLOs have the same priority and there are not enough resources,
some or all of the SLOs will not be met consistently. Thus, determine
which SLOs must be met and assign priorities accordingly.
Consider the following example which has two workloads, where both
have SLOs at the same priority. Fortunately, the server has the resources
to meet both workloads’ goals, as shown in Figure 5-3.

Figure 5-3 Workloads with SLOs at same priority

Accounts payable (AP)
Response time in seconds

4 Accounts receivable (AR)

2 AP goal

1 AR goal

Number of transactions

194 Chapter 5
 Configuring WLM
Defining SLOs

Now add a third workload named Payroll with an SLO at the same
priority as those for the other workloads. This workload’s SLO is to
calculate each employee’s overtime, commissions, bonuses, taxes, and
total pay in less than 0.5 seconds. The system is now overloaded and
cannot meet each SLO.
Because each SLO has the same priority, WLM cannot allocate enough
resources to any one workload to help it achieve its SLO. Consequently,
no SLO is met, as shown in Figure 5-4.

Figure 5-4 Additional workload with same priority SLO

Response time in seconds

2 AP goal

1 AR goal
P goal

Number of transactions
Accounts payable (AP)
Accounts receivable (AR)
Payroll (P)

In this case, assign the SLOs different priorities so that WLM can
determine how to allocate the limited system resources, allowing at least
one SLO to be met. Other options are to relax the SLOs or purchase more
hardware resources, if the applications are consistently in need of more
resources.

Specifying the workload group to which the SLO

applies (optional)
SLOs govern workloads that are based on workload groups. Therefore,
each workload group must be assigned an SLO. If you want an SLO for a
single application, place that application in a workload group by itself.

Chapter 5 195
Configuring WLM
Defining SLOs

NOTE If you plan on managing only virtual partitions or nPartitions—with no

FSS groups or PSETs inside, the entity keyword is not needed.

Specify the workload group to which an SLO applies using the entity
keyword. The entity keyword is required. Use the following syntax:
entity = PRM group group_name;
where
group_name Is a workload group name.

NOTE You cannot specify PRM_SYS in an slo structure.

Specifying the lower and upper bound requests on

CPU resources (optional)
Specify lower and upper bound requests to prevent an SLO’s controller
from:

• Requesting so few CPU resources that the associated workload

cannot perform reasonably well
• Requesting so many CPU resources that other workloads cannot
perform reasonably well
Use the mincpu and maxcpu keywords to state the minimum and
maximum allocations that the SLO’s controller can request. Because
these allocations are merely requests, the minimum allocation values
across all SLOs do not have to sum to 100%. (For information on setting
hard CPU limits, see “Specifying a group’s minimum CPU resources
(optional)” on page 175 and “Specifying a group’s maximum CPU
resources (optional)” on page 177.)
WLM grants requests based on the priority of the SLOs, their current
performance, and available resources.

196 Chapter 5
 Configuring WLM
Defining SLOs

NOTE For information on the effect of these keywords in passive mode, see
“Passive mode versus actual WLM management” on page 238.

Specify the lower and upper bounds on CPU resources for an SLO using
the following syntax:
mincpu = lower_bound_request;
maxcpu = upper_bound_request;
where
lower_bound_request
Is an integer from 0 to upper_bound_request,
inclusive. lower_bound_request is the minimum
number of CPU shares the SLO’s controller can
request.
If an SLO does not also contain a cpushares statement
or a goal statement, the mincpu value is used as the
SLO’s shares request. If an SLO does not contain a
mincpu statement, 0 is used as the SLO’s shares
request—although a gmincpu value or hmincpu value
may keep the allocation from actually being 0 shares.
lower_bound_request is out of the total CPU
resources, which is 100 multiplied by the number of
cores (if you set the tunable absolute_cpu_units to 1
or it is implied by other elements in your
configuration)—or just 100 by default.
To have a minimum request of 2 cores on an 8-core
system with absolute_cpu_units enabled
(absolute_cpu_units = 1), you would specify:
mincpu = 200;
If you specify a lower_bound_request greater than
the total CPU resources, WLM treats it as equal to the
total CPU resources.

Chapter 5 197
Configuring WLM
Defining SLOs

When configuring WLM on a partition, be sure to select

a value for lower_bound_request that makes sense in
terms of the limits placed on the partition when it was
created—namely its minimum and maximum number
of CPU resources.

NOTE The lower_bound_request value is not a hard limit:

Higher priority SLOs may consume all CPU resources
before all SLOs are granted CPU resources. However,
the associated workload group’s gmincpu value is a
hard limit. It serves as the group’s minimum CPU
allocation when it represents more CPU resources than
the mincpu values used in the group’s SLOs. The
gmincpu value is also used to determine the group’s
minimum CPU allocation in SLOs with cpushares
statements but no mincpu statements. For information
on the default gmincpu value, see the gmincpu section
“Specifying a group’s minimum CPU resources
(optional)” on page 175. Similarly, hmincpu is a hard
limit for allocation to a host.

upper_bound_request
Is an integer greater than or equal to
lower_bound_request. upper_bound_request is the
maximum number of CPU shares the SLO’s controller
can request.
upper_bound_request is out of the total CPU
resources, which is 100 multiplied by the number of
cores (if you set the tunable absolute_cpu_units to 1
or it is implied by other elements in your
configuration)—or just 100 by default.
If you specify an upper_bound_request greater than
the total CPU resources, WLM treats it as equal to the
total CPU resources.
To have a maximum request of 3 cores on an 8-core
system with absolute_cpu_units enabled
(absolute_cpu_units = 1), you would specify:
maxcpu = 300;

198 Chapter 5
 Configuring WLM
Defining SLOs

When configuring WLM on a partition, be sure to select

a value for upper_bound_request that makes sense in
terms of the limits placed on the partition when it was
created—namely its minimum and maximum number
of CPU resources.

NOTE An upper_bound_request may be ignored if the

associated workload’s CPU resources are already
limited by the group’s gmaxcpu value. In the case of
SLOs with cpushares statements but no maxcpu
statements, the group’s gmaxcpu value is still used to
limit CPU allocation. For information on the default
value of gmaxcpu, see the gmaxcpu section “Specifying a
group’s maximum memory (optional)” on page 184.
Similarly, hmaxcpu can limit CPU allocation to a host.

If lower_bound_request and upper_bound_request are equal, WLM

attempts to grant that exact amount of CPU resources; consequently,
specifying a goal would not be particularly useful because WLM would
not change the SLO’s CPU allocation to better achieve a goal.
For more information on absolute CPU units, see the section “Using
absolute CPU units” on page 217.

Specifying a goal (optional)

An SLO’s goal specifies either:

• A range for a workload’s CPU utilization

• Whether the workload’s performance should be less than or greater
than some specified floating-point value
Use the goal keyword to specify such goals.
The goal keyword is optional. If neither the goal nor cpushares
keyword is specified, the SLO is allocated CPU resources according to its
mincpu setting. For information on setting mincpu, see “Specifying the
lower and upper bound requests on CPU resources (optional)” on
page 196.

Chapter 5 199
Configuring WLM
Defining SLOs

You cannot specify both a goal statement and a cpushares statement in

the same SLO. Similarly, you cannot have a workload with one SLO that
has a goal statement and another SLO that has a cpushares statement
that includes more.
Specify the goal of an SLO using the following syntax:
goal = goal_expression;
where
goal_expression
Indicates either a usage goal or a metric goal
(performance goal). Use a usage goal to ensure a
workload uses a certain percentage of its allocated
CPU resources. Usage goals are especially beneficial
when you have a workload that cannot provide
performance data. Metric goals are based on
performance data and require understanding of that
data. Because you can implement usage goals
immediately without prior knowledge of workload
performance, HP recommends using them instead of
metric goals.
With a usage goal, WLM adjusts a workload’s allocation to more
efficiently match the workload’s actual CPU usage. For example, if a
workload is using 20 CPU shares and has a 50-share allocation, its
utilization is 20/50 or 40%. WLM attempts to keep a workload’s
utilization between a low and high bound. WLM tracks the usage metric
internally, on a workload-group basis; you do not have to provide it.

NOTE Typically, you should set wlm_interval to 5 when your WLM

configuration contains a usage goal.

For details about specifying metric goals, see “Specifying a metric goal
(optional)” on page 470. Specify a usage goal in an slo structure as
follows:
goal = usage _CPU [low_util_bound [high_util_bound]];
where
low_util_bound

200 Chapter 5
 Configuring WLM
Defining SLOs

Is an integer less than or equal to high_util_bound,

but greater than or equal to 0. WLM attempts to keep
the utilization percentage above this threshold value,
which is 50 by default. It does so by reducing the
requested allocation whenever utilization drops below
this value.

NOTE Setting low_util_bound at or near 0 can result in an

SLO that never reduces its requested share allocation.
This results in the SLO not giving up its unused
shares.

high_util_bound
Is an integer greater than or equal to low_util_bound,
but less than or equal to 100. WLM attempts to keep
the utilization percentage under this threshold value.
It does so by increasing the requested allocation
whenever utilization surpasses this value. When not
specified, this value defaults to the specified
low_util_bound; when both are not specified, this
value defaults to 75.

NOTE Setting high_util_bound at or near 100 can result in

an SLO that never requests a larger allocation.

Figure 5-5 shows conceptually how WLM works to keep CPU utilization
within a range. The goal here is to keep utilization in the default range,
50% to 75%.

Chapter 5 201
Configuring WLM
Defining SLOs

Figure 5-5 Usage goal conceptually

Goal: Keep utilization between 50% and 75%

➊ With utilization above 75%, the workload is pretty

busy and is using most of its allocation. WLM
Utilization increases its allocation to ensure it gets enough
(CPU used) / (CPU allocation)
CPU. This moves the utilization to less than 75%.
100
➊ ➋ In this range, the workload is using a reasonable
amount of its allocation. It seems to efficiently use
75 the CPU it has, but it would not be able to use more
➋ CPU very efficiently and would suffer with less CPU.
50
➌ With utilization less than 50%, the workload is not
25 ➌ very busy. WLM takes away some of its unused
CPU to give to other workloads. With a smaller
0 CPU allocation, the workload’s utilization moves
above 50%.

Here is an example of a usage goal statement:

goal = usage _CPU 60 80;
When WLM requests an allocation change, the request is proportional to
how far the current utilization is below low_util_bound or above
high_util_bound. Use cntl_kp or cntl_convergence_rate in a tune
structure with _CPU_group_name as the metric value to adjust the
proportion, causing the utilization to move into the desired range more
quickly or slowly. For example, a cntl_kp value of 10 will cause the
utilization to move in larger jumps than will a value of 0.1.
To get an idea of how such a tune structure would look, consider a
workload named buy. Its tune structure would look like the following:
tune _CPU_buy {
cntl_kp = 0.1;
}
The cntl_kp value must be between 0 and 1,000,000 inclusive. The
default value is 1.
For more information on cntl_kp or cntl_convergence_rate, see the
section “Tuning a workload’s SLO convergence: cntl_kp (optional)” on
page 224.

202 Chapter 5
 Configuring WLM
Defining SLOs

Goals vs stretch goals

You can specify one or more goals for a single workload. The highest
priority goal should represent the minimum acceptable service level. All
other goals should indicate stretch goals—goals that may be hard to
achieve, but are desired if possible. Assign stretch goals lower priorities
than the primary goal.
Think of goals as “needs” and stretch goals as “wants”. Needs (goals) are
required to complete the task at the desired performance level.
Wants (stretch goals) form a superset of the needs and may increase
performance, but only at the sacrifice of the needs of other services.
Consider this trade-off when assigning priorities to your goals and
stretch goals.
The following example shows a goal at priority 1 with a desired response
time of less than 2.0. The stretch goal, with a priority of 5, is for the
response time to be less than 1.0. This stretch goal may be met, but only
when the CPU resource requests of all SLOs at higher priorities are
being met.
# This is an SLO for the finance group.
slo finance_query {
pri = 1;
mincpu = 20;
maxcpu = 50;
entity = PRM group finance;
goal = metric fin_app.query.resp_time < 2.0;
condition = Mon - Fri;
}
# This is a stretch goal for the finance group. If all other
# goals of higher priority have been met, apply more CPU to group
# finance, so its application runs faster.
slo finance_query_stretch {
pri = 5;
mincpu = 20;
maxcpu = 80;
entity = PRM group finance;
goal = metric fin_app.query.resp_time < 1.0;
condition = Mon - Fri;
}

Chapter 5 203
Configuring WLM
Defining SLOs

Specifying a fixed or additive allocation of CPU

shares (optional)
An SLO can directly express an allocation request using the cpushares
keyword. This keyword allows you to make fixed or additive allocation
requests, where a fixed allocation is a specific number of CPU shares,
while an additive allocation provides shares that are added to the
allocation from SLOs of higher or equal priority. (The cpushares
keyword also enables you to specify allocation requests of the form “x
shares of the CPU resources for each metric y”, as discussed in the next
section.)
The cpushares syntax for defining a fixed or additive allocation is:
cpushares = value { more | total };
where
value Is the number of CPU shares allocated for the
associated workload group. This value is either an
integer or a floating-point number, not expressed in
exponential notation.
A request is additive when using the more keyword and
absolute when using the total keyword. You must
specify either more or total.
You cannot specify both a goal statement and a
cpushares statement in the same SLO. Similarly, you
cannot have a workload group with one SLO that has a
goal statement and another SLO that has a
cpushares statement that includes more.
When you specify the cpushares keyword, the mincpu
and maxcpu keywords are optional.
more Makes additive allocation requests by adding the
value to other additive requests at the same priority
and to any requests from higher priority SLOs. If there
are no higher priority SLOs, the request is added to the
workload group’s gmincpu value, which is 1% of the
system’s total CPU resources by default (if the tunable
extended_shares is set to 1, the gmincpu value is 0.2%
by default).
value is bounded by the SLO’s mincpu and maxcpu
values, if specified.

204 Chapter 5
 Configuring WLM
Defining SLOs

If the workload group can get a larger allocation from

an SLO with an absolute allocation request at that
priority, it does so. This absolute request can come from
an SLO that uses cpushares with total or from an
SLO that uses only the mincpu and maxcpu keywords.
total Makes absolute allocation requests starting from 0.
The request is exactly equal to value, within the
bounds formed by the SLO’s mincpu and maxcpu
values, if specified.
If the associated workload group can get a larger
allocation of shares from SLOs of higher or equal
priority making absolute allocation requests, it does so.
For example, to have a fixed allocation of 300 CPU shares assigned to a
workload, specify cpushares as follows (this assumes absolute mode is
enabled, where 300 shares equals 3 cores):
cpushares = 300 total;

Specifying a shares-per-metric allocation request

(optional)
An SLO can directly express an allocation request using the cpushares
keyword. This keyword allows you to make allocation requests of the
form “x shares of the CPU resources for each metric y”. For example, you
could give an Oracle instance n CPU shares for each process in the
instance.
The cpushares syntax is:
cpushares = value { more | total } [ per metric met [ plus offset ] ];
For details on the syntax, see “Specifying a shares-per-metric allocation
request (optional)” on page 472.

Specifying when the SLO is active (optional)

Use the keywords condition and exception to indicate when the SLO
is active. The values of these keywords form Boolean expressions. The
SLO is active when the condition expression is true, and the exception
expression is false. By default, the expressions are set so that the SLO is
always active.
The condition and exception keywords are optional.

Chapter 5 205
Configuring WLM
Defining SLOs

If a workload has no active SLOs, it receives the following allocation of

CPU resources at minimum, unless the gmincpu value is greater, in
which case the workload receives the allocation specified by gmincpu:

• For an FSS group, at least 1% (or 0.2% if the tunable

extended_shares is set to 1) of the total CPU resources that are not
allocated to PSET-based groups
• For a PSET-based group, at least one core if the tunable
transient_groups is not set to 1, or zero if this tunable is set to 1
As for memory, a workload with no active SLOs receives at least 1% of
the memory (if extended_shares is set to 1, then at least 0.2% of the
memory), unless the workload has a gminmem value requesting more, in
which case the workload receives an allocation equal to that value.

NOTE If the transient_groups tunable is set to 1, a workload group with no

active SLOs is temporarily removed (for FSS groups) or assigned 0 CPU
resources (for PSET-based groups)—until it has at least one active SLO.
In this case, the group receives no CPU or memory resource. An FSS
group receives no CPU or memory resources regardless of its gmincpu
and gminmem values; if gmincpu or gminmem is specified for a PSET-based
group, the group receives the specified minimum, if available. However,
if the group is associated with a process map, it remains active and
continues to receive the minimum resources even if it has no active
SLOs.
If the transient_groups tunable is set to 1, then when an inactive FSS
group is temporarily removed, any processes that were placed in that
group by either the prmrun or prmmove command are moved to OTHERS or
PRM_SYS and remain there even when the group becomes active again.
For this reason, HP discourages using the transient_groups tunable
and recommends using the extended_shares tunable instead (which
minimizes the waste of resources for inactive groups).

Specify when the SLO is active using the following syntax:

condition = condition_expression;
exception = exception_expression;
where
condition_expression

206 Chapter 5
 Configuring WLM
Defining SLOs

Is an expression that must be true for the SLO to be

active.

NOTE Do not create a condition statement that attempts to

detect processes in a transient group using tools such
as glance or ps. Whenever the group is deleted (FSS
group) or assigned zero CPU resources (PSET-based
group), it is impossible for the system to place
processes in the group. The condition will then never
detect the processes it is looking for.

exception_expression
Is an expression that must be false for the SLO to be
active.
Use the following components to form either of the expressions:

• metric met > numeric_value

• metric met < numeric_value
• metric met
• Date
• Date range
Combine components to form Boolean expressions with the operators
&& (AND), || (OR), ! (NOT). Group components with parentheses ().
met must have an associated tune structure. numeric_value must be a
floating-point value, either positive or negative. The metric met
expression is false if met equals 0. For all other values, the expression is
true.
In a Serviceguard cluster, where workloads may move between servers,
use metric met to inform WLM of the active workloads. Ideally, a single
WLM configuration file can be used on all the servers in the cluster. For
more information, see “Integrating with Serviceguard” on page 414.
Specify dates or date ranges in condition_expression and
exception_expression using the following components:
[weekday] [mm/dd/ccyy] [hh:mm]
where

Chapter 5 207
Configuring WLM
Defining SLOs

weekday Is Mon, Tue, Wed, Thu, Fri, Sat, or Sun.

mm/dd/ccyy Takes mm values 1-12, dd values 1-31, and ccyy values
as four-digit years. Use an asterisk (*) for a component
to indicate that all valid values are accepted.
hh:mm Is hours and minutes on a 24-hour clock. Use an
asterisk (*) for hh and/ or mm to indicate that all valid
values are accepted.
Using the components just explained, specify a date range according to
one of the following formats:

• mm/dd/ccyy - mm/dd/ccyy
• hh:mm - hh:mm
• weekday - weekday
• mm/dd/ccyy hh:mm - mm/dd/ccyy hh:mm
• weekday hh:mm - weekday hh:mm
• mm/dd/* - mm/dd/*
• */dd/* - */dd/*
• *:mm - *:mm
• mm/dd/* hh:mm - mm/dd/* hh:mm
• */dd/* hh:mm - */dd/* hh:mm
For formats that do not specify the hh:mm component, the start-time
defaults to 00:00, and the end-time defaults to 23:59.
Here are some examples showing various condition and exception
statements. In the examples, consecutive statements are not used
together unless explicitly stated.
exception = Sat - Sun; # SLO is active during the week
condition = 20:00 - 22:59; # Combining these two lines,
exception = Fri - Sun; # the SLO is active from 8pm
# to 11pm every night except Friday, Saturday, and
# Sunday
condition = metric resp_time > 2; # SLO is active only
# when resp_time is greater than 2
condition = metric num_users > 5; # SLO is active only
# when the number of users logged in is greater than 5

208 Chapter 5
 Configuring WLM
Defining SLOs

exception = metric metricA; # SLO is active only when

# metricA is 0
condition = (metric metricA) && !(metric metricB);
# SLO is active when metricA is nonzero,
# and metricB is zero
condition = */01/2003;
# SLO is active on the 1st of every month in the
# year 2003

Chapter 5 209
Configuring WLM
Tuning the metrics and the SLOs

Tuning the metrics and the SLOs

You can tune metrics and SLOs using tune structures. Among other
features, these structures allow you to specify the data collector and its
command-line arguments, the frequency at which WLM checks for new
performance data and adjusts CPU allocations, and the controllers’
variables.
There are three types of tune structures:

• Global structure
This tune structure applies to all metrics and SLOs. It does not
reference the name of any metric or SLO. It can be specified, at most,
once in the configuration file. Its syntax is:
tune {
[ wlm_interval = number_of_seconds; ]
[ absolute_cpu_units = {0 | 1}; ]
[ distribute_excess = {0 | 1}; ]
[ extended_shares = {0 | 1}; ]
[ transient_groups = {0 | 1}; ]
[ wlmdstats_size_limit = number_of_megabytes; ]
[ coll_argv = data_collector_and_arguments; ]
[ coll_stderr = file; ]|
[ cntl_smooth = smoothing_value; ]
[ cntl_avg = {0 | 1}; ]
[ cntl_kp = proportional_term; ]
[ cntl_convergence_rate = number_of_shares; ]
[ cntl_margin = margin_value; ]
[ cntl_base_previous_req = {0 | 1}; ]
}

210 Chapter 5
 Configuring WLM
Tuning the metrics and the SLOs

• Metric-specific structure
A metric-specific tune structure applies to all SLOs using metric.
This structure can be specified, at most, once per metric. Its syntax
is:
tune metric {
[ coll_argv = data_collector_and_arguments; ]
[ coll_stderr = file; ]
[ cntl_smooth = smoothing_value; ]
[ cntl_avg = {0 | 1}; ]
[ cntl_kp = proportional_term; ]
[ cntl_convergence_rate = number_of_shares; ]
[ cntl_margin = margin_value; ]
[ cntl_base_previous_req = {0 | 1}; ]
}
• Metric/SLO-specific structure
This tune structure applies to the specified metric/SLO pair. It
can be specified, at most, once per metric/SLO pair. Its syntax
is:
tune metric slo_name {
[ cntl_kp = proportional_term; ]
[ cntl_convergence_rate = number_of_shares; ]
[ cntl_margin = margin_value; ]
[ cntl_base_previous_req = {0 | 1}; ]
}
In cases where two or more tune structures could apply in the same
situation, the more specific structure type takes precedence. Thus, a
metric/SLO-specific structure overrides a metric-specific structure,
which in turn overrides a global structure.
Here is a sample tune structure:
tune sales_app.resp_time {
coll_argv = /opt/sales_app/bin/sales_monitor -v;
}

Chapter 5 211
Configuring WLM
Tuning the metrics and the SLOs

Defining a tune structure consists of the following tasks:

• Specifying a data collector (optional)

• Specifying the WLM interval (optional)
• Using absolute CPU units
• Distributing excess CPU resources to your workloads (optional)
• Refining granularity of CPU (and memory) allocation by increasing
shares per core (optional)
• Temporarily removing groups with inactive SLOs (optional)
• Capturing your collectors’ stderr (optional)
• Smoothing metric values (optional)
• Controlling averaging in usage controllers (optional)
• Trimming the statistics log file automatically (optional)
• Tuning a workload’s SLO convergence: cntl_kp (optional)
• Tuning a workload’s SLO convergence: cntl_convergence_rate
(optional)
• Tuning the goal buffer (optional)
• Releasing cores properly (optional)

Tuning WLM using the WLM GUI

In addition to tuning with a text editor, you can use the WLM
Configuration Wizard (/opt/wlm/bin/wlmcw). Alternatively, you can use
the WLM GUI (/opt/wlm/bin/wlmgui).
The following steps show how to set the WLM interval and use absolute
CPU units (recommended) using the GUI. It is assumed you went
through the procedure on “Defining PRM components using the WLM
GUI” on page 151 to define a partition set. For more information on using
the WLM GUI, see its online help.

Step 1. Select the name of the host, wlmhost0 in this case, in the left pane. The
right pane allows you to set the type of configuration elements you would
like to see in the new configuration.

Select the “Global tunables” box in the right pane. A “Global tunables”
item then appears in the left pane.

212 Chapter 5
 Configuring WLM
Tuning the metrics and the SLOs

Chapter 5 213
Configuring WLM
Tuning the metrics and the SLOs

Step 2. Select the “Global tunables” item in the left pane. The right pane
changes, allowing you to set various tunables.

Set any tunables as desired.

Step 3. Select the [Commit changes] button to save the current configuration
in memory. To save changes to disk, go to the Deploy tab. (The file is
saved to the file specified in the file name field in the Modify tab when
the system is selected in the left pane.)

The previous steps highlight only one use of the WLM GUI. For
additional information, see the GUI’s online help.

214 Chapter 5
 Configuring WLM
Tuning the metrics and the SLOs

Specifying a data collector (optional)

Whenever you use a metric in your WLM configuration, you need to
supply a value for that metric. The coll_argv statement launches a data
collector to gather values for a metric. You can specify a data collector in
a metric-specific tune structure to gather values for that one metric. If
multiple metrics use the same command, such as wlmrcvdc, to collect
values, you can specify the command in a global tune structure, instead
of specifying it separately for each metric in its own metric-specific tune
structure.
The coll_argv keyword is optional. However, if the SLO has a
performance goal, specify a data collector. The coll_argv keyword is
allowed in global and metric-specific tune structures.

NOTE Data collectors invoked by WLM run as root and can pose a security
threat. Hewlett-Packard makes no claims of any kind with regard to the
security of data collectors not provided by Hewlett-Packard.
Furthermore, Hewlett-Packard shall not be liable for any security
breaches resulting from the use of said data collectors.

Use the following syntax in a tune structure to specify a data collector

and its command-line arguments:
coll_argv = data_collector_and_arguments;
For details on the syntax, see “Specifying a data collector” on page 477.

Specifying the WLM interval (optional)

Once per interval, WLM:

• Checks for new data from the data collectors

• Adjusts CPU allocations to better achieve SLOs, if necessary
• Adjusts memory allocations to compensate for any workload groups
that became active or inactive in the last WLM interval
By specifying the interval, you can control how frequently these checks
and adjustments occur.

Chapter 5 215
Configuring WLM
Tuning the metrics and the SLOs

The shorter the interval, the more often WLM checks for new
performance data and alters the CPU allocation if workloads are not
meeting their SLOs. If there is no new data, WLM does nothing.
With longer intervals, WLM is more likely to receive new performance
data; however, a workload is also more likely to not achieve its SLO for
longer periods.
The wlm_interval tunable is optional. It is allowed only in a global tune
structure within the WLM configuration file.

NOTE The current WLM interval length is available to data collectors specified
in coll_argv statements. The length can be retrieved through the
WLM_INTERVAL environment variable.

Use the following syntax in a tune structure to specify the interval:

wlm_interval = number_of_seconds;
where
number_of_seconds
Specifies how often the WLM daemon checks for new
data from the data collectors and adjusts CPU
allocations. Valid values are from 1 to 86400 seconds (1
day).
The default is 60.
Typically, number_of_seconds should be 5 when your
WLM configuration contains a usage goal.
When generating audit data (with the wlmd -t option),
number_of_seconds should be no more than 60 to
ensure the audit data sampling rate is sufficiently
frequent to:
If you are running WLM within an Integrity VM
(guest), specify an interval length greater than 60
seconds. This helps ensure a fair allocation of CPU
resources for FSS groups.

• Minimize the amount of audit data lost if the WLM

daemon exits unexpectedly

216 Chapter 5
 Configuring WLM
Tuning the metrics and the SLOs

• Minimize the effect of changes in the number of

available CPU resources (due to WLM
management of vPar, Instant Capacity, Temporary
Instant Capacity, and Pay per use resources)
For example, the following global tune structure sets the interval to 15
seconds:
tune {
wlm_interval = 15;
}

Using absolute CPU units

With the absolute_cpu_units tunable, you can control whether the
CPU units used by the following keywords/tunables are absolute or
relative:

• mincpu
• maxcpu
• gmincpu
• gmaxcpu
• cpushares
• cntl_kp
• cntl_convergence_rate
With absolute CPU units enabled (absolute_cpu_units = 1), you
specify CPU units in terms of 100, where 100 represents an entire core.
So, if you want a mincpu of half a core, you would specify:
mincpu = 50;
If you want a maxcpu of two cores, you would specify:
maxcpu = 200;
Absolute CPU units are used when the number of active CPU resources
changes due to WLM management of Instant Capacity, Temporary
Instant Capacity, Pay per use, or Virtual Partitions resources. Regardless
of the number of active cores, the absolute CPU units represent the same
amount of CPU resources. HP recommends using absolute CPU units.

Chapter 5 217
Configuring WLM
Tuning the metrics and the SLOs

With relative CPU units (absolute_cpu_units = 0, the default), the

units you specify represent a percentage of the system’s total CPU
resources and are consequently relative to the number of active cores.
For example, the following statement:
mincpu = 50;
is 50% of the system’s CPU resources, which is 50% of one core on a
system with only one active core, but is eight cores on a system with 16
active cores.
To use absolute CPU units, use the following statement in a global tune
structure:
absolute_cpu_units = 1;

NOTE Several conditions involving absolute_cpu_units can cause your WLM

configuration file to be invalid:

• Setting absolute_cpu_units equal to 0 and setting primary_host

• Setting absolute_cpu_units equal to 0 in a configuration that does
not have a prm structure
• In a configuration with a prm structure:

— Setting absolute_cpu_units equal to 0 and specifying a PSET

group
• In a configuration without a prm structure:

— Setting absolute_cpu_units equal to 0 and setting hmincpu

— Setting absolute_cpu_units equal to 0 and setting hmaxcpu
— Setting absolute_cpu_units equal to 0 and setting hweight

Distributing excess CPU resources to your workloads

(optional)
By default, if any CPU resouces remain after satisfying all SLOs, the
remainder is given to OTHERS. To distribute this excess to the workloads
you have defined, set the distribute_excess tunable to 1 (true) in a
global tune structure:

218 Chapter 5
 Configuring WLM
Tuning the metrics and the SLOs

tune {
distribute_excess = 1;
}
Only workloads with active SLOs receive the excess CPU resources.
This distribution is based on balancing the weight-to-allocation ratios for
the workloads. These ratios are discussed in “Weighting a group so it
gets more CPU resources (optional)” on page 178.
The distribution is subject to the group CPU maximum values specified
by the gmaxcpu keyword. If the excess CPU resources are not fully
distributed because of group CPU maximum values, the excess is given
to the OTHERS group as usual—even if giving OTHERS this excess places it
over its gmaxcpu value.
The default value for distribute_excess is 0, in which case the OTHERS
group is given any excess CPU resources.

Refining granularity of CPU (and memory) allocation

by increasing shares per core (optional)
By default, allocations to FSS groups are based on 100 shares per core.
The minimum allocation to groups with inactive SLOs is one share or 1%
of CPU resources. If you are using WLM memory management, the
group receives 1% of memory. You can refine the granularity for
minimum allocations by setting the extended_shares tunable to 1 (true)
in a global tune structure:
tune {
extended_shares = 1;
}
In this way, CPU allocations are based on 1000 shares per core
(granularity of 0.001). This requires that you use absolute CPU units,
which is also recommended (set absolute_cpu_units to 1, as explained
in “Using absolute CPU units” on page 217). Minimum allocations of
memory are also based on 1000 shares instead of 100.
With extended_shares set to 1, the minimum allocation of CPU or
memory resources for a group with no active SLOs (this assumes
transient_groups is disabled) decreases from 1/100 core or 1% to
2/1000 core or 0.2%. Granularity for minimum allocations can be based
on 0.1% increases (for example, 0.3%, 0.4%, 0.5%). With

Chapter 5 219
Configuring WLM
Tuning the metrics and the SLOs

extended_shares enabled, WLM can support 256 groups starting with

HP-UX 11i V2 Update 2 (the 64-group limit is still in effect on HP-UX 11i
V1).
The default value for extended_shares is 0, where 1 core consists of 100
shares.
Enable extended_shares if:

• You want finer granularity of allocation to FSS groups. This might be

preferred when the number of FSS groups or CPU resources is large.
• You want to use more than 63 FSS workload groups.
Enable extended_shares instead of transient_groups if you want to
prevent groups from being removed when they become inactive, while
providing smaller minimum allocations to these groups.

NOTE Regardless of the value of extended_shares, all configuration file values

and all values output by wlminfo are based on hundredths (when using
absolute CPU units). Enabling extended_shares affects the granularity
for all allocations and makes possible smaller minimum allocations.

Temporarily removing groups with inactive SLOs

(optional)
By default, all workload groups are always present—even those with no
active SLOs. A workload group with no active SLOs still requires 1% of
the total CPU resources for FSS groups (if extended_shares is set to 1,
an FSS group requires 0.2%) or a whole core for PSET-based groups,
unless it has a gmincpu value requesting more. If the group has a
gmincpu value requesting more, the group receives an allocation equal to
that value, if such resources are available. Similarly, if you are using
WLM memory management, the workload group with no active SLOs
receives 1% of the memory (if extended_shares is set to 1, it receives
0.2% of the memory, with incremental allocations of 0.1%), unless the
workload group has a gminmem value requesting more.
If you would prefer these groups to go away temporarily (as long as they
have no active SLOs) and consume no CPU or memory resources, set the
transient_groups tunable to 1 in a global tune structure:

220 Chapter 5
 Configuring WLM
Tuning the metrics and the SLOs

tune {
transient_groups = 1;
}

NOTE Setting transient_groups equal to 1 in a configuration that does not

have a prm structure results in an invalid configuration.

With the transient_groups keyword set to 1: FSS groups with no active

SLOs are deleted and therefore use no resources; the minimum CPU
allocation for PSET groups becomes 0 (or the minimum specified by
gmincpu, if resources are available). However, groups associated with a
process map remain active and continue to receive the minimum
allocation of resources even if they have no active SLOs.
Using the transient_groups keyword does not throttle the resource
usage of processes in transient groups that are inactive. In fact, those
processes are moved—possibly to groups where they get more resources,
as discussed in the “Placement of processes” sections that follow.
The OTHERS group is never removed, regardless of its number of active
SLOs.
If an FSS workload group has been temporarily removed, its gmincpu
and gminmem values (if any) are ignored.
To prevent groups from being removed when they become inactive, while
providing them smaller minimum allocations, enable the
extended_shares tunable instead of the transient_groups tunable.
For information on the extended_shares tunable, see “Refining
granularity of CPU (and memory) allocation by increasing shares per
core (optional)” on page 219.

NOTE Do not create a condition statement that attempts to detect processes

in a transient group using tools such as glance or ps. Whenever the
group is deleted (FSS group) or assigned zero CPU resources
(PSET-based group), it is impossible for the system to place processes in
the group. The condition will then never detect the processes it is looking
for.

Chapter 5 221
Configuring WLM
Tuning the metrics and the SLOs

Placement of processes for inactive FSS groups

With transient_groups=1, if an FSS workload group, say mygrp, has no
active SLOs, but does have processes assigned to it by user records, Unix
group records, application records, or compartment records, WLM moves
its processes to a temporary group named _IDLE_. This group has only
the minimum CPU and memory resources and can greatly restrict the
progress of a process. When mygrp has active SLOs again, the processes
placed in mygrp by records are moved back to mygrp. However, note that
groups associated with process maps always remain active even if the
groups have no active SLOs.
If a process is not assigned to a group by a record, it is moved to OTHERS
or PRM_SYS if its current group is removed. The process remains in
OTHERS or PRM_SYS even when the group has active SLOs again. For this
reason, be cautious when using only prmrun or prmmove to place a
process in an FSS group that may be removed. Using user records, Unix
group records, application records, or compartment records for processes
that go into transient FSS groups ensures those processes return to the
desired groups when the groups return. (For information on how WLM
determines which group assignment takes precedence when the same
process is identified by multiple records, see “How the application
manager affects workload group assignments” on page 459.)

Placement of processes for PSET-based groups

The placement of processes in a PSET-based group depends on whether
the group has CPU resources (cores) assigned to it. With
transient_groups=1, the group can have zero CPU resources if you
request it or if the group has no active SLOs.
Assume a PSET-based workload group, say mygrp2, has no cores. Any
processes in the group when its last core is taken away, as well as
processes you try to place in the group using prmrun or prmmove when
the group has no cores, are placed in the OTHERS group.

NOTE To minimize the number of processes moved to OTHERS, assign at least

one core to PSET-based groups that have running processes.

When mygrp2 has cores again, the processes placed in mygrp2 by

application records, user records, Unix group records, or compartment
records are moved back to mygrp2. Similarly, any processes you

222 Chapter 5
 Configuring WLM
Tuning the metrics and the SLOs

attempted to place in the group with prmrun or prmmove are moved to the
group. (For information on how WLM determines which group
assignment takes precedence when the same process is identified by
multiple records, see “How the application manager affects workload
group assignments” on page 459.)

NOTE When WLM is managing PSETs, do not change PSET settings by using
the psrset command. Only use WLM to control PSETs.

Capturing your collectors’ stderr (optional)

Because they are started by a daemon process, data collectors do not
have a stderr on which to communicate errors. The coll_stderr tunable
allows you to capture these errors. Specify coll_stderr using the
following syntax:
coll_stderr = file;
For details on the syntax, see “Capturing your collectors’ stderr
(optional)” on page 479.

Smoothing metric values (optional)

Use the cntl_smooth keyword to get a running average of a metric from
a data collector, smoothing out dips and spikes in the metric before it is
used by WLM. Specify cntl_smooth using the following syntax:
cntl_smooth = smoothing_value;
For details on the syntax, see “Smoothing metric values (optional)” on
page 480.

Controlling averaging in usage controllers (optional)

Use the cntl_avg keyword to control averaging in usage controllers. By
default, averaging is enabled (cntl_avg=1). With averaging disabled
(cntl_avg=0), only the most recent interval’s usage data is used for a
usage metric.
This tunable is ignored for metrics that are not CPU usage metrics.

Chapter 5 223
Configuring WLM
Tuning the metrics and the SLOs

Trimming the statistics log file automatically

(optional)
You can automatically trim the statistics log file /var/opt/wlm/wlmdstats.
This file is created when you use the -l option to wlmd. Enable automatic
trimming of the file by using the wlmdstats_size_limit tunable. The
syntax is:
wlmdstats_size_limit = number_of_megabytes;
where
wlmdstats_size_limit
Is an optional tunable. Specify this tunable in a global
tune structure.
number_of_megabytes
Is an integer value from 0 to 2048. Once a file’s size is
greater than number_of_megabytes, the file is
trimmed. The default value is 0, which disables
automatic trimming. The wlmdstats file is trimmed by
renaming it wlmdstats.old. Then a new wlmdstats file
is started. The wlmdstats.old file includes a line at the
end of the file indicating that the file has been
automatically trimmed.

Tuning a workload’s SLO convergence:

cntl_kp (optional)

NOTE You can also tune convergence with the cntl_convergence_rate

tunable discussed in the section “Tuning a workload’s SLO convergence:
cntl_convergence_rate (optional)” on page 229.
The cntl_convergence_rate tunable, which uses normalization to
arrive at a new CPU allocation, is typically easier to use—requiring less
analysis than cntl_kp.

224 Chapter 5
 Configuring WLM
Tuning the metrics and the SLOs

WLM starts a performance controller for each goal-based SLO. It also

starts a usage controller for each usage goal. Each controller calculates
new CPU shares requests if the reported data indicates the workload is
overachieving or underachieving its goal. The controller then requests
the new number of CPU shares.

NOTE Although convergence tuning is optional from a syntactic point of view,

you should use cntl_kp or cntl_convergence_rate for each controller
to fine-tune it to the characteristics of its workload.

The performance controllers receive two real-time inputs: The number of

CPU shares the workload had during the last WLM interval and the
workload performance during that period. Usage controllers work on
inputs of the workload’s percent of CPU resources used and its CPU
allocation for the last interval.
To determine the new CPU shares allocation, each controller effectively
executes an algorithm that, when plugging in cntl_kp (as opposed to
cntl_convergence_rate), is represented as follows:
New CPU allocation =
(Allocation last interval) + cntl_kp * P
where
cntl_kp Is a tunable parameter for the controller to indicate a
workload’s sensitivity to changes in CPU allocation. It
is specified in the WLM configuration file.
P Is the deviation from the goal.
WLM calculates P based on the goal type, as indicated in the following:
Performance goal with met < value:
P = met - value
where, as defined in the goal_expression, met is some
metric for the workload and value is a goal value for
the metric.
For example, if the goal (value) was that response time
be less than 2 seconds, and the measured response time
(met) was 3 seconds, the deviation from goal is
calculated:

Chapter 5 225
Configuring WLM
Tuning the metrics and the SLOs

P = 3 - 2 = 1
Performance goal with met > value:
P = value - met
Usage goal:
P = Actual utilization - Target utilization
Target utilization is either low_util_bound or
high_util_bound. If actual utilization is below
low_util_bound, then
P = Actual utilization - low_util_bound
If actual utilization is above high_util_bound,
P = Actual utilization - high_util_bound
For example, if the goal is to keep CPU utilization
between 50% and 75%, with the utilization at 85%, the
deviation from the goal is:
P = 85 - 75 = 10

226 Chapter 5
 Configuring WLM
Tuning the metrics and the SLOs

Use the optional cntl_kp tunable to tune convergence. It can be used in

global, metric-specific, and metric/SLO-specific tune structures. Its
syntax is:
cntl_kp = proportional_term;
where
proportional_term
Is a floating-point value between 0 and 1,000,000
(inclusive) used on the proportional term in the
controller’s expression. The default value is 1.
Change this value according to how sensitive the SLO’s
associated workload is to changes in CPU allocation
and based on the magnitude of the goal being
measured.
Recall the formula for determining new allocation
requests:
New CPU allocation =
(Allocation last interval) + cntl_kp * P
If P is typically large, say 10 or 100 or higher, use a
smaller cntl_kp to scale down the cntl_kp * P result
so it does not overcorrect. Similarly, for very small
values of P (less than 1), use cntl_kp to scale up the
cntl_kp * P result.
If WLM changes allocations too rapidly, resulting in
instability, decrease proportional_term. If WLM
changes allocations too slowly, increase
proportional_term.
With absolute CPU units enabled
(absolute_cpu_units = 1), your
proportional_term maintains more predictable
behavior from your workload regardless of the number
of available cores. Without absolute CPU units, the
effect of a given proportional_term depends on the
number of available cores, which could produce
undesirable effects. HP recommends enabling absolute
CPU units.

Chapter 5 227
Configuring WLM
Tuning the metrics and the SLOs

NOTE A proportional_term equal to 0, when applied to the

formula for determining new allocations
New CPU allocation =
(Allocation last interval) + cntl_kp * P
results in the formula
New CPU ent. = (Allocation last interval)
which leads to no change in an SLO’s allocation
request.
Also, using large values for proportional_term can
produce unstable behavior, causing service levels and
allocations to oscillate drastically.

In the following example, cntl_kp is set to 2 (twice the

default) so that the SLO converges twice as fast on its
goal:
tune sales_app.resp_time {
coll_argv = /opt/sales_app/monitor;
cntl_kp = 2.0;
}
For more information on how to tune, see the white paper “Tuning
HP-UX Workload Manager” at /opt/wlm/share/doc/howto/tuning.html.

228 Chapter 5
 Configuring WLM
Tuning the metrics and the SLOs

Tuning a workload’s SLO convergence:

cntl_convergence_rate (optional)

NOTE You can also tune convergence with the cntl_kp tunable discussed in the
section “Tuning a workload’s SLO convergence: cntl_kp (optional)” on
page 224. (If cntl_convergence_rate is not zero, it is used instead of
cntl_kp.)
Using the cntl_convergence_rate tunable changes the allocation
algorithm to take the goal value into consideration, effectively
normalizing the result by the goal’s magnitude. Given the normalization
that cntl_convergence_rate provides, as well as the greater analysis
required to fine-tune the cntl_kp tunable, you may want to use
cntl_convergence_rate first. In many cases, setting
cntl_convergence_rate = 1.0 will provide the desired convergence and
meet your needs.

For each performance and usage goal, WLM must determine the
appropriate number of CPU shares needed to achieve that goal. To do
this, WLM creates a controller for each such goal.

NOTE Although convergence tuning is optional from a syntactic point of view,

you should use cntl_convergence_rate or cntl_kp for each controller
to fine-tune it to the characteristics of its workload.

Chapter 5 229
Configuring WLM
Tuning the metrics and the SLOs

To determine the new CPU shares allocation, each controller effectively

executes an algorithm that, when plugging in cntl_convergence_rate
(as opposed to cntl_kp), is represented as follows:
New CPU allocation = (Allocation last interval) +
(cntl_convergence_rate / 0.10) * (P / goal)
where
cntl_convergence_rate
Is a tunable parameter for the controller that indicates
the number of CPU shares by which to adjust a
workload’s allocation when it differs from its goal. It is
specified in the WLM configuration file.
P
Is the deviation from the goal and is calculated as
shown in the previous section, “Tuning a workload’s
SLO convergence: cntl_kp (optional)”.
There are two special cases to consider in the previous formula:

• For goal = 0, “(P / goal)” becomes “P”

• For usage goals, goal becomes the average of the low_util_bound
and high_util_bound values: “(low_util_bound + high_util_bound) /
2”
Use the optional cntl_convergence_rate tunable to tune convergence.
It can be used in global, metric-specific, and metric/SLO-specific tune
structures. Its value is inherited from a higher level tune structure if you
do not specify it at a given level.
Its syntax is:
cntl_convergence_rate = number_of_shares;
where
number_of_shares
Is a floating-point value that represents the number of
shares (either absolute or relative) by which a
workload’s CPU allocation is adjusted when its service
level differs from its goal by 10%. When the difference
is less than 10%, the adjustment is proportionally

230 Chapter 5
 Configuring WLM
Tuning the metrics and the SLOs

smaller than number_of_shares. Similarly, when the

difference is greater than 10%, the adjustment is
proportionally larger than number_of_shares.
The larger number_of_shares is, the larger will be
adjustments made by WLM to the workload’s CPU
allocation are. This generally produces faster
convergence on the SLO goal.
If WLM changes allocations too rapidly, resulting in
instability, decrease number_of_shares. If WLM
changes allocations too slowly, increase
number_of_shares.
With absolute CPU units enabled
(absolute_cpu_units = 1), your number_of_shares
maintains more predictable behavior from your
workload regardless of the number of available cores.
Without absolute CPU units, the effect of a given
number_of_shares depends on the number of available
cores, which could produce undesirable effects. HP
recommends enabling absolute CPU units.

Tuning the goal buffer (optional)

WLM attempts to meet a goal that is slightly different from the goal you
specify in your configuration. By working toward this goal, WLM has a
buffer to work within—and small fluctuations in the service level do not
result in SLO violations.
You can specify the percentage size of this buffer with the cntl_margin
tunable. This tunable is optional and can be used in global,
metric-specific, and metric/SLO-specific tune structures.
The cntl_margin tunable syntax is:
cntl_margin = margin_value;
where
margin_value
Is a floating-point value between 0 and 1 (inclusive)
indicating a percentage distance away from the SLO’s
goal. The default value is 0.1, or 10%.

Chapter 5 231
Configuring WLM
Tuning the metrics and the SLOs

WLM uses this value to re-target the goal it is trying to

converge on. For example, with a margin_value of 0.1
and a goal of X, the re-targeted goal is X - (0.1*X). The
controller adjusts the goal up or down (based on
whether the goal is > or <) by this percentage to create
a buffer zone. This adjustment prevents small
fluctuations in the service level from causing SLO
violations.
Consider Figure 5-6. Assume the goal in the
configuration file is response_time < 2 seconds, and the
default cntl_margin value of 0.1 is in effect. WLM
internally re-targets the goal to 1.8 seconds (0.1*2 =
0.2; 2 - 0.2 = 1.8). As shown, the response_time values
are close to 1.8, with some values below and some
above the re-targeted goal. Without cntl_margin,
these values would converge from below and above on
the goal in the configuration file. Each value above the
goal would then cause an SLO violation. With the
re-targeted goal, these fluctuations do not cause SLO
violations.

NOTE The “cntl_margin = margin_value” tunable applies

only to performance goals. Do not use it with usage
goals.

Figure 5-6 Effect of the cntl_margin tunable parameter

2
Goal
Re-targeted goal
response_time 1

232 Chapter 5
 Configuring WLM
Example configuration

For more information on how to use the cntl_margin tunable, see the
white paper “Tuning HP-UX Workload Manager” at
/opt/wlm/share/doc/howto/tuning.html.

Releasing cores properly (optional)

By default, the cntl_base_previous_req tunable is set to 1, which can
be beneficial when you are using the WLM global arbiter (wlmpard) to
manage virtual partitions or nPartitions or when your WLM
configuration has at least one PSET- based workload group with an SLO.
WLM creates a controller for each slo structure that has a goal
statement. Controllers make requests to the WLM arbiter for shares
allocations. Setting cntl_base_previous_req=0 can result in some
controllers requesting CPU resources more aggressively; however, the
distribution of cores may become unfair due to artificially high resource
requests.
Use this optional tunable in global, metric-specific, and
metric/SLO-specific tune structures

Example configuration
The following is an example configuration consisting of two workload
groups and four SLOs. A discussion of the example is presented after the
example.
# Define the workload groups
prm {
groups = finance:2, sales:3;
apps = finance: /opt/fin_app/count_money, sales: /opt/sales/do_ebiz;
}

# This is an SLO for the finance group.

slo finance_query {
pri = 1;
mincpu = 20;
maxcpu = 50;
entity = PRM group finance;
goal = metric fin_app.query.resp_time < 2.0;
condition = Mon - Fri;

Chapter 5 233
Configuring WLM
Example configuration

# This is a stretch goal for the finance query group. If all other CPU
# requests of higher priority SLOs have been met, apply more CPU to
# group finance, so its application runs faster.
slo finance_query_stretch {
pri = 5;
mincpu = 20;
maxcpu = 80;
entity = PRM group finance;
goal = metric fin_app.query.resp_time < 1.0;
condition = Mon - Fri;
}

# On weekends, we do not expect any query transactions, but just in

# case, we will specify a nominal CPU allocation for this application
# for off-hours.
slo finance_query_weekend {
pri = 1;
cpushares = 5 total;
entity = PRM group finance;
condition = Sat - Sun;
}

# This is an SLO for the Sales group.

slo sales_query {
pri = 1;
mincpu = 40;
maxcpu = 80;
entity = PRM group sales;
goal = metric sales_app.resp_time < 10.0;
}

tune {
wlm_interval = 30;
}

tune fin_app.query.resp_time {
coll_argv = /opt/fin_app/finance_collector -a 123 -v;
cntl_kp = 0.8;
}

tune sales_app.resp_time {
coll_argv = /opt/sales_app/monitor -threshold 2 -freq 30 ;
cntl_kp = 2.0;
}

234 Chapter 5
 Configuring WLM
Example configuration

This configuration file specifies four SLOs. The finance_query SLO is

active Monday through Friday. Its goal is that the metric
fin_app.query.resp_time, which is provided by the executable
/opt/fin_app/finance_collector, must always be less than 2.0. This goal is
priority 1, the highest priority. The controller for this goal determines the
CPU entitlement (allocation) needed to achieve the goal, but is bounded
by the minimum and maximum CPU resource requests, which are 20%
and 50%.
Additionally, a stretch goal is defined for this workload. The stretch goal
is the SLO named finance_query_stretch, which is also only
applicable Monday through Friday. The stretch goal is of lower priority
(pri = 5). The stretch goal is that the metric fin_app.query.resp_time be
less than 1.0. The controller for the stretch goal is bounded by the same
minimum CPU allocation, but has a higher maximum.
The SLO named finance_query_weekend applies to this workload
group as well. This SLO does not specify a performance goal, but
requests a CPU allocation of 5% for weekends.
The sales_query SLO is active at all times. Its goal is that the metric
sales_app.resp_time be less than 10.0. This metric is provided by the
data collector /opt/sales_app/monitor. This SLO specifies that the
controller for this SLO never requests a CPU allocation of less than 40%,
nor more than 80%. This goal is priority 1.
The global tunable wlm_interval is set to 30, thus the WLM daemon
checks for new performance data every 30 seconds.
The finance_query and finance_query_stretch SLOs both use the
metric fin_app.query.resp_time. The tune structure for that metric
specifies the settings of the tunables used by those SLOs. The argv for
the process used to collect the metric fin_app.qurey.resp_time is given by:
coll_arg = /opt/fin_app/finance_collector -a 123 -v;
For the controllers that use this metric, the value of the proportional
constant is set to 1.0. All other tunables are set according to the default
values listed in the master tunables file.
The sales_query SLO uses the metric sales_app.resp_time. The tune
structure for this metric specifies that when the daemon starts the data
collector to collect this metric, it uses the coll_argv string
/opt/sales_app/monitor -threshold 2 -freq 30. Also, this tune
structure specifies the proportional constant used by the controllers for

Chapter 5 235
Configuring WLM
Trying a configuration without affecting the system

SLOs that use this metric. The value of the proportional constant
(cntl_kp) for those controllers is 2.0. All other tunables are set according
to the default values in the master tunables file.
For more examples files, see Chapter 9, “Example configuration files,” on
page 283.

Trying a configuration without affecting the

system
WLM provides a passive mode that allows you to see how WLM will
approximately respond to a given configuration—without putting WLM
in charge of your system’s resources. Using this mode, you can analyze
your configuration’s behavior—with minimal effect on the system.
Besides being useful in understanding and experimenting with WLM,
passive mode can be helpful in capacity-planning activities.
A sampling of possible uses for passive mode are included later in this
section. These uses help you determine:

• How does a condition statement work?

Activate your configuration in passive mode then start the wlminfo
utility. Use wlmsend to update the metric that is used in the
condition statement. Alternatively, wait for the condition to change
based on the date and time. Monitor the behavior of the SLO in
question in the wlminfo output. Is it on or off?

NOTE Always wait at least 60 seconds (the default WLM interval) for WLM
changes to resource allocations to appear in the wlminfo output.
(Alternatively, you can adjust the interval using the wlm_interval
tunable in your WLM configuration file.)

• How does a cpushares statement work?

236 Chapter 5
 Configuring WLM
Trying a configuration without affecting the system

Activate your configuration in passive mode then start the wlminfo

utility. Use wlmsend to manipulate the metric used in the cpushares
statement. What is the resulting allocation shown in the wlminfo
output?
• How do goals work? Is my goal set up correctly?
Activate your configuration and monitor the WLM behavior in the
wlminfo output. What is the range of values for a given metric? Does
WLM have the goal set to the level expected? Is WLM adjusting the
workload’s CPU allocation?
• How might a particular cntl_convergence_rate value or the values
of other tunables affect allocation changes?
Create several configurations, each with a different value for the
tunable in question. Activate one of the configurations and monitor
the WLM behavior in the wlminfo output. Observe how WLM
behaves differently under each of the configurations.
• How does a usage goal work?
In passive mode, a usage goal’s behavior might not match what
would be seen in regular mode, but what is its basic behavior if the
application load for a particular workload is increased?
Activate your configuration and monitor the wlminfo output to see
how WLM adjusts the workload’s CPU allocation in response to the
group’s usage.
• Is my global configuration file set up as I wanted? If I used global
arbitration on my production system, what might happen to the CPU
layouts?

NOTE You can run wlmpard in passive mode with each partition’s wlmd
daemon running in regular mode. Thus, you can run wlmpard
experiments on a production system without consequence.

In addition, passive mode allows you to validate workload, application,

and user configuration. For example, with passive mode, you can
determine:

• Is a user’s default workload group set up as I expected?

• Can a user access a particular workload group ?

Chapter 5 237
Configuring WLM
Trying a configuration without affecting the system

• When an application is run, which workload group does it run in?

• Can I run an application in a particular workload group?
• Are the alternate names for an application set up correctly?
Furthermore, using metrics collected with glance_prm, passive mode
can be useful for capacity planning and trend analysis. For more
information, see glance_prm(1M).

Passive mode versus actual WLM management

This section covers the following topics:

• The WLM feedback loop

• Effect of mincpu and maxcpu values
• Using wlminfo in passive mode
• The effect of passive mode on usage goals and metric goals

The WLM feedback loop

WLM operations are based on a feedback loop: System activity typically
affects WLM arbitration of service-level objectives. This arbitration
results in changes to CPU allocations for the workloads, which can in
turn affect system activity—completing the feedback loop.
The following diagram shows normal WLM operation, including the
feedback loop.

Figure 5-7 Normal WLM operation

Usage/metrics
System activity WLM

Allocation changes

In passive mode, however, the feedback loop is broken, as shown in the

following diagram.

238 Chapter 5
 Configuring WLM
Trying a configuration without affecting the system

Figure 5-8 Passive WLM operation

Usage/metrics
System activity WLM

Thus, in passive mode, WLM takes in data on the workloads. It even

forms a CPU request for each workload based on the data received.
However, it does not change the CPU allocations for the workloads on the
system.

Effect of mincpu and maxcpu values

In passive mode, WLM does use the values of the following keywords to
form shares requests:

• mincpu/maxcpu
• gmincpu/gmaxcpu
• hmincpu/hmaxcpu
However, because WLM does not adjust allocations in passive mode, it
may appear that these values are not used.

Monitoring WLM in passive mode

Use the wlminfo utility to monitor WLM in passive mode. Its output
reflects WLM behavior and operation. It shows how much CPU WLM is
requesting for a workload—given the workload’s current performance.
However, because WLM does not actually adjust CPU allocations in
passive mode, WLM does not affect the workload’s performance—as
reported in usage values and metric values. Once you activate WLM in
normal mode, it adjusts allocations and affects these values.
For the purposes of passive mode, WLM creates a PRM configuration
with each of your workload groups allocated one CPU share, and the rest
going to the reserved group PRM_SYS. (If your configuration has
PSET-based workload groups, the PSETs are created but with zero CPU
resources.) In this configuration, CPU capping is not enforced—unlike in
normal WLM operation. Furthermore, this configuration will be the only
one used for the duration of the passive mode. WLM does not create new
PRM configurations to change resource allocations. Consequently, do not

Chapter 5 239
Configuring WLM
Trying a configuration without affecting the system

rely on prmlist or prmmonitor to observe changes when using passive

mode. These utilities will display the configuration WLM used to create
the passive mode. However, you can use prmmonitor to gather CPU
usage data.

The effect of passive mode on usage goals and metric goals

As noted previously, in passive mode, the WLM feedback loop is not in
place. The lack of a feedback loop is most dramatic with usage goals.
With usage goals, WLM changes a workload’s CPU allocation so that the
group’s actual CPU usage is a certain percentage of the allocation. In
passive mode, WLM does not actually change CPU allocations. Thus, an
SLO with a usage goal might be failing; however, that same SLO might
easily be met if the feedback loop were in place. Similarly, an SLO that is
passing might fail if the feedback loop were in place. However, if you can
suppress all the applications on the system except for the one with a
usage goal, wlminfo should give you a good idea of how the usage goal
would work under normal WLM operation.
Passive mode can have an effect on SLOs with metric goals as well.
Because an application is not constrained by WLM in passive mode, the
application might produce metric values that are not typical for a normal
WLM session. For example, a database application might be using most
of a system. As a result, it would complete a high number of transactions
per second. The database performance could be at the expense of other
applications on the system. However, your WLM configuration might
scale back the database’s access to resources to allow the other
applications more resources. Thus, the wlminfo output would show
efforts to reduce the database’s CPU allocation. Because passive mode
prevents a reduction in the allocation, the database’s number of
transactions per seconds (and system use) remains high. WLM, believing
the previous allocation reduction did not produce the desired result,
again lowers the database’s allocation. Thus, with the removal of the
feedback loop, WLM actions in passive mode do not always indicate what
it would do normally.
Because of these discrepancies, always be careful when using passive
mode as an indicator of normal WLM operation. Use passive mode to see
trends in WLM behavior—with the knowledge that the trends may be
exaggerated because the feedback loop is not present.

240 Chapter 5
 Configuring WLM
Activating the configuration file

Activating the configuration file

When activating a WLM configuration file, you can run WLM in passive
mode—allowing you to verify a configuration before using it to control
the system’s resources. To use passive mode, specify -p with the wlmd
command:
# wlmd -p -a configfile
Use the wlminfo utility to then monitor how WLM would have allocated
CPU resoruces to your workloads in configfile.
For information on passive mode, including its limitations, see “Passive
mode versus actual WLM management” on page 238.
After fine-tuning your WLM configuration, activate it—letting WLM
take control of your system’s resources—as follows:
# wlmd -a configfile
Both of these command lines check that configfile is valid. If the file is
valid with respect to the WLM syntax, it is passed to PRM for validation.
So, after passing WLM validation, you may encounter PRM validation
errors. Once your file passes both validations, the WLM daemon is
started. The daemon then starts all the data collectors specified in the
configuration file. If a previous instance of wlmd is running, it is replaced
by this new instance.
After starting the data collectors, every wlm_interval seconds, the
WLM daemon checks for performance data to act on. The default interval
value is 60 seconds. You can alter this value as explained in the section
“Specifying the WLM interval (optional)” on page 215.
For information on activating the WLM global arbiter configuration, see
Chapter 7, “Managing SLOs across partitions,” on page 255.

Chapter 5 241
Configuring WLM
Setting WLM to start automatically at reboot

Setting WLM to start automatically at reboot

You must either activate a valid WLM configuration or specify one with
the variable WLM_STARTUP_SLOFILE in the file /etc/rc.config.d/wlm before
you set WLM to start automatically at reboot. For information on
activating a configuration, see “Activating the configuration file” on
page 241.
You can set WLM to start automatically at reboot by setting the
WLM_ENABLE variable in the file /etc/rc.config.d/wlm to 1:
WLM_ENABLE=1
When started at reboot, WLM automatically uses the most recent
configuration file that was activated.
If you want WLM to activate a specific configuration when it
automatically starts at reboot, edit the following line in the
/etc/rc.config.d/wlm file:
WLM_STARTUP_SLOFILE=”configfile”
where configfile is the configuration file to use at reboot.
For information on starting the WLM global arbiter automatically, see
the section “Setting WLM global arbitration to start automatically at
reboot” on page 242.

Setting WLM global arbitration to start

automatically at reboot
You must either activate a valid WLM global arbiter configuration or
specify one with the variable WLMPARD_STARTUP_SLOFILE in the file
/etc/rc.config.d/wlm before you set the WLM global arbiter to start
automatically at reboot. For information on activating a global arbiter
configuration, see “Setting up cross-partition management” on page 260.
The WLM global arbiter is used to manage WLM SLOs across virtual
partitions.

242 Chapter 5
 Configuring WLM
Setting the WLM communications daemon to start automatically at reboot

You can set the global arbiter to start automatically at reboot by setting
the WLMPARD_ENABLE variable in the file /etc/rc.config.d/wlm to 1:
WLMPARD_ENABLE=1
When started at reboot, the WLM global arbiter automatically uses the
most recent configuration file that was activated.
If you want the global arbiter to activate a specific configuration when it
automatically starts at reboot, edit the following line in the
/etc/rc.config.d/wlm file:
WLMPARD_STARTUP_SLOFILE=”configfile”
where configfile is the configuration file to use at reboot.
For information on starting WLM automatically, see the section “Setting
WLM to start automatically at reboot” on page 242.

Setting the WLM communications daemon to

start automatically at reboot
The WLM communications daemon (wlmcomd) services requests from the
WLM graphical user interface, wlmgui. The daemon must be running on
a system for you to control that system’s WLM instance or WLM global
arbiter using wlmgui.
You can set wlmcomd to start automatically at reboot by setting the
WLMCOMD_ENABLE variable in the file /etc/rc.config.d/wlm to 1:
WLMCOMD_ENABLE=1
With wlmcomd running on a system, WLM itself does not need to be
running on that system because you can deploy WLM there with wlmgui.
However, you can start WLM automatically if desired, as described in the
section “Setting WLM to start automatically at reboot” on page 242.

Chapter 5 243
Configuring WLM
Securing WLM communications

Securing WLM communications

When you start WLM using the /sbin/init.d/wlm script, the script uses
secure mode by default. (However, if you are upgrading WLM and the
/etc/rc.config.d/wlm script had been modified prior to the upgrade, the
default might not be secure mode. Ensure that the secure mode variables
discussed in the following discussion are enabled.) To use secure mode,
you must distribute security certificates to all systems or partitions
being managed by the same WLM global arbiter (wlmpard). For more
information on using security certificates and other tasks necessary to
enable secure communications, see wlmcert(1M). This and other WLM
manpages are also available at the following Web site:
http://www.hp.com/go/wlm
The communications mode is determined by the following variables in
the file /etc/rc.config.d/wlm:
WLMD_SECURE_ENABLE
WLMPARD_SECURE_ENABLE
WLMCOMD_SECURE_ENABLE
If necessary, you can change the settings for these variables so that
communications are not secured by default at reboot. (HP recommends
using secure communications.)
To manually activate a daemon (wlmd, wlmpard, or wlmcomd) to run in
secure mode, you can use the -s option with the daemons. If you run
WLM’s global arbitration without secured communications, use it only on
trusted local area networks.

244 Chapter 5
 Configuring WLM
Enabling statistics logging at reboot

Enabling statistics logging at reboot

The following variables in /etc/rc.config.d/wlm allow you to log statistics
starting at reboot:

• WLM_STATS_LOGGING
Set WLM to start logging statistics at reboot by setting the
WLM_STATS_LOGGING variable in the following file:
/etc/rc.config.d/wlm
Valid values are:

— all
— group
— host
— metric
— slo
Values can be combined, separated by commas, with no white space:
WLM_STATS_LOGGING=slo,metric
Be sure to include double quotes when you request logging less often
than once per WLM interval:
WLM_STATS_LOGGING=”slo=10,metric”
Setting WLM_STATS_LOGGING has the same effect as using the
wlmd -l option. For a description of the -l arguments, see the
reference section “wlmd” on page 374.
You can limit the size of /var/opt/wlm/wlmdstats as explained in the
section “Trimming the statistics log file automatically (optional)” on
page 224.

Chapter 5 245
Configuring WLM
Disabling statistics logging

• WLMPARD_STATS_LOGGING
Set the WLM global arbiter to start logging statistics at reboot by
setting the WLMPARD_STATS_LOGGING variable in /etc/rc.config.d/wlm
as follows:
WLMPARD_STATS_LOGGING="vpar"
You can limit the size of /var/opt/wlm/wlmpardstats as explained in
“Trimming the global arbiter statistics log automatically (optional)”
on page 272.

Disabling statistics logging

To disable statistics logging by WLM, restart WLM without the -l. For
example:

• Restart WLM with the last valid configuration:

# wlmd -A
• Restart WLM with a new configuration:
# wlmd -a configfile
To disable statistics logging by the WLM global arbiter, restart wlmpard
without the -l. For example:

• Restart the WLM global arbiter with the last valid configuration:
# wlmpard -A
• Restart the WLM global arbiter with a new configuration:
# wlmpard -a configfile

NOTE If logging is set in the /etc/rc.config.d/wlm file, logging will resume at the
next reboot.

246 Chapter 5
 Configuring WLM
WLM and kernel parameters

WLM and kernel parameters

WLM assumes your HP-UX kernel parameters are already set
appropriately for the workloads you are running. Consequently, WLM
does not change kernel parameters to meet the specified SLOs.

Chapter 5 247
Configuring WLM
WLM and kernel parameters

248 Chapter 5
6 Auditing and billing

WLM produces audit information when you activate a configuration

using the -t option with either the WLM daemon wlmd or the WLM
global arbiter daemon wlmpard:
# wlmd -t -a configfile
or
# wlmpard -t -a configfile
Once you’ve activated a configuration using -t, use the wlmaudit
command to display the audit data:
# wlmaudit
The wlmaudit command allows you to specify a date range for the data to
display. By default, the output is plain text; however, you can display
output in formatted HTML as well.
For command syntax, see the Appendix A, “WLM command reference,”
on page 363 or see wlmaudit(1M).

NOTE To ensure the smooth running of the operating system and key HP-UX
daemons, WLM runs these system processes in a special workload called
PRM_SYS. This group is not restrained by WLM: It consumes system
resources as needed. As a result, a workload’s CPU usage may be less
than its allocation (or entitlement as it is seen in the wlmaudit report)
because PRM_SYS requires some of the group’s resources. However, the
low usage could also be the result of the group’s low CPU resource
demands, or a combination of the two factors. Also, there may be times
when CPU usage is slightly above the allocation due to dynamics in the
CPU scheduler that WLM uses. Likewise, if memory management is
enabled, a workload’s memory usage may be less than the number of
memory shares for reasons similar to those just stated. It could also be
slightly above the memory shares value due to extreme paging pressure
or when the current group allocation is being reduced.

Chapter 6 249
Auditing and billing
Example wlmaudit report

Example wlmaudit report

Here is a sample wlmaudit report. (Periods after January are removed
for brevity.)
Date: 08/26/2003
Host: host1
Subject: WLM Audit Report

Summary for wlmd on host1 from 01/01/2003 to 08/26/2003:

Duration CPU Entitlement CPU Usage

Entity (hr) (CPU-hr) (CPU-hr)
-----------------------------------------------------------------------
OTHERS 3758.526 16638.380 1039.816
PRM_SYS 3758.526 1389.540 917.580
_IDLE_ 2928.954 159.613 0.000
g_apache 3758.526 2040.202 31.853
g_nice 3758.526 2093.390 504.050
g_nightly 3758.526 406.796 156.060
g_team 3758.526 984.799 0.210

Detail audit report for wlmd on host1:

Period: Jan 2003

----------------
Entity: OTHERS
Daily records:

Date Duration Entitlement Usage

-------------------------------------------------------
01/24/2003 1.663 5.338 0.111
01/25/2003 24.000 109.727 1.982
01/26/2003 24.000 109.565 1.122
01/27/2003 24.000 105.233 13.105
01/28/2003 24.000 103.373 10.297
01/29/2003 24.000 102.295 9.128
01/30/2003 24.000 104.443 15.542
01/31/2003 24.000 100.606 8.371

250 Chapter 6
 Auditing and billing
Example wlmaudit report

Entity: PRM_SYS
Daily records:

Date Duration Entitlement Usage

-------------------------------------------------------
01/24/2003 1.663 3.052 0.508
01/25/2003 24.000 29.685 4.938
01/26/2003 24.000 29.448 4.877
01/27/2003 24.000 33.425 5.507
01/28/2003 24.000 35.716 5.872
01/29/2003 24.000 36.154 5.960
01/30/2003 24.000 39.523 6.469
01/31/2003 24.000 40.943 6.763

Entity: g_apache
Daily records:

Date Duration Entitlement Usage

-------------------------------------------------------
01/24/2003 1.663 0.545 0.007
01/25/2003 24.000 7.338 0.030
01/26/2003 24.000 7.200 0.028
01/27/2003 24.000 11.487 0.228
01/28/2003 24.000 13.285 0.307
01/29/2003 24.000 13.835 0.371
01/30/2003 24.000 12.024 0.253
01/31/2003 24.000 13.412 0.389

Entity: g_nice
Daily records:

Date Duration Entitlement Usage

-------------------------------------------------------
01/24/2003 1.663 2.283 1.032
01/25/2003 24.000 11.824 2.428
01/26/2003 24.000 12.490 2.563
01/27/2003 24.000 11.609 2.550
01/28/2003 24.000 11.973 2.788
01/29/2003 24.000 12.232 2.884
01/30/2003 24.000 11.779 2.852
01/31/2003 24.000 13.544 3.439

Chapter 6 251
Auditing and billing
Example wlmaudit report

Entity: g_nightly
Daily records:

Date Duration Entitlement Usage

-------------------------------------------------------
01/24/2003 1.663 0.826 0.000
01/25/2003 24.000 3.671 1.035
01/26/2003 24.000 3.401 0.984
01/27/2003 24.000 4.400 0.936
01/28/2003 24.000 3.696 1.170
01/29/2003 24.000 3.785 1.125
01/30/2003 24.000 3.711 1.085
01/31/2003 24.000 3.716 1.096

Entity: g_team
Daily records:

Date Duration Entitlement Usage

-------------------------------------------------------
01/24/2003 1.663 0.478 0.000
01/25/2003 24.000 6.503 0.000
01/26/2003 24.000 6.467 0.000
01/27/2003 24.000 5.764 0.000
01/28/2003 24.000 5.802 0.000
01/29/2003 24.000 5.894 0.000
01/30/2003 24.000 5.576 0.000
01/31/2003 24.000 5.960 0.000

252 Chapter 6
 Auditing and billing
Audit data files

Audit data files

wlmaudit takes the comma-separated data from audit files and displays
it in an easily readable report. However, if you would like to use these
files directly, they are located in the directory /var/opt/wlm/audit/. The
files are named based on the daemon of origin and the date:
wlmd.monyyyy and wlmpard.monyyyy, with monyyyy representing the
month and year, as in nov2001.
Here is an example entry from one of these files:
host1, 10/10/2002, group1, PRM, 10.000000, 0.000417, 0.000153
Each line has seven fields:
Field 1 The name of the host from which the data was
gathered
Field 2 The date (mm/dd/yyyy) the data was gathered
Field 3 The name of the entity on which the data is focused
Field 4 The type of entity. Possible types are:
NPAR an nPartition
PRM a PRM group (also known as a
workload group)
VPAR a virtual partition
Field 5 Approximate number of hours of data available for the
entity
Field 6 The CPU entitlement, or allocation, for the entity for
the date shown (in CPU hours)
Field 7 The CPU usage for the entity for the date shown (in
CPU hours)

Chapter 6 253
Auditing and billing
Enabling auditing at reboot

Enabling auditing at reboot

You can automatically set the WLM daemon, wlmd, and the WLM global
arbiter daemon, wlmpard, to generate audit data by setting the following
variables to 1 in the /etc/rc.config.d/wlm file:

• WLMD_AUDIT_ENABLE
• WLMPARD_AUDIT_ENABLE
Both variables are set to 0 (no audit data) by default.

254 Chapter 6
7 Managing SLOs across
partitions
WLM can manage SLOs across virtual partitions and nPartitions. WLM
provides a global arbiter, wlmpard, that can take input from the WLM
instances on the individual partitions. The global arbiter then moves
CPU resources (cores) between partitions, as needed to better achieve
the SLOs specified in the WLM configuration files that are active in the
partitions. These partitions can be nested—and can even contain FSS
and PSET-based workload groups. (wlmpard can be running in one of the
managed partitions or on a supported platform with network
connectivity to the managed partitions.)
The following sections describe how WLM manages SLOs across virtual
partitions and nPartitions and explains how to configure cross-partition
management.

Overview
WLM virtual partition (vPar) management migrates cores between
virtual partitions. However, with nPartitions being physical entities,
WLM nPartition management only gives the appearance of migrating
cores. This pseudo-migration is achieved—using the Instant Capacity
(iCAP) software—by deactivating cores on one nPartition then activating
cores on another nPartition.
Figure 7-1 shows WLM managing the partitions on a server. For a
detailed explanation of the figure, see “How WLM works” on page 112.

Chapter 7 255
Managing SLOs across partitions
Overview

Figure 7-1 WLM managing partitions

Define WLM Event Monitoring WLM monitoring tools

workloads configuration Service (EMS) (wlminfo or wlmgui)
and SLOs file
SLO stats
(pass/fail)
Message log
WLM daemon (wlmd) /var/opt/wlm/msglog
Workload Grp A
(metric goal) Usage Data Controller
Collector

Statistics log (optional)

Workload Grp B Usage Data /var/opt/wlm/wlmdstats
(usage goal) Controller
Collector
Arbiter

Workload Grp C Fixed Audit data files (optional)

(no goal) Allocation /var/opt/wlm/audit/

Workload Grp D Metric Data Shares-per-metric

(no goal) Collector Allocation Global arbiter statistics
log (optional)
/var/opt/wlm/wlmpardstats

PRM
Workload groups get
new CPU allocations
better suited to their SLOs WLM global arbiter
WLM creates a new PRM configuration daemon (wlmpard)

WLM
global arbiter
configuration
file

Par 0

WLM can manage

vPars, nPars,
WLM EMS WLM EMS or a combination
wlminfo/ wlminfo/
WLM EMS configuration configuration
wlminfo/ wlmgui wlmgui
configuration file file
wlmgui vPars get
file
Log Log cores added
Grp A WLM WLM or removed
Log files files
Grp B WLM files to better
Grp C suit the SLOs
App1 App2 App3 App1 App2 App3
With nPars, a
PRM core is
deactivated
Par 1 Par 2 Par 3 on one nPar, then
a core on
another nPar
is activated

HP-UX server

256 Chapter 7
 Managing SLOs across partitions
Recommendations, requirements, and restrictions

Recommendations, requirements, and

restrictions
To successfully manage WLM SLOs across partitions, observe the
following:

• HP recommends running WLM global arbitration in secure mode.

If you do not run WLM global arbitration in secure mode, a rogue
user could manipulate the communications, resulting in one or more
partitions being granted an incorrect number of cores. To enable
secure communications, set up security certificates and distribute
them to all systems or partitions being managed by the same WLM
global arbiter (wlmpard). For more information, see “Securing WLM
communications” on page 244 and wlmcert(1M).
Assuming you have completed the required steps for setting up and
distributing security certificates, WLM global arbitration runs in
secure mode by default when you use the /sbin/init.d/wlm script to
start WLM. (If you upgraded WLM, secure mode might not be the
default. Ensure that the WLMPARD_SECURE_ENABLE variable in
/etc/rc.config.d/wlm is enabled.) You can also activate global
arbitration in secure mode by using the -s option with the wlmpard
command. HP recommends using secure communications. If you
must disable secure communications, use global arbitration only on
trusted local area networks. For more information on enabling or
disabling secure communications, see “Securing WLM
communications” on page 244.
For information on using global arbitration with firewalls, see
wlmparconf(4).
• When running WLM within an Integrity VM (guest), do not use
Instant Capacity, Pay per use, and vPar integration.
Such integration is not supported when running WLM within an
Integrity VM at that level. However, an Integrity VM will take
advantage of cores added to the Integrity VM Host by Pay per use
(PPU), Instant Capacity (iCAP), and Temporary Instant Capacity
(TiCAP). When running WLM on an Integrity VM Host, use a strictly
host-based configuration.

Chapter 7 257
Managing SLOs across partitions
Recommendations, requirements, and restrictions

• For managing nPartitions with WLM, you must use Instant Capacity
cores (formerly known as iCOD CPUs). Use the Instant Capacity
versions specified in the WLM Release Notes
(/opt/wlm/share/doc/Rel_Notes).
• If you manage virtual partitions in combination with Instant
Capacity, you must use vPars A.03.01 or later.
• Do not adjust any WLM-managed partition while wlmpard is
running. This includes using vparmodify, icapmodify, or
icod_modify to change the name, configuration, or resources (CPU
and memory) associated with the virtual partition or nPartition. This
also includes using parolrad to perform online cell (Cell OL*)
operations on any cell in a WLM-managed partition. (To check the
status of online cell operations, use the parolrad -m command.) To
adjust a partition or cell, first shut down WLM—including
wlmpard—on all partitions that will be affected by the modification,
then modify the partition. Restart WLM after modifying the
partition. (Changes to Instant Capacity affect the entire complex;
changes to a virtual partition affect the nPartition only, unless
Instant Capacity is configured on the nPartition.) For example, if
WLM is managing two virtual partitions vParA and vParB, and you
need to migrate memory resources from vParA to vParB, you must
shut down WLM in both virtual partitions. As another example, to
change the name of an nPartition, you must first shut down WLM in
every operating system instance across the entire complex, because
the name change affects Instant Capacity, and Instant Capacity
changes affect every nPartition across the complex.
For instructions on how to stop and start the WLM daemons, see
Appendix A, “WLM command reference,” on page 363, or see
wlmd(1M) and wlmpard(1M).
• Do not use cell-specific CPU bindings or user-assigned CPU bindings
on virtual partitions you are going to manage with WLM.
• With Instant Capacity v6 or earlier, do not include spaces in partition
names. Also, if icod_stat or icapstatus truncate the name of an
nPartition, use parmodify to shorten the name so that it is not
truncated.
You can configure WLM to manage FSS and PSET-based workload
groups and partitions (nPartitions or virtual partitions) at the same
time. Certain software restrictions apply to using PSET-based groups

258 Chapter 7
 Managing SLOs across partitions
Recommendations, requirements, and restrictions

with virtual partitions (vPars), Instant Capacity, and Pay per use. For
more information, see the WLM Release Notes
(/opt/wlm/share/doc/Rel_Notes).
WLM allocates cores to a partition based on the CPU limits of the
partition (physical limits for nPartitions; logical limits for virtual
partitions). For example, WLM adjusts the number of cores assigned to a
vPar within the limits of the given vPar’s minimum and maximum
number of cores, which you set using vparmodify.
The way WLM uses group weighting to determine CPU allocations
across partitions is the same as the way it uses group weighting to
determine allocations within a partition. For more information, see
“Weighting a group so it gets more CPU resources (optional)” on
page 178.

Chapter 7 259
Managing SLOs across partitions
Setting up cross-partition management

Setting up cross-partition management

The following steps give an overview of how to implement cross-partition
management.

Step 1. (Optional) Set up secure WLM communications.

Follow the procedure HOW TO SECURE COMMUNICATIONS in

wlmcert(1M)—skipping the step about starting/restarting the WLM
daemons. You will do that later in this procedure.

Step 2. Create a WLM configuration file for each partition.

Each partition on the system must have the WLM daemon wlmd running.
Create a WLM configuration file for each partition, ensuring each
configuration uses the primary_host keyword to reference the partition
where the global arbiter is running. For information on the
primary_host syntax, see “Setting up your WLM configuration file” on
page 264.

NOTE If the cntl_base_previous_req tunable is set to 0 in a WLM

configuration that contains goal-based SLOs, those SLOs may not
release cores properly when the cores are no longer needed.
cntl_base_previous_req is set to 1 by default. For more information,
see “Releasing cores properly (optional)” on page 233 or see wlmconf(4).

On systems with WLM installed, you can use the example configuration:

/opt/wlm/examples/wlmconf/par_usage_goal.wlm

NOTE Do not edit this configuration file in place. Copy it to a location outside
/opt/wlm/. Then edit and activate the configuration from the new
location.

260 Chapter 7
 Managing SLOs across partitions
Setting up cross-partition management

This configuration specifies a usage goal for its workload group. The file
is included in this book in the section “par_usage_goal.wlm” on page 310.
(Be sure to use the par_usage_goal.wlmpar file for the WLM global
arbiter.)

There is also an example partition configuration in which you manually

request the number of cores for a partition by using the wlmsend
command to feed the request to WLM:

/opt/wlm/examples/wlmconf/par_manual_allocation.wlm

NOTE Do not edit this configuration file in place. Copy it to a location outside
/opt/wlm/. Then edit and activate the configuration from the new
location.

With this configuration, you manually request the number of cores for an
nPartition using the wlmsend command to feed the request to WLM. The
file is in this book in the section “par_manual_allocation.wlm” on
page 304. (Be sure to use the par_manual_allocation.wlmpar file for the
WLM global arbiter.)

Step 3. (Optional) Activate each partition’s WLM configuration in passive mode.

WLM operates in “passive mode” when you include the -p option in your
command to activate a configuration. With passive mode, you can see
approximately how a particular configuration is going to affect your
system—without the configuration actually taking control of your
system.

Activate each partition’s WLM configuration file configfile in passive

mode as follows:

# wlmd -p -a configfile

To see approximately how the configuration would affect your system,

use the WLM utility wlminfo. Fine-tune each partition’s configuration
until the wlminfo output is as desired.

For information on passive mode, including its limitations, see “Passive

mode versus actual WLM management” on page 238.

Step 4. Activate each partition’s WLM configuration.

Chapter 7 261
Managing SLOs across partitions
Setting up cross-partition management

After verifying and fine-tuning each partition’s WLM configuration file

configfile, activate it as follows:

# wlmd -a configfile

To use secure communications, activate the file using the -s option:

# wlmd -s -a configfile

The wlmd daemon runs in secure mode by default when you use the
/sbin/init.d/wlm script to start WLM. (If you upgraded WLM, secure
mode might not be the default. Ensure that the appropriate secure mode
variables in /etc/rc.config.d/wlm are enabled. For more information, see
“Securing WLM communications” on page 244.)

Step 5. Create a configuration file for the global arbiter.

On the system running the global arbiter, create a configuration file for
the global arbiter. (The global arbiter can run on any HP-UX system that
has network connectivity to the partitions being managed by WLM. If
this system is being managed by WLM, it will have both a WLM
configuration file and a WLM global arbiter configuration file. You can
set up and run the global arbiter configuration on a system that is not
managed by WLM if needed for the creation of fault-tolerant
environments or Serviceguard environments.)

This global arbiter configuration file is required. In the file specify the:

• Global arbiter interval

• Port used for communications between the partitions

• Size at which to truncate wlmpardstats log file

• Lowest priority SLO at which Temporary Instant Capacity (v6 or

later) or Pay per use (v4, v7, or later) resources are used

NOTE Specifying this priority ensures WLM maintains compliance with

your Temporary Instant Capacity (TiCAP) usage rights. When your
prepaid amount of temporary capacity expires, WLM no longer
attempts to use the temporary resources.

When 15 or fewer processing days (the default) of temporary capacity

are available, WLM stops activating Temporary Instant Capacity; in
this case, you must purchase extra capacity. Before you add the

262 Chapter 7
 Managing SLOs across partitions
Setting up cross-partition management

capacity, stop wlmpard (using the -k option). For information about

how to stop wlmpard, see Appendix A, “WLM command reference,” on
page 363.

You can change the 15-day default by setting the WLM global arbiter
utility_reserve_threshold keyword. For more information, see
“Specifying the reserve threshold that determines when WLM stops
activating temporary capacity resources” on page 274 or see
wlmparconf(4).

For information on the syntax of this file, see the section “Setting up your
WLM global arbiter configuration file” on page 265 or see wlmparconf(4).

You can use the WLM GUI (wlmgui) to configure the global arbiter, as
described in “Using the WLM GUI to set up the global arbiter
configuration file” on page 267.

On systems with WLM installed, you can use the example configuration
/opt/wlm/examples/wlmconf/par_usage_goal.wlmpar or
/opt/wlm/examples/wlmconf/par_manual_allocation.wlmpar. These files
are included in this book in the chapter Chapter 9, “Example
configuration files,” on page 283.

Step 6. (Optional) Activate the global arbiter configuration file in passive mode.

Similar to the WLM passive mode, the WLM global arbiter has a passive
mode (also enabled with the -p option) that allows you to verify wlmpard
settings before letting it control your system.

Activate the global arbiter configuration file configfile in passive mode

as follows:

# wlmpard -p -a configfile

Again, to see approximately how the configuration would affect your

system, use the WLM utility wlminfo.

Step 7. Activate the global arbiter.

Activate the global arbiter configuration file as follows:

# wlmpard -a configfile

To use secure communications, activate the file using the -s option:

Chapter 7 263
Managing SLOs across partitions
Setting up your WLM configuration file

# wlmpard -s -a configfile

The global arbiter runs in secure mode by default when you use the
/sbin/init.d/wlm script to start WLM. If you upgraded WLM, secure mode
might not be the default. Ensure that the WLMPARD_SECURE_ENABLE
variable in /etc/rc.config.d/wlm is enabled. For more information, see
“Securing WLM communications” on page 244.

NOTE In a complex (a system divided into either nPartitions or virtual

partitions):

• If the complex is an Instant Capacity system, you must use exactly

one wlmpard process to manage all the partitions in the complex that
are under WLM control.
• If the complex is not an Instant Capacity system, you must use a
separate wlmpard process for each nPartition—with each wlmpard
managing only the virtual partitions within its nPartition.
A complex is an Instant Capacity system if Instant Capacity is installed
and an Instant Capacity license is applied on the system.

For information on the wlmpard syntax, see Appendix A, “WLM

command reference,” on page 363 or see wlmpard(1M).

Setting up your WLM configuration file

In each partition, you must activate a WLM configuration that indicates
the host name for the system running the WLM global arbiter. Indicate
the host of the global arbiter as follows, specifying the primary_host
keyword outside all prm, slo, and tune structures. (If you are using the
WLM GUI (wlmgui), a default host name is provided when you add a new
“Partition Set”; you can then modify the provided host name by selecting
it in the left pane and entering your preferred host name in the
“Hostname” field in the right pane that then appears.)
primary_host = hostname [ : port_number ] ;
where

264 Chapter 7
 Managing SLOs across partitions
Setting up your WLM global arbiter configuration file

primary_host Is an optional keyword that identifies the host name of

the system running the global arbiter. The system can
be any HP-UX system that has network connectivity to
the partitions being managed by WLM.
hostname Is the name or IP address of the host running the
arbiter.
port_number (Optional) Is a port number greater than 0 indicating
the port that the global arbiter is to monitor. If you
specify a port number in a WLM configuration file on a
partition, specify the same port number in the WLM
global arbiter configuration file and in the WLM
configuration file in each partition.
For more information on how a port is chosen, see the
section “Setting up your WLM global arbiter
configuration file” on page 265 or see wlmparconf(4).

NOTE Recall that WLM uses absolute CPU units when a configuration includes
the primary_host keyword. As a result, 100 represents a single core,
and any CPU shares you specify are out of 100 multiplied by the number
of cores. For example, 200 represents 2 cores. For more information on
absolute CPU units, see “Using absolute CPU units” on page 217.

For information on creating the rest of the WLM configuration file, see
the chapter Chapter 5, “Configuring WLM,” on page 135 or see
wlmconf(4).

Setting up your WLM global arbiter

configuration file
On the system where the global arbiter is going to run, create a global
arbiter configuration file.

Chapter 7 265
Managing SLOs across partitions
Setting up your WLM global arbiter configuration file

The global arbiter configuration file allows you to control settings for the
HP-UX WLM global arbiter, which governs cross-partition management
and management of Temporary Instant Capacity (TiCAP) and Pay per
use (PPU) resources.
WLM can manage cores for virtual partitions and nPartitions. (The
partitions can even be nested and contain FSS and PSET-based workload
groups.) WLM virtual partition management migrates cores between
virtual partitions. With nPartitions being physical entities, WLM
nPartition management—through the use of Instant Capacity
software—only gives the appearance of migrating cores. This
pseudo-migration is achieved by deactivating cores on one nPartition and
then activating cores on another nPartition.

NOTE The configuration file is required.

The file’s syntax is free-form, allowing white space to be used freely in

formatting the file. Comment lines are preceded with the hash mark (#).
Use wlmpard to activate a global arbiter configuration file.
The WLM global arbiter configuration file consists of a par structure
that allows you to specify:

• How frequently the WLM global arbiter checks for input from the
individual WLM instances running in the partitions
• The port that the WLM global arbiter should monitor for input from
the individual WLM instances
• The size, in megabytes, at which the wlmpardstats file is
automatically truncated
• The lowest priority SLO at which WLM should use Temporary
Instant Capacity (TiCAP) or Pay per use (PPU) resources to manage
the total core capacity available
If you specify a port number in the primary_host statement of any of the
WLM configuration files or in the WLM global arbiter configuration file,
you must specify the same port number in all the files.
You can use the WLM GUI to set up the global arbiter configuration file,
as described in “Using the WLM GUI to set up the global arbiter
configuration file” on page 267. Otherwise, you can use a text editor to

266 Chapter 7
 Managing SLOs across partitions
Setting up your WLM global arbiter configuration file

create or modify this configuration file. To follow is the syntax of the par
structure, followed by an example structure. An explanation of the
syntax specific for each keyword is provided in subsequent sections.
If your configuration uses a previously supported structure type, such as
vpar or npar_icod, WLM silently interprets these as a par structure.

par structure
The structure takes the following format:
par {
[ interval = number_of_seconds; ]
[ port = port_number; ]
[ wlmpardstats_size_limit = number_of_megabytes; ]
[ utilitypri = integer; ]
[ utility_reserve_threshold = integer; ]

}
Here is an example par structure:
par {
interval = 180;
port = 3701;
wlmpardstats_size_limit = 3;
utilitypri = 2;
utility_reserve_threshold = 10;
}

Using the WLM GUI to set up the global arbiter

configuration file
You can use the WLM GUI (/opt/wlm/bin/wlmgui) to set up the global
arbiter configuration file. For information on using the WLM GUI to
accomplish various tasks, see its online help.
The following steps show how to begin setting up the global arbiter
configuration file using the GUI.

Step 1. Set your DISPLAY environment variable.

Step 2. Start the GUI:

# /opt/wlm/bin/wlmgui

Chapter 7 267
Managing SLOs across partitions
Setting up your WLM global arbiter configuration file

Step 3. Select the Modify tab.

Step 4. Select the [New] button.

268 Chapter 7
 Managing SLOs across partitions
Setting up your WLM global arbiter configuration file

Step 5. Select the “Global arbiter configuration” box at the top of the right pane,
as in the following example. (The [Add], [Copy], and [Remove] buttons
are for setting up the WLM configurations for the partitions themselves.
You select a partition in the left pane to modify the WLM configuration
for that partition.)

Chapter 7 269
Managing SLOs across partitions
Setting up your WLM global arbiter configuration file

Step 6. Select the “Global Arbiter” item in the left pane. The right pane changes,
allowing you to fill in the various fields for the global arbiter
configuration keywords. The syntax for each of the keyword values you
specify is described in the remaining sections of this chapter. (The fields
listed in the top of the right pane are used when you want to open an
existing configuration; that is, for “Hostname” you would enter the name
of the host on which the configuration file resides, for “Port” you would
enter the port to use when connecting to the host, and so on.)

Step 7. When you have finished defining the various global arbiter settings,
select the [Commit changes] button to save the current configuration
in memory. To save changes to disk, go to the Deploy tab. (The file is
saved to the file specified in the Filename field in the Modify tab when
the system is selected in the left pane.)

Specifying the global arbiter interval (optional)

Specify how often the WLM global arbiter is to check for input from the
WLM instances—and potentially alter the number of cores for the
partitions—using the keyword interval. The syntax is:

270 Chapter 7
 Managing SLOs across partitions
Setting up your WLM global arbiter configuration file

interval = number_of_seconds;
where
interval Is a optional keyword.
number_of_seconds
Is an integer value greater than or equal to 1 indicating
how often, in seconds, WLM should consider moving
cores between partitions.

NOTE The interval for your global arbiter should be larger

than the largest WLM interval being used on the
system.

When generating audit data (with the wlmpard -t

option), number_of_seconds should be no more than
120 (twice the suggested interval for the WLM
instances when auditing). This value ensures the audit
data sampling rate is sufficiently frequent to:

• Minimize the amount of audit data lost if the WLM

global arbiter daemon exits unexpectedly
• Minimize the effect of changes in the number of
available cores (due to WLM management of
partition resources)

Specifying the port (optional)

The port keyword is an optional keyword specifying which port the
WLM global arbiter should monitor for input from the various WLM
instances. Indicate a port using the following syntax:
port = port_number;
where
port Is an optional keyword.
port_number Is a port number greater than 0 that the WLM global
arbiter should monitor to collect input from the WLM
instances running on the partitions. If you specify a

Chapter 7 271
Managing SLOs across partitions
Setting up your WLM global arbiter configuration file

port number in the WLM global arbiter configuration

file, specify the same port number in each partition’s
WLM configuration file.
If you do not specify a port, wlmpard searches the file /etc/services for the
first line with the following format:
hp-wlmpar port_number/tcp
If such an entry is found, port_number is used as the port. If such an
entry is not found, the default port of 9691 is used, assuming it is not in
/etc/services with protocol tcp. If it is, an error is issued.

Trimming the global arbiter statistics log

automatically (optional)
You can automatically trim the global arbiter statistics log file
/var/opt/wlm/wlmpardstats. This file is created when you use the -l
option to wlmpard. Enable automatic trimming of the file by using the
wlmpardstats_size_limit keyword. The syntax is:
wlmpardstats_size_limit = number_of_megabytes;
where
wlmpardstats_size_limit Is a optional keyword.
number_of_megabytes Is an integer value from 0 to 2048.
Once a file’s size is greater than
number_of_megabytes, the file is
trimmed. The default value is 0,
which disables automatic trimming.
The wlmpardstats file is trimmed by
renaming it wlmpardstats.old. Then
a new wlmpardstats file is started.
The wlmpardstats.old file includes a
line at the end of the file indicating
that the file has been automatically
trimmed.

272 Chapter 7
 Managing SLOs across partitions
Setting up your WLM global arbiter configuration file

Specifying the priority at which to use Temporary

Instant Capacity or Pay per use resources (optional)
While wlmpard has always managed migration of cores across partitions
for WLM, it also now provides management of Temporary Instant
Capacity (TiCAP) and Pay per use (PPU) resources for WLM. This
management is available on standalone systems, as well as across a
collection of partitions. With the utilitypri keyword, wlmpard
optimizes the Temporary Instant Capacity or Pay per use resources. It
determines the amount of resources needed to meet your workloads’
SLOs, then adjusts the total active cores to meet demand. Owned cores
are always kept active.
If you have Temporary Instant Capacity (v6 or later) or Pay per use (v4,
v7, or later) resources available on a system, WLM can help you optimize
the use of those resources—using them only as needed to meet the
service-level objectives for your workloads. To use wlmpard to optimize
the use of these resources, follow the steps given previously in the section
“Setting up cross-partition management” on page 260—with one
exception: Specify the utilitypri keyword in the global arbiter
configuration file. This keyword works with Temporary Instant Capacity
v6 or later and with PPU v4, v7, and later.

NOTE The utilitypri keyword allows WLM—when Temporary Instant

Capacity is available—to adjust the total of cores to meet demand. Also,
this keyword ensures WLM maintains compliance with your Temporary
Instant Capacity usage rights. When the prepaid amount of temporary
capacity days have expired, WLM no longer attempts to activate the
temporary resources. In addition, by default WLM will not activate
Temporary Instant Capacity when 15 or fewer processing days of
temporary capacity are available; in this case, you must purchase extra
capacity. You can change this default by setting the
utility_reserve_threshold, as described in “Specifying the reserve
threshold that determines when WLM stops activating temporary
capacity resources” on page 274. Before adding the capacity, be sure to
stop wlmpard (using the -k option). For more information on Temporary
Instant Capacity, see “Integrating with Temporary Instant Capacity
(TiCAP)/ Pay per use (PPU)” on page 410. For information about how to
stop wlmpard, see Appendix A, “WLM command reference,” on page 363.

This keyword has the syntax:

Chapter 7 273
Managing SLOs across partitions
Setting up your WLM global arbiter configuration file

utilitypri = integer;
where
utilitypri Is an optional keyword.
integer Is an integer value greater than or equal to 1. If
Temporary Instant Capacity or PPU resources exist,
they are used whenever SLOs with a priority from 1 to
integer (inclusive) are demanding more cores.

Specifying the reserve threshold that determines

when WLM stops activating temporary capacity
resources
By default, if 15 or fewer processing days of Temporary Instant Capacity
(TiCAP) resources remain available, WLM stops activating temporary
capacity resources. You must then purchase additional resources.
Beginning with WLM A.03.02, you can change this default by setting the
WLM global arbiter utility_reserve_threshold keyword. The value
assigned to this keyword determines how long the WLM global arbiter
continues allocating temporary capacity resources (above the owned
number of cores). For example, if you set the keyword to the value 10, the
global arbiter continues allocating temporary capacity resources until 10
or fewer processing days of temporary capacity resources remain
available.
This keyword has the syntax:
utility_reserve_threshold = integer;
where
utility_reserve_threshold
Is an optional keyword.
integer
Is an integer value greater than or equal to 0. Specify a
value appropriate for the amount of temporary capacity
resources available on your system. As long as the
number of processing days of temporary capacity
resources is greater than integer, WLM continues
allocating temporary capacity resources. When the
number of available processing days becomes equal to

274 Chapter 7
 Managing SLOs across partitions
Setting up your WLM global arbiter configuration file

(or less than) integer, you must purchase additional

resources. Before adding capacity, be sure to stop
wlmpard (using the -k option) and all wlmd clients on
the complex. You can set the keyword to 0 to cause the
global arbiter to always activate temporary capacity
resources as long as any number of temporary capacity
resources are available.
If you assign a value that is too high, the amount of
temporary capacity can reach the threshold too quickly,
causing WLM to stop using temporary capacity sooner
than preferred. Although you can set the value to 0
(enabling WLM to activate temporary capacity as long
as any amount is available), you could set the value too
low in certain circumstances, such as on systems with
large workloads. When the value is too low, temporary
capacity could be consumed so quickly that WLM might
not detect the threshold breach in time and would
continue allocating reserves that no longer exist. This
would result in errors when WLM attempts to move
these temporary capacity cores across partitions. For
information on additional restrictions involving
activation of temporary capacity resources, see the
Instant Capacity (iCAP) documentation.

NOTE HP recommends keeping some quantity of temporary capacity in reserve.

Purchase of TiCAP codewords (required to activate additional temporary
capacity cores) may take one or more days, so having a buffer of
temporary capacity allows you to avoid delays in activation of additional
cores. Instant Access Capacity (IAC) is provided with the initial purchase
of a temporary capacity component to give you an immediate buffer of
temporary capacity in case extra capacity is needed before you can
purchase a TiCAP codeword. However, IAC only provides an initial
buffer; ongoing purchases of additional temporary capacity are
recommended to replenish this capacity.

Chapter 7 275
Managing SLOs across partitions
Setting up your WLM global arbiter configuration file

276 Chapter 7
8 Management of nested nPars /
vPars / workload groups
You can manage any combination of FSS or PSET-based workload groups
inside virtual partitions inside nPartitions if desired.

NOTE You can use FSS and PSET-based workload groups with partition
management. Certain software restrictions apply to using PSET-based
groups with virtual partitions (vPars), Instant Capacity, and Pay per use.
For more information, see the WLM Release Notes
(/opt/wlm/share/doc/Rel_Notes).

Setting up the various configurations

The following discussions only indicate where configuration files are
needed. For information on the WLM configuration file, see Chapter 5,
“Configuring WLM,” on page 135. For detailed information on setting up
your wlmpard configuration, see Chapter 7, “Managing SLOs across
partitions,” on page 255.

Managing FSS and PSET-based groups inside vPars

inside nPars (Instant Capacity available in the
complex)
Consider a complex, such as the one shown in Figure 8-1, consisting of
three nPartitions, with two of those nPartitions each having three virtual
partitions, and the third partition divided into two FSS workload groups
and a PSET-based workload group.

Chapter 8 277
Management of nested nPars / vPars / workload groups
Setting up the various configurations

Figure 8-1 Nested partitions to be managed (with Instant Capacity)

vpar0 vpar0 FSS1

vpar1 vpar1 FSS2

vpar2 vpar2 PSET

nPar1 nPar2 nPar3

Assume you want to share cores, as indicated by the arrows in the figure,
among the:

• Virtual partitions within nPar1

• Virtual partitions within nPar2
• FSS and PSET-based workload groups within nPar3
• Three nPartitions
Instant Capacity (iCAP, formerly known as iCOD) is available on the
complex so WLM can migrate your rights to use the product across the
nPartitions to simulate CPU (core) movement. With Instant Capacity
present, you must have only one wlmpard managing the partitions. In
particular:

Step 1. Set up a wlmpard configuration on some system, say mysystem.

mysystem can be in the complex or on another system on your network.

In this file, say myfile, specify the utilitypri keyword to indicate the
range of SLO priorities that can cause WLM to activate Temporary
Instant Capacity (TiCAP) resources.

If you are not using Temporary Instant Capacity resources, you can omit
the utilitypri keyword.

278 Chapter 8
 Management of nested nPars / vPars / workload groups
Setting up the various configurations

NOTE Specifying this keyword ensures WLM maintains compliance with your
Temporary Instant Capacity (TiCAP) usage rights. When your prepaid
amount of temporary capacity expires, WLM no longer attempts to use
the temporary resources.

When 15 or fewer processing days (the default) of temporary capacity are

available, WLM stops activating Temporary Instant Capacity; in this
case, you must purchase extra capacity. Before you add the capacity, stop
wlmpard (using the -k option). For information about how to stop
wlmpard, see Appendix A, “WLM command reference,” on page 363.

You can change the 15-day default by setting the WLM global arbiter
utility_reserve_threshold keyword. For more information, see
“Specifying the reserve threshold that determines when WLM stops
activating temporary capacity resources” on page 274 or see
wlmparconf(4).

Step 2. Start wlmpard on mysystem.

Use the file you created in the previous step with wlmpard:

# wlmpard -a myfile

Step 3. Set up and start a configuration for wlmd in each virtual partition.

Each configuration must include a primary_host statement of the form:

primary_host = mysystem;

This configuration can be just for the virtual partition itself, or you can
add a prm structure and create FSS and PSET-based workload groups
inside the virtual partition.

Step 4. Set up and start a configuration for wlmd in nPar3 to manage the FSS
and PSET-based workload groups.

This configuration must include a primary_host statement of the form:

primary_host = mysystem;

Chapter 8 279
Management of nested nPars / vPars / workload groups
Setting up the various configurations

Managing FSS and PSET-based groups inside vPars

inside nPars (Instant Capacity not available)
Consider the same complex as before, but without Instant Capacity.
Movement of cores across the nPartitions cannot be simulated.
Figure 8-2 shows this complex.

Figure 8-2 Nested partitions to be managed (without Instant Capacity)

vpar0 vpar0 FSS1

vpar1 vpar1 FSS2

vpar2 vpar2 PSET

nPar1 nPar2 nPar3

Again, assume you want to share cores, as indicated by the arrows in the
figure, among the:

• Virtual partitions within nPar1

• Virtual partitions within nPar2
• FSS and PSET-based workload groups within nPar3

280 Chapter 8
 Management of nested nPars / vPars / workload groups
Setting up the various configurations

With Instant Capacity not available, you must have one wlmpard for each
nPartition containing virtual partitions. In particular:

Step 1. Set up nPar1.

a. Set up and start a configuration for wlmpard on some system, say

mysystem1.
mysystem1 can be in the complex or another system on your network.
b. Set up and start a configuration for wlmd in each virtual partition in
the nPartition
Each configuration must include a primary_host statement of the
form:
primary_host = mysystem1;

Step 2. Set up nPar2.

a. Set up and start a configuration for wlmpard on some system, say

mysystem2, and start wlmpard.
mysystem2 can be in the complex or another system on your network.
b. Set up and start a configuration for wlmd in each virtual partition in
the nPartition.
Each configuration must include a primary_host statement of the
form:
primary_host = mysystem2;

Step 3. Set up and start a configuration for wlmd in nPar3 to manage the FSS
and PSET-based workload groups.

Chapter 8 281
Management of nested nPars / vPars / workload groups
Managing FSS and PSET-based groups inside vPars

Managing FSS and PSET-based groups inside

vPars
If your system is not broken into nPartitions, you do not need to set up
your configurations based on whether the complex has Instant Capacity.
You just need to:

Step 1. Run one wlmpard to manage the system’s virtual partitions.

Each virtual partition will have a configuration for wlmd with a

primary_host statement naming the system where wlmpard is running.

Step 2. Create your FSS and PSET-based workload groups in each virtual
partition’s WLM configuration as desired.

282 Chapter 8
9 Example configuration files

This chapter presents the example configuration files available from the
/opt/wlm/examples/wlmconf/ directory, as well as an example from the
/opt/wlm/toolkits/weblogic/config/ directory. These examples show how to
use the syntax discussed in Chapter 5, “Configuring WLM,” on page 135.

NOTE Copy these examples to another directory before modifying them. Items
kept under /opt/wlm/ may be replaced or altered by future WLM product
updates.

The following list provides an overview of the available example files.

The files are listed alphabetically, not by complexity.

• “distribute_excess.wlm” on page 286

Example configuration file demonstrating the use of the weight and
distribute_excess tunables. This functionality is used to manage
the distribution of resources among workload groups after honoring
performance goals specified in slo structures.
• “enabling_event.wlm” on page 289
A configuration file demonstrating the use of WLM to enable or
disable an SLO when a certain event occurs.
• “entitlement_per_process.wlm” on page 291
A configuration file that demonstrates the use of a shares-per-metric
entitlement request. A workload group’s entitlement is based directly
on the number of currently active processes running in the group.
• “fixed_entitlement.wlm” on page 294
This example configuration illustrates the use of WLM for allocating
a fixed entitlement to a particular group of users.

Chapter 9 283
Example configuration files

• “manual_cpucount.wlm” on page 296

A configuration file to help a WLM user characterize the behavior of
a workload. The goal is to determine how a workload, placed in a
PSET-based workload group, responds to a series of changes in the
number of CPU resources in the PSET. This example is located in the
directory /opt/wlm/toolkits/weblogic/config/.
• “manual_entitlement.wlm” on page 298
A configuration file to help a WLM user characterize the behavior of
a workload. The goal is to determine how a workload responds to a
series of entitlements.
• “metric_condition.wlm” on page 301
Configuration file to illustrate that an SLO can be enabled based
upon the value of a metric (in this case, the metric is provided by a
glance data collector provided with the WLM product). Metrics can
be used in both the goal statement and the condition statement of
a single SLO.
• “par_manual_allocation.wlm” on page 304,
“par_manual_allocation.wlmpar” on page 307
These configuration files demonstrate how WLM can resize HP-UX
Virtual Partitions (vPars) and nPartitions (nPars). In this
configuration, you manually request the number of CPU resources
for a partition by using the wlmsend command to feed the request to
WLM. Configure WLM in each partition on the system using the
.wlm file. Configure the WLM global arbiter in one partition using
the .wlmpar file.
• “par_usage_goal.wlm” on page 310,
“par_usage_goal.wlmpar” on page 312
These configuration files demonstrate WLM’s ability to resize HP-UX
Virtual Partitions and nPartitions based on a usage goal for
service-level objectives. Configure WLM in each virtual partition on
the system using the .wlm file. Configure the WLM global arbiter in
one vPar using the .wlmpar file.
• “performance_goal.template” on page 315
This file has a different file name extension (.template instead of
.wlm). That is simply because this file distinguishes between
configuration file special keywords and user-modifiable values by
placing the items that a user would need to customize within square

284 Chapter 9
 Example configuration files

brackets ([, ]). Because of the presence of the square brackets, the
sample file will not pass the syntax-checking mode of wlmd (wlmd -c
template).
• “stretch_goal.wlm” on page 318
Example configuration file to demonstrate how to use multiple SLOs
for the same workload (but at different priority levels) to specify a
stretch goal for a workload. A stretch goal is one that we would like
to have met if all other higher-priority SLOs are being satisfied and
additional CPU resources are available.
• “time_activated.wlm” on page 321
This configuration file demonstrates the use of WLM for allocating a
fixed entitlement to a particular group of users only during a certain
time period.
• “transient_groups.wlm” on page 323
This configuration file demonstrates the use of transient groups. The
groups in this configuration consume no resources when they have
no active SLOs.
• “twice_weekly_boost.wlm” on page 326
This configuration file demonstrates a conditional entitlement with a
moderately complex condition.
• “usage_goal.wlm” on page 331
This configuration demonstrates the usage goal for SLOs. This type
of goal is very different from the typical performance goal in that it
does not require explicit metric data.
• “usage_stretch_goal.wlm” on page 334
This configuration demonstrates how to use multiple SLOs for
several workloads, defining a stretch goal in addition to a base usage
goal for each workload.
• “user_application_records.wlm” on page 338
A configuration file that demonstrates the use of, and precedence
between, user and application records in placing processes in
workload groups.

Chapter 9 285
Example configuration files
distribute_excess.wlm

NOTE For example configuration files that you can use with Oracle instances,
see the section “How do I get started with ODBTK?” on page 429. For
pointers to the example configurations for the various WLM toolkits, see
the EXAMPLES section of wlmtk(5).

distribute_excess.wlm
This example features the distribute_excess and weight keywords.
#
# Name:
# distribute_excess.wlm
#
# Version information:
#
# (C) Copyright 2001-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.9 $
#
# Caveats:
# DO NOT MODIFY this script in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# Demonstrate the use of the weight and distribute_excess keywords
# to distribute resources among groups.
#
# Dependencies:
# This example was designed to run with HP-UX WLM version A.01.01
# or later.
#

286 Chapter 9
 Example configuration files
distribute_excess.wlm

# prm structure
#
# In this example we have two groups using the machine, Orders
# and Sales. In the event there are additional resources available,
# we’d like for Sales to get three shares for every share that Orders
# receives.
#
# See wlmconf(4) for complete HP-UX WLM configuration information.
#
prm {
groups= OTHERS : 1,
Orders : 2,
Sales : 3;
weight= Orders : 1,
Sales : 3;
}

#
# slo structure
#
# In this example we have two SLOs, one for actual order processing
# and another for sales’ product availability requests. These are
# deemed to be equal in priority and have goals based on the
# response times of their applications.
#
# In the event that both goals are met, we want to distribute the
# excess CPU resources according to the weight specification above.
# See the tune structure explanation for details on what the impact
# might be in this situation.
#
slo order_processing {
pri = 1;
mincpu = 0;
maxcpu = 100;
entity = PRM group Orders;
goal = metric order_transaction_time < 10.0;
}

slo product_availability {
pri = 1;
mincpu = 0;
maxcpu = 100;
entity = PRM group Sales;
goal = metric sales_request_time < 5.0;
}

Chapter 9 287
Example configuration files
distribute_excess.wlm

# tune structure
#
# We must define a data collector for every metric used in
# SLO definitions. In this example, we add a global tune structure
# where we enable distribution of excess shares to groups defined in
# the prm structure above. This is accomplished by simply setting
# the keyword distribute_excess to 1 (TRUE). Without this setting,
# HP-UX WLM would allocate all excess shares to the OTHERS group.
#
# HP-UX WLM will, by default, provide an allocation sufficient to meet
# the specified goals. Let us assume that both goals are being met and
# that the Orders group is consuming 20% of the CPU resources and
# the Sales group is also consuming 20%. Then 60% of the machine is
# available for distribution to the two groups. If distribute_excess
# is enabled, WLM will ultimately allocate about 25% of the CPU
# resources to the Orders group and about 75% of the CPU resources to
# the Sales group, reflecting the 3:1 weight ratio specified for the
# groups in the prm structure. (The OTHERS group must get a minimum
# of 1% of the CPU. This 1% will be taken from either the Sales group
# or Orders group. As a result, WLM will not be able to grant CPU
# exactly in the 3:1 weight ratio.)
#
# Enabling distribute_excess is likely to reduce the response
# times for both groups well below the goals specified (for example,
# the sales_request_time may drop down to 3 seconds). Without the
# distribute_excess keyword set, HP-UX WLM would keep the response
# times close to the goals (so, sales_request_time would be kept
# around 4.5 seconds).
#
# With distribute_excess enabled, HP-UX WLM allocates excess shares so
# that the resulting allocations are as close as possible to the
# weight distribution without decreasing allocations resulting from
# SLOs. Thus, HP-UX WLM will distribute CPU resources sufficient to
# meet the SLOs and only after that action will HP-UX WLM begin
# distributing excess shares to achieve the weight distribution.
#
# Consider yet another scenario where SLO goals are being met.
# However, the Orders group is using 50% of the resources to meet its
# response time goal, and the Sales group is using only 20%. HP-UX WLM
# tries to match the allocations according to the weight
# specifications, but it will not reduce an allocation if doing so
# will cause the SLOs to fail (the goals to not be achieved).
# HP-UX WLM will give the Sales group the remaining 30% of the CPU
# resources so that the resulting allocation is 50% for each group.
# This does not meet the 3:1 ratio (that is, 75%/25%), but doing so
# would cause the order_processing SLO to fail. (As OTHERS must get

288 Chapter 9
 Example configuration files
enabling_event.wlm

# at least 1% of the CPU, the allocation for either the Sales group
# or Orders group would be reduced by 1%.)
#
tune {
distribute_excess = 1;
}

tune sales_request_time {
coll_argv = /home/sales/data_collector;
}

tune order_transaction_time {
coll_argv = /home/orders/data_collector;
}
For more information on the distribute_excess and weight keywords,
see “Distributing excess CPU resources to your workloads (optional)” on
page 218 and “Weighting a group so it gets more CPU resources
(optional)” on page 178.

enabling_event.wlm
This example enables an SLO based on an event.
#
# Name:
# enabling_event.wlm
#
# Version information:
#
# (C) Copyright 2001-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.9 $
#
# Caveats:
# DO NOT MODIFY this script in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.

Chapter 9 289
Example configuration files
enabling_event.wlm

# Purpose:
# Demonstrate the use of HP-UX WLM to enable a service-level objective
# (SLO) when a certain event occurs.
#
# Dependencies:
# This example was designed to run with version HP-UX WLM A.01.02
# or later.
#

#
# prm structure
#
# See wlmconf(4) for complete HP-UX WLM configuration information.
#
# Define workload groups in the prm structure. Individual users are
# assigned to groups in this structure as well.
#
# In this example configuration, the user backup_meister can execute
# applications in only the Backups group.
#

prm {
groups = Backups : 3;
users = backup_meister: Backups;
}

#
# slo structure
#
# The following slo structure is enabled and disabled based on the
# value of the metric backup_running. If backup_running’s value is
# zero then the SLO is disabled, and any application running in the
# group Backups will get only 1% of the CPU resources. When the
# value is nonzero (for example, 1) the SLO is enabled and the groups
# within the Backups group get a fixed allocation of 60% of the CPU
# resources on the system.
#
slo backup_processing {
pri = 1;
cpushares = 60 total;
entity = PRM group Backups;
condition = metric backup_running;
}

290 Chapter 9
 Example configuration files
entitlement_per_process.wlm

# tune structure
#
# Use of a metric in a SLO structure, whether it is a goal or
# condition, requires that the metric have a tune structure associated
# with it. The structure must specify the data collector for the
# metric. In this example, the collector specified with the coll_argv
# keyword is wlmrcvdc. This allows the metric backup_running to be set
# with wlmsend from a command line. For example,
#
# % wlmsend backup_running 1
#
# would enable the SLO above.
#
tune backup_running {
coll_argv = wlmrcvdc;
}
For information on the condition keyword, see “Specifying when the
SLO is active (optional)” on page 205.

entitlement_per_process.wlm
The following example shows how to request five CPU shares for each
active process in a workload group.
#
# Name:
# entitlement_per_process.wlm
#
# Version information:
#
# (C) Copyright 2001-2065 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.14 $
#
# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#

Chapter 9 291
Example configuration files
entitlement_per_process.wlm

# Purpose:
# Demonstrate the use of a shares-per-metric goal.
#
# A machine hosts a group’s web servers. However, the group would
# like to use the rest of the CPU cycles without impacting the web
# servers, which are often not busy. From past experience, they
# have determined an httpd base entitlement (allocation) of 10
# percent of the CPU resources gives good response for random queries,
# and that sustained web processing can be done by providing an
# additional 5 shares per active (not sleeping) process. The httpd
# processes and their children (CGI scripts, servlets, etc) that were
# recently active are included in the count. See the glance(1)
# documentation for more information on available metrics.
#
# Components:
# The glance toolkit is used. See glance_app(1M) for more
# information on the glance data collectors.
#
# Allocation change frequency:
# Because wlm_interval is not explicitly set, the 60 second default
# is used. This means wlmd will collect measurements and make
# allocation changes every 60 seconds.
#
# Dependencies:
# This example was designed to run with HP-UX WLM version A.01.02 or
# later. It uses the cpushares keyword introduced in A.01.02, so
# is incompatible with earlier versions of HP-UX WLM.
#

#
# prm structure
# Create workload groups. Designate which workload binaries will
# be placed in each. We will be actively managing one workload,
# apache, and leaving the rest of the CPU resources to workload
# group OTHERS.
#
# See wlmconf(4) for complete HP-UX WLM configuration information.
#
prm {
groups = OTHERS : 1,
servers : 2 ;

apps = servers : /opt/hpws/apache/bin/httpd ;

292 Chapter 9
 Example configuration files
entitlement_per_process.wlm

# Grant 5 shares to servers for every active httpd process.

# Never allow the allocation to fall below 10 shares, nor to
# rise above 90% of the CPU resources.
#
slo servers_proportional {
pri = 1;
mincpu = 10;
maxcpu = 90;
entity = PRM group servers;
cpushares = 5 more per metric apache.active_procs ;
}

# Any CPU resources that remain after satisfying the above SLO is given to
# the OTHERS group by default. You can change this default using the
# distribute_excess keyword. For more information on this keyword, see
# the wlmconf(4) manpage.

#
# Collect the glance metric APP_ACTIVE_PROC as a measure
# of how many httpd processes are actually busy.
#
# NOTE: If the number of active processes is too volatile, consider using the
# smooth(1M) tool to calculate a running average, smoothing out the extreme
# values. smooth is shown below, commented out.
#
tune apache.active_procs {
coll_argv =
wlmrcvdc
# smooth
glance_prm APP_ACTIVE_PROC servers ;
}
For information on the cpushares keyword, see “Specifying a
shares-per-metric allocation request (optional)” on page 205.

Chapter 9 293
Example configuration files
fixed_entitlement.wlm

fixed_entitlement.wlm
The following example shows a fixed entitlement for a workload group.
#
# Name:
# fixed_entitlement.wlm
#
# Version information:
#
# (C) Copyright 2001-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.7 $
#
# Caveats:
# DO NOT MODIFY this script in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# Demonstrate the use of HP-UX WLM in allocating a fixed entitlement
# (allocation) to a particular group of users.
#
# Dependencies:
# This example was designed to run with version HP-UX WLM A.01.02
# or later.
#

#
# prm structure
#
# See wlmconf(4) for complete HP-UX WLM configuration information.
#
# All workload groups must be defined in the prm structure. Individual
# users are assigned to groups in this structure as well.
#
# In this example, the user bob will have all of his applications
# run in the Marketing workload group. The user sally can execute
# applications in either Marketing or OTHERS. Marketing is listed
# first for sally, so it is the group that all of her applications
# will execute in by default. Because OTHERS is also listed, it is an
# alternate group for sally. She can move existing processes to, or
# start new processes in, alternate groups using the prmmove or prmrun

294 Chapter 9
 Example configuration files
fixed_entitlement.wlm

# commands. For more information, see prmmove(1) and prmrun(1).

#
# Note that the group OTHERS is a group created automatically.
# Applications run by users not referenced in the prm structure will
# execute in the OTHERS group. So, only bob and sally can execute
# applications in the Marketing group.
#

prm {
groups = Marketing : 2;
users = bob : Marketing,
sally: Marketing OTHERS;
}

#
# slo structure
#
# The keywords pri (priority) and entity (group to which
# the SLO applies) are required for any SLO specification.
#
# The cpushares statement requests a fixed allocation of 30% of the
# CPU resources on the system for the Marketing group.
#
slo Marketing_Analysis {
pri = 1;
cpushares = 30 total;
entity = PRM group Marketing;
}
For information on the cpushares keyword, see “Specifying a
shares-per-metric allocation request (optional)” on page 205.

Chapter 9 295
Example configuration files
manual_cpucount.wlm

manual_cpucount.wlm
This example is similar to the previous one: It allows you to easily step
through a number of different CPU allocations for a workload group. The
difference is that this configuration uses a PSET-based workload group.
When you change CPU allocations, you are changing the number of CPU
resources assigned to the group’s PSET. The file is located at
/opt/wlm/toolkits/weblogic/config/manual_cpucount.wlm.
#
# Name:
# manual_cpucount.wlm
#
# Version information:
#
# (c) Copyright 2002, Hewlett-Packard Company, all rights reserved.
#
# $Revision: 1.9 $
#
# Caveats:
# DO NOT MODIFY this script in its /opt/wlm/toolkits location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# This example is similar to the
# /opt/wlm/examples/wlmconf/manual_entitlement.wlm
# example. It lets a user or system administrator easily set the
# CPU count for a PRM PSET group using the wlmsend command.
#
# This is useful for benchmarking or capacity-planning situations--
# a benchmark can be run against an instance, then the PSET
# CPU count changed. After the count is changed, the benchmark
# can be measured again, all without restarting WLM or the instance
# or manually reconfiguring the PSET.
#
# Components:
# This example does use a data collector, but it has no other
# required configuration file.

296 Chapter 9
 Example configuration files
manual_cpucount.wlm

# Dependencies:
# This example was designed to run with HP-UX WLM version A.02.01 or
# later. It uses the CPU movement among PSET groups feature
# introduced in WLM A.02.01. Consequently, it is incompatible with
# earlier versions of HP-UX WLM.
#

#
# prm structure
# There is a single WebLogic instance, instA, being controlled
# in a WLM workload group, wls1_grp.
#
# The users statement allows the user named ‘wladmin’ to run jobs in
# OTHERS or wls1_grp, with group wls1_grp being his default group.
#

prm {
groups =
OTHERS : 1,
wls1_grp : PSET
;

# Now use a user record to place all processes owned by ‘wladmin’

# in the target group. This assumes that ‘wladmin’ runs the instance
# but no other resource-intensive jobs. If the user ‘wladmin’ runs
# other UNIX processes, they will be placed in the wls1_grp too, and
# compete for its resources.
users =
wladmin: wls1_grp OTHERS
;
}

#
# Create an SLO that allocates CPU resources to group wls1_grp based on the
# metric wls1_grp.desired.cpucount. If wls1_grp.desired.cpucount is 1.0, the
# allocation is 100, which is one core of CPU resources. 2 is 200, or two
# cores, and so on.
#
slo wls_base {
pri = 1;
entity = PRM group wls1_grp;
cpushares = 100 total per metric wls1_grp.desired.cpucount;
}

Chapter 9 297
Example configuration files
manual_entitlement.wlm

# Tell wlmrcvdc to watch for metrics coming in via command lines:

# % /opt/wlm/bin/wlmsend wls1_grp.desired.cpucount 1
# or
# % /opt/wlm/bin/wlmsend wls1_grp.desired.cpucount 2
#
tune wls1_grp.desired.cpucount {
coll_argv = wlmrcvdc ;
}

#
# Check for new metrics every 5 seconds.
# Also, turn on absolute CPU units, so resources on a 4-core box are
# represented as 400 shares instead of 100 shares.
#
tune {
wlm_interval = 5;
absolute_cpu_units = 1;
}
For information on the cpushares keyword, see “Specifying a
shares-per-metric allocation request (optional)” on page 205. For
information on using wlmrcvdc and wlmsend in this manner, see
“Sending data from the command line” on page 495.

manual_entitlement.wlm
This next example is helpful in determining what type of performance to
expect from a workload at various amounts of CPU resources. With that
information, you can create better service-level objectives for the
workload. As such, this example is a good model to follow when setting
up your WLM configuration.
#
# Name:
# manual_entitlement.wlm
#
# Version information:
#
# (C) Copyright 2001-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.14 $

298 Chapter 9
 Example configuration files
manual_entitlement.wlm

# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# This example demonstrates the use of a parametric entitlement
# (allocation) to characterize the behavior of a workload. The user
# can directly set an allocation for a workload with wlmsend. By
# gradually increasing the workload’s allocation with a series of
# wlmsend commands, the operator can determine how the workload
# behaves with various amounts of CPU. This research can then be
# compared with similar data for the other workloads that will run on
# the system. This comparison gives you insight into which workloads
# you can combine (based on their needed CPU) on a single system
# and still achieve the desired SLOs. Alternatively, if you
# cannot give a workload its optimal amount of CPU, you will know
# what kind of performance to expect with a smaller allocation.
#
# The user’s workload is placed in grp1 and is associated with
# a metric called myapp.desired.allocation. The metric value
# represents an absolute allocation request as defined by the
# controlling SLO’s cpushares statement (see the definition for
# grp1 below).
#
# The workload is tested by sending a series of allocation requests
# like the following:
#
# % wlmsend myapp.desired.allocation 10
# % <manually measure workload performance under new allocation>
# % wlmsend myapp.desired.allocation 20
# % <manually measure workload performance under new allocation>
# % wlmsend myapp.desired.allocation 30
# % <manually measure workload performance under new allocation>
# % wlmsend myapp.desired.allocation 40
# % <manually measure workload performance under new allocation>
# % wlmsend myapp.desired.allocation 50
# % <manually measure workload performance under new allocation>
# % wlmsend myapp.desired.allocation 60
# % <manually measure workload performance under new allocation>
# etc.
#
# After each allocation request is sent, the user must manually
# measure the workload performance to determine its response to

Chapter 9 299
Example configuration files
manual_entitlement.wlm

# the specific allocation.

# Components:
# Uses the wlmsend and wlmrcvdc tools to relay a metric from
# an outside user.
#
# Dependencies:
# This example was designed to run with HP-UX WLM version A.01.02 or
# later. It uses the cpushares keyword introduced in A.01.02, so
# is incompatible with earlier versions of HP-UX WLM.
#
#

#
# prm structure
# Create a workload group called grp1 and define the binaries that
# make it up. In this example, the apache webserver binary
# /opt/hpws/apache/bin/httpd and the apache benchmark utility
# /opt/hpws/apache/bin/ab are used as the workloads. This
# also illustrates how to place two different binaries into
# the same workload group. See the example configurations in
# /opt/wlm/toolkits/apache/config/ for more WLM configurations
# to place and control apache.
#
# See wlmconf(4) for complete HP-UX WLM configuration information.
#
prm {
groups = OTHERS : 1, grp1 : 2;
apps = grp1 : /opt/hpws/apache/bin/httpd,
grp1 : /opt/hpws/apache/bin/ab;
}

#
# Have HP-UX WLM manage the CPU allocation such that the workload group
# grp1 gets 1 share per metric. That is, setting the metric
# myapp.desired.allocation to 20 results in 20 shares for grp1,
# setting the metric myapp.desired.allocation to 50 results in 50
# shares for grp1, and so forth.
#
slo grp1 {
pri = 1;
entity = PRM group grp1;
cpushares = 1 total per metric myapp.desired.allocation;
}

300 Chapter 9
 Example configuration files
metric_condition.wlm

# Any CPU that remains after satisfying the above SLO is given to the
# OTHERS group by default. You can change this default using the
# distribute_excess keyword. For more information on this keyword, see
# the wlmconf(4) manpage.

#
# Relay a metric from the outside user.
#
tune myapp.desired.allocation {
coll_argv = wlmrcvdc;
}
For information on the cpushares keyword, see “Specifying a
shares-per-metric allocation request (optional)” on page 205. For
information on using wlmrcvdc and wlmsend in this manner, see
“Sending data from the command line” on page 495.

metric_condition.wlm
This example shows a metric enabling an SLO only when the associated
workload has work to do.
#
# Name:
# metric_condition.wlm
#
# Version information:
#
# (C) Copyright 2001-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.8 $
#
# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.

Chapter 9 301
Example configuration files
metric_condition.wlm

# Purpose:
# Demonstrate the use of HP-UX WLM to enable a service-level objective
# (SLO) when a measurable metric value is reached. Also make use of a
# glance data collector to provide a metric value.
#
# Components:
# The glance toolkit (included with HP-UX WLM) is used. See
# glance_prm(1M) for more information on the glance data collectors.
#
# Dependencies:
# This example was designed to run with version HP-UX WLM A.01.01
# or later.
#
# See wlmconf(4) for complete HP-UX WLM configuration information.
#

#
# prm structure
# Define all workload groups in the prm structure.
#
prm {
groups = OTHERS : 1,
jobs : 2;
apps = jobs: /opt/batch/bin/submit;
}

# slo structures
#
# This SLO has a metric goal. It also has a metric used in the
# condition statement. Both these metrics will require that more
# information be provided in metric-specific tune structures.
#
# This SLO becomes active based on the number of active jobs, once
# the server actually has jobs submitted to it. It attempts to keep
# the average job-completion time under 10 minutes (these are batch
# jobs, so we’re not dealing in seconds of response time) when there
# are any active jobs. If there are no jobs, this SLO is inactive.
#
slo job_processing {
pri = 1; # SLO of highest priority
mincpu = 40; # minimum CPU allocation (percentage)
maxcpu = 90; # maximum CPU allocation (percentage)
entity = PRM group jobs;
goal = metric avg_completion_time < 10;
condition = metric number_of_active_jobs > 0;

302 Chapter 9
 Example configuration files
metric_condition.wlm

}
# tune structures
#
# These structures provide the data collector information
# for the metrics used in the slo structure above.
#
# One data collector is a hypothetical application, written to
# calculate and provide average job-completion time in minutes.
#
# The other metric is calculated using the glance toolkit and
# a glance metric called APP_ALIVE_PROC.
#

tune avg_completion_time {
coll_argv = /opt/batch/metrics/job_complete_time -minutes;
}

tune number_of_active_jobs {
coll_argv = wlmrcvdc glance_prm APP_ALIVE_PROC jobs;
}
For information on the condition keyword, see “Specifying when the
SLO is active (optional)” on page 205.

Chapter 9 303
Example configuration files
par_manual_allocation.wlm

par_manual_allocation.wlm
This file, in combination with the global arbiter configuration file in the
next section, can migrate cores across HP-UX Virtual Partitions (vPars)
and/or nPartitions (nPars) based on the number of cores you request on
the command line using wlmsend. The way WLM manages cores depends
on the software enabled on the complex (such as Instant Capacity, Pay
per use, and Virtual Partitions).
Activate the WLM configuration file in each partition. However, you need
to activate the WLM global arbiter’s configuration in only one partition.
#
# Name:
# par_manual_allocation.wlm
#
# Version information:
#
# (C) Copyright 2003-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.4 $
#
# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# This example, used with par_manual_allocation.wlmpar, demonstrates
# WLM’s ability to resize HP-UX Virtual Partitions and/or
# nPartitions based on manual feedback from the user through the
# wlmsend command.
#
# The configuration is strictly host-based, not supporting FSS
# or PSET groups; thus, applications within a partition are
# treated as a single workload. Because the utilitypri feature is
# not used in par_manual_allocation.wlmpar, the total number of
# active cores remains constant, but the allocations change
# to meet the manual requests.
#
# The way WLM manages CPU resources depends on the software enabled
# on the complex (such as Instant Capacity, Pay per use, and Virtual
# Partitions.)

304 Chapter 9
 Example configuration files
par_manual_allocation.wlm

# Dependencies:
# This example was designed to run with HP-UX WLM version A.03.00 or
# later. (A.03.00 was the first version to support strictly
# host-based configurations.)
#
# To implement WLM’s dynamic partition resizing:
# 1. Set the primary_host keyword in this file
#
# 2. Copy this WLM configuration to each partition in the system
#
# 3. Adjust the priority for the SLO named slo_myslo to reflect the
# priority of the applications for the current partition relative
# to the priority of the applications in all the other partitions
#
# 4. Customize the configuration file
# par_manual_allocation.wlmpar used by the WLM global
# arbiter (see that file for details)
#
# 5. Activate the par_manual_allocation.wlmpar file on the
# primary host:
#
# wlmpard -a par_manual_allocation.wlmpar
#
# 6. Activate the WLM configuration file on each partition:
#
# wlmd -a par_manual_allocation.wlm
#
# NOTE: You will activate both the par_manual_allocation.wlmpar
# file and the par_manual_allocation.wlm file on the primary
# host.
#
# 7. Change the number of cores a partition requests using wlmsend
#
# Using the wlmsend command on a partition, you can explicitly
# request a certain number of cores for that partition. The
# configuration below defines a metric named num_cpus. You can
# change the value of this metric with wlmsend. For example, the
# following command requests 3 cores:
#
# % /opt/wlm/bin/wlmsend num_cpus 3
#
# After using wlmsend, wait one wlm_interval (set at 5 seconds
# below) then use the wlminfo command from the next step to see
# how the group’s allocation is affected. Continue changing the

Chapter 9 305
Example configuration files
par_manual_allocation.wlm

# num_cpus value to see how the workload behaves with various

# numbers of cores. With small partitions, you should be able to
# step through all the available cores and evaluate workload
# response quickly.
#
# 8. Monitor each SLO’s request for CPU shares, using the following
# wlminfo command:
#
# wlminfo slo -v [-l]
#
# The output will show the shares request (“Req” column)
# change for the partition as you change the num_cpus value
# using wlmsend.
#
# To monitor the partitions, use the following wlminfo command
# at the host on which wlmpard is running:
#
# wlminfo par -l
#
# The output will include information about the CPU resources
# associated with each partition.
#
# Now for the actual configuration components.
#
# The primary_host keyword specifies the host name for the partition where
# WLM’s global arbiter will run. (This keyword has the same value on each
# partition.)
#
# See wlmconf(4) for complete HP-UX WLM configuration information.
#
primary_host = myserver; # Change this value

#
# Set the interval on which WLM takes CPU requests and makes changes in CPU
# allocations to 5 seconds. (The default interval is 60 seconds. Using a
# smaller interval allows WLM to respond more quickly. If you change this
# interval, be sure the global arbiter interval set in par_usage_goal.wlmpar
# is greater than the new wlm_interval value you set here.)
#
tune {
wlm_interval = 5;
}

#
# Change the priority (pri) value after copying this file to each partition.
# This value (1 being the highest priority) indicates the importance of the

306 Chapter 9
 Example configuration files
par_manual_allocation.wlmpar

# current partition’s applications relative to the importance of the

# applications in all the other partitions.
#
# When managing partitions, WLM equates 1 core of CPU resources to 100
# shares. The cpushares statement causes the SLO to request 100 shares, or
# 1 core, multiplied by the metric num_cpus. So, if num_cpus = 7, the SLO
# requests 7 cores for the partition.
#
slo slo_myslo {
pri = 1; # Change this value
cpushares = 100 total per metric num_cpus;
}

#
# The following structure sets up the metric num_cpus that is used in the
# cpushares statement above. This set up allows you to change the metric’s
# value using wlmsend on the command line. See Steps 7 and 8 above for
# usage and monitoring examples.
#
tune num_cpus {
coll_argv = wlmrcvdc;
}
For more information on WLM partition management, see Chapter 7,
“Managing SLOs across partitions,” on page 255.

par_manual_allocation.wlmpar
This file is a configuration file for the WLM global arbiter. In
combination with the WLM configuration file in the previous section,
this file can migrate cores across HP-UX Virtual Partitions and/or
nPartitions based on the number of cores you request for a partition by
using the wlmsend command. The way WLM manages cores depends on
the software enabled on the complex (such as Instant Capacity, Pay per
use, and Virtual Partitions). This file also shows how several additional
par structure keywords (including utilitypri) are used (these are
commented out).
Activate the WLM global arbiter’s configuration in only one partition.
However, activate the WLM configuration file in each partition.

Chapter 9 307
Example configuration files
par_manual_allocation.wlmpar

#
# Name:
# par_manual_allocation.wlmpar
#
# Version information:
#
# (C) Copyright 2003-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.6 $
#
# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# This example, used with par_manual_allocation.wlm, demonstrates
# WLM’s ability to resize HP-UX Virtual Partitions and/or
# nPartitions based on manual feedback from the user through the
# wlmsend command.
#
# This configuration is for the WLM global arbiter, wlmpard, which
# takes CPU requests from the WLM instances in each partition.
# It then shifts cores between the partitions based on the requests
# and priorities of partition workloads. Because the utilitypri
# feature is not used here, the total number of active cores remains
# constant, but the CPU allocations change to meet the manual requests.
#
# The way WLM manages CPU resources depends on the software enabled
# on the complex (such as Instant Capacity, Pay per use, and Virtual
# Partitions.)
#
# Dependencies:
# This example was designed to run with HP-UX WLM version A.03.00 or
# later.
#
# To implement WLM’s dynamic partition resizing:
# See instructions in par_manual_allocation.wlm for the steps
# needed to configure WLM for dynamic partition resizing.
#
# The WLM global arbiter’s interval is set to 10 seconds. Every interval,
# the arbiter takes CPU requests from the WLM instances running on the
# partitions and makes changes in the partitions’ CPU allocations. (If you
# change the global arbiter interval, be sure it is greater than the

308 Chapter 9
 Example configuration files
par_manual_allocation.wlmpar

# wlm_interval value you use in any of the partitions’ WLM configuration

# files.)
#
# Several additional par structure keywords are included below but commented
# out. Use the port keyword to specify the port that the global arbiter
# should monitor for input from the various WLM instances. Specify a port
# number greater than 0. If you specify a port number, you must specify the
# same port number in each partition's WLM configuration file. The default
# port used by WLM is 9691. In the example below, port 9692 is specified.
#
# Use the wlmpardstats_size_limit keyword to automatically trim the global
# arbiter statistics log file /var/opt/wlm/wlmpardstats. This file is created
# when you use the -l option to wlmpard. Specify the file size (from 0 to
# 2048 megabytes) at which you want the file trimmed. The default is 0,
# which disables trimming. In the example below, the file would be trimmed
# when its size reaches 1024 megabytes.
#
# If Temporary Instant Capacity or Pay per use resources are available,
# you can optimize the use of these resources by specifying the utilitypri
# keyword. The global arbiter will then adjust the total number of active
# cores on the system to ensure that certain SLO resource demands are met.
# Specify an integer value greater than or equal to 1. This value determines
# the priority levels at which SLO demands will be met. In the example below,
# the value specified is 2, meaning that any available Temporary Instant
# Capacity or PPU resources are used whenever SLOs with a priority from 1 to
# 2 (inclusive) are demanding more CPU resources.
#
# See wlmparconf(4) for complete HP-UX WLM global arbiter configuration
# information.

par {
interval = 10;
# port = 9692;
# wlmpardstats_size_limit = 1024;
# utilitypri = 2;
}
For more information on WLM partition management, see Chapter 7,
“Managing SLOs across partitions,” on page 255.

Chapter 9 309
Example configuration files
par_usage_goal.wlm

par_usage_goal.wlm
This file, in combination with the global arbiter configuration file in the
next section, can migrate cores across HP-UX Virtual Partitions and/or
nPartitions based on usage goals. The way WLM manages cores depends
on the software enabled on the complex (such as Instant Capacity, Pay
per use, and Virtual Partitions).
Activate the WLM configuration file in each partition. However, you only
need to activate the WLM global arbiter’s configuration in one partition.
#
# Name:
# par_usage_goal.wlm
#
# Version information:
#
# (C) Copyright 2003-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.4 $
#
# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# This example, used with par_usage_goal.wlmpar, demonstrates WLM’s
# ability to resize HP-UX Virtual Partitions and/or nPartitions
# based on workload usage. The configuration is strictly host-based,
# not supporting FSS or PSET groups; thus, applications within a
# partition are treated as a single workload. Because the utilitypri
# feature is not used in par_usage_goal.wlmpar, the total number of
# active cores remains constant, but the CPU allocations for partitions
# change automatically to meet each partition’s usage needs.
#
# The way WLM manages CPU resources depends on the software enabled
# on the complex (such as Instant Capacity, Pay per use, and Virtual
# Partitions.)
#
# Dependencies:
# This example was designed to run with HP-UX WLM version A.03.00 or
# later. (A.03.00 was the first version to support strictly

310 Chapter 9
 Example configuration files
par_usage_goal.wlm

# host-based configurations. It was also the first version that does

# not require mincpu/maxcpu statements; thus, this configuration file
# must be run on A.03.00 or later.)
#
#
# To implement WLM’s dynamic partition resizing:
# 1. Set the primary_host keyword in this file
#
# 2. Copy this WLM configuration to each partition in the system
#
# 3. Adjust the priority for the SLO named slo_myslo to reflect the
# priority of the applications for the current partition relative
# to the priority of the applications in all the other partitions
#
# 4. Customize the configuration file par_usage_goal.wlmpar used by
# the WLM global arbiter (see that file for details)
#
# 5. Activate the par_usage_goal.wlmpar file on the primary host:
#
# wlmpard -a par_usage_goal.wlmpar
#
# 6. Activate the WLM configuration file on each partition:
#
# wlmd -a par_usage_goal.wlm
#
# NOTE: You will activate both the par_usage_goal.wlmpar file and
# the par_usage_goal.wlm file on the primary host.
#
# 7. Monitor each SLO’s request for CPU shares, using the following
# wlminfo command:
#
# wlminfo slo -v [-l]
#
# The output will show the shares request (“Req” column)
# increasing for the partitions as the loads on those partitions
# increase.
#
# To monitor the partitions, use the following wlminfo command
# at the host on which wlmpard is running:
#
# wlminfo par -l
#
# The output will include information about the CPU resources
# associated with each partition.
#
# The primary_host keyword specifies the host name for the partition

Chapter 9 311
Example configuration files
par_usage_goal.wlmpar

# where WLM’s global arbiter will run. (This keyword has the same value
# on each partition.)
#
# See wlmconf(4) for complete HP-UX WLM configuration information.
#
primary_host = myserver; # Change this value

#
# Set the interval on which WLM takes CPU requests and makes changes in CPU
# allocations to 5 seconds. (The default interval is 60 seconds. Using a
# smaller interval allows WLM to respond more quickly to changes in
# workload performance. If you change this interval, be sure the global
# arbiter interval set in par_usage_goal.wlmpar is greater than the new
# wlm_interval value you set here.)
#
tune {
wlm_interval = 5;
}

#
# Change the priority (pri) value after copying this file to each
# partition. This value (1 being the highest priority) indicates the
# importance of the current partition’s applications relative to
# the importance of the applications in all the other partitions.
#
slo slo_myslo {
pri = 1; # Change this value
goal = usage _CPU;
}
For more information on WLM partition management, see Chapter 7,
“Managing SLOs across partitions,” on page 255.

par_usage_goal.wlmpar
This file is a configuration file for the WLM global arbiter. In
combination with the WLM configuration file in the previous section,
this file can migrate cores across HP-UX Virtual Partitions and/or
nPartitions based on usage goals. The way WLM manages cores depends
on the software enabled on the complex (such as Instant Capacity, Pay

312 Chapter 9
 Example configuration files
par_usage_goal.wlmpar

per use, and Virtual Partitions). This file also shows how several
additional par structure keywords (including utilitypri) are used
(these are commented out).
Activate the WLM global arbiter’s configuration in only one partition.
However, activate the WLM configuration file in each partition to be
managed by WLM.
#
# Name:
# par_usage_goal.wlmpar
#
# Version information:
#
# (C) Copyright 2003-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.7 $
#
# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# This example, used with par_usage_goal.wlm, demonstrates WLM’s
# ability to resize either HP-UX Virtual Partitions or nPartitions
# based on workload usage.
#
# This configuration is for the WLM global arbiter, wlmpard, which
# takes CPU requests from the WLM instances in each partition.
# It then shifts cores between the partitions based on the requests
# and priorities of partition workloads. Because the utilitypri
# feature is not used here, the total number of active cores remains
# constant, but the CPU allocations for partitions change
# automatically to meet each partition’s usage needs. The way WLM
# manages CPU resources depends on the software enabled on the
# complex (such as Instant Capacity, Pay per use, and Virtual
# Partitions).
#
# Dependencies:
# This example was designed to run with HP-UX WLM version A.03.00 or
# later.
#
# To implement WLM’s dynamic partition resizing:
# See the instructions in par_usage_goal.wlm for the steps needed to

Chapter 9 313
Example configuration files
par_usage_goal.wlmpar

# configure WLM for dynamic partition resizing.

#
# The WLM global arbiter’s interval is set to 10 seconds. Every interval,
# the arbiter takes CPU requests from the WLM instances running on the
# partitions and makes changes in the partitions’ CPU allocations. (If you
# change the global arbiter interval, be sure it is greater than the
# wlm_interval value you use in any of the partitions’ WLM configuration
# files.)
#
# Several additional par structure keywords are included below but commented
# out. Use the port keyword to specify the port that the global arbiter
# should monitor for input from the various WLM instances. Specify a port
# number greater than 0. If you specify a port number, you must specify the
# same port number in each partition's WLM configuration file. The default
# port used by WLM is 9691. In the example below, port 9692 is specified.
#
# Use the wlmpardstats_size_limit keyword to automatically trim the global
# arbiter statistics log file /var/opt/wlm/wlmpardstats. This file is created
# when you use the -l option to wlmpard. Specify the file size (from 0 to
# 2048 megabytes) at which you want the file trimmed. The default is 0,
# which disables trimming. In the example below, the file would be trimmed
# when its size reaches 1024 megabytes.
#
# If Temporary Instant Capacity or Pay per use resources are available,
# you can optimize the use of these resources by specifying the utilitypri
# keyword. The global arbiter will then adjust the total number of active
# cores on the system to ensure that certain SLO resource demands are met.
# Specify an integer value greater than or equal to 1. This value determines
# the priority levels at which SLO demands will be met. In the example below,
# the value specified is 2, meaning that any available Temporary Instant
# Capacity or PPU resources are used whenever SLOs with a priority from 1 to
# 2 (inclusive) are demanding more CPU resources.
#
# See wlmparconf(4) for complete HP-UX WLM global arbiter configuration
# information.

par {
interval = 10;
# port = 9692;
# wlmpardstats_size_limit = 1024;
# utilitypri = 2;
}
For more information on WLM partition management, see Chapter 7,
“Managing SLOs across partitions,” on page 255.

314 Chapter 9
 Example configuration files
performance_goal.template

performance_goal.template
The following file is a template showing how to use various components
of the configuration file. The file shows how to use performance-based
goals to determine whether an SLO is being met. Values that you must
customize are shown in square brackets ([ ]). You must remove the
brackets.
#
# Name:
# performance_goal.template
#
# Version information:
#
# (C) Copyright 2001-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.5 $
#
# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# This file contains a SAMPLE HP-UX WLM configuration file, meant
# to expand on the descriptions given in the wlmconf(4) manpage.
#
# Specifically in this file, we illustrate the use of performance-
# based goals to determine whether an SLO is being met.
#
# Keep in mind that this example is for illustration purposes ONLY.
# While it does contain all the required components, the specific
# values (such as group, user, SLO names, and executable locations)
# are hypothetical. The service-level objectives (SLOs) and all
# other identifiers must be tailored to your environment.
#
# This sample file can be viewed as a simple template, as the non-
# keyword items that the user would need to customize are contained
# within square brackets ([]’s). Because of these brackets, this
# file will not “pass” the syntax-checking mode of wlmd.
#

Chapter 9 315
Example configuration files
performance_goal.template

##################
# PRM Components #
##################

#
# prm structure
#
# First, we define the workload groups.
#
# For this example, we will assume two basic workload groups:
# finance and sales
# Each group only has one application that we will monitor.
#
prm {
groups = [finance:2], [sales:3];
apps = [finance]: [/opt/fin_app/count_money], # app for finance group
[sales]: [/opt/sales/do_ebiz]; # app for sales group
}

############################
# Service-Level Objectives #
############################

#
# This is an SLO for the finance group and is only “active” on weekdays.
# It has a response-time goal, desiring that finance queries should
# complete in less than 2 seconds. A data collector to provide these
# response-time metrics to HP-UX WLM is specified later in a tune
# structure (a tune structure is required for all metrics used in an
# slo structure).
#
# In the goal line of this SLO, even though “metric” is a keyword, it could
# also have been contained within the brackets (as a user-configurable item).
# This is because there are other types of goal statements (such as usage)
# besides a metric (performance-based) goal. However, as this template is
# focused on showing the use of performance goals, “metric” is used
# explicitly, leaving just the “what-am-I-measuring?” piece as configurable.
#
slo [finance_query] {
pri = [1]; # SLO of highest priority
mincpu = [20]; # minimum CPU allocation (%)
maxcpu = [50]; # maximum CPU allocation (%)
entity = PRM group [finance];

316 Chapter 9
 Example configuration files
performance_goal.template

goal = metric [fin_app.query.resp_time < 2.0];

condition = [Mon - Fri]; # only active on weekdays
}
# On weekends, we do not expect any query transactions, but just in
# case, we will specify a nominal, fixed CPU allocation for this
# application for off-hours.
#
slo [finance_query_weekend] {
pri = [1];
mincpu = [5];
maxcpu = [5];
entity = PRM group [finance];
condition = [Sat - Sun];
}

#
# This is an SLO for the Sales group, active at all times (there are no
# conditions or exceptions).
#
slo [sales_query] {
pri = [1];
mincpu = [40];
maxcpu = [80];
entity = PRM group [sales];
goal = metric [sales_app.resp_time < 10.0];
}

#########################
# Global tune structure #
#########################

#
# Have HP-UX WLM check for new performance data (and make any necessary
# adjustments to allocations) every 30 seconds.
#
tune {
wlm_interval = [30]; # wlmd polling interval
}

###################################
# Metric-specific tune structures #
###################################

#
# This structure specifies the data collector (coll_argv) for the
# fin_ap.query.resp_time metric, used in the goal statements of the

Chapter 9 317
Example configuration files
stretch_goal.wlm

# finance SLOs (above). This theoretical application

# (/opt/fin_app/finance_collector) is developed or otherwise provided
# by the user.
# For more information on how to develop a data collector (also known as
# performance monitor), please see /opt/wlm/share/doc/howto/perfmon.html.
#
# This structure also specifies a constant (cntl_kp), which controls the
# rate of service-level convergence toward its goal. For more information
# on tuning this value, see /opt/wlm/share/doc/howto/tuning.html.
#
tune [fin_app.query.resp_time] {
coll_argv = [/opt/fin_app/finance_collector -a 123 -v];
cntl_kp = [1.0];
}

#
# Structure specifying similar information for the sales_app.resp_time
# metric.
#
tune [sales_app.resp_time] {
coll_argv = [/opt/sales_app/monitor -threshold 2 -freq 30];
cntl_kp = [2.0];
}
For related information, see Chapter 5, “Configuring WLM,” on page 135.

stretch_goal.wlm
Stretch goals are secondary goals and are of lower priority than a
workload group’s main SLO. Here, we have a stretch goal to provide a
workload group with more CPU resources if available. For an example
configuration with stretch goals for several workload groups, see
“usage_stretch_goal.wlm” on page 334.
#
# Name:
# stretch_goal.wlm
#
# Version information:
#
# (C) Copyright 2001-2006 Hewlett-Packard Development Company, L.P.
#

318 Chapter 9
 Example configuration files
stretch_goal.wlm

# $Revision: 1.7 $

# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# Demonstrate the use of multiple SLOs at different priority levels,
# but for the same workload, used to facilitate a “stretch” goal (one
# that we’d like to have met if all other higher-priority SLOs are
# being met).
#
# This file is very similar to the performance_goal.template file.
# It is provided without the user-customizable fields in brackets.
# But, more importantly, we have added an SLO to illustrate how one
# can accomplish stretch (“would-be-nice-if-there-are-extra-cycles”)
# goals.

#
# PRM structure
#
# In this example, we have two groups again:
# finance and sales
# Each workload has one application.
#
prm {
groups = finance:2,
sales:3;
apps = finance: /opt/fin_app/count_money, # application for finance group
sales: /opt/sales/do_ebiz; # application for sales group
}

#
# slo structures
#

#
# This is an SLO for the finance group, only “active” on weekdays.
slo finance_query {
pri = 1; # SLO of highest priority
mincpu = 20; # minimum CPU allocation (percentage)

Chapter 9 319
Example configuration files
stretch_goal.wlm

maxcpu = 50; # maximum CPU allocation (percentage)

entity = PRM group finance;
goal = metric fin_app.query.resp_time < 2.0;
condition = Mon - Fri; # only active on weekdays
}
# This is a “stretch” goal for the finance query group. If all other
# goals of higher priority (lower “pri” integral values) have been met,
# apply more CPU to group finance, so its application runs faster
# during prime time (Monday through Friday between 9am and 5pm).
#
slo finance_query_stretch {
pri = 5;
mincpu = 20;
maxcpu = 60; # let it take more CPU if available
entity = PRM group finance;
goal = metric fin_app.query.resp_time < 1.0;
condition = (Mon - Fri) && (09:00 - 17:00);
}

#
# This is an SLO for the Sales group, active at all times (there are no
# conditions or exceptions).
#
slo sales_query {
pri = 1;
mincpu = 40;
maxcpu = 80;
entity = PRM group sales;
goal = metric sales_app.resp_time < 10.0;
}

#
# tune structures
#
# This first structure specifies the data collector (coll_argv) for
# the fin_ap.query.resp_time metric, used in the goal statements
# of the finance SLOs (above). This hypothetical application
# (/opt/fin_app/finance_collector) is developed or otherwise provided
# by the user.
#
# NOTE: Because the data collectors for these metrics are
# hypothetical applications, this file will not pass the syntax-
# checking mode of wlmd (wlmd -c stretch_goal.wlm). A real data-
# collecting program must exist, as HP-UX WLM will launch it and rely
# upon it to provide performance metrics (or the HP-provided interface,
# wlmrcvdc, can be used when appropriate).

320 Chapter 9
 Example configuration files
time_activated.wlm

#
tune fin_app.query.resp_time {
coll_argv = /opt/fin_app/finance_collector -a 123 -v;
}

#
# tune structure specifying similar information for the
# sales_app.resp_time metric.
#
tune sales_app.resp_time {
coll_argv = /opt/sales_app/monitor -threshold 2 -freq 30;
}
For information on the condition keyword, see “Specifying when the
SLO is active (optional)” on page 205. Also see “Goals vs stretch goals” on
page 203.

time_activated.wlm
The following example enables an SLO based on time, or in this case,
date.
#
# Name:
# time_activated.wlm
#
# Version information:
#
# (C) Copyright 2001-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.9 $
#
# Caveats:
# DO NOT MODIFY this script in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# Demonstrate the use of HP-UX WLM in allocating a fixed allocation
# to a particular group of users only during a certain time period.
#

Chapter 9 321
Example configuration files
time_activated.wlm

# Dependencies:
# This example was designed to run with version HP-UX WLM A.01.02
# or later.
#

# prm structure
#
# See wlmconf(4) for complete HP-UX WLM configuration information.
#
# Define all workload groups in the prm structure. Individual
# users are assigned to particular groups in this structure as well.
#
# In this example configuration, the user don can execute
# applications in either the Payroll or OTHERS workload groups. So,
# he can move existing processes to, or start new processes in,
# OTHERS using the prmmove or prmrun commands. For more information,
# see prmmove(1) and prmrun(1). The users paysupv and payadm can
# execute applications in the Payroll group but nowhere else.
#
# Note that the group OTHERS is created automatically. Applications
# run by users not referenced in the prm structure will execute in
# the OTHERS group. Given the prm structure below, only don,
# paysupv and payadm can execute applications in the Payroll
# group.

prm {
groups= Payroll : 3;
users= don: Payroll OTHERS,
paysupv: Payroll,
payadm: Payroll;
}

#
# slo structure
#
# The keywords pri (priority), and entity (group to which
# the SLO applies) are required for any SLO specification.
#
# The cpushares statement requests a fixed allocation of 80% of the
# CPU resources on the system for the Payroll group.
#
# With the condition set as shown, this SLO is only in effect
# on the 6th and 21st of each month. On these dates, applications
# executing in the Payroll group will have 80% of the system’s CPU
# resources dedicated to them. Note that on all other dates, the
# SLO is disabled, and only the minimum default of 1% of the CPU

322 Chapter 9
 Example configuration files
transient_groups.wlm

# resources will be available to users in the Payroll group!

#

slo Payroll_Processing {
pri = 1;
cpushares = 80 total;
entity = PRM group Payroll;
condition = */06/* || */21/*;
}
For information on the condition keyword, see “Specifying when the
SLO is active (optional)” on page 205.

transient_groups.wlm
This example shows how you can reduce the resources used by groups
with no active SLOs.
#
# Name:
# transient_groups.wlm
#
# Version information:
#
# (C) Copyright 2003-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.7 $
#
# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# This example demonstrates WLM’s management of groups with no active
# SLOs. By default, WLM workload groups continue to consume system
# resources even when the groups have no active SLOs.
#

Chapter 9 323
Example configuration files
transient_groups.wlm

# By setting the transient_groups keyword to 1:

#
# * Whenever an FSS group has no active SLOs, the group is removed
# from the configuration and therefore consumes no resources
#
# * Whenever a PSET-based group has no active SLOs, the group gets 0
# CPU resources
#
# See the discussion of the transient_groups keyword in the
# wlmconf(4) manpage for information on where processes belonging to
# such groups are placed.
#

#
# Dependencies:
# This example was designed to run with HP-UX WLM version A.02.02 or
# later. (A.02.02 was the first version to support PSET-based groups
# as transient groups.)
#

# This example has an Apache web server that is used as a front-end to

# billing and paying applications, both of which are in HP Serviceguard
# packages. The Apache workload is run in an FSS group, as is the Billing
# workload. The other workload is run in a PSET group. The default user
# group OTHERS is explicitly defined.

prm {
groups = OTHERS : 1,
Apache : 2,
Billing : 3,
Paying : PSET;

# The workloads are placed in their workload groups:

apps = Apache : /opt/hpws/apache/bin/httpd,
Billing : /opt/orders/bin/billing,
Paying : /opt/orders/bin/paying;
}

324 Chapter 9
 Example configuration files
transient_groups.wlm

# Set up wlmrcvdc to pick up metrics indicating whether the Serviceguard

# packages are active; set transient_groups keyword.
#
# Have WLM modify allocations (if necessary) every 5 seconds
# because the configuration includes usage goals.
#
tune {
coll_argv = wlmrcvdc sg_pkg_active;
transient_groups = 1;
wlm_interval = 5;
}

# The SLO Paying_slo applies to a PSET-based group, so absolute CPU units

# are in effect. Thus, each core of CPU resources represents 100 shares. The
# mincpu and maxcpu values can be up to (n * 100) shares, where n is the
# total number of cores on the system.

# The SLO for the Apache workload is going to request 1 to 2 cores. It has a
# usage goal, which will ensure the group uses a certain percentage of its
# CPU allocation. This SLO is priority 1, as Apache must get the CPU
# resources it needs.
slo Apache_slo {
pri = 1;
mincpu = 100;
maxcpu = 200;
entity = PRM group Apache;
goal = usage _CPU;
}

# Whenever the Billing Serviceguard package is active, this SLO’s associated

# workload group is allocated 1 to 4 cores, based on a usage goal. When the
# package is not active, the Billing workload group, which is an FSS group,
# is removed from the configuration and consumes no resources. This SLO is
# priority 2; it is not as critical as the Apache workload.
slo Billing_slo {
pri = 2;
mincpu = 100;
maxcpu = 400;
entity = PRM group Billing;
goal = usage _CPU;
condition = metric Billing_active;

Chapter 9 325
Example configuration files
twice_weekly_boost.wlm

# Whenever the Paying Serviceguard package is active, this SLO’s associated

# workload group is allocated 1 to 4 cores, based on a usage goal. When the
# package is not active, the Paying workload group, which is based on a
# PSET group, gets no CPU resources. This SLO is priority 3; it gets CPU only
# after the Apache_slo and Billing_slo are satisfied.
slo Paying_slo {
pri = 3;
mincpu = 100;
maxcpu = 400;
entity = PRM group Paying;
goal = usage _CPU;
condition = metric Paying_active;
}
For information on transient groups, see the “Temporarily removing
groups with inactive SLOs (optional)” on page 220.

twice_weekly_boost.wlm
This example presents an interesting mix of conditions for active SLOs.
#
# Name:
# twice_weekly_boost.wlm
#
# Version information:
#
# (C) Copyright 2001-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.12 $
#
# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/toolkits location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#

326 Chapter 9
 Example configuration files
twice_weekly_boost.wlm

# Purpose:
# Demonstrate a conditional allocation with a moderately complex
# condition.
# A baseball park’s server runs a number of different workloads
# for two groups: the front office and the scouting staff. The
# basic allocations are 30 shares for front_office, 30 shares for
# scouting, and the remainder (40 in this case) for OTHERS.
#
# The front office staff has one important, long running job,
# “analyze_ticket_sales”, which is usually run every Tuesday and
# Thursday. During these days, the front_office group receives a
# ‘boost’, and its allocation is 60 shares.
#
# For these regularly scheduled runs, the system administrator relies
# on HP-UX WLM to automatically re-allocate CPU resources.
#
# In addition to those regular runs, occasionally a special events
# ticket sale is held. For these sales, the job is run at an
# unscheduled time, with an allocation of 70 shares.
#
# To manually enable the front office boost for special events,
# the system administrator executes this command:
#
# % wlmsend front_office.boost_enable 1
#
# To manually disable after the special event, the system
# administrator executes this command:
#
# % wlmsend front_office.boost_enable 0
#
# The scouting staff has one particularly important, long running
# job, /opt/baseball/scouting/bin/batting_averages, which is
# usually run every Monday and Wednesday, when it receives 60
# shares.
#
# In addition to those regular runs, occasionally farm league
# makeup games are held, and the job must be run at an unscheduled
# time. During these times, the scouting group receives a manual
# ‘boost’ to 70 shares.
#
# To manually enable the scouting boost for special events,
# the system administrator executes this command:
#
# % wlmsend scouting.boost_enable 1
#
# To manually disable after the special event, the system

Chapter 9 327
Example configuration files
twice_weekly_boost.wlm

# administrator executes this command:

#
# % wlmsend scouting.boost_enable 0
# Manually requested boosts receive a higher priority than
# the automatic date-based boosts. This is achieved with the ‘pri’
# keyword in the slo definitions.
#
# In the unusual case that the front office *and* the scouting
# team manually boost their allocations, the front office takes
# priority, and the scouting boost is disallowed.
#
# Allocation change frequency:
# Because wlm_interval is not explicitly set, the 60 second default
# is used. This means wlmd will collect measurements and make
# allocation changes every 60 seconds.
#
# Components:
# Uses the wlmsend and wlmrcvdc tools to relay a metric from
# an outside user.
#
# Dependencies:
# This example was designed to run with HP-UX WLM version A.01.02 or
# later.
#

#
# prm structure
# Create workload groups and designate which workload binaries
# will be placed in each. Because the baseball application
# is nicely split into scouting/bin and finance/bin, wildcards
# can be used to place the processes in the correct workload
# groups.
#
# See wlmconf(4) for complete HP-UX WLM configuration information.
#
prm {
groups = OTHERS : 1,
front_office : 2,
scouting : 3 ;

apps = scouting : “/opt/baseball/scouting/bin/*”,

front_office : “/opt/baseball/finance/bin/*” ;
}

328 Chapter 9
 Example configuration files
twice_weekly_boost.wlm

##########
#
# Give the front office its basic allocation of 30 shares.
#
slo front_office_basic {
pri = 3;
entity = PRM group front_office;
cpushares = 30 total;
}

#
# When the day is correct, boost the front office to 60 shares, unless
# scouting has requested a manual boost.
#
slo front_office_date_boost {
pri = 2;
entity = PRM group front_office;
cpushares = 60 total;
condition = (Tue || Thu);
exception = (metric scouting.boost_enable > 0) ;
}

#
# If the system administrator requests it, boost the front
# office to 70 shares.
#
slo front_office_manual_boost {
pri = 1;
entity = PRM group front_office;
cpushares = 70 total;
condition = (metric front_office.boost_enable > 0) ;
}

##########
#
# Give the scouting staff its basic allocation of 30 shares.
#
slo scouting_basic {
pri = 3;
entity = PRM group scouting;
cpushares = 30 total;
}

Chapter 9 329
Example configuration files
twice_weekly_boost.wlm

# When the day is correct, boost scouting to 60 shares, unless

# scouting has requested a manual boost.
#
slo scouting_date_boost {
pri = 2;
entity = PRM group scouting;
cpushares = 60 total;
condition = (Mon || Wed);
exception = (metric scouting.boost_enable > 0) ;
}

#
# If the system administrator requests it, boost scouting to 70 shares.
#
slo scouting_manual_boost {
pri = 1;
entity = PRM group scouting;
cpushares = 70 total;
condition = (metric scouting.boost_enable > 0) ;

# front office manual boost overrides scouting manual boost

exception = (metric front_office.boost_enable > 0) ;
}

# Any CPU that remains after satisfying the above SLOs is given to the
# OTHERS group by default. You can change this default using the
# distribute_excess keyword. For more information on this keyword, see
# the wlmconf(4) manpage.

#
# Relay the boost enable metrics from the outside user.
#
tune front_office.boost_enable {
coll_argv = wlmrcvdc;
}

tune scouting.boost_enable {
coll_argv = wlmrcvdc;
}
For information on the condition keyword, see “Specifying when the
SLO is active (optional)” on page 205.

330 Chapter 9
 Example configuration files
usage_goal.wlm

usage_goal.wlm
This example shows a CPU usage goal, where WLM attempts to keep a
workload’s CPU utilization, defined as (CPU used) / (CPU allocated),
between a certain range.
#
# Name:
# usage_goal.wlm
#
# Version information:
#
# (C) Copyright 2001-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.10 $
#
# Caveats:
# DO NOT MODIFY this script in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# Demonstrate the usage goal for service-level objective (SLO)
# specifications.
#
# Dependencies:
# This example was designed to run with HP-UX WLM version A.01.01
# or later.
#

#
# prm structure
#
# See wlmconf(4) for complete HP-UX WLM configuration information.
#
prm {
groups= OTHERS : 1,
Orders : 2,
Batch: 3;

gmincpu = OTHERS : 10;

}

Chapter 9 331
Example configuration files
usage_goal.wlm

# slo structures
#

#
# This SLO is defined with a CPU usage, or utilization, goal. This
# is a special goal in that WLM tracks the utilization for you.
# By default, WLM attempts to keep the group’s utilization of its
# allocated CPU between 50% and 75%. If utilization falls below 50%
# (due perhaps to fewer applications running), WLM reduces the Orders
# group’s allocation, making more CPU available to the OTHERS and
# Batch groups. Similarly, when utilization is above 75%, WLM
# allocates more CPU to the group.
#
slo order_processing {
pri = 1;
mincpu = 20;
maxcpu = 80;
entity = PRM group Orders;
goal = usage _CPU;
}

#
# This SLO is also defined with a CPU usage goal. It is at a
# lower priority than the SLO for the Orders group. We also
# explicitly specify the utilization bounds. We use a small value
# (25) for the upper bound, because we want this group to request
# more CPU whenever there is any activity in the group. The
# order_processing SLO is higher priority, so it can steal CPU from
# this SLO whenever it needs it. The gmincpu value for OTHERS
# ensures that we never completely starve that group.
#
# If the boundary values are not specified (as in the previous SLO),
# then they default to 50 and 75.
#
slo batch_processing {
pri = 99;
mincpu = 5;
maxcpu = 100;
entity = PRM group Batch;
goal = usage _CPU 15 25;
}

332 Chapter 9
 Example configuration files
usage_goal.wlm

# tune structure
#
# Have WLM modify allocations (if necessary) every 5 seconds
# because the configuration includes usage goals.
#

tune {
wlm_interval = 5;
}
For more information on usage goals, see “Specifying a goal (optional)” on
page 199.

Chapter 9 333
Example configuration files
usage_stretch_goal.wlm

usage_stretch_goal.wlm
This example shows the use of stretch goals in addition to base CPU
usage goals for several different workload groups. A priority 1 SLO
specifies a base CPU usage goal for the OTHERS group to ensure that it
receives between 1 and 100 CPU shares. Additional priority 1 SLOs are
defined for three additional groups to ensure that they receive between 1
and 200 CPU shares. For each of these three groups, an additional
priority 10 SLO defines a stretch goal calling for between 1 and 800 CPU
shares if any remain after the priority 1 SLOs are satisfied.
#
# Name:
# usage_stretch_goal.wlm
#
# Version information:
#
# (C) Copyright 2003-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.6 $
#
# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# Demonstrate workload groups with multiple SLOs at different
# priority levels, creating a base goal and a “stretch” goal (a goal
# that we’d like to have met if all other higher-priority SLOs are
# being met). All the SLOs are based on usage goals.
#
# With a usage goal, WLM adjusts a workload group’s number of CPU
# shares to keep its CPU utilization within a certain range. For
# example, if a workload group’s processes are using 20 CPU shares
# and have a 50 CPU share allocation, the group’s utilization is
# 20/50 or 40%. WLM attempts to keep a workload group’s utilization
# between a low and high bound--50% and 75% by default. To bring our
# example group’s utilization up to 50%, WLM would change its
# allocation from 50 shares to 40 shares. The utilization is
# then 20/40, or 50%.
#
#

334 Chapter 9
 Example configuration files
usage_stretch_goal.wlm

# Dependencies:
# This example was designed to run with version HP-UX WLM A.02.00
# or later.
#
# prm structure
#
# In this example there are four groups defined. Each group, except
# OTHERS, has application records. An application record
# tells WLM to run an application in a certain group. (OTHERS does
# not have an application record because it is the default group:
# Any nonroot processes without application records or user records
# run in OTHERS.)
#
# The paths in the application records are examples. Modify them to
# fit your environment.
#
prm {
groups =
OTHERS : 1,
OVO : 2,
SVCDESK : 3,
SIP : 4;

apps =
SVCDESK : /path/to/svcdesk/binaries,
SIP : /path/to/sip/binaries,
OVO : /path/to/ovo/binaries;
}

#
# tune structure
#
# WLM uses absolute CPU units mode because the absolute_cpu_units
# tunable is set to 1. With these units, 100 shares equates to
# 1 core of CPU resources.
#
# With the wlm_interval tunable set to 5, WLM will adjust CPU shares
# allocated to the workloads every 5 seconds.
#
tune {
absolute_cpu_units = 1;
wlm_interval = 5;
}

#
# slo structure

Chapter 9 335
Example configuration files
usage_stretch_goal.wlm

#
# There are seven SLOs in this example.
#
# This first SLO ensures that OTHERS receives between 0 and 100
# shares. (The 100 shares represent 1 core because absolute_cpu_units
# is set to 1). The goal is a usage goal, attempting to ensure the
# group uses between 50% and 75% of its allocated CPU shares (as
# explained in the “Purpose” section above).
#
slo OTHERS_Base {
pri = 1;
entity = PRM group OTHERS;
mincpu = 1;
maxcpu = 100;
goal = usage _CPU;
}

#
# These next SLOs are set to priority 1 (pri = 1) to make sure that
# each group is allocated CPU shares. Each SLO is for a different
# group and requests between 1 and 200 shares (that is, 2 cores).
# With the usage goals, WLM allocates CPU to the groups based on how
# much of their allocations they are currently using. WLM changes
# their allocations so that the groups are using between 50% and 75%
# of those allocations.
#
slo SIP_Base {
pri = 1;
entity = PRM group SIP;
mincpu = 1;
maxcpu = 200;
goal = usage _CPU;
}

slo SD_Base {
pri = 1;
entity = PRM group SVCDESK;
mincpu = 1;
maxcpu = 200;
goal = usage _CPU;
}

slo OVO_Base {
pri = 1;
entity = PRM group OVO;
mincpu = 1;

336 Chapter 9
 Example configuration files
usage_stretch_goal.wlm

maxcpu = 200;
goal = usage _CPU;
}

#
# The following SLOs are for the groups with priority 1 SLOs above.
# The SLOs below are all priority 10 (pri = 10) and are stretch goals.
# These SLOs are met only if there are shares left over after the
# higher priority SLOs have been satisfied. Each SLO is for a
# different group and requests between 1 and 800 shares (or 8
# cores). With the usage goals, WLM allocates CPU resources to the
# groups based on how much of their allocations they are currently
# using. WLM changes their allocations so that the groups are using
# between 50% and 75% of those allocations.
#
slo SIP_Stretch {
pri = 10;
entity = PRM group SIP;
mincpu = 1;
maxcpu = 800;
goal = usage _CPU;
}

slo SD_Stretch {
pri = 10;
entity = PRM group SVCDESK;
mincpu = 1;
maxcpu = 800;
goal = usage _CPU;
}

slo OVO_Stretch {
pri = 10;
entity = PRM group OVO;
mincpu = 1;
maxcpu = 800;
goal = usage _CPU;
}
For more information on usage goals and stretch goals, see “Specifying a
goal (optional)” on page 199.

Chapter 9 337
Example configuration files
user_application_records.wlm

user_application_records.wlm
This example shows how to place applications in workload groups. It also
shows that application records take precedence when both user records
and application records are in effect for an application.
#
# Name:
# user_application_records.wlm
#
# Version information:
#
# (C) Copyright 2001-2006 Hewlett-Packard Development Company, L.P.
#
# $Revision: 1.13 $
#
# Caveats:
# DO NOT MODIFY this file in its /opt/wlm/examples/wlmconf location!
# Make modifications to a copy and place that copy outside the
# /opt/wlm/ directory, as items below /opt/wlm will be replaced
# or modified by future HP-UX WLM product updates.
#
# Purpose:
# Demonstrate the use of, and precedence between, user and application
# records in placing processes in workload groups.
#
# A development server is funded and used by two groups, test and
# development. Along with normal test and development work, the
# server also supports the two groups’ joint website (via apache),
# and is the box employees use to fetch web pages (with netscape).
# However, in the past, both web functions, apache and netscape,
# have negatively affected the performance of the box. To correct
# this problem, users’ netscape sessions are limited to 10% of the
# CPU resources, and the httpd processes are limited to 10%. The
# remaining 80 percent is split 35 for test, 35 for development, and
# 10 percent for users not belonging to either group.
#
# Components:
# No external data collectors are required.
#
# Dependencies:
# This example was designed to run with HP-UX WLM version A.01.02 or
# later. It uses the cpushares keyword introduced in A.01.02, so
# is incompatible with earlier versions of HP-UX WLM.

338 Chapter 9
 Example configuration files
user_application_records.wlm

#
# prm structure
# Create workload groups. Designate which workload binaries
# and users will be placed in each. We will be managing
# two workloads, apache and netscape, and two groups of users,
# testers and coders. Users not belonging to either group
# are placed in OTHERS.
#
# The users section places individuals into a workload group based
# on their login. Users not listed will run in OTHERS. Because
# application records take precedence over user records, if user larry
# runs netscape, that process will run in workload group ‘surfers’
# rather than ‘testers’. In a similar manner, if user larry runs
# httpd, it will run in ‘servers’ because the app record is used
# even though the user, larry, does not have permission to
# explicitly start or move other jobs to ‘servers’. Consult
# wlmconf(4) and prmconf(4) for more information.
#
#
# Note that netgroups can be used in the users record. For
# instance, if all development staff belonged to a netgroup
# ‘devel_netgrp’, this line could be used to place them all in
# workload group ‘coders’:
#
# users = +devel_netgrp : coders surfers,
# +test_netgrp : testers surfers;
#
# See wlmconf(4) for complete HP-UX WLM configuration information.
#
prm {
groups = OTHERS : 1,
testers : 2,
coders : 3,
servers : 4,
surfers : 5;

apps = servers : /opt/hpws/apache/bin/httpd,

surfers : /opt/netscape/netscape;

users = moe : coders surfers,

curly : coders surfers,
larry : testers surfers;
}

Chapter 9 339
Example configuration files
user_application_records.wlm

#
# Grant 35 shares to coders.
#
slo coders_fixed {
pri = 1;
entity = PRM group coders;
cpushares = 35 total;
}

#
# Grant 35 shares to testers.
#
slo testers_fixed {
pri = 1;
entity = PRM group testers;
cpushares = 35 total;
}

#
# Grant 10 shares to servers.
#
slo servers_fixed {
pri = 1;
entity = PRM group servers;
cpushares = 10 total;
}

# Grant 10 shares to surfers.

#
slo surfers_fixed {
pri = 1;
entity = PRM group surfers;
cpushares = 10 total;
}

# Any CPU that remains after satisfying the above SLOs is given to the
# OTHERS group by default. You can change this default using the
# distribute_excess keyword. For more information on this keyword, see
# the wlmconf(4) manpage.
For information on user and application records, see “Assigning users
and user access to workload groups (optional)” on page 164 and
“Assigning applications to workload groups (optional)” on page 166.

340 Chapter 9
 Example configuration files
user_application_records.wlm

For more information on how the application manager works, see “How
application processes are assigned to workload groups at start-up” on
page 455 and “How the application manager affects workload group
assignments” on page 459.

Chapter 9 341
Example configuration files
user_application_records.wlm

342 Chapter 9
10 Monitoring SLO compliance and
WLM
WLM allows you to monitor SLO compliance and much more information
through wlminfo, wlmgui, and EMS, as described in the following
sections:

• “Monitoring WLM with the wlminfo command” on page 343

• “Monitoring WLM with the wlmgui command” on page 347
• “Monitoring WLM with EMS” on page 354

Monitoring WLM with the wlminfo command

The wlminfo command provides various WLM data, with reports
focusing on SLOs, metrics, or workloads. The command has both a
command-line interface and a graphical interface.
For information on wlminfo options and output, see wlminfo(1M).

NOTE To ensure the smooth running of the operating system and key HP-UX
daemons, WLM runs these system processes in a special workload called
PRM_SYS. This group is not restrained by WLM: It consumes system
resources as needed. As a result, a workload’s CPU usage (shown in the
‘CPU Util’ column) may be less than its CPU shares because PRM_SYS
requires some of the group’s resources. However, the low usage could also
be the result of the group’s low CPU resource demands, or a combination
of the two factors. Also, CPU usage might at times be slightly above the
shares value due to dynamics in the CPU scheduler that WLM uses.
Likewise, if memory management is enabled, a workload’s memory
usage may be less than the number of memory shares for reasons similar
to those just stated. It could also be slightly above the memory shares
value due to extreme paging pressure or when the current group
allocation is being reduced.

Chapter 10 343
Monitoring SLO compliance and WLM
Monitoring WLM with the wlminfo command

A few examples of wlminfo are shown below.

In the first example, we focus on SLOs. Entering wlminfo slo -v, we
get output that includes the SLOs’ goals, as well as the metrics that show
how the workloads are performing relative to the goal. Also, we see from
the ‘Concern’ column that two SLOs are Disabled, most likely due to a
condition statement. This column helps highlight information. A dash
(-) in the ‘Req’ column indicates that no requests are being made for the
SLO. The ‘State’ column indicates whether an SLO is passing or is off.
% /opt/wlm/bin/wlminfo slo -v
Tue Jun 11 16:06:09 2006

SLO Name Group Pri Metric Goal Req Shares State Concern
s_nightly_kickof g_nightl 1 - - - 0 OFF Disabled
s_nightly_run g_nightl 1 30.5 75 - 0 OFF Disabled
s_apache_10min g_apache 2 7 - 72 72 PASS
s_apache_2min g_apache 2 0 - 72 72 PASS
s_nice g_nice 2 30.5 50 30 30 PASS
s_others OTHERS 2 1.35 50 433 462 PASS
s_team_playgroun g_team 2 0 75 1 30 PASS
s_apache_more g_apache 3 0 - 72 72 PASS
s_nice_xtra_min g_nice 3 - - 30 30 PASS
s_team_playgroun g_team 3 - - 30 30 PASS
Now we focus on workloads/workload groups. Entering wlminfo group,
we see by the ‘CPU Util’ column the amount of CPU resources the
processes in the workloads are using. This command also displays (as of
WLM A.03.02) a ‘Mem Util’ column indicating the memory utilization of
each group for which memory management is in effect.
% /opt/wlm/bin/wlminfo group
Tue Jun 11 16:06:27 2006

Workload Group PRMID CPU Shares CPU Util Mem Shares Mem Util State
OTHERS 1 432.00 171.34 40.00 30.21 ON
g_nice 2 84.00 49.22 15.00 4.89 ON
g_nightly 3 0.00 0.00 0.00 0.00 OFF
g_team 4 6.00 0.00 15.00 0.00 ON
g_apache 5 72.00 0.00 29.00 0.00 ON
_IDLE_ 7 6.00 0.00 1.00 0.00 ON

344 Chapter 10
 Monitoring SLO compliance and WLM
Monitoring WLM with the wlminfo command

Note also that beginning with WLM A.03.02 you can use the -v option
with the wlminfo group command to see the minimum and maximum
percentage of CPU resources (gmincpu and gmaxcpu) and the minimum
and maximum percentage of memory (gminmem and gmaxmem) assigned
for each group, if applicable in the active configuration (if a minimum or
maximum is not assigned, wlminfo displays “-” in place of a numeric
value; if memory management is not being used for a group, wlminfo
displays a “-” in the ‘Mem Shares’ column). Because the width of the
display exceeds 80 characters, the wlminfo group -v command displays
the information in long-line format, each row wrapping to the next line
as in the following example:
% /opt/wlm/bin/wlminfo group -v
Tue Jun 11 16:06:27 2006

Workload Group PRMID CPU Shares CPU Min CPU Max CPU Util Mem Shares
Mem Min Mem Max Mem Util State
OTHERS 1 432.00 - - 171.34 40.00
- - 30.21 ON
g_nice 2 84.00 10 80 49.22 15.00
10 20 4.89 ON
g_nightly 3 0.00 - - 0.00 -
10 20 - ON
g_team 4 6.00 2 4 0.00 15.00
2 10 0.00 ON
g_apache 3 72.00 10 55 0.00 29.00
4 15 0.00 ON
_IDLE_ 7 6.00 - - 0.00 1.00
1 - 0.00 ON

Last, we look at the metrics used in the current WLM configuration. The
‘PID’ column shows the PID of the data collector providing the metric to
WLM. In this example, the WLM daemon, wlmd, with PID 2103 is
providing many of the metrics itself, for usage goals. (Because wlmd
starts, and then starts the data collectors, wlmd typically has the lowest
PID.) The ‘State’ column indicates whether the metric value was updated
in the interval (NEW), no value has been received for the metric since the
WLM daemon started (INIT), or the metric’s value was not updated in
the interval (OLD). The last column shows the value received for the
metric.
% /opt/wlm/bin/wlminfo metric

Chapter 10 345
Monitoring SLO compliance and WLM
Monitoring WLM with the wlminfo command

Tue Jun 11 16:06:45 2006

Metric Name PID State Value

_CPU_g_nightly 2103 NEW 30.549558
m_nightly_on 2107 OLD 0.000000
m_nightly_procs 2108 OLD 6.600000
_CPU_g_team 2103 NEW 0.000000
_CPU_OTHERS 2103 NEW 65.095184
_CPU_g_nice 2103 NEW 17.218712
m_apache_access_10min 2109 NEW 7.000000
m_apache_access_2min 2110 NEW 0.000000
m_list.cgi_procs 2111 NEW 0.000000

NOTE You can configure EMS to set an alarm for a metric value (for example, if
the metric value exceeds a certain threshold, you can have EMS notify
you). For more information on using EMS, see the Using the Event
Monitoring Service manual. For information about the metric value
resource monitored by EMS, see “Metric status updates” on page 358.

346 Chapter 10
 Monitoring SLO compliance and WLM
Monitoring WLM with the wlmgui command

Monitoring WLM with the wlmgui command

To display monitoring data graphically, use the wlmgui command.
Running wlmgui requires Java Runtime Environment version 1.4.2 or
later and, for PRM-based configurations, PRM C.03.00 or later. (To take
advantage of the latest updates to WLM and the GUI, use the latest
version of PRM available.)
The interface has three tabs:

• Monitor
• Modify
• Deploy
You can perform these operations on the local system or on remote
systems.
To begin monitoring:

Step 1. Set your DISPLAY environment variable.

Step 2. Start the WLM GUI:

# /opt/wlm/bin/wlmgui

Step 3. Select the Monitor tab.

Step 4. Select the [Add] button.

You will be prompted for a system running WLM to monitor

For additional information on navigating the WLM GUI, see its online
help.

Chapter 10 347
Monitoring SLO compliance and WLM
Monitoring WLM with the wlmgui command

Monitoring the configuration

You can view WLM configurations as well as WLM global arbiter
configurations using the GUI. To see a configuration, in the Monitor tab,
select the Configurations tab.
Figure 10-1 shows parts of a configuration. Scroll bars are available to
view the entire configuration.

Figure 10-1 Monitoring a configuration

348 Chapter 10
 Monitoring SLO compliance and WLM
Monitoring WLM with the wlmgui command

Monitoring the number of CPU resources

The GUI allows you to monitor how the number of CPU resources has
changed over time. This feature is useful when managing partitions. To
see this graph, in the Monitor tab, select the CPU resources tab.
Figure 10-2 shows the system has had a constant number of CPU
resources (cores) active.

Figure 10-2 Monitoring the number of CPU resources

Chapter 10 349
Monitoring SLO compliance and WLM
Monitoring WLM with the wlmgui command

Monitoring the workloads

By default, the “Workload groups” tab allows you to monitor the CPU
shares and CPU usage for one or more workloads/workload groups.
The graph in Figure 10-3 shows the amount of CPU resources that are
allocated to the OTHERS group as well as how much it is using.

Figure 10-3 Monitoring a workload

350 Chapter 10
 Monitoring SLO compliance and WLM
Monitoring WLM with the wlmgui command

In addition to the default ‘CPU Shares’ and ‘CPU Usage’ values, you can
graph the selected groups’ ‘Minimum CPU’ and ‘Maximum CPU’ values.
These correspond to the gmincpu and gmaxcpu keywords in the
configuration.
To adjust what values are being graphed, right-click in the graph area to
display the menu of options. Figure 10-4 shows this menu.

Figure 10-4 Items to graph when monitoring a workload

Chapter 10 351
Monitoring SLO compliance and WLM
Monitoring WLM with the wlmgui command

Monitoring SLOs
In the “Service-level objectives” tab, we can see graphs of metrics used in
SLOs—along with the CPU allocations WLM granted in response to the
changing metrics. This view provides a significant amount of other data.
Figure 10-5 shows details for the SLO for the test group.

Figure 10-5 Graphing SLOs

352 Chapter 10
 Monitoring SLO compliance and WLM
Monitoring WLM with the wlmgui command

Monitoring items you define

The Custom tab allows you to pull together any graphable items you
want. Figure 10-6 shows one item graphed.

Figure 10-6 Custom graphing

Chapter 10 353
Monitoring SLO compliance and WLM
Monitoring WLM with EMS

Monitoring WLM with EMS

WLM provides an EMS monitor to track the workloads’ SLO compliance
and WLM itself. EMS can also report the status and values of WLM
metrics. You can configure EMS to send notification of items such as SLO
performance. The monitor places this data in the standard EMS
registrar for access from SAM, SMH, HP OpenView operations for unix,
and other EMS clients.
Figure 10-7 illustrates the role of EMS in using WLM.

Figure 10-7 Interaction between WLM and EMS

HP-UX WLM EMS registrar

HP-UX WLM EMS monitor (stores the
wlmemsmon /applications/wlm/*
EMS resources)

SAM, SMH, or
OpenView operations for unix
...

What EMS resources are available?

The WLM EMS monitor, /opt/wlm/lbin/wlmemsmon, provides
information on how well WLM and the managed applications are
performing. wlmemsmon monitors the WLM daemon wlmd and provides
EMS resources for an EMS client to monitor. The EMS client can also
receive event notification periodically, when a value changes, or when a
value crosses some threshold. For more information on EMS capabilities
or operational paradigm, see the Using the Event Monitoring Service
manual.
Table 10-1 provides a quick reference for the EMS resources that WLM
provides. For more detailed information, see the sections following the
table.

354 Chapter 10
 Monitoring SLO compliance and WLM
Monitoring WLM with EMS

Table 10-1 Overview of WLM EMS resources

To determine Check the following EMS resource

Whether the WLM daemon is up or down /applications/wlm/daemon_status

When the current configuration was /applications/wlm/config_modify

activated

The priority for the SLO slo_name /applications/wlm/slo_config/slo_name/priority

The metric that SLO slo_name uses /applications/wlm/slo_config/slo_name/metric

The workload/workload group to which /applications/wlm/slo_config/slo_name/groupname

SLO slo_name applies

Whether SLO slo_name is: /applications/wlm/slo_status/slo_name

• Without an active data collector

• Without performance data since the

data collector started
• Inactive

• Passing

• Failing due to higher priority SLOs

• Failing due to its maxcpu setting

• Failing for any other reason

The data collector for a specific metric /applications/wlm/metric_config/met_name/coll_argv

Smoothing value for a specific metric /applications/wlm/metric_config/met_name/cntl_smooth

Whether averaging is enabled for a /applications/wlm/metric_config/met_name/cntl_avg

specific metric

Current values for metrics (dynamic) /applications/wlm/metric_status/met_name

Chapter 10 355
Monitoring SLO compliance and WLM
Monitoring WLM with EMS

WLM status and time of last configuration

EMS resources regarding WLM status and the time of the last
configuration include:

• /applications/wlm/daemon_status
Indicates the state of the WLM daemon. Possible values are:
WLM_DOWN WLM daemon not running
WLM_UP Daemon is running: PRM
configuration is actively being
managed by the WLM daemon
• /applications/wlm/config_modify
Indicates the time when the last WLM configuration was activated.

SLO configuration data

EMS resources regarding WLM SLO configuration include:

• /applications/wlm/slo_config/
This resource class contains resources for each SLO configured in
WLM. Each of the resources provides information specific to that
SLO.
• /applications/wlm/slo_config/slo_name/
This resource class contains resources that provide information
about the SLO slo_name.
• /applications/wlm/slo_config/slo_name/priority
This resource specifies the priority for slo_name.
• /applications/wlm/slo_config/slo_name/metric
This resource specifies the metric to which the SLO applies.
• /applications/wlm/slo_config/slo_name/groupname
This resource specifies the workload/workload group groupname to
which the SLO applies.

356 Chapter 10
 Monitoring SLO compliance and WLM
Monitoring WLM with EMS

SLO status updates

EMS resources regarding the status of WLM SLOs include:

• /applications/wlm/slo_status/
This class contains a resource instance for each SLO. That instance
provides the status of that SLO.
• /applications/wlm/slo_status/slo_name
This provides the status for slo_name. Possible values are:
WLM_SLO_COLLECTOR_DIED The data collector for this SLO
exited; consequently, the status
(passing or failing) is unknown
WLM_SLO_STARTUP_NODATA The data collector for this SLO
has started but not yet sent data
to WLM; consequently, the status
(passing or failing) is unknown
WLM_SLO_INACTIVE This SLO is currently inactive
WLM_SLO_PASS This SLO is currently passing
(meeting its goal)
WLM_SLO_CLIP_FAIL This SLO is currently failing, but
is not receiving as large an
allocation as requested by the
controller, due to higher-priority
SLOs
WLM_SLO_AT_MAXCPU_FAIL This SLO is currently failing, but
is receiving the maximum CPU
allocation allowed for this SLO
WLM_SLO_FAIL This SLO is failing

Chapter 10 357
Monitoring SLO compliance and WLM
Monitoring WLM with EMS

Metric status updates

EMS resources providing the status of WLM metrics include the
following. A resource instance exists for each metric, where met_name is
the name of the metric as specified in the WLM configuration file.

• /applications/wlm/metric_config/met_name/coll_argv
This identifies a specific metric’s data collector as specified with the
coll_argv keyword in the tune structure. For more information on
specifying the coll_argv keyword in the configuration file, see
“Specifying a data collector (optional)” on page 215.
• /applications/wlm/metric_config/met_name/cntl_smooth
This indicates a specific metric’s smoothing value as specified with
the cntl_smooth keyword in the tune structure. The resource value
can range from 0 to 0.999. A value of 0 (the default) signifies that a
running average is not taken for the data collected; in other words,
dips and spikes of data received by the data collector are not
smoothed out before WLM uses the data. The higher the value, the
more smoothing that is performed. For more information on
specifying the cntl_smooth keyword in the configuration file, see
“Smoothing metric values (optional)” on page 223.
• /applications/wlm/metric_config/met_name/cntl_avg
This indicates whether averaging is enabled for a specific metric, as
specified with the cntl_avg keyword in the tune structure. Possible
values are:
WM_METRIC_CNTL_AVG_ON Averaging is enabled
WM_METRIC_CNTL_AVG_OFF Averaging is disabled, meaning
that only the most recent
interval’s (wlm_interval) usage
data is used for a usage metric
For more information on specifying the cntl_avg keyword in the
configuration file, see “Controlling averaging in usage controllers
(optional)” on page 223.
• /applications/wlm/metric_status/met_name
This indicates the current value for a specific metric. In contrast to
the previous metric resources (which are constant for a given WLM
configuration), the metric_status value is dynamic, meaning that the
value changes periodically during a configuration’s deployment.

358 Chapter 10
 Monitoring SLO compliance and WLM
Monitoring WLM with EMS

To demonstrate how these EMS resources function, consider the

following WLM configuration:
slo orders {
pri = 1;
entity = PRM group sales;
cpushares = 1 total per metric more_1;
}
slo buying {
pri = 1;
entity = PRM group marktg;
goal = usage_CPU;
}

tune {
absolute_cpu_units = 1;
wlm_interval = 1;
}
tune more_1 {
coll_argv = /workforce/sales/data_collector division1;
cntl_avg = 1;
cntl_smooth = 0.4;
}
prm {
groups = sales : 3, marktg : 4;
}

The EMS instances returned for the metric more_1 in this configuration
would be as follows, where current_value (reported for metric_status)
is the current value (which changes at each WLM interval) :
/applications/wlm/metric_status/more_1/
current_value
/applications/wlm/metric_config/more_1/coll_argv/
"/workforce/sales/data_collector division1"
/applications/wlm/metric_config/more_1/cntl_avg
WM_METRIC_CNTL_AVG_ON
/applications/wlm/metric_config/more_1/cntl_smooth
0.40000

Chapter 10 359
Monitoring SLO compliance and WLM
Monitoring WLM with EMS

Configuring EMS notification

Use the HP System Management Homepage (SMH), the enhanced
version of SAM, to configure how and when you should be notified of the
values of WLM resources. Using an HP-UX 11i v3 (B.11.31) host, SMH
enables you to perform system administration tasks on a system through
a single Web interface. You can access SMH either by running
/usr/sbin/smh on your local node or by accessing http://SMH_host:2301
from a remote system with a Web browser. For accessing SMH from your
local node, start with step 2 in the following instructions; for accessing
SMH from a remote system with a Web browser, start with step 1.

Step 1. Log in to SMH by pointing your Web browser to:

http://SMH_host:2301

where SMH_host is an HP-UX 11i v3 (B.11.31) system that has SMH and
WLM A.03.02.02 or later installed. By using port 2301, if SMH is not
currently running on SMH_host, it is started. For more information, see
the hpsmh(1M) manpage. Additional SMH documentation is available on
http://docs.hp.com by selecting the Network and System Management
link.

Step 2. Log in as root. To start SMH, enter the following:

# /usr/sbin/smh

Step 3. Select the Tools menu item at the top of the page.

Step 4. In the Resource Management section, select Event Monitoring Service.

To use this service from a PC client, you must have X Windows Server
software running.

Step 5. Select the Run button to run the EMS configuration GUI.

Step 6. Select Actions followed by Add Monitoring Request from the menu bar.

Step 7. Double-click the following resource class in the Add or Copy Monitoring
Request window:

applications

Step 8. Double-click the following resource class:

wlm

Step 9. Navigate to the desired resource.

360 Chapter 10
 Monitoring SLO compliance and WLM
Monitoring WLM with EMS

Step 10. Double-click the resource.

Step 11. Specify the Monitoring Request Parameters to indicate how you want to
receive notification of various WLM events.

Step 12. Select the OK button.

Chapter 10 361
Monitoring SLO compliance and WLM
Monitoring WLM with EMS

362 Chapter 10
A WLM command reference

This appendix describes the following WLM commands:

• wlmaudit
WLM audit report generator
• wlmcert
WLM certificate manager
• wlmcomd
WLM communications daemon
• wlmcw
WLM configuration wizard
• wlmd
WLM daemon
• wlmgui
WLM graphical user interface
• wlminfo
WLM information monitor
• wlmpard
WLM global arbiter (cross-partition management)
• wlmrcvdc
WLM built-in data collector
• wlmsend
Command that makes your command-line or script data available to
the wlmrcvdc utility for forwarding to the WLM daemon

Appendix A 363
WLM command reference
wlmaudit

wlmaudit
The wlmaudit command displays audit data generated by WLM and its
global arbiter.
Use the -t option with the WLM daemon wlmd or the global arbiter
daemon wlmpard before using wlmaudit.
wlmaudit uses /opt/perl/bin/perl to display data from audit files stored in
the /var/opt/wlm/audit/ directory. For information on the structure of
these files, see wlmaudit(1M).
The command syntax is:
wlmaudit -h
wlmaudit -V
wlmaudit [-d {wlmd | wlmpard}] [-s start_date] [-e end_date] [-o html]
where
-h
Displays usage information and exits. This option
overrides all other options.
-V
Displays version information and exits. This option
overrides all other options other than -h.
-d wlmd | wlmpard
Specifies the daemon for which to display audit data. If
you do not specify this option, wlmaudit displays the
audit data from both daemons, if available.
-s start_date
Instructs wlmaudit to display audit data beginning
from start_date. The default is 01/01/1900. Use the
format mm/dd/yyyy when specifying start_date.

364 Appendix A
 WLM command reference
wlmaudit

-e end_date
Instructs wlmaudit to display audit data up to
end_date. The default is the date on the current
system. Use the format mm/dd/yyyy when specifying
end_date.
-o html
Displays audit data in a formatted HTML report. The
default is text.

Appendix A 365
WLM command reference
wlmcert

wlmcert
wlmcert allows you to manage your WLM security certificates.
WLM uses secure communications by default when you use the
/sbin/init.d/wlm script to start WLM. For information on using security
certificates, see wlmcert(1M).
The command syntax is:
wlmcert -h [cmd]
wlmcert -V
wlmcert reset
wlmcert install -c certificate
wlmcert delete -c certificate
wlmcert list
wlmcert extract [-d directory]
where
-h [cmd]
Displays usage information and exits. This option
overrides all other options.
To get usage information for the command reset,
install, delete, list, or extract, specify the
command after -h. For example:
# wlmcert -h reset
-V
Displays version information and exits. This option
overrides all options other than -h.
reset
Creates the certificates for the system on which the
command is executed.
Only root can execute this operation.

366 Appendix A
 WLM command reference
wlmcert

This operation is performed automatically when you

install WLM. After running this operation:

• The system trusts itself

• You can use the wlmcert extract command to
make a copy of the system’s certificate, which you
can then add to other systems’ WLM certificate
repositories (truststores) to enable secure
communications between the current system and
those systems
install -c certificate
Adds the named certificate to the WLM truststore
on the current system.
Only root can execute this operation.
The current system can communicate securely with
any system for which it has a certificate in its
truststore. When using WLM management of virtual
partitions or nPartitions, each partition must have in
its truststore the certificate for every other partition
with which it is being managed.

NOTE If you use Serviceguard on the system running

wlmpard, any systems to which wlmpard might fail over
must have the same certificates installed in their
truststores as does the primary wlmpard node.
Therefore, be sure to install the certificates from the
systems managed by that wlmpard on any systems to
which wlmpard might fail over. Also, install the
certificates from all failover systems to the systems
being managed by that wlmpard.
delete -c certificate
Removes the named certificate from the WLM
truststore on the current system.
Only root can execute this operation.

Appendix A 367
WLM command reference
wlmcert

list
Lists the certificates in the WLM truststore on the
current system.
The current system can communicate securely with
any system for which it has a certificate in its
truststore. When using WLM management of virtual
partitions or nPartitions, each partition must have in
its truststore the certificate for every other partition
with which it is being managed.
extract [-d directory]
Extracts the WLM certificate for the current system,
placing it in the named directory. If a directory is not
specified, the certificate is placed in the current
directory.
The certificate is named host.pem, where host is the
name of the current system.

368 Appendix A
 WLM command reference
wlmcomd

wlmcomd
The wlmcomd communications daemon services requests from the HP-UX
Workload Manager (WLM) graphical user interface, wlmgui, allowing
local and remote access to the system.
You must start wlmcomd to use wlmgui.
Start wlmcomd on any system running a WLM daemon (wlmd) or a WLM
global arbiter daemon (wlmpard) that you would like to interact with
using wlmgui. (wlmpard is needed only if you are using WLM vPar
management or its Instant Capacity-based nPartition management. You
only need to start one wlmcomd even if the system is running both wlmd
and wlmpard.)
You can start wlmcomd on the command line. Or, you can start wlmcomd
at boot time by editing the file /etc/rc.config.d/wlm, as described in the
section “Setting the WLM communications daemon to start
automatically at reboot” on page 243.
The syntax for wlmcomd is:
wlmcomd -h
wlmcomd -V
wlmcomd [-p port]
wlmcomd [-s]
wlmcomd -k
where
-h Displays usage information and exits. This option
overrides all other options.
-V Displays version information and exits. This option
overrides all options other than -h.
-p port Changes the port that wlmcomd monitors for requests to
port. When using this option, be sure to configure
wlmgui to send requests to port as well.
port is a port number greater than 0.
If you do not specify a port, wlmcomd searches the file
/etc/services for the first line with the following format:

Appendix A 369
WLM command reference
wlmcomd

hp-wlmcom port_number/tcp
If such an entry is found, port_number is used as the
port. If such an entry is not found, the default port of
9692 is used, assuming it is not in /etc/services with
protocol tcp. If it is, an error is issued.
-s Causes WLM to run in secure mode if you have
distributed security certificates to the systems or
partitions being managed by the same WLM global
arbiter (wlmpard). For more information on using
security certificates, see wlmcert(1M).
WLM runs in secure mode by default when you use the
/sbin/init.d/wlm script to start WLM. (If you upgraded
WLM, secure mode might not be the default. Ensure
that the appropriate secure mode variables in
/etc/rc.config.d/wlm are set correctly. You can change
the default by editing the values for these variables.
For more information on these variables, see “Securing
WLM communications” on page 244.)
-k Kills any running instance of wlmcomd, preventing the
servicing of any more requests. However, requests that
are already being serviced (via children of wlmcomd) are
not interrupted. Thus, active monitoring sessions can
continue, without service interruption.

NOTE If you are not using secure communications (enabled manually using the
wlmcomd -s option or automatically when you use the /sbin/init.d/wlm
script to start WLM, use wlmcomd only on trusted LANs where you trust
all the users: All data exchanged between wlmcomd and wlmgui,
including the user’s password, is transmitted without encryption over
the network.
Restrict communications between wlmcomd and wlmgui to only
authorized users to improve security.
Each connection to wlmcomd represents a separate process on the system.
As such, each connection consumes resources, such as open file
descriptors, a process ID, memory, and so forth. A large number of

370 Appendix A
 WLM command reference
wlmcomd

connections could result in denial of service. You can restrict connections

by deploying wlmcomd on systems behind a firewall that blocks access to
the port being used.

Appendix A 371
WLM command reference
wlmcw

wlmcw
The wlmcw command starts the WLM configuration wizard. The wizard
greatly simplifies the creation of your initial WLM configuration. The
wizard is only for creating new configurations. It cannot edit existing
configurations. Also, it provides only a subset of the WLM functionality
to simplify the initial configuration process. After you create a
configuration, you can view it to gain a better understanding of how to
create more complex configurations manually.
Because the wizard is an X-windows application, be sure to set your
DISPLAY environment variable before attempting to start the wizard.
wlmcw requires Java Runtime Environment version 1.4.2 or later and,
for PRM-based configurations, PRM C.03.00 or later must be installed on
your system. (To take advantage of the latest updates to WLM, use the
latest version of PRM available.)
The syntax for wlmcw is:
wlmcw [ -s { small | medium | large } ]
where
-s size Changes the font point size used by wlmcw to size.
Acceptable values for size are:
small Default system font point size.
medium Default system font point size plus 4.
large Default system font point size plus 6.
If -s is not specified, the wizard uses the default system font point size
plus 2.
After creating your configuration file, called configfile for example,
you can activate it in passive mode as follows:
# wlmd -p -a configfile
With passive mode, you can see approximately how a particular
configuration is going to affect your system—without the configuration
actually taking control of your system’s resources. To see how the
configuration would affect your workloads, use the WLM utility wlminfo.
Fine-tune the configuration until the wlminfo output is as desired, then
activate the configuration as follows:

372 Appendix A
 WLM command reference
wlmcw

# wlmd -a configfile

Appendix A 373
WLM command reference
wlmd

wlmd
The wlmd (daemon) command controls the WLM daemon, allowing you to
activate configurations as well as stop the daemon. You must log in as
root to run wlmd, unless you are just using the -c option. The following
are valid option combinations:
wlmd -h
wlmd -V
wlmd -C
wlmd [-p] [-s] [-t] [-W] [-i] -A [-l logoption[=n][,...]]
wlmd [-p] [-s] [-t] [-W] [-i] -a configfile [-l logoption[=n][,...]]
wlmd [-W] -c configfile
wlmd -k
where:
-h Displays usage information and exits. This option
overrides all other options.
-V Displays version information and exits. This option
overrides all options other than -h.
-C Displays the most recent configuration, appending two
commented lines that indicate the origin of the
configuration.

374 Appendix A
 WLM command reference
wlmd

-i Initializes workload group assignments, ensuring a

new configuration’s user, Unix group, compartment,
and application records are used when the same
workload groups exist in the active and new WLM
configurations.
Use this option when the following conditions are met:

• You have workload groups that are in both the

active WLM configuration and the new
configuration that you want to activate
• You are going to activate the new configuration
without first stopping the WLM daemon
Without -i, if a currently running process is in a
workload group that also exists in the new
configuration, the process stays in that group
regardless of application, user, compartment, or Unix
group records in the new configuration.
The -i option is only valid with the -a or -A options.
-p Causes WLM to run in passive mode. In this mode, you
can see how a particular configuration is going to
approximately affect your system—without the
configuration actually taking control of your system.
Using this mode allows you to analyze and fine-tune a
configuration.
To see how the configuration would affect your
workloads, use the WLM utility wlminfo.
The -p option must be used with the -a or -A options.
For information on passive mode, including its
limitations, see “Passive mode versus actual WLM
management” on page 238.
-s Causes WLM to run in secure mode if you have
distributed security certificates to the systems or
partitions being managed by the same WLM global
arbiter (wlmpard). For more information on using
security certificates, see wlmcert(1M).

Appendix A 375
WLM command reference
wlmd

WLM runs in secure mode by default when you use the

/sbin/init.d/wlm script to start WLM. (If you upgraded
WLM, secure mode might not be the default. Ensure
that the appropriate secure mode variables in
/etc/rc.config.d/wlm are set correctly. You can change
the default by editing the values for these variables.
For more information on these variables, see “Securing
WLM communications” on page 244.)
-t Generates comma-separated audit data files. These
files are placed in the directory /var/opt/wlm/audit/ and
are named wlmd.monyyyy, with monyyyy representing
the month and year the data was gathered. You can
access these files directly or through the wlmaudit
command. (wlmaudit has audit data to display only
when you use the -t option.) For information on
wlmaudit or on the format of the data files, see
wlmaudit(1M).
When you use the -t option, be sure to set
wlm_interval in your WLM configuration file as
indicated in wlmconf(4).
-A Activates a copy of the most recent configuration.
-W Prints warning messages found when parsing the
configuration file as error messages. The -W option is
only valid with the -A, -a, and -c options.
-a configfile Activates the configuration specified in the file
configfile. If configfile is not valid, an error
message is displayed, and wlmd exits.
The -a option cannot be used with the -c option.
-c configfile Checks the configuration specified in the file
configfile for syntax errors. The current
configuration is not affected.
This option cannot be used with the -a option.
-l logoption Logs statistics in the file /var/opt/wlm/wlmdstats to
assist you in performance tuning. You must use -A or
-a configfile with -l logoption.
Valid logoption values are:

376 Appendix A
 WLM command reference
wlmd

all Logs group, host, metric, and SLO

statistics every WLM interval.
all=n Logs group, host, metric, and SLO
statistics every n WLM intervals.
group Logs group statistics every WLM
interval.
group=n Logs group statistics every n WLM
intervals.
host Logs host statistics every WLM
interval.
host=n Logs host statistics every n WLM
intervals.
metric Logs metric statistics every WLM
interval.
metric=n Logs metric statistics every n WLM
intervals.
slo Logs SLO statistics every WLM
interval.
slo=n Logs SLO statistics every n WLM
intervals.
When the same logoption is specified multiple times,
the last one specified takes precedence.
Combine multiple values separating them with a
comma. The following combination requests all the
statistics—with the exception of the host statistics,
which have been turned off:
-l all,host=0
The interval is 60 seconds by default, but can be
changed as explained in “Specifying the WLM interval
(optional)” on page 215.
For information on setting logging as a default, see
“Enabling statistics logging at reboot” on page 245.
Use the wlminfo command to review statistics from
/var/opt/wlm/wlmdstats. For example, to view SLO
data, enter:

Appendix A 377
WLM command reference
wlmd

% wlminfo slo -o
In place of slo, you can also use group, host, or
metric. For more information on wlminfo, see
wlminfo(1M).
You can enable automatic trimming of the wlmdstats
file by using the wlmdstats_size_limit tunable in
your WLM configuration. For more information, see
wlmconf(4).
-k Stops (kills) wlmd.

NOTE Do not use prmconfig -r while wlmd is active. Use wlmd -k to stop
WLM.

378 Appendix A
 WLM command reference
wlmgui

wlmgui
The wlmgui command invokes the WLM graphical user interface. It
allows you to create, modify, and deploy WLM configurations both locally
and remotely. In addition, it provides monitoring capabilities. Valid
option combinations are:
wlmgui
wlmgui -h
wlmgui -V
where:
-h Displays usage information and exits. This option
overrides all other options.
-V Displays version information and exits. This option
overrides all options other than -h.
wlmgui is part of the B8843CA WLM product bundle. If you would like to
install wlmgui on HP-UX systems where WLM is not installed, you can
install just the WLMUtilities bundle from the quarterly AR CD-ROM or
from the following Web site:
http://www.hp.com/go/softwaredepot
For Microsoft Windows, you can also download wlmgui from this site.
You can run wlmgui on a system where WLM is running or on any
remote system with the appropriate JRE (Java Runtime Environment)
version installed. Running wlmgui requires JRE version 1.4.2 or later.
On PRM-based configurations, PRM C.03.00 or later is required on the
system being managed by WLM. (To take advantage of the latest updates
to WLM and the GUI, use the latest version of PRM available.) (For
more on JRE version requirements, see the DEPENDENCIES section in
wlmgui(1M).)
The version of mongui must match the version of the WLM product that
it will manage. You can install multiple versions of mongui on a Microsoft
Windows PC.

Appendix A 379
WLM command reference
wlmgui

You must start wlmcomd on each system that has a WLM (wlmd) or a
WLM global arbiter (wlmpard) that you want to manage using wlmgui.
(wlmpard is needed only if you are using WLM vPar management or its
Instant Capacity-based nPartition management.)
As a security measure, wlmcomd must be explicitly started:
/opt/wlm/bin/wlmcomd
You can also start wlmcomd at boot time by editing the following file:
/etc/rc.config.d/wlm
Be sure to set your DISPLAY environment variable before attempting to
start wlmgui.

NOTE Use secure communications, as explained in “Securing WLM

communications” on page 244 and in wlmcert(1M). Otherwise, do not use
wlmgui over the internet, and use wlmgui only on trusted LANs where
you trust all the users. Without secure communications, all data
exchanged between wlmcomd and wlmgui, including the user’s password,
is transmitted without encryption over the network.
Restrict communications between wlmgui and wlmcomd to only
authorized users to improve security.
Also see the WARNINGS section of wlmgui(1M).

380 Appendix A
 WLM command reference
wlminfo

wlminfo
The wlminfo command provides various WLM data. You indicate the
type of data to display by specifying a command with wlminfo.
Commands include slo, metric, group, host, and par. Each command
has its own options. The following are valid option combinations:
wlminfo -h [cmd]
wlminfo -V
wlminfo -i
wlminfo slo [-l] [-o] [-v] [-b { 0 | 1 }] [-q] [-c]
wlminfo slo -s slo1 [-s slo2 ...] [-l] [-o] [-v] [-b { 0 | 1 }] [-q] [-c]
wlminfo slo -g grp1 [-g grp2 ...] [-l] [-o] [-v] [-b { 0 | 1 }] [-q] [-c]
wlminfo slo -m met1 [-m met2 ...] [-l] [-o] [-v] [-b { 0 | 1 }] [-q] [-c]
wlminfo metric [-l] [-o] [-b { 0 | 1 }] [-q]
wlminfo metric -m met1 [-m met2 ...] [-l] [-o] [-b { 0 | 1 }] [-q]
wlminfo group [-l] [-o] [-b { 0 | 1 }] [-q] [-S] [-v]
wlminfo group -g grp1 [-g grp2 ...] [-l] [-o] [-b { 0 | 1 }] [-q] [-S] [-v]
wlminfo host [-l] [-o] [-b { 0 | 1 }] [-q]
wlminfo par [-l] [-o] [-b { 0 | 1 }] [-q]
wlminfo par -h host1 [-h host2 ...] [-l] [-o] [-b { 0 | 1 }] [-q]
wlminfo proc [-l] [-t secs] [-n cnt] [-p] [-v] [-b { 0 | 1 }]
wlminfo proc -g grp1 [-g grp2 ...] [-l] [-t secs] [-n cnt] [-p] [-v]
[-b { 0 | 1 }]
where

NOTE For more information on the following options, see wlminfo(1M).

-h [cmd]

Appendix A 381
WLM command reference
wlminfo

Displays usage information and exits. If you specify

cmd, the usage information is limited to cmd data. This
option overrides all other options and commands.
-V
Displays version information and exits. This option
overrides all commands and any options other than -h.
-i
Launches wlminfo in interactive mode, displaying a
graphical user interface (GUI). This option overrides
all commands.
Be sure WLM is enabled and your DISPLAY
environment variable is set before you use this option.
Launching wlminfo in this mode requires Java
Runtime Environment version 1.4.2 or later in
/opt/java1.4/jre/bin/java, and with PRM-based
configurations, PRM C.03.00 or later must also be
running. (To take advantage of the latest updates to
WLM and the GUI, use the latest version of PRM
available.)
slo [options]
Displays data about SLOs, including their priorities
and associated workloads.
metric [options]
Displays data about metrics, including their values.
group [options]
Displays data about workloads/workload groups,
including their CPU allocations.
host [options]
Displays data about the host.
par [options]
Displays data about virtual partitions or
nPartitions—if wlmpard is running.
proc [options]

382 Appendix A
 WLM command reference
wlminfo

Displays data about the most active processes.

For a description of the wlminfo output, see wlminfo(1M).

Appendix A 383
WLM command reference
wlmpard

wlmpard
The wlmpard command controls the HP-UX WLM global arbiter, which
governs cross-partition management as well as management of
Temporary Instant Capacity (TiCAP) and Pay per use (PPU) resources.
Every global arbiter interval (120 seconds by default), the WLM global
arbiter checks for CPU resource requests from the partitions using that
global arbiter.
When managing partitions, the arbiter then moves cores across
partitions, if needed, to better achieve the SLOs specified in the WLM
configuration files that are active in the partitions. (Given the physical
nature of nPartitions, WLM only simulates core movement—as
described in Chapter 7, “Managing SLOs across partitions,” on
page 255.) The WLM daemon wlmd must be running in each partition.
Also, the WLM configuration in each partition must use the keyword
primary_host to reference the name of the host of the partition where
the global arbiter is running.
For information on the syntax of the global arbiter configuration file, see
wlmparconf(4).
Only root can run wlmpard. The following are valid option combinations:
wlmpard -h
wlmpard -V
wlmpard -C
wlmpard [-p] [-s] [-t] [-n] [-l par[=n]] -A
wlmpard [-p] [-s] [-t] [-n] [-l par[=n]] -a configfile
wlmpard [-n] -c configfile
wlmpard -k
where:
-h
Displays usage information and exits. This option
overrides all other options.

384 Appendix A
 WLM command reference
wlmpard

-V
Displays version information and exits. This option
overrides all options other than -h.
-C
Displays the most recent global arbiter configuration,
appending two commented lines that indicate the
origin of the configuration.
-n
Prevents the global arbiter from running in daemon
mode (that is, forces it to run in the foreground).
-p
Causes the global arbiter to run in passive mode. In
this mode, you can see how a particular global arbiter
configuration is going to approximately affect your
system—without the configuration actually taking
control of your system. Using this mode allows you to
verify and fine-tune a configuration.
To see how the configuration would affect your
workloads and virtual partitions, use the WLM utility
wlminfo.
The -p option must be used with the -a or -A options.
For information on passive mode, including its
limitations, see “Passive mode versus actual WLM
management” on page 238.
-s
Causes the global arbiter to run in secure mode if you
have distributed security certificates to the systems or
partitions being managed by the same WLM global
arbiter (wlmpard). For more information on using
security certificates, see wlmcert(1M).
The global arbiter runs in secure mode by default when
you use the /sbin/init.d/wlm script to start WLM. (If
you upgraded WLM, secure mode might not be the
default. Ensure that the WLMPARD_SECURE_ENABLE
variable in /etc/rc.config.d/wlm is set correctly. You can
change the default by editing the value for this

Appendix A 385
WLM command reference
wlmpard

variable. For more information on this and other secure

mode variables, see “Securing WLM communications”
on page 244.)
-t
Generates comma-separated audit data files. These
files are placed in the directory /var/opt/wlm/audit/ and
are named wlmpard.monyyyy, with monyyyy
representing the month and year the data was
gathered. You can access these files directly or through
the wlmaudit command. For information on wlmaudit
or on the format of the data files, see wlmaudit(1M).
When you use the -t option, be sure to set interval in
your WLM global arbiter configuration file as indicated
in wlmparconf(4).
-A
Activates a copy of the most recent global arbiter
configuration.

NOTE WLM activation may take longer than usual when

managing nPars.

-a [configfile]
Activates the configuration specified in the file
configfile. If configfile is not valid, an error
message is displayed, and wlmpard exits.

NOTE WLM activation may take longer than usual when

managing nPars.

-c configfile
Checks the configuration specified in the file
configfile for syntax errors. The current
configuration is not affected.

386 Appendix A
 WLM command reference
wlmpard

-l par
Logs statistics in the file /var/opt/wlm/wlmpardstats.
You must use -A or -a configfile with -l par.
When using -l, specifying:
par Logs statistics every global arbiter
interval.
par=n Logs statistics every n global arbiter
intervals.
Change the interval as explained in “Specifying the
global arbiter interval (optional)” on page 270.
For information on setting logging as a default, see
“Enabling statistics logging at reboot” on page 245.
You can use the wlminfo command to review statistics
from /var/opt/wlm/wlmpardstats:
% wlminfo par -o
For more information on wlminfo, see wlminfo(1M).
You can enable automatic trimming of the
wlmpardstats file by using the keyword
wlmpardstats_size_limit in your WLM global
arbiter configuration. For more information, see
wlmparconf(4).
-k
Kills any running instance of wlmpard. Use this option
to shutdown the HP-UX Workload Manager global
arbiter.

NOTE WLM shutdown may take longer than usual when

managing nPars.

Appendix A 387
WLM command reference
wlmrcvdc

wlmrcvdc
The wlmrcvdc utility collects data and forwards it to the WLM daemon.
It can collect this data from either of the following rendezvous points:

• Named pipe (FIFO)

You send data to named pipes using wlmsend, discussed in the
section “wlmsend” on page 393.
wlmrcvdc creates the named pipe, using access permissions of 0600.
• A command’s standard output
For examples showing how to get data to WLM, see “What methods exist
for sending data to WLM?” on page 493.
wlmrcvdc always creates a named pipe to be fed metric data by
executions of wlmsend. If a command is also specified, wlmrcvdc starts
the command in the background and reads metric values from its
standard output. If command exits with 0, wlmrcvdc will continue
running using the named pipe rendezvous point; otherwise, wlmrcvdc
will exit with error.

NOTE If you use both a named pipe and a command to send the values of a
single metric to WLM, be aware that the WLM daemon checks for new
metric values once every WLM interval, and that the daemon uses only
the last value sent during this interval. This value may have come from
the named pipe or the command, depending on which one was updated
more recently.

Use wlmrcvdc only in WLM configuration files. The syntax is as follows:

wlmrcvdc [-h] [-V] [-u user] [-g group] [command [args...]]

NOTE wlmrcvdc accepts any unit-less integer or floating-point number. If a

value is invalid, it is discarded and a warning is entered in the log file
/var/opt/wlm/msglog.

The wlmrcvdc name comes from receive (rcv) data collector (dc).

388 Appendix A
 WLM command reference
wlmrcvdc

This utility simplifies the process of providing WLM the data it needs to
gauge SLO performance, set shares-per-metric allocations, and
enable/disable SLOs. By using wlmrcvdc, you can avoid using the WLM
API, which is discussed in “Sending data from a collector written in C” on
page 499.
On the command line, the following options are available:
-h Displays usage information and exits. This option
overrides all other options.
-V Displays version information and exits. This option
overrides all other options except -h.
Otherwise, use wlmrcvdc only in a WLM configuration file, as a value for
a coll_argv keyword:
tune metric {
...
coll_argv = wlmrcvdc options_and_arguments;
...
}
For information on coll_argv, see “Specifying a data collector
(optional)” on page 215.
The options_and_arguments are based on whether the data source is a
named pipe or a command’s standard output:

• Named pipe
[-u user] [-g group]
• A command’s standard output
[-u user] [-g group] command [args...]
where:
-u user
Sets the user (owner) of the FIFO file to user (symbolic
or numeric) and gives user write permission on the
rendezvous point. If command is specified, this option
also sets the owner of the command process to user. By
default, user is root.

Appendix A 389
WLM command reference
wlmrcvdc

-g group
Sets the Unix group of the FIFO file to group (symbolic
or numeric) and changes permissions on the
rendezvous point to 0620. If command is specified, this
option also sets the Unix group of the command process
to group. By default, group is bin.
command [args...]
Instructs wlmrcvdc to start command with the specified
args arguments in the background and use its
standard output as the rendezvous point.
Use the full path to command unless you are using one
of the following commands.
Although you are able to use other commands, WLM
provides a number of commands to be used in this
context:

NOTE For more information on the following options, see

glance_app(1M).

glance_app
Retrieves data for applications
defined in the GlancePlus file
/var/opt/perf/parm
glance_gbl
Retrieves GlancePlus global data
(system data)
glance_prm
Retrieves general PRM data and
PRM data for specific workload
groups (also known as PRM groups)

390 Appendix A
 WLM command reference
wlmrcvdc

glance_prm_byvg
Retrieves PRM data regarding logical
volumes
glance_tt/glance_tt+
Retrieve ARM transaction data for
applications registered through the
ARM API function arm_init()
sg_pkg_active
Checks on the status of a
Serviceguard package
time_url_fetch
Measures the response time for
fetching a URL using the Apache ab
tool. You can use this command with
the WLM Apache Toolkit (ApacheTK)
to manage your Apache-based
workloads
wlmdurdc
Helps manage the duration of
processes in a workload

Appendix A 391
WLM command reference
wlmrcvdc

wlmoradc
Produces an SQL value or an
execution time (walltime) that results
from executing SQL statements
against an Oracle instance
wlmwlsdc
Gathers WebLogic Server
Management Bean (MBean)
information to track how busy
WebLogic instances are

NOTE The WLM daemon discards the stderr for command; however, using the
coll_stderr tunable, you can redirect stderr to a specified file. For more
information on this tunable, see “Capturing your collectors’ stderr
(optional)” on page 223. Also, be aware that wlmrcvdc immediately sends
data in the rendezvous point to wlmd. However, wlmd only uses the last
piece of data sent before the WLM interval ends.

For more information on wlmrcvdc, see “Sending data with wlmsend and
wlmrcvdc: How it works” on page 509.

392 Appendix A
 WLM command reference
wlmsend

wlmsend
The wlmsend utility sends data to a rendezvous point for the wlmrcvdc
utility to collect. Use wlmsend on the command line, in a shell script, or
in a perl program.
For examples showing how to use wlmsend to get data to WLM, see
“What methods exist for sending data to WLM?” on page 493.
The syntax is:
wlmsend [-h] [-V] [-w wait_time] metric [value]

-h Displays usage information then exits. This option

overrides all other options.
-V Displays version information then exits. This option
overrides all other options except -h.
-w wait_time Waits wait_time seconds for the rendezvous point to
be created before exiting. The default is 5 seconds.
metric Sets the name of the rendezvous point to metric. This
argument is required and must match a metric string
specified in a goal, cpushares, condition, or
exception statement in the WLM configuration file.
value Designates the metric value to send to the rendezvous
point. This numeric argument must be the last
argument on the command line. If value is not
provided, metric values separated by white space will
be taken from standard input and sent to the
rendezvous point.
wlmrcvdc accepts any unit-less integer or
floating-point number. If a value is invalid, it is still
sent to the rendezvous point. However, wlmsend prints
an error message and exits with status 1.
You can use wlmsend to feed piped data to WLM:
glance_adviser_command | data_formatter | wlmsend metric

Appendix A 393
WLM command reference
wlmsend

NOTE Be careful of I/O buffering when feeding data to wlmsend. For example,
the following line works as expected:
tail -f logfile | wlmsend job_time
However, adding awk or other utilities that buffer I/O can result in data
being delayed, or not even sent, to wlmsend—depending on when the
buffer is flushed:
tail -f logfile | awk ‘{print $1}’ | wlmsend job_time
Always check the file /var/opt/wlm/wlmdstats, created by wlmd -l
metric as explained in wlmd(1M), to ensure that your data gets to WLM
in a timely fashion.

For more information on wlmsend, see “Sending data with wlmsend and
wlmrcvdc: How it works” on page 509.

394 Appendix A
B WLM configuration file
syntax overview
This appendix provides a quick reference for the WLM configuration file
syntax, indicating the required and optional components. Optional
components are enclosed in square brackets ([]). Pointers to detailed
syntax information are also included. Also included is an example WLM
configuration.

Configuration file syntax

[ version = 0; ]
[ icod_thresh_pri = integer; ]
[ icod_filter_intervals = integer; ]
[ primary_host = hostname [ : port_number ]; ]

[
prm {
groups = { FSS_group_def | PSET_group_def [: LCPU = {ON | OFF} ]} [, ...];
[ users = user : init_group [alt_group1 alt_group2 ...] [, ...]; ]
[ uxgrp = uxgrp_name : group [, ...]; ]
[ apps = group : application [alt_name1 alt_name2...] [, ... ]; ]
[ scomp = compartment : group [, ...]; ]
[ procmap = group : PID_finder [, ...]; ]
[ disks = group : volume ent [, ...]; ]
[ gmincpu = group : min [, ...]; ]
[ gmaxcpu = group : max [, ...]; ]
[ weight = group : wt [, ...]; ]
[ gminmem = group : min [, ...]; ]
[ gmaxmem = group : max [, ...]; ]
[ memweight = group : wt [, ...]; ]
}
]

slo slo1_name {
pri = priority;
[ entity = PRM group group_name; ]
[ mincpu = lower_bound_request; ]
[ maxcpu = upper_bound_request; ]
[ goal = goal_expression; ]
[ condition = condition_expression; ]
[ exception = exception_expression; ]

Appendix B 395
WLM configuration file syntax overview
Configuration file syntax

slo slo2_name {
pri = priority;
[ entity = PRM group group_name; ]
cpushares = value { more | total } [ per metric met [ plus offset ] ];
[ mincpu = lower_bound_request; ]
[ maxcpu = upper_bound_request; ]
[ condition = condition_expression; ]
[ exception = exception_expression; ]
}

tune [ metric [ slo_name ] ] {

[ coll_argv = data_collector; ]
[ wlm_interval = number_of_seconds; ]
[ absolute_cpu_units = {0 | 1}; ]
[ distribute_excess = {0 | 1};]
[ extended_shares = {0 | 1}; ]
[ transient_groups = {0 | 1};]
[ coll_stderr = file; ]
[ cntl_smooth = smoothing_value; ]
[ cntl_avg = {0 | 1}; ]
[ wlmdstats_size_limit = number_of_megabytes; ]
[ cntl_kp = proportional_term; ]
[ cntl_convergence_rate = number_of_shares; ]
[ cntl_margin = margin_value; ]
[ cntl_base_previous_req = {0 | 1}; ]

}
where
FSS_group_def has the syntax:
group : group_ID
PSET_group_def has the syntax:
group : PSET [: LCPU = {ON | OFF} ]
For more information on the three structure types, see the following
sections:

396 Appendix B
 WLM configuration file syntax overview
Configuration file syntax

• “Defining the PRM components (optional)” on page 149

• “Defining SLOs” on page 186
This section explains the two different forms of the slo structure
shown previously.
• “Tuning the metrics and the SLOs” on page 210

Appendix B 397
WLM configuration file syntax overview
Configuration file example

Configuration file example

Use the following example to better understand the syntax. For an
explanation of the file’s components, see Chapter 5, “Configuring WLM,”
on page 135.
# Define the workload groups (which are based on PSETs and FSS groups)
prm {
groups = finance : 2,
sales : 3,
marketing : PSET : LCPU = ON;

users = jdoe : finance,

pdoe : sales,
admin : finance sales marketing;

apps = finance : /opt/fin_app/count_money,

sales : /opt/sales/do_ebiz;

procmap = finance :
/bin/env/ UNIX95= /bin/ps -C pid_app -o pid=,
sales : /scratch/pidsbyapp salespid_app,
marketing : /scratch/pidsbyapp mrketpid_app;

gmincpu = finance : 20,

sales : 10;

gmaxcpu = sales : 20;

gminmem = finance : 30,

sales : 10,
marketing : 20;
}

# This is an SLO for the finance group.

slo finance_query {
pri = 1;
mincpu = 20;
maxcpu = 50;
entity = PRM group finance;
goal = metric fin_app.query.resp_time < 2.0;
condition = Mon - Fri;
}

398 Appendix B
 WLM configuration file syntax overview
Configuration file example

# This is a stretch goal for the finance query group. If all other CPU
# requests of higher priority SLOs have been met, apply more CPU to
# group finance, so its application runs faster.
slo finance_query_stretch {
pri = 5;
mincpu = 20;
maxcpu = 80;
entity = PRM group finance;
goal = metric fin_app.query.resp_time < 1.0;
condition = Mon - Fri;
}
# On weekends, we do not expect any query transactions, but just in
# case, we will specify a nominal CPU allocation for this application
# for off-hours.
slo finance_query_weekend {
pri = 1;
cpushares = 5 total;
entity = PRM group finance;
condition = Sat - Sun;
}

# This is an SLO for the Sales group.

slo sales_query {
pri = 1;
mincpu = 40;
maxcpu = 80;
entity = PRM group sales;
goal = metric sales_app.resp_time < 10.0;
}

tune {
wlm_interval = 30;
}

tune fin_app.query.resp_time {
coll_argv = /opt/fin_app/finance_collector -a 123 -v;
cntl_kp = 0.8;
}

tune sales_app.resp_time {
coll_argv = /opt/sales_app/monitor -threshold 2 -freq 30;
cntl_kp = 2.0;
}

Appendix B 399
WLM configuration file syntax overview
Configuration file example

400 Appendix B
C HP-UX command and system
call support
Several HP-UX commands and system calls support WLM in assigning
users and applications to the proper workload groups. Other commands
have options that allow you to use WLM more efficiently. These are
standard HP-UX commands and system calls; they are not shipped as
part of the WLM or PRM products.
Table C-1 lists HP-UX commands and system calls that support
workload groups.
Table C-1 HP-UX commands/system calls that support workload groups

Command/
Supports WLM as follows
system call

at Places the scheduled job in the user’s initial workload

group. If the user does not have an initial group, the job
is placed in the user default group, OTHERS (workload
group ID 1).

cron Places the scheduled job in the user’s initial workload

group. If the user does not have an initial group, the job
is placed in the user default group, OTHERS (workload
group ID 1).

login Places the login process in the user’s initial workload

group. If the user does not have an initial group, the
login process is placed in the user default group,
OTHERS (workload group ID 1).

exec() Process remains in its current workload group.

fork() Starts child process in the parent’s workload group.

pstat() Returns a process’s workload group ID.

Appendix C 401
HP-UX command and system call support

Table C-2 describes HP-UX commands that have options for WLM.
Table C-2 WLM options in HP-UX commands

Command Option Description

acctcom -P Displays the workload group ID (PRMID) of each process.

acctcom -R group Displays only processes belonging to the workload group

given by group, which is specified by workload group
name or workload group ID.

id -P Displays the workload group ID (PRMID) and name of the

invoking user’s initial group.

ps -P Adds a column named PRMID to the ps output that gives

the workload group name associated with each process.

ps -R group_list Displays only the processes that belong to workload

groups specified in group_list.
group_list must consist of workload group IDs
(PRMIDs) or workload group names. Groups must be
separated by commas; no spaces are allowed.

For more information on these commands, see their manpages.

402 Appendix C
D Integration with other products

WLM integrates with various other products to provide greater

functionality. Currently, these other products are:

• Process Resource Manager (PRM)

• Processor sets (PSETs)
• nPartitions
• Virtual partitions
• HP Integrity Virtual Machines (Integrity VM)
• Temporary Instant Capacity (TiCAP)/ Pay per use (PPU)
• Security Containment
• OpenView Performance Agent for UNIX /
OpenView Performance Manager for UNIX
• Serviceguard
• HP Systems Insight Manager and Servicecontrol Manager
• Oracle databases
• Apache web server
• BEA WebLogic Server
• SAP software
• SAS Software
• SNMP
The integration with these products is described in the sections that
follow.

Appendix D 403
Integration with other products
Integrating with Process Resource Manager (PRM)

Integrating with Process Resource Manager

(PRM)
You can use WLM to control resources that are managed by PRM. WLM
uses PRM when a prm structure is included in the WLM configuration.
With such configurations, you can use PRM’s informational and
monitoring commands such as prmlist and prmmonitor. You can also
use the prmrun and prmmove commands, among others. If you use the
prmconfig command, invoke it with no options or the -u (unlock)
option—do not use the -r (reset) option.
Ordinarily, WLM and PRM should not be used to manage resources on
the same system at the same time. In some cases, this could cause
inconsistent behavior and undesirable performance. However, you can
use both products at the same time if the PRM configuration uses FSS
groups only (no PSET-based groups) and the WLM configuration is
strictly host-based. (A strictly host-based configuration is one that does
not include a prm structure; it is designed exclusively for moving cores
across HP-UX Virtual Partitions or nPartitions, or for activating
Temporary Instant Capacity (TiCAP) cores or Pay per use (PPU) cores.)
You might want to use both products to take advantage of certain
features of PRM that are not included with the latest release of WLM,
such as PRM’s CPUCAPOFF mode, enabled with the prmconfig -M
CPUCAPOFF command. (In this mode, a PRM group’s upper bound for CPU
resource consumption is determined by the CAP value, available on
HP-UX 11i v3 and later. For more information, see the HP Process
Resource Manager User’s Guide or prmconfig(1M).)

404 Appendix D
 Integration with other products
Integrating with processor sets (PSETs)

Integrating with processor sets (PSETs)

PSETs allow you to group processors together, dedicating those CPU
resources to certain applications. WLM can automatically adjust the
number of CPU resources in a PSET-based workload group in response to
SLO performance. Combining PSETs and WLM, you can dedicate CPU
resources to a group without fear of the group’s needing additional CPU
resources when activity peaks or concern that the group, when less busy,
has resources that other groups could be using.
For information on configuring integration with PSETs, see the section
“Specifying workload groups (optional)” on page 159.
WLM supports the Hyper-Threading feature for PSET-based groups.
Cores can be moved from one partition to another and will take on the
Hyper-Threading state (enabled or disabled) of their destination PSET.
When new PSETs are created, they inherit the state of the system unless
specified otherwise. You can override the default state by explicitly
enabling or disabling Hyper-Threading for any cores assigned to a
specific PSET-based group. To explicitly enable or disable
Hyper-Threading for a PSET-based group, specify the LCPU keyword
with the PSET group definition in the prm structure. For information on
setting the Hyper-Threading state for a specific WLM PSET-based group,
see “Specifying workload groups (optional)” on page 159.
The PRM configuration generated by the WLM configuration file reflects
the per-PSET Hyper-Threading state currently specified for the affected
workload groups.
The LCPU keyword is based on an attribute value that can also be
examined and set with psrset -t. For more information, see psrset(1M).
You can modify the Hyper-Threading state of the system by using the
kctune command; for more information, see kctune(1M).

NOTE When WLM is managing PSETs, do not use the psrset or kctune
command to change PSET settings (including the Hyper-Threading state
of the system or the Hyper-Threading state set for any PSET). Stop
WLM before using these commands to modify PSETs. Whenever
possible, use WLM to control PSETs.

Appendix D 405
Integration with other products
Integrating with processor sets (PSETs)

NOTE On HP-UX 11i v1 (B.11.11) systems, you must install PSET

(PROCSETS) software; see the HP-UX WLM Release Notes. PSET
functionality comes with HP-UX 11i v2 (B.11.23) and later. Certain
software restrictions apply to using PSET-based groups with virtual
partitions (vPars), Instant Capacity, and Pay per use. For more
information, see the WLM Release Notes (/opt/wlm/share/doc/Rel_Notes).

406 Appendix D
 Integration with other products
Integrating with nPartitions (nPars)

Integrating with nPartitions (nPars)

You can run WLM within and across nPartitions. For systems with
partitions using Instant Capacity cores, WLM provides a global arbiter,
wlmpard, that can take input from the WLM instances on the individual
partitions. The global arbiter then “moves” cores across partitions, if
needed, to better achieve the SLOs specified in the WLM configuration
files that are active in the partitions. (This movement is achieved by
deactivating a core in one nPar, then activating a core in another nPar.
The way WLM manages cores depends on the software enabled on the
complex (such as Instant Capacity, Pay per use, and Virtual Partitions.)
For more information, see wlmpard(1M) and wlmparconf(4). (Instant
Capacity was formerly known as iCOD.)
For more information on configuring this integration, including the
nesting of virtual partitions within nPartitions, see Chapter 7,
“Managing SLOs across partitions,” on page 255.

Integrating with virtual partitions

You can run WLM within and across virtual partitions. For systems with
partitions, WLM provides a global arbiter, wlmpard, that can take input
from the WLM instances on the individual partitions. The global arbiter
then moves cores between partitions, if needed, to better achieve the
SLOs specified in the WLM configuration files that are active in the
partitions.
For more information on configuring this integration, including the
nesting of virtual partitions within nPartitions, see Chapter 7,
“Managing SLOs across partitions,” on page 255.

Appendix D 407
Integration with other products
Integrating with HP Integrity Virtual Machines (Integrity VM)

Integrating with HP Integrity Virtual

Machines (Integrity VM)
HP Integrity Virtual Machines is a robust soft partitioning and
virtualization technology that provides operating systems isolation,
shared CPU resources (with sub-core granularity), shared I/O, and
automatic, dynamic resource allocation. It is available for HP-UX 11i v2
running on HP Integrity servers.
You can run WLM both on the Integrity VM Host and in an Integrity VM
(guest), but each WLM runs as an independent instance.
Given a system with Integrity VM installed, you can run WLM on the
system itself (on the Integrity VM Host) and inside an Integrity VM
(guest), but each WLM runs as an independent instance.
The following figure illustrates how WLM can be used. Here, WLM runs
on the Integrity VM Host and in three of the four guests.

Figure D-1 WLM and Virtual Machines

WLM WLM WLM

VM1 VM2 VM3 VM4

WLM
HP-UX system with Integrity Virtual Machines installed

Observe the guidelines included in the following sections.

408 Appendix D
 Integration with other products
Integrating with HP Integrity Virtual Machines (Integrity VM)

Running WLM on an Integrity VM Host

To run WLM on the Integrity VM Host, you must use a strictly
host-based configuration—a WLM configuration designed exclusively for
moving cores across HP-UX Virtual Partitions or nPartitions, or for
activating Temporary Instant Capacity (TiCAP) or Pay per use (PPU)
cores. (WLM will not run with FSS groups or PSETs on Integrity VM
Hosts where guests are running.) In addition, ensure that the minimum
number of cores allocated to a WLM host is greater than or equal to the
maximum number of virtual CPUs (vCPU count) assigned to each VM
guest. Otherwise, VM guests with a vCPU count greater or equal to
WLM’s minimum allocation could receive insufficient resources and
eventually crash. For example, if an Integrity VM host has 8 cores and
three guests with 1, 2, and 4 virtual CPUs, respectively, your WLM host
should maintain an allocation of at least 4 cores at all times. You can
achieve this by using the WLM hmincpu keyword.

Running WLM within an Integrity VM (guest)

To run WLM within an Integrity VM, you cannot use Instant Capacity,
Pay per use, and vPar integration. However, guests will take advantage
of cores added to the Integrity VM Host by Instant Capacity, Temporary
Instant Capacity, and Pay per use.
As noted previously, WLM must continue allocating at least as many
cores as the maximum number of virtual CPUs in any VM guest on the
system. In addition, specify a WLM interval greater than 60 seconds.
This helps ensure a fair allocation of CPU resources for FSS groups.

For more HP Integrity VM information

For more information on HP Integrity VM, see the following Web site and
navigate to the "Solution components" page:
www.hp.com/go/vse

Appendix D 409
Integration with other products
Integrating with Temporary Instant Capacity (TiCAP)/ Pay per use (PPU)

Integrating with Temporary Instant Capacity

(TiCAP)/ Pay per use (PPU)
This section discusses the use of WLM with Temporary Instant Capacity
(v6 or later) or Pay per use (v4, v7, or later). (Instant Capacity was
formerly known as iCOD.) In particular, with WLM managing the use of
these CPU resources, you can ensure your workloads use only the
amount of resources needed for them to meet their SLOs.
Temporary Instant Capacity activates capacity in a temporary
“calling-card fashion” such as in 20-day or 30-day increments (where a
day equals 24 hours for one core). With this option, you can activate and
deactivate temporary capacity cores. You purchase a TiCAP codeword to
obtain rights to use these cores for a preset amount of days. This
codeword is applied to a system so you can turn on and off any number of
Instant Capacity cores on your system as long as your prepaid amount of
temporary capacity days has not expired. WLM integrates with
Temporary Instant Capacity v6 or later and can be configured to activate
or deactivate temporary capacity cores as needed. (To activate a core, you
need a minimum balance of 30 minutes of temporary capacity per core.
Codewords must be applied in the order in which they were obtained.)
Similarly, HP offers a Pay per use (PPU) feature for customers interested
in leasing CPU capacity from HP Finance. The Pay per use (PPU) feature
provides the capacity to support peak anticipated demand, but with
payment for the HP server based on monitored usage of that capacity.
WLM integrates with PPU v4, v7, or later. On systems with PPU v4,
capacity can be increased or decreased by whole cores—as needed, with
billing determined by the number of active cores. Beginning with PPU
v5, all cores on a PPU system are active and billing is based on your
percentage usage of those cores. Starting with PPU v7, which includes v5
capabilities, billing can also be based on the number of active cores on
the system, with WLM activating only those cores that are needed.
If you have WLM on either a Temporary Instant Capacity system (using
v6 or later) or a PPU system (using v4, v7, or later), you can configure
WLM to minimize the costs of using these resources by optimizing the
amount of time the resources are used to meet the needs of your
workloads.

410 Appendix D
 Integration with other products
Integrating with Temporary Instant Capacity (TiCAP)/ Pay per use (PPU)

To take advantage of this optimization, use the utilitypri keyword in

your global arbiter configuration as explained in wlmparconf(4) and
wlmpard(1M).

NOTE Specifying this priority ensures WLM maintains compliance with your
Temporary Instant Capacity usage rights. When your prepaid amount of
temporary capacity expires, WLM no longer attempts to use the
temporary resources

NOTE When 15 or fewer processing days (the default) of temporary capacity are
available, WLM will stop using Temporary Instant Capacity; in this case,
you must purchase extra capacity. Before you add the capacity, stop
wlmpard (using the -k option). For information about how to stop
wlmpard, see Appendix A, “WLM command reference,” on page 363.
You can change the 15-day default by setting the WLM global arbiter
utility_reserve_threshold keyword. For more information, see
“Specifying the reserve threshold that determines when WLM stops
activating temporary capacity resources” on page 274 or see
wlmparconf(4).

For more Temporary Instant Capacity / Pay per use

information
Fore more information on Temporary Instant Capacity, visit:

• http://www.hp.com/go/utility
• http://search.hp.com/, and search for “Temporary Instant Capacity”
Fore more information on Pay per use, visit:

• http://www.hp.com/go/utility
• http://docs.hp.com, and search for “Pay per use”

Appendix D 411
Integration with other products
Integrating with Security Containment (to form Secure Resource Partitions)

Integrating with Security Containment (to

form Secure Resource Partitions)
The HP-UX feature Security Containment provides file and process
isolation and is available starting with HP-UX 11i v2. Combining that
isolation with WLM workload groups, you can form Secure Resource
Partitions, which give your workload groups both isolation and
automatic resource allocation.
To integrate the two products:

Step 1. Create a configuration for Security Containment.

The srpgen utility, located in /opt/prm/bin/, automates the creation of a

configuration for Security Containment and PRM. For information, see
srpgen(1).

For information on Security Containment, see compartments(5).

Step 2. Activate the Security Containment configuration.

Use the setrules command to activate your configuration. For

information, see setrules(1M).

Step 3. Create your WLM configuration.

Use the /opt/wlm/bin/wlmprmconf utility to convert the PRM

configuration created in Step 1 to a WLM configuration.

Step 4. Activate your WLM configuration.

Use the wlmd command to activate your WLM configuration.

412 Appendix D
 Integration with other products
Integrating with OpenView Performance Agent (OVPA) / OpenView Performance Manager (OVPM)

Integrating with
OpenView Performance Agent (OVPA) /
OpenView Performance Manager (OVPM)
You can treat your workload groups as applications and then track their
application metrics in OpenView Performance Agent for UNIX as well as
in OpenView Performance Manager for UNIX.

NOTE NOTE: If you complete the procedure that follows, OVPA/OVPM will
track application metrics only for your workload groups; applications
defined in the parm file will no longer be tracked. GlancePlus, however,
will still track metrics for both workload groups and applications defined
in your parm file.

To track application metrics for your workload groups:

1. Edit /var/opt/perf/parm
Edit your /var/opt/perf/parm file so that the “log” line includes
“application=prm” (without the quotes). For example:
log global application=prm process dev=disk,lvm
transaction
2. Restart the agent
With WLM running, execute the following command:
% mwa restart scope

NOTE The WLM workload groups must be enabled at the time the scopeux
collector is restarted by the mwa restart scope command. If WLM
is not running, or transient_groups is set to 1 in your WLM
configuration, data for some—or all—workload groups may be absent
from OpenView graphs and reports. Also, it may affect alarms
defined in /var/opt/perf/alarmdefs.

For more information, see the following Web site:

Appendix D 413
Integration with other products
Integrating with Serviceguard

http://openview.hp.com.
Now all the application metrics will be in terms of workload (PRM)
groups. That is, your workload groups will be “applications” for the
purposes of tracking metrics.

Integrating with Serviceguard

This section discusses how you can better use WLM with Serviceguard.
The optional HP product Serviceguard provides users and applications
with a high availability environment. Whenever a mission-critical
application becomes unavailable because of a software or hardware
failure, Serviceguard automatically moves the application to another
server or partition.
By using the same WLM configuration on each server in a Serviceguard
cluster, you can better ensure that your workloads achieve their
SLOs—regardless of where they run in the cluster.
The WLM configuration file allows you to inform wlmd whether a
particular SLO is active on the current server. System resources
assigned to the inactive SLOs’ associated workloads become available to
workloads with active SLOs.
An active SLO is an SLO that WLM is trying to enforce. All SLOs are
active by default. An SLO’s time as active can be limited through
condition and exception statements in the slo structure in the
configuration file. These statements allow you to make SLOs active
based on time or on a metric’s value. You can use a metric’s value to
indicate whether a Serviceguard package is active.
Consider the example in Figure D-2. There are two servers in a
Serviceguard cluster. One server runs two packages, while the second
server runs one package. In this case, all packages are able to
comfortably meet their SLOs. However, Server1 crashes in the middle of
the night. Its packages then fail over to Server2. Now that Server2 has
three packages, there is concern about the packages meeting their SLOs.
When packages failover, WLM realizes—because of condition
statements in the configuration file—that new packages have appeared.
Based on the packages’ priorities, WLM allocates resources to the
packages so they can potentially still achieve their SLOs.

414 Appendix D
 Integration with other products
Integrating with Serviceguard

Figure D-2 WLM integration with Serviceguard

Before failover

PackageA
PackageC
PackageB

Server1 Server2

After failover

X
PackageA
PackageB
PackageC

Server1 Server2

Appendix D 415
Integration with other products
Integrating with Serviceguard

Steps for integration

To integrate WLM with Serviceguard:

Step 1. Install WLM on each node in your Serviceguard cluster.

Step 2. Edit a single WLM configuration file to handle all the Serviceguard
packages in the cluster. The following example assumes there are two
packages: pkgA and pkgB. This configuration file must:

a. Place all the packages’ applications in workload groups in the prm

structure:
prm {
...
groups = pkgA:2, pkgB:3;
apps = pkgA:/opt/dbase/bin/sales_dbase,
pkgB:/opt/dbase/bin/finance_dbase;
...
}
b. Set up tune structures to report a status metric for each package:
tune pkgA_active {
coll_argv = wlmrcvdc sg_pkg_active;
}

tune pkgB_active {
coll_argv = wlmrcvdc sg_pkg_active;
}
These tune structures set the metric values pkgA_active and
pkgB_active to 1 if their packages are indeed active on the current
node. The key component is the sg_pkg_active data collector, which
is included with WLM. For more information on this data collector,
see sg_pkg_active(1M).
Rather than creating tune structures for each package, you can set
up a global tune structure that takes in package status data from any
running sg_pkg_active:
tune {
coll_argv = wlmrcvdc sg_pkg_active;
}

416 Appendix D
 Integration with other products
Integrating with Serviceguard

c. Set up slo structures for each status metric, with the SLO being
active when the package is active:
slo pkgA_slo {
...
condition = metric pkgA_active;
...
}

slo pkgB_slo {
...
condition = metric pkgB_active;
...
}
Recall that the condition statement governs when an SLO is active:
If an SLO’s condition expression is true, the SLO is active. In these
cases, the expressions “metric pkgA_active” and
“metric pkgB_active” are true when the pkgA_active and
pkgB_active metrics are 1.

NOTE Workload groups that have only inactive SLOs continue to consume
system resources. To prevent this needless consumption, use the
transient_groups tunable, which is described in Step e.

d. (Optional) Use absolute_cpu_units in a global tune structure to

ensure that WLM treats 100 CPU shares as one core. For example,
use it in the configuration if the SLO for pkgA is requesting 200
shares, which must be treated as two cores. Set this tunable as
shown:
tune {
absolute_cpu_units = 1;
}
e. (Optional) Use transient_groups in a global tune structure to
temporarily remove workload groups with no active SLOs.
By default, if a package’s workload group has no active SLOs, WLM
reduces its resource shares. Such a workload group receives a
minimum of 1% of the total CPU resources (for FSS groups) or one
core (for PSET-based groups), unless it has a gmincpu value
requesting more. If the tunable extended_shares is set to 1, FSS

Appendix D 417
Integration with other products
Integrating with Serviceguard

workload groups with inactive SLOs receive a minimum of 0.2% of

the total CPU resources (with incremental allocations of 0.1%).
Similarly, if you are using WLM memory management, the workload
group with no active SLOs receives 1% of the memory (0.2% if
extended_shares is set, with incremental allocations of 0.1%), unless
the group has a gminmem value requesting more. However, note that
groups associated with a process map always remain active even if
they have no associated active SLOs.
If you would prefer these groups to go away temporarily (as long as
they have no active SLOs) and consume no CPU or memory resources,
set the transient_groups tunable to 1 in a global tune structure:
tune {
transient_groups = 1;
}
With the transient_groups keyword set to 1, FSS groups with no
active SLOs are temporarily removed and therefore use no resources;
the minimum CPU allocation for PSET groups becomes 0 (or the
value for gmincpu, if it is defined and such resources are available).
Note that workload groups associated with a process map always
remain active.
If an FSS workload group has been temporarily removed, its gmincpu
and gminmem values (if any) are ignored.
If you prefer that these groups not be removed, leave
transient_groups disabled and enable the extended_shares
tunable instead. In addition, make sure the absolute_cpu_units
tunable is enabled. The extended_shares tunable significantly
reduces the minimum allocations of resources to groups.

NOTE The OTHERS workload is never removed—regardless of how many

active SLOs it has.

Step 3. Validate the syntax of the configuration file:

# /opt/wlm/bin/wlmd -c configfile

Correct any errors that are found.

Step 4. Distribute the WLM configuration file to all the nodes in the cluster.

418 Appendix D
 Integration with other products
Integrating with Serviceguard

Step 5. Activate WLM with your configuration file on all the nodes:

# /opt/wlm/bin/wlmd -a configfile

NOTE If you are using WLM’s secure communications, be sure to distribute the
security certificates as explained in the section HOW TO SECURE
COMMUNICATIONS in wlmcert(1M).

For information on Serviceguard, see the manual Managing

MC/ServiceGuard, available at http://docs.hp.com.
For information on the condition keyword, see “Specifying when the
SLO is active (optional)” on page 205.
For more information on the sg_pkg_active data collector, see
sg_pkg_active(1M).

Appendix D 419
Integration with other products
Integrating with HP Systems Insight Manager (SIM) and Servicecontrol Manager (SCM)

Integrating with HP Systems Insight Manager

(SIM) and Servicecontrol Manager (SCM)
This section discusses how you can use WLM with the HP products
Systems Insight Manager and Servicecontrol Manager. These products
both provide a single point of administration for multiple HP-UX
systems. Systems Insight Manager is the newer product. The WLM
integration with these products allows system administrators at a SIM /
SCM Central Management Server (CMS) to perform the following
activities on nodes in the SIM / SCM cluster that have WLM installed:

• Workload Manager Console

• Activate WLM Configuration
• Enable WLM
• Disable WLM
• Start WLM
• Stop WLM
• Reconfigure WLM
• Distribute WLM configuration files to the selected nodes
• Retrieve currently active WLM configuration files from the nodes
• Check the syntax of WLM configuration files, on either the CMS or
the selected nodes
• View, rotate, and truncate WLM log files

What WLM tasks are available through SIM / SCM?

The following sections are named for the HP-UX WLM tools available
through SIM and SCM.

Workload Manager Console

Launch the WLM GUI after selecting the nodes to manage and setting
your DISPLAY variable.

420 Appendix D
 Integration with other products
Integrating with HP Systems Insight Manager (SIM) and Servicecontrol Manager (SCM)

Activate WLM Configuration

Gracefully shuts down WLM on the selected nodes, then restarts it,
activating the WLM configuration file at
/var/opt/wlm/SCM-managed.wlm.
Run this tool after placing a configuration on the node using the tool
Install WLM Configuration.

Enable WLM
Sets the variable WLM_ENABLE to 1 in the file /etc/rc.config.d/wlm on the
selected nodes. This allows WLM to start automatically whenever the
system is booted or “/sbin/init.d/wlm start” is run.

Disable WLM
Sets the variable WLM_ENABLE to 0 in the file /etc/rc.config.d/wlm on the
selected nodes. This prevents WLM from starting automatically
whenever the system is booted or “/sbin/init.d/wlm start” is run.

Install WLM Configuration

Prompts you for a configuration file, then copies the file to the selected
nodes, placing it in /var/opt/wlm/SCM-managed.wlm. Run the tool
Activate WLM Configuration to point WLM to the new configuration.

Restart WLM
Stops and restarts WLM by invoking the command
/sbin/init.d/wlm stop
followed by the
/sbin/init.d/wlm start
command. When restarted, WLM uses:

• The configuration configfile in the file /etc/rc.config.d/wlm in the

line
WLM_STARTUP_SLOFILE=”configfile”
• The last activated configuration file—if WLM_STARTUP_SLOFILE is not
specified

Appendix D 421
Integration with other products
Integrating with HP Systems Insight Manager (SIM) and Servicecontrol Manager (SCM)

Retrieve WLM Configuration

Prompts you for a destination directory on the CMS, then places the
currently activated configuration files from the selected nodes in the
specified directory. These files are named $HOST.wlm, with $HOST
replaced by the names of the nodes the files were retrieved from.

Rotate WLM Log Files

Rotates the /var/opt/wlm/msgslog files on the selected nodes by copying
the current log file to a date-stamped log file, then truncating the current
log file:
cp /var/opt/wlm/msglog /var/opt/wlm/msglog.`date +%Y%m%d-%H%M`
cp /dev/null /var/opt/wlm/msglog
The previous log files are then available as
msglog.YYYYMMDD-HHMM.

Rotate Statistics Log Files

Rotates the /var/opt/wlm/wlmdstats files on the selected nodes by
copying the current statistics log file to a date-stamped statistics log file,
then truncating the current statistics log file:
cp /var/opt/wlm/msglog /var/opt/wlm/wlmdstats.`date +%Y%m%d-%H%M`
cp /dev/null /var/opt/wlm/wlmdstats
The previous statistics log files are then available as
wlmdstats.YYYYMMDD-HHMM.

Start WLM
Starts WLM using the command /sbin/init.d/wlm start.

Stop WLM
Stops WLM using the command /sbin/init.d/wlm stop.

Syntax Check Configuration

Prompts you for a configuration file, then copies the file to the selected
nodes and checks the files’ syntax. Output from the syntax checks is sent
back to the CMS.

422 Appendix D
 Integration with other products
Integrating with HP Systems Insight Manager (SIM) and Servicecontrol Manager (SCM)

Checking the syntax after distributing the files allows you to verify that
the applications, data collectors, and any users in the configuration file
actually exist on the selected nodes. However, if you have other types of
syntax issues, you will have to fix the issues in each of the distributed
files—or fix them once in the CMS file and redistribute.

Syntax Check on CMS

Prompts you for a configuration file, then checks the file’s syntax on the
CMS.
Running this command before distributing a configuration file to the
selected nodes allows you to fix syntax errors in one file rather than in all
the distributed copies. Be aware, however, that this check will flag
missing data collectors, applications, and users that may be on the
selected nodes, but are not on the CMS.

Truncate Log Files

Truncates the /var/opt/wlm/msgslog files on the selected nodes by
running the command:
cp /dev/null /var/opt/wlm/msglog

Truncate Statistics Log Files

Truncates the /var/opt/wlm/wlmdstats statistics log files on the selected
nodes by running the command:
cp /dev/null /var/opt/wlm/wlmdstats

View WLM Log Files

Displays the /var/opt/wlm/msglog file from each selected node by running
the command:
xterm -e $PAGER /var/opt/wlm/msglog

View Statistics Log Files

Displays the /var/opt/wlm/wlmdstats statistics log file from each selected
node by running the command:
xterm -e $PAGER /var/opt/wlm/wlmdstats

Appendix D 423
Integration with other products
Integrating with HP Systems Insight Manager (SIM) and Servicecontrol Manager (SCM)

Accessing the WLM tools

NOTE Using WLM with SIM / SCM requires that you install the fileset
CMSConfig.WLMB-CMS-Tools on the SIM / SCM CMS. This fileset is
available from the depot /var/opt/mx/depot11 on the host where WLM
has been installed.
Also be aware: If you are installing this fileset on a CMS that has WLM
installed, the installation will fail if the fileset is not compatible with
(does not have the same revision string as) the installed WLM.

How you access the tools depends on whether your are using SIM or
SCM. (With SCM, the version also determines how you access the tools.)
With SIM:

Step 1. Start SIM in a web browser.

Step 2. Select the menu item corresponding to your desired WLM tool:

Optimize -> Workload Manager -> Desired Tool

Using a SCM version prior to 3.0, access the WLM tools as follows:

Step 1. Start SCM.

Step 2. Double-click the Tools icon.

Step 3. Double-click the Workload Management icon.

Step 4. Double-click the desired tool.

For SCM version 3.0 and later, SCM has a web interface. To access the
WLM tools:

Step 1. Start SCM in a web browser.

Step 2. Select a node on which to run the WLM tools.

Step 3. In the left portion of the browser window, select the Tools tab if it is not
already selected.

Step 4. Select the “Workload Management” item in the Tools list.

Step 5. Select the WLM tool you would like to run.

424 Appendix D
 Integration with other products
Integrating with HP Systems Insight Manager (SIM) and Servicecontrol Manager (SCM)

For more SCM information

For SCM documentation, visit:
http://docs.hp.com/hpux/netsys/

Appendix D 425
Integration with other products
Integrating with Oracle® databases

Integrating with Oracle® databases

WLM allows you to place Oracle database instances and other
applications in their own WLM workloads. With the instances and
applications separated in this manner, WLM can then manage the
performance of each instance and application through prioritized SLOs.
These SLOs typically attempt to ensure:

• A consistent level of performance

• The needs of critical instances are met—even during peak demand
• Resources are allocated based on time of day, system events, or
application and database metrics
HP has developed a toolkit, HP-UX WLM Oracle Database Toolkit
(ODBTK), to simplify getting metrics on Oracle database instances into
WLM. This toolkit, which is included with WLM as part of the WLM
Toolkits product, works with:
Oracle 8.0.x, Oracle 8.1.5, Oracle 8.1.6, Oracle 8.1.7, Oracle 9.0.1
For information on toolkit requirements, see the HP-UX Workload
Manager Toolkit User’s Guide, available at
/opt/wlm/toolkits/doc/WLMTKug.pdf

426 Appendix D
 Integration with other products
Integrating with Oracle® databases

Why use Oracle database metrics with WLM?

The key benefit of using Oracle database metrics with WLM is that you
can use the database metrics to manage the performance of your
instances. You specify SLOs for the instances based on the metrics.
For example, with these metrics you can:

• Keep response times for your transactions below a given level by

setting response-time SLOs
• Increase an instance’s available CPU resources when a particular
user connects to the instance
• Increase an instance’s available CPU resources when more than n
users are connected
• Increase an instance’s available CPU resources when a particular job
is active
• Give an instance n CPU shares for each process in the instance
• Give an instance n CPU shares for each user connection to the
instance
For examples showing how to set up these types of SLOs, see the files
with names ending in “.wlm” in the directory
/opt/wlm/toolkits/oracle/config/.

Appendix D 427
Integration with other products
Integrating with Oracle® databases

Tools in the HP-UX WLM Oracle Database Toolkit

(ODBTK)
This toolkit includes two tools:
wlmoradc
wlmoradc is a data collector for Workload Manager and
is designed to provide an easy building block for Oracle
instance management with wlmd.
It takes one or more SQL statements and uses the
Oracle tool SQL*Plus to connect to an Oracle instance
and execute the statements, returning either the raw
value returned from the SQL or the elapsed execution
time. The results are sent to stdout for human viewing,
logging, or most often, for use by wlmd by means of the
wlmrcvdc or wlmsend utilities.
smooth
smooth takes a stream of newline-delimited numbers
and outputs a stream of numbers that are a running
average of the last n values, where n is a value that can
be set on the command line. The principal use for the
smooth utility is to remove short spikes or dips in data
collector output used with WLM, but can be applied to
any stream of floating-point numbers.
Although not part of ODBTK, the functionality provided by the
cpushares keyword in the WLM configuration file fits quite nicely with
the toolkit.

NOTE The cpushares keyword is available starting with WLM

Version A.01.02.

A CPU share is a portion of the CPU resources. The cpushares keyword

allows shares-per-metric allocations. This enables you to create
goal-based SLOs in WLM of the form “x percent of the CPU resources for
each metric y,” such as three CPU shares for each process in a workload.
(This type of allocation can also be thought of as a parametric allocation.
It is calculated directly from the metric and is thus a function of the
metric. This type of function is a parametric equation.)

428 Appendix D
 Integration with other products
Integrating with Oracle® databases

What metrics are available?

The following types of database metrics are available:

• Time elapsed while SQL code executes

• Value returned by executed SQL code
This value can be information from Oracle V$ tables. These tables
provide dynamic performance data for Oracle instances and allow
the Oracle database administrator to see current performance
information.

How do I get started with ODBTK?

The toolkit comes with numerous example files that you can copy and
modify to fit your needs. These files include WLM configuration files and
wlmoradc configuration files, which include SQL.
The files are available in /opt/wlm/toolkits/oracle/config/. Table D-1
describes the WLM example configuration files.
Table D-1 ODBTK’s example WLM configuration files described

WLM configuration file Purpose

alpha_shares_per_user.wlm Demonstrate how to customize the supplied file

shares_per_user.wlm for a slightly different set of instances

batchuser_boost.wlm Demonstrate a conditional allocation, with the allocation

enforced when a certain user connects

manual_payroll_boost.wlm Demonstrate a conditional allocation, with the allocation

enforced when a certain application becomes active; also,
demonstrate how to feed “external” metrics to WLM using
wlmsend

shares_per_process.wlm Demonstrate an allocation where each instance gets a

certain number of CPU shares per process

shares_per_user.wlm Demonstrate an allocation where each instance gets a

certain number of CPU shares per user connection

timed_select_scott.wlm Demonstrate a response-time goal using a SCOTT/TIGER

table

Appendix D 429
Integration with other products
Integrating with Oracle® databases

Table D-1 ODBTK’s example WLM configuration files described

WLM configuration file Purpose

timed_sys_table.wlm Demonstrate a response-time goal using V$ Oracle system

tables

user_cnt_boost.wlm Demonstrate a conditional allocation, with a new allocation

enforced when more than a set number of users connect

Table D-2 describes the wlmoradc configuration files. These files can be
used to set database environment variables for wlmoradc to use. You can
also place the SQL statements for wlmoradc to execute in these files.
Table D-2 wlmoradc example configuration files described

wlmoradc configuration
Purpose
file

process_cnt.oradc Report number of user processes using an instance

select_scott_resptime.oradc Demonstrate a timed proxy transaction with the

SCOTT/TIGER tables

sys_table_resptime.oradc Demonstrate a timed proxy transaction against V$ Oracle

system tables

user_cnt.oradc Report number of users connected to an instance

430 Appendix D
 Integration with other products
Integrating with Oracle® databases

ODBTK examples
As noted in the previous section, ODBTK comes with many useful
examples in the directory /opt/wlm/toolkits/oracle/config/. We will look at
parts of those files here.
The first example draws from
/opt/wlm/toolkits/oracle/config/shares_per_user.wlm. The slo structure
gives workload group Ora_grp_1 three CPU shares for each user
connected to the associated Oracle instance.
slo Ora_1_slo {
pri = 1;
mincpu = 5;
maxcpu = 90;
entity = PRM group Ora_grp_1;
cpushares = 3 total per metric oracle.instance1.user_cnt;
}
Looking at the tune structure in the same file, we see that the metric
oracle.instance1.user_cnt is provided by wlmoradc, which uses the SQL
in the configuration file user_cnt.oradc to get the user count.
tune oracle.instance1.user_cnt {
coll_argv =
wlmrcvdc
wlmoradc
--configfile /opt/wlm/toolkits/oracle/config/user_cnt.oradc
--home /oracle/app/oracle/product/8.1.5
--instance instance1
;
}

Appendix D 431
Integration with other products
Integrating with Oracle® databases

The next example is from

/opt/wlm/toolkits/oracle/config/user_cnt_boost.wlm. The second SLO,
Ora_1_slo, provides a minimum 20 share allocation. The first SLO,
Ora_1_slo_boost, becomes active and boosts the allocation to 40 shares if
the metric oracle.instance1.user_cnt is 11 or more.
slo Ora_1_slo_boost {
pri = 1;
cpushares = 40 total;
entity = PRM group Ora_grp_1;
condition = metric oracle.instance1.user_cnt > 10;
}

slo Ora_1_slo {
pri = 3;
cpushares = 20 total;
entity = PRM group Ora_grp_1;
}
Again, the tune structure shows wlmoradc providing the metric to WLM.
This tune structure also uses the smooth tool, which calculates a
running average of the last five user counts, smoothing out extreme
values when the user count is volatile.
tune oracle.instance1.user_cnt {
coll_argv =
wlmrcvdc
smooth -c 5
wlmoradc
--configfile /opt/wlm/toolkits/oracle/config/user_cnt.oradc
--home /oracle/app/oracle/product/8.1.5
--instance instance1
;
}

432 Appendix D
 Integration with other products
Integrating with Oracle® databases

For more ODBTK information

If you would like to learn more about ODBTK, see:

• wlmtk(5)
• wlmoradc(1M)
• smooth(1M)
• HP-UX Workload Manager Toolkits User’s Guide
(opt/wlm/toolkits/doc/WLMTKug.pdf)
• HP-UX Workload Manager Toolkits A.01.10.xx Release Notes
(/opt/wlm/toolkits/doc/Rel_Notes)

Appendix D 433
Integration with other products
Integrating with Apache

Integrating with Apache

WLM can help you manage and prioritize Apache-based workloads
through the use of the WLM Apache Toolkit (ApacheTK), which is part of
the freely available product WLM Toolkits (WLMTK). WLM can be used
with Apache processes, Tomcat, CGI scripts, and related tools using the
HP-UX Apache-based Web Server.

Why use ApacheTK?

Assume your enterprise (or corporate) applications use Apache as a front
end to dispatch work to workloads running Java software, CGI scripts,
and other such processes. You can then use WLM and ApacheTK to
manage these processes in a manner that reflects the business priorities
they support.

Tools in ApacheTK
ApacheTK includes a white paper and example configuration files that
demonstrate resource separation of Apache-based workloads. It also
includes the simple data collector time_url_fetch, which uses the
Apache benchmark tool ab to time URL response times. Also, ApacheTK
provides the script wlm_watch.cgi, which provides a web-based view of
the standard prmmonitor, prmlist, and other WLM and PRM
command-line tools. These are view-only reports—no modifications are
allowed from the CGI script.

434 Appendix D
 Integration with other products
Integrating with Apache

How do I get started with ApacheTK

The best way to use ApacheTK is to read the white paper Using HP-UX
Workload Manager with Apache available from
/opt/wlm/toolkits/apache/doc/apache_wlm_howto.html and at the
following Web site:
http://www.hp.com/go/wlm
The paper guides you through the steps and tools needed to have WLM:

• Separate Apache from Oracle database instances

• Separate Apache from batch work
• Isolate a resource-intensive CGI workload
• Isolate a resource-intensive servlet workload
• Separate all Apache Tomcat workloads from other Apache workloads
• Separate two departments’ applications using two Apache instances
• Separate module-based workloads with two Apache instances
• Manage Apache CPU allocation by performance goal

For more ApacheTK information

If you would like to learn more about ApacheTK and Apache, see:

• /opt/wlm/toolkits/apache/doc/apache_wlm_howto.html
• wlmtk(5)
• time_url_fetch(1M)
• wlm_watch(1M)
• HP-UX Workload Manager Toolkits User’s Guide
(opt/wlm/toolkits/doc/WLMTKug.pdf)
• HP-UX Workload Manager Toolkits A.01.10.xx Release Notes
(/opt/wlm/toolkits/doc/Rel_Notes)
• http://www.hp.com/go/webservers, then select the Apache link

Appendix D 435
Integration with other products
Integrating with BEA WebLogic Server

Integrating with BEA WebLogic Server

WLM can help you manage and prioritize WebLogic-based workloads
through the use of the WLM BEA WebLogic Toolkit (WebLogicTK), which
is part of the freely available product WLM Toolkits (WLMTK).

Why use WebLogicTK?

Using WLM with WebLogic you can move CPU resources to or from
WebLogic Server instances as needed to maintain acceptable
performance. By managing the instances’ CPU resources, the instances
will tend to use less net CPU resources over time. You can then use the
additional CPU resources for other computing tasks.
As indicated previously, WLM and WebLogicTK control CPU allocation
to individual WebLogic instances. However, the latest version of the
paper Using HP-UX Workload Manager with BEA WebLogic expands the
methods for controlling instances to control WebLogic Server clusters.

Tools in WebLogicTK
WebLogicTK includes a white paper and example configuration files that
demonstrate resource separation of WebLogic-based workloads. It also
includes the data collector wlmwlsdc, which tracks metrics for WebLogic
instances. Also, WebLogicTK provides the expsmooth utility for
smoothing values from WLM data collectors by computing a running
average in which the importance of old values diminishes (decays) over
time.

How do I get started with WebLogicTK

The best way to use WebLogicTK is to read the white paper Using
HP-UX Workload Manager with BEA WebLogic Server available from
/opt/wlm/toolkits/weblogic/doc/weblogic_wlm_howto.html and at the
following Web site:
http://www.hp.com/go/wlm
The paper guides you through example WLM configurations that show
how to manage various types of WebLogic instances.

436 Appendix D
 Integration with other products
Integrating with BEA WebLogic Server

For more WebLogicTK information

If you would like to learn more about WebLogicTK, see:

• /opt/wlm/toolkits/weblogic/doc/weblogic_wlm_howto.html.
• wlmtk(5)
• wlmwlsdc(1M)
• expsmooth(1M)
• HP-UX Workload Manager Toolkits User’s Guide
(opt/wlm/toolkits/doc/WLMTKug.pdf)
• HP-UX Workload Manager Toolkits A.01.10.xx Release Notes
(/opt/wlm/toolkits/doc/Rel_Notes)

Appendix D 437
Integration with other products
Integrating with SAP software

Integrating with SAP software

In conjunction with HP Serviceguard Extension for SAP (SGeSAP),
WLM provides integration with SAP applications through the WLM SAP
Toolkit (SAPTK). This toolkit is part of the freely available WLM
Toolkits, or WLMTK.
SAP has several different types of processes such as dialog (interactive),
batch, update, and spool processes. Each type of process might have
greater importance at unique times of the month. For example, batch
processes can become very important at the end of the month when
information is being compiled for end-of-month reports. The issue with
managing SAP workloads has been that the process types cannot be
determined from standard ps output, which is what WLM typically uses
to place processes in workload groups.
WLM and SAPTK now provide the solution, made possible by the WLM
process map feature introduced in WLM A.03.01. Now you can identify
different SAP processes and separate them into different workloads. The
WLM SAP Toolkit provides a process ID identifier called wlmsapmap that
is designed to use process maps. The wlmsapmap tool allows you to
identify and isolate entire SAP instances—or just subsets of an
instance’s processes—as a separate workload. For example, you can use
wlmsapmap to collect batch and dialog processes and place them in
separate workload groups.

Why use SAPTK?

SAPTK allows easy isolation and separation of SAP workloads. You can
use WLM to prioritize and assign specific SAP processes to workload
groups. For example, you can:

• Isolate an entire SAP system as a workload

• Isolate an SAP instance as a workload
• Separate SAP processes from an instance and place them in a
workload

Tools in SAPTK
This toolkit includes the following tool:

438 Appendix D
 Integration with other products
Integrating with SAP software

wlmsapmap
wlmsapmap is the SAP process ID collector for WLM. It
returns a list of process IDs that are of a specified
process type. SAP has several process types, including
dialog (DIA), batch (BTC), and update (UPD).

How do I get started with SAPTK?

The best way to get started with SAPTK is to read the white papers
Using HP-UX Workload Manager with SAP and SAP and HP-UX
Workload Manager: Potential use cases, available from:
http://www.hp.com/go/wlm
The Using HP-UX Workload Manager with SAP white paper is also
available from:
/opt/wlm/toolkits/sap/doc/sap_wlm_howto.html
The paper guides you through the steps and tools needed to use WLM
with SAP applications.
In addition, look at the example configuration files in
/opt/wlm/toolkits/sap/config.

For more SAPTK information

If you would like to learn more about SAPTK, see:

• wlmtk(5)
• wlmsapmap(1M)
• HP-UX Workload Manager Toolkits A.01.09 Release Notes
/opt/wlm/toolkits/doc/Rel_Notes

Appendix D 439
Integration with other products
Integrating with SAS software

Integrating with SAS software

WLM provides integration with SAS software through the WLM Toolkit
for Base SAS Software (SASTK). This toolkit, which is part of the freely
available WLM Toolkits, or WLMTK, product relies upon the WLM
Duration Management Toolkit, DMTK.

NOTE The HP-UX WLM Duration Management toolkit (DMTK), including its
wlmdurdc command, and the HP-UX WLM Toolkit for Base SAS
Software (SASTK), will be deprecated in a future release. However, a
new and improved SASTK will be made available and will include a
white paper and example configuration files. Support for the DMTK
wlmdurdc command will be removed in a future release. In the
meantime, for wlmdurdc documentation, see the wlmdurdc(1M). HP
recommends using usage-based controllers instead of DMTK.

WLM and DMTK help control CPU resources by granting a critical job
only the amount of CPU resources needed to complete within a certain
timeframe. Because the business-critical job is being duration managed,
the extra compute resource on the server can be made available to other
users or jobs without affecting the managed business-critical job. This
translates to more efficient use of existing compute resources. This
feature, known as duration management, is useful in Base SAS
environments and many other environments.
Furthermore, even without DMTK, WLM can grant computing resources
upon demand by providing an “express lane” to ensure that your most
important jobs are given top priority. Express lanes can be particularly
beneficial in a Base SAS environment where any user has the ability to
launch a job that can, regardless of its business priority, significantly
affect the performance of other jobs.

Why use SASTK?

Combining SASTK with DMTK, you can control your SAS jobs using:

• Job duration providing jobs just the right amount of CPU

resources—not too much or too little—to finish within user-specified
time ranges

440 Appendix D
 Integration with other products
Integrating with SAS software

• Examples that show how express lanes can be used to quickly

complete urgent jobs
DMTK does not reduce the amount of CPU time an application must
have to complete; it merely attempts to regulate the application’s access
to CPU resources. For example, if an application takes one hour to
complete when using 100% of the CPU resources, DMTK cannot make its
duration less than one hour.

Tools in SASTK
SASTK provides a macro:
hp_wlmtk_goals_report
This is a SAS macro that is useful in instrumenting SAS jobs to:

• Get profile data indicating elapsed time for a job

• Inform wlmdurdc of a job’s percent completed

How do I get started with SASTK?

To get ideas on how to implement SASTK in your environment, look at
the example configuration files that come with SASTK. These files are in
/opt/wlm/toolkits/sas/config/. Also, see how the example scripts in
/opt/wlm/toolkits/sas/examples/ may help you.

For more SASTK information

If you would like to learn more about SASTK, see:

• wlmtk(5)
• wlmdurdc(1M)
• hp_wlmtk_goals_report(1M)
• HP-UX Workload Manager Toolkits User’s Guide
(opt/wlm/toolkits/doc/WLMTKug.pdf)
• HP-UX Workload Manager Toolkits A.01.10.xx Release Notes
(/opt/wlm/toolkits/doc/Rel_Notes)

Appendix D 441
Integration with other products
Integrating with the HP-UX SNMP agent

Integrating with the HP-UX SNMP agent

WLM provides integration with the HP-UX SNMP agent through the
WLM SNMP Toolkit (SNMPTK). This toolkit is part of the freely
available WLM Toolkits, or WLMTK.
SNMPTK provides a WLM data collector called snmpdc, which fetches
values from an SNMP agent so you can use them as metrics in your
WLM configuration.

Why use SNMPTK?

SNMPTK allows easy access to SNMP agent metrics that you can use in
your WLM configuration to:

• Drive SLO goals

• Set up shares-per-metric allocations
• Enable and disable SLOs
Sources of metrics include:

• PRM data, available starting at the OID .1.3.6.1.4.1.11.5.4.2.1

(hp.hpSysMgt.hpUXSysMgt.hpPRM.prmReadOnly)

Tools in SNMPTK
SNMPTK provides the snmpdc data collector for pulling data from the
SNMP agent.

How do I get started with SNMPTK?

To get ideas on how to implement SNMPTK in your environment, look at
the example configuration files that come with SNMPTK. These files are
in /opt/wlm/toolkits/snmp/config/.

442 Appendix D
 Integration with other products
Integrating with the HP-UX SNMP agent

For more SNMPTK information

If you would like to learn more about SNMPTK, see:

• wlmtk(5)
• snmpdc(1M)
• HP-UX Workload Manager Toolkits A.01.10.xx Release Notes
(/opt/wlm/toolkits/doc/Rel_Notes)

Appendix D 443
Integration with other products
Integrating with the HP-UX SNMP agent

444 Appendix D
E Useful PRM utilities

This appendix highlights PRM utilities that WLM users may find
helpful.

NOTE These PRM utilities are helpful only when the current WLM
configuration includes a prm structure.

For additional information, see the manpages or to the Process Resource

Manager User’s Guide (available in /opt/prm/doc/).
Useful PRM utilities are:

• prmanalyze (with any options)

Allows you to analyze resource usage and contention to help plan
configurations.
• prmavail (with any options)
Displays estimated resource availability to help plan configurations.
• prmconfig (with no options or with -u)
Displays configuration information (with no options).
Releases, or unlocks, the configuration lock (-u). If you need to
release a configuration lock, ensure that the WLM daemon is
completely stopped by entering the following command:
# wlmd -k

NOTE The prmconfig command has other options, but do not use them
with WLM.

• prmlist (with any options)

Displays the current workload group, memory, user, application, and
disk configuration information.

Appendix E 445
Useful PRM utilities

• prmmonitor (with any options)

Monitors current PRM configuration and resource usage by workload
group.
• prmmove (with any options)
Moves processes or groups of processes to another workload group.
• prmrun (with any options)
Runs an application in its assigned group or in a specified group.
Do not use the prmloadconf and prmrecover tools with WLM.

446 Appendix E
F Understanding how PRM
manages resources
One of the ways in which WLM performs resource management is
through HP Process Resource Manager (PRM).
This appendix focuses on management using PRM. The appendix is for
background information and is included here only for completeness, as
WLM uses some of these concepts and tools.
Table F-1 provides an overview of the resource management.
Table F-1 Resources managed

Resource
Management algorithm
managed

CPU (core) Set minimum and maximum CPU request values and/or a
shares-per-metric request, then WLM automatically adjusts cores based on
workload performance, priority, and available cores.
With WLM, you can also set hard limits on CPU usage with the gmincpu
and gmaxcpu keywords.

Disk PRM re-orders the Logical Volume Manager (LVM) volume group’s I/O
bandwidth requests in the kernel based on the PRM group shares.

Real If the system is paging or a workload group is exceeding its cap, the prm2d
memory memory manager forces the group’s processes to re-use their own workload
group’s memory.
With WLM, you can also set hard limits on memory usage with the gminmem
and gmaxmem keywords.

Appendix F 447
Understanding how PRM manages resources
Management of CPU resources

Management of CPU resources

When you configure WLM, you specify minimum and maximum requests
for CPU shares and/or a shares-per-metric request for each SLO. Based
on the SLO’s priority, the workload’s performance, and the system’s
available CPU resources, WLM manages each workload group’s number
of CPU shares, increasing or decreasing that number automatically.
WLM drives each workload group’s CPU resources to a certain number of
shares, resulting in a new PRM configuration. PRM then enables the
new configuration, giving groups with more shares more opportunities to
use CPU time. (WLM partition management is performed without the
PRM configuration.)
For an overview of the method WLM uses to allocate CPU resources, see
“Allocating CPU resources: The rising tide model” on page 122.

Management of CPU resources for real-time processes

Although PRM is designed to treat processes fairly based upon their
assigned shares, PRM does not restrict real-time processes. Real-time
processes using either the POSIX.4 real-time scheduler (rtsched) or the
HP-UX real-time scheduler (rtprio) keep their assigned priorities
because timely scheduling is crucial to their operation. Hence, they are
permitted to exceed their group’s number of CPU shares and its cap.
However, the CPU resources they use are still counted as part of the
CPU allocated to their groups. Thus, they can prevent other processes in
their groups from running.

448 Appendix F
 Understanding how PRM manages resources
Management of real memory

Management of real memory

NOTE WLM manages memory based on your use of the keywords gminmem,
gmaxmem, and memweight in your WLM configuration.

A portion of real memory is always reserved for the kernel

(/stand/vmunix) and its data structures, which are dynamically
allocated. The amount of real memory not reserved for the kernel and its
data structures is termed available memory—available memory is not
the total memory on the system. Available memory is the amount
reported by prmavail. Available memory is consumed by user processes
and nonkernel system processes such as network daemons; therefore, it
varies over time. Because the size of the kernel varies depending on the
number of interface cards, users, and values of the tunable parameters,
available memory also varies from system to system.
PRM memory management allows you to prioritize how available
memory is allocated to user and application processes. This control
enables you to ensure that critical users and applications have enough
real memory to make full use of their CPU time.
Processes in the PRM_SYS group (ID 0) and the kernel get as much
memory as they need. They are not subject to PRM memory constraints.
The memory manager (prm2d) partitions memory with each workload
group getting a partition. A partition includes x Mbytes of memory,
where x Mbytes is equivalent to the group’s entitled percent of the
available memory. Each partition pages separately.
When system memory use is not at 100%, a workload group that does not
have its memory use capped can freely borrow excess memory pages from
other workload groups. If a process requires memory and its memory use
is capped, processes in the same workload group as the original process
are forced to page to free up memory.
When system memory use is at a peak, borrowed memory pages are
returned to the owning workload groups if needed. In addition, if a group
is exceeding its memory allocation, prm2d forces members of that group
to re-use their own memory pages.
prm2d does not allow groups to exceed their memory caps.

Appendix F 449
Understanding how PRM manages resources
Management of real memory

Capping memory use

You can optionally specify a memory cap (upper bound) for a workload
group using the gmaxmem keyword in your WLM configuration, as
explained in “Specifying a group’s maximum memory (optional)” on
page 184. Typically, you might choose to assign a memory cap to a
workload group of relatively low priority, so that it does not place
excessive memory demands on the system.

NOTE Processes in the PRM_SYS group (ID 0) and the kernel are not subject to
memory capping.

Management of locked memory

Real memory can be locked (that is, its pages kept in memory for the
lifetime of a process) by the kernel, by the plock() system call, or by the
mlock() system call.
Locked memory cannot be paged or swapped out. Typically, locked real
memory holds frequently accessed programs or data structures, such as
critical sections of application code. Keeping them memory-resident
improves system performance. Locked memory is extensively used in
real-time environments, like hospitals, where some processes require
immediate response and must be constantly available.
With the prm2d memory manager, locked memory is distributed based on
the assigned memory allocations. For example, assume a system has 200
Mbytes of available memory, 170 Mbytes of which is lockable. Lockable
memory divided by available memory is 85%. If GroupA has a 50%
memory allocation, it gets 100 Mbytes of real memory. Of that amount,
85% (or 85 Mbytes) is lockable. Notice that 85 Mbytes/170 Mbytes is
50%, which is the group’s memory allocation. Figure F-1 illustrates this
idea.

450 Appendix F
 Understanding how PRM manages resources
Management of real memory

Figure F-1 Locked memory distribution by prm2d memory manager

200 Mbytes of available memory

(includes lockable memory) GroupA

170 Mbytes of
lockable memory
GroupB GroupC

PRM does not suppress a process that uses locked memory once the
process has the memory because suppressing the process will not cause it
to give back memory pages. However, the memory resources that such a
process consumes are still counted against its PRM group. If processes
using locked memory consume as much or more memory than their
group is entitled to, other processes in that group may be suppressed
until the demands of the processes with locked memory are lower than
the group’s share.
Also, if a workload group is using all of its lockable memory, you cannot
reduce its memory allocation. This is because a reduction in its allocation
would result in a reduction in its amount of lockable memory. However,
because the group is already using all of its lockable memory, it cannot
give that memory up.

Appendix F 451
Understanding how PRM manages resources
Management of disk bandwidth

Management of disk bandwidth

PRM manages disk bandwidth at the logical volume group level. As such,
your disks must be mounted and under the control of Logical Volume
Manager (LVM) to take advantage of PRM disk bandwidth management.
LVM divides the disk in much the same way as the hard partitions
implemented under previous versions of HP-UX for the Series 800
systems. However, logical volumes are much easier to reconfigure than
partitions, and they can span two or more disks. These two attributes
make LVM a much more powerful and flexible tool than hard partitions.
LVM uses the concept of a volume group, which is a collection of one or
more disks. A volume group can be divided into several partitions, which
are called logical volumes.

NOTE When setting up LVM, do not create swap partitions in any volume group
that is under PRM control.

For information on using LVM, see Managing Systems and Workgroups:

A Guide for HP-UX System Administrators. This book is available on the
Web at http://docs.hp.com.
PRM controls disk bandwidth by re-ordering a volume group’s I/O
requests. This has the effect of delaying the I/O requests of low-priority
processes and accelerating those of higher-priority processes.
Disk bandwidth management works only when there is contention for
disk bandwidth, and it works only for actual I/O to the disk. (Commonly,
I/O on HP-UX is staged through the buffer cache to minimize or
eliminate as much disk I/O as possible.)
Disk bandwidth management works on disk devices, stripes, and disk
arrays. It does not work on tape or network devices.
When you change share allocations on a busy disk device, it typically
takes 30 seconds for the actual bandwidth to conform to the new
allocations.

452 Appendix F
 Understanding how PRM manages resources
How resource allocations interact

Multiple users accessing raw devices (raw logical volumes) will tend to
spend most of their time seeking. The overall throughput on this group
will tend to be very low. This degradation is not due to PRM’s disk
bandwidth management.
When performing file system accesses, you need approximately six disk
bandwidth consumers in each workload group before I/O scheduling
becomes noticeable. With two users, you just take turns. With four, you
still spend a lot of your time in system call overhead relative to the peak
device bandwidth. At six, PRM disk bandwidth management begins to
take effect. The more demand you put on the system, the closer the disk
bandwidth manager approaches the specified values for the shares.

How resource allocations interact

You can assign different numbers of shares for core, memory, and disk
bandwidth to a workload group depending on the group’s requirements
for each type of resource. To optimize resource use, it is important to
understand the typical demands for resources within a workload group.
For example, suppose the DesignTool application is assigned to workload
group DTgroup, and it is the only application running in that group.
Suppose also that the DesignTool application uses CPU resources and
memory in an approximate ratio of 2 to 3. For optimal results, assign the
resource shares for DTgroup in the same ratio. For example, assign 10
CPU shares and 15 memory shares or 20 CPU shares and 30 memory
shares.
If the percentages assigned do not reflect actual usage, then a workload
group may not be able to fully utilize a resource to which it is entitled.
For instance, assume you assign 50 CPU shares and 30 memory shares
to DTgroup. At times of peak system load, DTgroup is able to use only
approximately 20 CPU shares (although it is assigned 50 shares) because
it is limited to 30 memory shares. (Recall that DesignTool uses CPU
resources and memory at a ratio of 2 to 3.) Conversely, if DTgroup is
assigned 10 CPU shares and 30 memory shares, then at times of peak
system load, DTgroup is only able to utilize 15 memory shares (not its 30
shares), because it is restricted to 10 CPU shares.

Appendix F 453
Understanding how PRM manages resources
Management of applications

To use system resources in the most efficient way, monitor typical

resource use in workload groups and adjust shares accordingly. You can
monitor resource use with the wlminfo command, the prmanalyze
command, the prmmonitor command, or the optional HP product
GlancePlus.
For wlminfo information, see wlminfo(1M). For prmanalyze information,
see prmanalyze(1). For more information on prmmonitor, see
prmmonitor(1).

Management of applications
This section describes how PRM assigns processes to run in workload
groups. The following topics are discussed:

• How application processes are assigned to workload groups at

start-up
• How child processes are handled
• Pattern matching for file names
• Pattern matching for renamed application processes
• How the application manager affects workload group assignments
When an application is started, it runs in the initial workload group of
the user that invoked it. If the application is assigned to a workload
group by a record in the WLM configuration file, the application
manager soon moves the application to its assigned group. A user who
does not have access to an application’s assigned workload group can still
launch the application as long as the user has execute permission to the
application. An application can be assigned to only one workload group
at a time. Child processes inherit their parent’s workload group.
Therefore, all the application’s child processes run in the same workload
group as the parent application by default.
You can explicitly place an application in a workload group with two
commands. Use the prmrun command to start an application in a
specified group. Use the prmmove command to move an existing
application to another group.

454 Appendix F
 Understanding how PRM manages resources
Management of applications

These rules may not apply to processes that bypass login. For more
information, see the Process Resource Manager User’s Guide.

How application processes are assigned to workload

groups at start-up
Table F-2 describes what workload groups an application process is
started in based on how the application is started.
Table F-2 Group assignments at process start-up

Process initiated Process runs in workload group as follows

By user Process runs in the user’s initial group. If the user does
By at not have an initial group, the process runs in the user
By cron default group, OTHERS. (If the process has a
Upon login compartment record or an application record, or is
owned by a user or Unix group that has a record, or if it
is identified by a process map, it still starts in the
invoking user’s initial group. However, the application
manager will soon move the process to its assigned
group—with process maps taking precedence over
compartment records, compartment records over
application records, application records over user
records, and user records over Unix group records.
Record types and their precedence in workload group
assignments are discussed in Chapter 5, “Configuring
WLM,” on page 135.)

By prmrun {-g targetgrp | -i} Process runs in the workload group specified by
targetgrp or in the user’s initial group. The application
manager cannot move a process started in this manner
to another group. For more information on the PRM
utility prmrun, see Appendix E, “Useful PRM utilities,”
on page 445 and prmrun(1).

By prmrun application Process runs in the application’s assigned workload

(-g targetgrp is not specified) group. If the application does not have a group, an error
is returned.

Appendix F 455
Understanding how PRM manages resources
Management of applications

Table F-2 Group assignments at process start-up (Continued)

Process initiated Process runs in workload group as follows

By prmmove {targetgrp | -i} Process runs in the workload group specified by

targetgrp or in the user’s initial group. The application
manager cannot move a process started in this manner
to another group. For more information on the PRM
utility prmmove, see Appendix E, “Useful PRM utilities,”
on page 445 and prmmove(1).

By another process Process runs in the parent process’s group.

How child processes are handled

When they first start, child processes inherit the workload groups of
their parent processes. At configurable polling intervals, the application
manager checks the PRM configuration file (maintained by WLM)
against all processes currently running. If any processes should be
assigned to different workload groups, the application manager moves
those applications to the correct workload groups. (You can configure the
polling interval with “prmconfig -I interval APPL”. For information,
see prmconfig(1).)
If you move a parent process to another workload group (with the
prmmove command), all of its child processes remain in the original
workload group. If the parent and child processes should be kept
together, move them as a process group or by user login name.

Pattern matching for file names

Application file names in application records can contain pattern
matching notation as described in regexp(5). This feature allows you to
assign all appropriate applications that reside in a single directory to a
workload group—without creating an application record for each
individual application.
The wildcard characters ([, ], *, and ?) can be used to specify application
file names. However, these characters cannot be used in directory names.
For example, the following record is valid:
apps = PRM_SYS : “/opt/wlm/bin/wlm[bcd]”;

456 Appendix F
 Understanding how PRM manages resources
Management of applications

However, the next record uses a wildcard in the directory name and is
not valid:
apps = PRM_SYS : “/opt/wl?/bin/wlmd”; #INVALID

NOTE Be sure to quote strings that include wildcard characters.

To assign all the applications in a directory to a workload group, create

an application record similar to the following, with the file name
specified only by an asterisk (*):
apps = GroupS : “/opt/special_apps/bin/*”;
File names are expanded to their complete names when a PRM
configuration is loaded by WLM. Explicit application records take
precedence over application records that use wildcards. If an application
without an explicit record is matched by several records that use pattern
matching, the record closest to the beginning of the configuration file is
used.

NOTE Beginning with WLM A.03.01, you can use wildcards in both the file
name and the alternate name in a single application record.

Pattern matching for renamed application processes

Alternate names specified in application records can also contain pattern
matching notation as described in regexp(5).

NOTE Use pattern matching only when it is not practical to list all possible
alternate names.

Many complex applications, such as database applications, may assign

unique names to new processes or rename themselves while running. For
example, some database applications rename processes based on the
database instance, as shown in this list of processes associated with a
payroll database instance:

Appendix F 457
Understanding how PRM manages resources
Management of applications

db02_payroll
db03_payroll
db04_payroll
dbsmon_payroll
dbwr_payroll
dbreco_payroll
To make sure all payroll processes are put in the same workload group,
use pattern matching in the alternate names field of the application
record, as shown in the following example:
apps = business_apps : “/usr/bin/database db*payroll”;
For alternate names and pattern matching to work, the processes must
share the same file ID. (The file ID is based on the file system device and
the file’s inode number.) PRM performs this check to make sure that only
processes associated with the application named in the application
record are put in a configured workload group.
If there are multiple application records with alternate names that
match an application name due to redundant pattern matching
resolutions, the first record to match the application name takes
precedence. For example, the application abb matches both of the
following application records:
apps = GroupA : /opt/foo/bin/bar “a*”,
GroupB : /opt/foo/bin/bar “*b”;
Because the *b record is first (based on ASCII dictionary order), the
application abb would be assigned to the workload group GroupB.
Note that Extended Regular Expression alternate names are matched
against the entire available command line, while non-ERE alternate
names are matched against non-dash command-line arguments only.
Note also that commas within an ERE are not separators for alternate
names; they must match commas in the command line.
Knowing the names of all the processes spawned and renamed by the
applications can help in creating pattern matching that is only as
general as it needs to be. Eliminate redundant name resolutions
whenever possible, and make sure pattern matching does not cause
unwarranted moves.
For information on how alternate name pattern matching affects
precedence, see the next section.

458 Appendix F
 Understanding how PRM manages resources
Management of applications

How the application manager affects workload group

assignments
The PRM application manager checks that applications are running in
the correct workload groups every interval seconds. The default
interval is 30 seconds; however, you can change it with “prmconfig -I
interval APPL” as explained in prmconfig(1).
When determining the workload group assignment for a process
identified by multiple records, WLM gives precedence (from highest to
lowest) to the assignments as follows:

1. Process maps
2. Compartment records
3. Application records
4. User records
5. Unix group records
Thus, if a PID specified by a PID_finder script defined in a process map
matches a compartment, application, user, or Unix group record, the
process map determines the placement of the process.
A process may start in a workload group other than its assigned group
because it inherits the group of the process that started it. However,
WLM will eventually move the process to the workload group specified in
its record. For information on process placement for inactive FSS groups
and PSET-based groups, see “Temporarily removing groups with inactive
SLOs (optional)” on page 220
If you use the prmmove or prmrun command to place a process in a
workload group, that assignment takes precedence over any of the
assignments defined by the WLM records or process maps.
To determine where to place a process, the application manager checks
for the following:

1. Did a user manually move (using prmrun or prmmove) the process to

the current workload group, or was the process moved to the current
workload group by a process map?
If yes, leave the process where it is.
If no, continue with the checklist.

Appendix F 459
Understanding how PRM manages resources
Management of applications

2. Is the process running in a secure compartment that is mapped to a

workload group using a compartment record? (Use the HP-UX
feature Security Containment to create secure compartments.)
If yes, move the process to the group indicated in the compartment
record.
If no, continue with the checklist.
3. Does the file ID of the process match the file ID for the full pathname
of any application listed in an application record in the current
configuration?
If no, skip to Step 4.
If yes, continue with the following checklist:

a. Is the application process name an exact match of an alternate

name given in an application record in the current configuration?
If yes, move the process to the group indicated in the application
record.
If no, continue with this checklist.
b. Does the application process name match any of the alternate
names specified by pattern (regular expression) that are in
application records in the current configuration?
If the application process name matches only one alternate
name, move the process to the group indicated in that record.
If the application process name matches multiple alternate
names specified by pattern, move the process to the workload
group indicated in the “first” matching record. Because the
application matches each of these records, the “first” matching
record is determined by sorting the alternate names specified by
pattern in lexicographical (ASCII dictionary) order.
If no, continue with this checklist.
c. Are there any application records with this file ID that do not
specify an alternate name?
If yes, move the current process to the workload group indicated
in the application record.
If no, continue with the next step.
4. Is the process running as root?

460 Appendix F
 Understanding how PRM manages resources
Management of applications

If yes, move the process to the PRM_SYS group.

If no, the application manager continues with the checklist.
5. Is the process in the PRM_SYS group, or does it have a user ID
different from its parent?
If yes, continue with the checklist.
If no, leave the process where it is.
6. Is the process run by a user associated with a user record?
If yes, move the process to the initial group indicated in the user
record.
If no, continue with the checklist.
7. Does the effective group ID (GID) of the process match a Unix group
record?
If yes, move the process to the group indicated in the Unix group
record.
If no, move the process to the OTHERS group.
To illustrate these rules, consider the following application records:
apps = GroupA : /bin/call_home,
GroupB : “/bin/cal*”,
GroupC : /bin/cal,
GroupD : “/bin/c*”,
GroupE : /bin/call_home phone_home “tele*_home”,
GroupF : /opt/foo/bin/bar,
GroupG : /opt/foo/bin/bar_none,
GroupZ : /bin/call_home “*home”;
Assume a user starts an application, my_favorite_app, without using
prmrun:
% my_favorite_app
Because the application does not have an application record, it does not
meet any of the criteria discussed previously and starts in the invoking
user’s workload group.
Now assume the user starts the bar_none application, which has a
record, but is started in a group specified using prmrun.
% prmrun -g GroupA bar_none

Appendix F 461
Understanding how PRM manages resources
Management of applications

In this case, the application manager determines that the application

has been moved manually and leaves it as is, in GroupA.
Next, assume the user launches the bar application, which also has an
application record.
% bar
The application starts in the invoking user’s initial group. However, the
application manager will soon place the application in the group
specified in the application record, GroupF.
The user then starts another program:
% phone_home
This application name is an exact match of an alternate name. If
phone_home has the same file ID as /bin/call_home, the phone_home
process is placed in GroupE.
Another user on the system starts a program:
% telegraph_home
This application name matches two alternate names, both specified
using regular expressions: tele*_home and *home. Sorting based on the
ASCII dictionary, the application matches *home first. Assuming
telegraph_home has the same file ID as /bin/call_home, it is placed in
GroupZ.
Starting one more program:
% call_home
The call_home command is matched by the first and eighth records.
(The second and fourth records do not match because PRM expands the
regular expressions when the configuration is loaded and finds
call_home already has a record.) The eighth record takes precedence
because it has an alternate name, and the call_home process is placed in
GroupZ.

NOTE Be careful when constructing regular expressions: As shown with the

eighth record (GroupZ), an expression that is not specific enough can
override explicit application records.

Lastly, a user starts the following program:

462 Appendix F
 Understanding how PRM manages resources
Management of applications

% calendar
The second and fourth records both seem to match the calendar
command. The expressions are expanded in the order they appear in the
configuration file. So, the second record is expanded first and is used for
the calendar process, placing it in GroupB.

Appendix F 463
Understanding how PRM manages resources
Management of applications

464 Appendix F
G Migrating from PRM to WLM

This appendix provides information on converting PRM configuration

files to WLM configuration files.
If your PRM configuration places users in PRM groups, these users can
be grouped similarly in WLM workload groups.
If you are migrating from PRM to WLM, you can quickly convert your
PRM configuration files to WLM configuration files with the wlmprmconf
utility.
This utility, available at /opt/wlm/bin/wlmprmconf, has the following
syntax:
wlmprmconf [-f] PRMconfigfile WLMconfigfile
The wlmprmconf utility takes a PRM configuration (see prmconf(4)) as
the input file PRMconfigfile and translates it to the equivalent WLM
configuration (see wlmconf(4)), storing the result in the file
WLMconfigfile. You can then edit the WLM configuration file to add
SLO goals, change SLO priorities, add time-based conditions and
exceptions, modify WLM tuning parameters, and so forth.
The wlmprmconf utility validates the input PRM configuration using
prmconfig before the translation begins. If prmconfig is not installed or
if the input configuration is invalid, wlmprmconf exits without creating
the WLM configuration file. However, using the -f option, you can force
wlmprmconf to create the WLM configuration file in both of these cases.
After the translation, wlmd checks the validity of the generated WLM
configuration. If the output configuration is invalid, wlmprmconf prints
the wlmd error messages and exits without deleting the generated
configuration file. You can then modify the generated WLM configuration
file without modifying the original PRM configuration file.
The wlmd daemon has stricter rules than prmconfig regarding the
validity of a configuration. In addition, wlmd treats most PRM warnings
as errors. Therefore, it is possible for a valid PRM configuration file to be
translated into a syntactically correct WLM configuration file that fails
the wlmd check. For example, the user names listed in the PRM user
records may not be defined on the system, or the application pathnames
may point to executables that do not exist. In such cases, modify the
generated WLM configuration file to correct the errors reported by wlmd.

Appendix G 465
Migrating from PRM to WLM

The wlmprmconf utility expects that, if specified in the PRM

configuration file, groups PRM_SYS and OTHERS have IDs 0 and 1,
respectively. Conversely, if IDs 0 and 1 are specified, the corresponding
group names must be PRM_SYS and OTHERS, respectively. When the PRM
configuration file does not follow these criteria, wlmprmconf generates a
WLM configuration file with comments indicating the inconsistency. The
wlmd check that WLM performs on the file it generates also highlights
the inconsistency.

466 Appendix G
H Advanced WLM usage: Using
performance metrics
This appendix includes details about configuring WLM SLOs based on
metric goals and supplying performance data to WLM.

Configuring WLM for metric-based SLOs

This section includes details about configuring WLM SLOs to satisfy
metric goals.

Overview
To use WLM with metric goals, follow these basic steps:

Step 1. Identify the workloads to run on a given system.

Each workload can consist of one or more applications and multiple

users.

Step 2. For workloads with performance goals, add goal-based SLOs to your
WLM configuration by following these steps. For details on how to
specify a metric goal, see “Specifying a metric goal (optional)” on
page 470 and “Specifying a shares-per-metric allocation request
(optional)” on page 472.

a. Determine the performance metrics that are already available and

implement other metrics that are needed to ensure that the SLOs are
being met.
b. Send the metrics to WLM using one of the WLM built-in data
collectors or develop your own collector.
Data collectors supply metric data to the WLM daemon. The daemon
then uses this data to determine new resource allocations to enable
the workloads to achieve their SLOs.
You have a number of options when it comes to data collectors:

Appendix H 467
Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

• The easiest data collector to set up is wlmrcvdc using the

sg_pkg_active command, wlmoradc command, one of the
glance_* commands, or one of the other commands given in the
wlmrcvdc section of Appendix A, “WLM command reference,” on
page 363.
• You can also set up wlmrcvdc to forward the stdout of a data-
collecting command to WLM.
• Combining wlmsend with wlmrcvdc, you can send data to WLM
from the command line, a shell script, or a perl program.
• If you are writing a data collector in C, your program can
interface directly with WLM through the libwlm(3) API.

NOTE Data collectors invoked by WLM run as root and can pose a security
threat. Hewlett-Packard makes no claims of any kind with regard to
the security of data collectors not provided by Hewlett-Packard.
Furthermore, Hewlett-Packard shall not be liable for any security
breaches resulting from the use of said data collectors.

For an overview of data collectors, see the section “How applications

can make metrics available to WLM” on page 483.
For more information on built-in data collectors and how to create
your own data collectors, see “Supplying data to WLM” on page 482.

Step 3. (Optional) Tune the controllers’ behavior.

Consider tuning controllers if your workload performance is not

responding to load changes quickly enough or if workload performance is
erratic.

Step 4. (Optional) For notification of SLO status changes, monitor the WLM
EMS resources.

For information on EMS, see Chapter 10, “Monitoring SLO compliance

and WLM,” on page 343.

Step 5. (Optional) Activate the configuration in passive mode.

With passive mode, you can see approximately how a particular

configuration is going to affect your system—without the configuration
actually taking control of your system.

468 Appendix H
 Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

For information on passive mode, including its limitations, see “Passive

mode versus actual WLM management” on page 238.

Activate the WLM file configfile in passive mode as follows:

# wlmd -p -a configfile

To see approximately how the configuration would affect your system,

use the WLM utility wlminfo..

Step 6. Activate the configuration.

Activate your configuration—putting WLM in control of your system’s

resources—as follows. When you start WLM by using the
/sbin/init.d/wlm script, WLM runs in secure mode (if you have upgraded
WLM, ensure that the secure mode variables in the /etc/rc.config.d/wlm
file are enabled). Running WLM in secure mode requires that you set up
security certificates and distribute them to all systems or partitions
being managed by the same WLM global arbiter. For more information,
see “Securing WLM communications” on page 244 and wlmcert(1M).

# wlmd -a configfile

To generate audit data (-t) and log statistics (-l all), use the following
command:

# wlmd -t -a configfile -l all

Step 7. Monitor SLO compliance.

Using wlmgui or wlminfo with its slo command allows you to monitor
your SLOs.

Also, the WLM EMS monitor makes various status data available to
EMS clients. Check this data to verify SLO compliance.

For more information on this topic, see Chapter 10, “Monitoring SLO
compliance and WLM,” on page 343.

Step 8. Monitor data collectors.

Data collection is a critical link in the effective maintenance of your

configured service-level objectives. When a data collector dies, each SLO
that uses the data from the dead collector is affected. Consequently,
monitor your data collectors so you can be aware when one dies.

Appendix H 469
Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

When using wlminfo slo, there are two columns that can indicate the
death of a data collector process: State and Concern. For more
information on these columns, see wlminfo(1M).

Alternatively, configure EMS monitoring requests that notify you on the

death of a data collector.

The SLO’s EMS resource:

/applications/wlm/slo_status/SLONAME

changes to:

WLM_SLO_COLLECTOR_DIED (5)

Use the EMS configuration interface (available in the SAM or SMH

“Resource Management” application group) to set up monitoring
requests to watch for this situation.

Step 9. (Optional) Configure global arbitration across partitions.

You can set up WLM to automatically move CPU resources between

virtual partitions or nPartitions in response to the service-level
objectives of the workloads in the partitions. The workloads would be
specified workloads inside the partitions or the partitions themselves if
you did not define workloads in the partitions.

For more information on the global arbiter, including its passive mode,
see the chapter Chapter 7, “Managing SLOs across partitions,” on
page 255.

Step 10. (Optional) Set up WLM to automatically start its wlmd and wlmpard
daemons at reboot.

Edit the /etc/rc.config.d/wlm file as explained in the sections “Setting

WLM to start automatically at reboot” on page 242 and “Setting WLM
global arbitration to start automatically at reboot” on page 242. You can
also set variables in /etc/rc.config.d/wlm to start logging statistics and
generating audit data automatically at reboot.

Specifying a metric goal (optional)

Use the goal keyword to specify whether the workload’s performance
should be less than or greater than some specified floating-point value.

470 Appendix H
 Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

The goal keyword is optional. If neither the goal nor cpushares

keyword is specified, the SLO is allocated CPU resources according to its
mincpu setting. For information on setting mincpu, see “Specifying the
lower and upper bound requests on CPU resources (optional)” on
page 196.
You cannot specify both a goal statement and a cpushares statement in
the same SLO. Similarly, you cannot have a workload group with one
SLO that has a goal statement and another SLO that has a cpushares
statement that includes more.
Specify a metric goal as follows:
goal = metric met relation value;
where
met Is a text string (no longer than 255 characters) naming
the metric to be used for the SLO. The met string must
also be specified in a tune structure that indicates the
path to your data collector executable that provides the
metric. met cannot contain the slash character (/) or
start with an underscore (_). For information on tune
structures, see “Tuning the metrics and the SLOs” on
page 210.
relation. <. If met is supposed to be less than
value.
>. If met is supposed to be greater than
value.
value Is a numeric goal value, either integer (greater than or
equal to 1) or floating-point number, not expressed in
exponential notation.
For example, here is a performance goal statement:
goal = metric response_time < 3.0;

Appendix H 471
Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

Specifying a shares-per-metric allocation request

(optional)
An SLO can directly express an allocation request using the cpushares
keyword. This keyword allows you to make allocation requests of the
form “x shares of the CPU resources for each metric y”. For example, you
could give an Oracle instance n CPU shares for each process in the
instance.
The cpushares syntax is:
cpushares = value { more | total } [ per metric met [ plus offset ] ];
where
cpushares Is an optional keyword for making CPU allocation
requests. Using the variables in the syntax statement
shown previously, a request—which we will call
request_value—equates to one of the following forms:
value
value * met
value * met + offset
A request is additive when using the more keyword and
absolute when using the total keyword.
You cannot specify both a goal statement and a
cpushares statement in the same SLO. Similarly, you
cannot have a workload group with one SLO that has a
goal statement and another SLO that has a
cpushares statement that includes more.
When you specify the cpushares keyword, the mincpu
and maxcpu keywords are optional.
value Specifies the number of CPU shares to request for the
associated workload group. This value is either an
integer or a floating-point number, not expressed in
exponential notation.
more Makes additive allocation requests by adding the
request_value to other additive requests at the same
priority and to any requests from higher priority SLOs.
If there are no higher priority SLOs, the request is
added to the workload group’s gmincpu value, which is

472 Appendix H
 Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

1% of the system’s total CPU resources by default (if

the tunable extended_shares is set to 1, the gmincpu
value is 0.2% by default).
request_value is bounded by the SLO’s mincpu and
maxcpu values, if specified.
If the workload group can get a larger allocation from
an SLO with an absolute allocation request at that
priority, it does so. This absolute request can come from
an SLO that uses cpushares with total or from an
SLO that uses only the mincpu and maxcpu keywords.
total Makes absolute allocation requests starting from 0.
The request is exactly equal to request_value
(discussed in the cpushares keyword description),
within the bounds formed by the SLO’s mincpu and
maxcpu values, if specified.
If the associated workload group can get a larger
allocation of shares from SLOs of higher or equal
priority making absolute allocation requests, it does so.
per metric Is an optional clause. Using per metric forms an
allocation request by multiplying value by the metric
met in request_value (discussed in the cpushares
keyword description).
met Is the text string naming the metric to be used. The
metric string must also be specified in a tune structure
that indicates the path to the data collector executable
providing the metric. met cannot contain the slash (/)
character, start with an underscore (_), or be more than
255 characters.
plus Is an optional clause, for use only with the per metric
clause, that allows you to increase or decrease the
number of CPU shares to be requested as part of the
request_value, which is discussed in the cpushares
keyword description.
offset Is a floating-point value (either positive or negative)
specifying the number of shares to use as an offset in
the request_value (discussed in the cpushares
keyword description).

Appendix H 473
Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

Consider using absolute_cpu_units (discussed in

“Using absolute CPU units” on page 217) to minimize
the effects of a system’s variable number of CPU
resources on your offset value.
Here are some request_value expressions and the corresponding
cpushares statements:
request_value = 25
cpushares = 25 total;
request_value = 10 * X + 30
cpushares = 10 total per metric X plus 30;
Consider the following example of an additive allocation request:
slo additive_example {
pri = 1;
mincpu = 0;
maxcpu = 50;
entity = PRM group App1;
cpushares = 5 more per metric application_procs;
}
Assume this is App1’s only SLO at this priority. Also assume gmincpu is
20 and application_procs (the number of processes the application has
running) is 3. The SLO requests 35 CPU shares: 5 shares for each of the
3 processes the application has running plus 20 shares from gmincpu.
The next example shows an absolute allocation request. It is the same as
the previous additive example—except it uses total in place of more.
slo absolute_example {
pri = 1;
mincpu = 0;
maxcpu = 50;
entity = PRM group App1;
cpushares = 5 total per metric application_procs;
}
Again, assume application_procs is 3. This time, because it is an absolute
request, the request starts from 0, not the previous allocation request.
Consequently, the request is 5 CPU shares for each of the 3 application
processes in workload group App1 for a total of 15. However, the request
is ignored because the group already has 20 shares because of its
gmincpu setting.

474 Appendix H
 Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

Providing CPU resources in proportion to a metric

This section explains how to set up a workload group with an allocation
that varies in proportion to a metric.
To adjust a workload’s CPU allocation in step with a given metric, such
as number of processes in the workload, users connected to a database,
or any other metric, use the cpushares keyword with per metric in an
slo structure.
In the following figure, the workload receives 5 CPU shares for each
active process in the workload group. As the number of processes
increases, the number of CPU shares increases.

Workload gets 5
CPU shares for each
active process in
the workload

To set up a workload group with an allocation that varies in proportion to

a metric:

Step 1. Define the workload group and assign a workload to it.

In your WLM configuration file, define your workload group in a prm

structure using the groups keyword. Assign a workload to the group
using the apps keyword.

Appendix H 475
Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

In this example, the focus is the sales group, which will get a varying
amount of CPU resources based on a metric:
prm {
groups = sales : 2;

apps = sales : /opt/sales/bin/sales_monitor;

}

Step 2. Define the SLO.

The SLO in your WLM configuration file must specify a priority (pri) for
the SLO, the workload group to which the SLO applies (entity), and the
cpushares statement to request CPU resources in proportion to a metric.

The following slo structure shows the cpushares statement. This SLO
requests 5 CPU shares for the sales group for each process in the
application—as given by the metric application_procs.
slo per_metric_example {
pri = 1;
mincpu = 25;
maxcpu = 50;
entity = PRM group sales;
cpushares = 5 total per metric application_procs;
}

However, if application_procs is less than five or greater than ten, the

values for the optional keywords mincpu and maxcpu will force the
request for additional CPU shares to be between 25 and 50.

Sources for a metric include data available through GlancePlus, SNMP,

and any other metrics you may already have available.

Step 3. Set up WLM to take values for the metric.

The simplest method for getting a metric to WLM is through the WLM
data collector wlmrcvdc.

To receive a value for the metric application_procs, set up a tune

structure. The following tune structure takes advantage of glance_prm,
one of the commands that WLM provides to simplify pulling data from
the optional HP product GlancePlus. In this case, glance_prm pulls the
APP_ACTIVE_PROC metric for the sales workload group:

476 Appendix H
 Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

tune application_procs {
coll_argv = wlmrcvdc glance_prm APP_ACTIVE_PROC sales;
}

As a result of this structure, each time the glance_prm command prints

a value on standard out, wlmrcvdc sends the value to WLM for use in
changing the CPU allocation for the sales group.

For information on other ways to use wlmrcvdc, see wlmrcvdc(1M).

Step 4. Activate the configuration.

# /opt/wlm/bin/wlmd -a config.wlm

substituting your configuration file’s name for config.wlm.

Specifying a data collector

Whenever you use a metric in your WLM configuration, you need to
supply a value for that metric. The coll_argv statement launches a data
collector to gather values for a metric. You can specify a data collector in
a metric-specific tune structure to gather values for that one metric. If
multiple metrics use the same command, such as wlmrcvdc, to collect
values, you can specify the command in a global tune structure, instead
of specifying it separately for each metric in its own metric-specific tune
structure.
The coll_argv keyword is required for SLOs that include a performance
goal. The coll_argv keyword is allowed in global and metric-specific
tune structures.

NOTE Data collectors invoked by WLM run as root and can pose a security
threat. Hewlett-Packard makes no claims of any kind with regard to the
security of data collectors not provided by Hewlett-Packard.
Furthermore, Hewlett-Packard shall not be liable for any security
breaches resulting from the use of said data collectors.

Use the following syntax in a tune structure to specify a data collector

and its command-line arguments:
coll_argv = data_collector_and_arguments;
where

Appendix H 477
Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

data_collector_and_arguments
Is the full path to a data collector, plus any arguments.
Separate arguments with white space. Use double
quotes to form single arguments for an option and
when using characters used in the syntax, such as
semicolons, pound characters (#), and curly brackets.
This string cannot exceed 240 characters.
stdout and stderr for each data collector are sent to /dev/null; however,
you can capture a collector’s stderr output using the coll_stderr
tunable, described in “Capturing your collectors’ stderr (optional)” on
page 479.
Here is an example coll_argv statement:
coll_argv = /opt/finance/bin/fin_mon -freq 3;
WLM provides a built-in data collector called wlmrcvdc. Specify this
collector as follows:
coll_argv = wlmrcvdc [command];
where
command (optional)
Is a command provided for gathering data from
GlancePlus, Oracle, other applications, or for checking
on the status of a Serviceguard package, or a
user-supplied data collector command.
For information on commands available with wlmrcvdc, see “wlmrcvdc”
on page 388.
WLM simplifies the task of developing data collectors with its wlmsend
and wlmrcvdc utilities. For information on these utilities and data
collectors in general, see “Supplying data to WLM” on page 482.
Here is a partial WLM configuration showing the use of wlmrcvdc in a
global tune structure.
# Global wlmrcvdc to collect any metric values sent in via wlmsend:
tune {
coll_argv = wlmrcvdc;
}

# Collector to use instead of the global wlmrcvdc to get values

# for the metric order_transaction_time:

478 Appendix H
 Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

tune order_transaction_time {
coll_argv = /home/orders/data_collector;
}

# Value of metric analysis_application_running given to WLM by wlmsend

# through global wlmrcvdc
slo analysis {
...
condition = metric analysis_application_running;
...
}

# Value of metric job_count given to WLM by wlmsend through

# global wlmrcvdc
slo batch_processing {
...
cpushares = 2 more per metric job_count;
...
}

# Uses metric value given by collector in metric-specific tune structure

slo order_processing {
...
goal = metric order_transaction_time < 10.0;
...
}
If you are using WLM with Serviceguard, you might consider using
wlmrcvdc in a global tune structure with sg_pkg_active to check the
status of all the Serviceguard packages on the current system. For more
information, see “Integrating with Serviceguard” on page 414 or see
sg_pkg_active(1M).

Capturing your collectors’ stderr (optional)

Because they are started by a daemon process, data collectors do not
have a stderr on which to communicate errors. The coll_stderr tunable
allows you to capture these errors. Specify coll_stderr using the
following syntax:
coll_stderr = file;
where

Appendix H 479
Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

coll_stderr Is an optional tunable with a default value of /dev/null.

Specify this tunable in global or metric-specific tune
structures.
file Is either syslog (which corresponds to syslog on the
system through the logger command, typically
/var/adm/syslog/syslog.log) or the full path to a file.
For example, you can specify file in either of the following ways:
tune num_users {
...
coll_stderr = syslog;
...
}

tune load_average {
...
coll_stderr = /logs/load_average.stderr;
...
}

NOTE There are no restrictions on the file specified. However, specifying

system files or files created by applications on your system (such as the
WLM /var/opt/wlm/msglog and /var/opt/wlm/wlmdstats) is not
recommended as it can damage the files.

Smoothing metric values (optional)

Use the cntl_smooth keyword to get a running average of a metric from
a data collector, smoothing out dips and spikes in the metric before it is
used by WLM. Specify cntl_smooth using the following syntax:
cntl_smooth = smoothing_value;
where
cntl_smooth
Is an optional tunable that provides exponential
smoothing. Specify this tunable in global or
metric-specific tune structures.
smoothing_value

480 Appendix H
 Advanced WLM usage: Using performance metrics
Configuring WLM for metric-based SLOs

Is a floating-point value ranging from 0 to 0.999. The

default value is 0, resulting in no smoothing. Values
closer to 1 result in more smoothing.

NOTE Do not use cntl_smooth for metrics that are expected to equal zero in
SLO condition expressions. For example, do not use smoothing globally
if your configuration uses the sg_pkg_active collector to indicate a
Serviceguard package is active (1) or inactive (0). You could use
cntl_smooth in metric-specific tune structures in such a configuration,
as long as those structures are not for Boolean metrics.

Smoothing occurs only in WLM intervals in which a new metric value is

received.
The metric value reported in the log file /var/opt/wlm/wlmdstats is the
smoothed value.

Appendix H 481
Advanced WLM usage: Using performance metrics
Supplying data to WLM

Supplying data to WLM

You supply data to WLM so it can manage SLOs that have performance
goals, shares-per-metric allocations, or condition/exception
statements with metric expressions. You gather this data with collectors
provided by WLM or ones you develop yourself. Data collectors are
specified in the WLM configuration file. WLM spawns the collectors
when the configuration is activated.
Sources for data include:

• ARM (Application Response Measurement) metrics

• GlancePlus metrics
• Oracle database metrics
• Various third-party applications
Metrics can be easily obtained for a number of third-party
applications through the WLM Toolkits (WLMTK). In addition to the
toolkit for Oracle databases, WLMTK provides toolkits for Apache,
BEA WebLogic Server, and SAS.
• Existing application and system metrics you already track
Once this data is collected, it can be sent to WLM in one of two ways:

• WLM wlmrcvdc and wlmsend utilities (which provide a

command-line, shell script, and perl program interface)
• WLM C language API
This chapter covers these topics from two views:

• Data-centric:
I have this type of data. How do I get it to WLM?
• Transport-centric:
I want to get data to WLM this way. What data is available for that
transport method?

482 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

NOTE A white paper on data collectors (”Writing a Better WLM Data

Collector”) is available at the following location:
/opt/wlm/share/doc/howto/perfmon.html
This paper provides additional information on implementing your data
collectors.

How applications can make metrics available to WLM

Consider the following overview of how to get metrics to WLM.

Time metrics from instrumentable applications

If the desired metric can be measured in units of time, and the
application can be modified, we recommend using the ARM API provided
by GlancePlus. WLM will then collect the ARM data from GlancePlus,
synchronizing the values used by WLM with those used in VantagePoint
Performance tools.
Adding ARM routines to an application is as simple as specifying your
application with an arm_init call, marking the start of the time period
to be measured with an arm_start call, and marking the end of the time
period with an arm_end call.
For more ARM information, see “Sending ARM transaction data from a
modified C program” on page 504.

Other data collection techniques

If your application cannot be modified to insert ARM calls, or if your
metric does not have time units, then implement an external data
collector. There are three types of external data collectors to consider:

• Independent collectors
• Stream collectors
• Native collectors
These collector types are explained in the remainder of this section.

Appendix H 483
Advanced WLM usage: Using performance metrics
Supplying data to WLM

Independent collectors Independent collectors use the wlmsend

command to communicate a metric value to WLM. For more information
on this command, see “What methods exist for sending data to WLM?” on
page 493.
They are called “independent” because they are not started by the WLM
daemon wlmd, and they are not required to run continuously.
This type of collector is ideal if you want to convey event information to
WLM, such as application startup or shutdown.
One caveat of using this type of collector is that on start-up, WLM has no
value for the metric until the collector provides one. For this reason, the
collector should be structured to report a value periodically, even if it has
not changed.
If your collector runs continuously, be careful if using pipes. The pipes
may have internal buffering that must either be defeated or flushed to
ensure the data is communicated in a timely manner.
To configure an independent collector for a metric called metricIC, place
the following tune structure in your configuration file:
tune metricIC {
coll_argv = wlmrcvdc;
}

Stream collectors Stream collectors convey their metric values to

WLM by writing them to stdout. WLM starts these data collectors when
activating a configuration, and expects them to continue to run and
provide metrics until notified of a WLM shutdown or restart.
Use this type of collector if the metric is available in a file or through a
command-line interface. In this case, the collector can simply be a script
containing a loop that reads the file or executes the command, extracts
the metric value, writes it on stdout, and sleeps for one WLM interval.
(The current WLM interval length is available through the
WLM_INTERVAL environment variable to data collectors started by WLM
through a coll_argv statement in the WLM configuration.)
Again, as with independent collectors, be careful if using pipes in the
data collector. These pipes may have internal buffering that must either
be defeated or flushed to ensure the data is communicated in a timely
manner.

484 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

Because they are started by a daemon process (wlmd), stream collectors

do not have a stderr on which to communicate errors. However, WLM
provides the coll_stderr tunable that allows you to log each collector’s
stderr. In addition, a stream data collector can communicate using either
syslog(3C) or logger(1) with the daemon facility.
To configure a stream collector for a metric called metricSC, place the
following tune structure in your configuration file:
tune metricSC {
coll_argv = wlmrcvdc collector_path collector_args ;
}
The sg_pkg_active data collector is an example of a stream collector, as
are several of the Toolkit data collectors, including time_url_fetch
(ApacheTK) and wlmwlsdc (WebLogicTK).

Native collectors Native collectors use the WLM API to communicate

directly with the WLM daemon. For information on the WLM API, see
“Sending data from a collector written in C” on page 499.
Like stream collectors, these collectors are started by WLM when
activating a configuration. WLM expects them to continue to run and
provide metrics until notified of a WLM shutdown or restart. For tips on
writing your own data collectors, see the white paper at
/opt/wlm/share/doc/howto/perfmon.html.
This type of collector is appropriate if the desired metric values are
obtained through calls to a C or C++ language API that is provided by
the source of the metric. One example of such an API is the pstat(2)
family of system calls used to obtain process statistics.
This type of collector establishes a direct connection with WLM using the
WLM API function wlm_mon_attach(). Then, executed in a loop, the
collector calls the API functions necessary to obtain the metric value,
followed by a call to the WLM API function wlm_mon_write() to pass the
value on.
Because they are started by a daemon process (wlmd), native collectors’
output to stdout and stderr is discarded. However, WLM provides the
coll_stderr tunable that allows you to log each collector’s stderr. In
addition, a native data collector can communicate using either syslog(3C)
or logger(1) with the daemon facility.
To configure a native collector for a metric called metricNC, place the
following tune structure in your configuration file:

Appendix H 485
Advanced WLM usage: Using performance metrics
Supplying data to WLM

tune metricNC {
coll_argv = collector_path collector_args ;
}
wlmrcvdc is an example of a native collector.

What happens when there is no new data?

If an entire WLM interval passes and WLM does not receive any new
data for a metric, all controllers using that metric simply request the
same allocations for their associated workload groups as they did the
previous interval. As always, the requests may not be met due to the
CPU resource requests of other controllers.

NOTE The current WLM interval length is available through the WLM_INTERVAL
environment variable to data collectors started by WLM (by specifying
the data collector in a coll_argv statement in a WLM configuration
file).

I have this type of data—how do I send it to WLM?

This section focuses on the type of data you have collected or plan to
collect. Knowing the type of data, you can then determine the best way to
get that data to WLM.
If you have any of the following types of data, send the data to WLM as
explained in this section:

• ARM transaction data

• GlancePlus application data
• GlancePlus global data
• GlancePlus PRM-specific application data
• GlancePlus PRM-controlled volume group data
• Oracle database data
• Existing metrics

486 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

GlancePlus is an optional HP product. Install it if you wish to use the HP

ARM implementation or to collect any of the GlancePlus data listed
previously. For purchase information, contact your HP sales
representative.
Table H-1 gives an overview of the types of data you can collect and the
methods for transporting that data to WLM.
Table H-1 Type of data and its transport method

What type of data do you have? Transport method

• The application is already instrumented with ARM API glance_tt

calls
• You have the application source code and are going to
instrument it with ARM API calls (TT_* metrics)

You already track GlancePlus “applications” you defined in glance_app

your /var/opt/perf/parm file (APP_* metrics)

• GlancePlus Global metrics (GBL_* metrics) glance_gbl

• Table metrics (TBL_* metrics)

GlancePlus PRM-specific application metrics glance_prm

(APP_PRM_* and APP_* metrics)

GlancePlus PRM By Volume Group metrics glance_prm_byvg

(PRM_BYVG_* metrics)

An SQL value or an execution time (walltime) resulting wlmoradc

from executing SQL statements against an Oracle instance

You have a program/script that reports metrics to stdout wlmrcvdc

You have metrics you are collecting outside GlancePlus wlmsend/wlmrcvdc

using a shell script or perl program

You have metrics you are collecting outside GlancePlus WLM API
using a C program

The following sections explore each of the data collection methods in

more detail.

Appendix H 487
Advanced WLM usage: Using performance metrics
Supplying data to WLM

ARM transaction data

For information on:

• How to get transaction data for an application that is already

instrumented with ARM API calls to WLM
• How to instrument an application with ARM API calls
see “Sending ARM transaction data from a modified C program” on
page 504.
For information on how to simulate transactions, see “Sending ARM
transaction data from a script with simulated transactions” on page 509.

GlancePlus application data

You can define GlancePlus applications in the /var/opt/perf/parm file.
Defining applications helps you see what is going on within a WLM
workload group. You can also configure your WLM workload groups to be
considered “applications.” For more information, see “Integrating with
OpenView Performance Agent (OVPA) / OpenView Performance
Manager (OVPM)” on page 413.
The following example shows an application definition for Oracle
database software:
application = Oracle
file = ora*, sqldba, sqlplus, tnslsnr, lsnrctl
By creating such an entry in the parm file, we can access metrics for all
Oracle and associated processes on the system.
Examples of GlancePlus application metrics are:
APP_ACTIVE_PROC
The number of processes in a GlancePlus application
that are competing for the CPU resources.
APP_ALIVE_PROC
The number of processes that exist in a GlancePlus
application.
APP_CPU_TOTAL_UTIL

488 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

The percentage of the total CPU time devoted to

processes in this group during the interval. This
indicates the relative CPU load placed on the system
by processes in this group.
APP_MEM_UTIL
The approximate percentage of the system’s physical
memory used as resident memory by processes in this
group during the interval.
For a list of metrics, see:

• The Application Metrics subsection of the Performance Metrics

section in the GlancePlus online help, available through gpm
• One of the /opt/perf/paperdocs/gp/C/metrics.* documents
• The glance_app(5) manpage. which lists some of the more frequently
used metrics (manpage also available at http://www.hp.com/go/wlm)
To extract application data (APP_* metrics), use wlmrcvdc with the
glance_app command in the configuration file. For example:
tune active_procs {
...
coll_argv = wlmrcvdc glance_app
APP_ACTIVE_PROC # Metric to monitor
Oracle; # Application defined in parm file
...
}
For wlmrcvdc conceptual information, see “Sending data with wlmsend
and wlmrcvdc: How it works” on page 509. For wlmrcvdc syntax
information, see “wlmrcvdc” on page 388.

GlancePlus global data

Global data provides information on the system as a whole.
Examples of GlancePlus global metrics are:
GBL_ACTIVE_PROC
The number of active processes. A process is active if it
exists and consumes some CPU resources.
GBL_CPU_TOTAL_UTIL

Appendix H 489
Advanced WLM usage: Using performance metrics
Supplying data to WLM

Percentage of time the CPUresources were active

during the interval.
GBL_NUM_USER
The number of users logged into the system.
For a full list of the available data, see the GlancePlus online help,
available through gpm.
To extract global data (GBL_*), use wlmrcvdc with the glance_gbl
command in the configuration file. For example:
tune num_users {
...
coll_argv = wlmrcvdc glance_gbl
GBL_NUM_USER; # Metric to monitor
...
}
For wlmrcvdc conceptual information, see “Sending data with wlmsend
and wlmrcvdc: How it works” on page 509. For wlmrcvdc syntax
information, see “wlmrcvdc” on page 388.

GlancePlus PRM-specific application data

GlancePlus provides application data that is specific to workload (PRM)
groups.
Examples of such GlancePlus metrics (APP_* metrics and APP_PRM_*
metrics) are:
APP_ACTIVE_PROC
The number of processes in a workload (PRM) group
that are competing for the CPU resources.
APP_PRM_MEM_UTIL
The percent of PRM memory used by processes
(process-private space plus a process’s portion of
shared memory) within the PRM group during the
interval. This metric is only available if the PRM
memory manager is enabled.
For a full list of the available data, see the GlancePlus online help,
available through gpm.
To extract PRM-specific application data, use wlmrcvdc with the
glance_prm command in the configuration file. For example:

490 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

tune active_procs {
...
coll_argv = wlmrcvdc glance_prm
APP_ACTIVE_PROC # Metric to monitor
Grp3; # Name of workload (PRM) group
...
}

tune mem_util {
...
coll_argv = wlmrcvdc glance_prm
APP_PRM_MEM_UTIL # Metric to monitor
Grp3; # Name of workload (PRM) group
...
}
Use glance_prm to collect metrics of the form APP_* and APP_PRM_*.
Although the APP_* metrics do not appear to be PRM-related, they are
actually specific to workload (PRM) groups by virtue of glance_prm’s
design.
For wlmrcvdc conceptual information, see “Sending data with wlmsend
and wlmrcvdc: How it works” on page 509. For wlmrcvdc syntax
information, see “wlmrcvdc” on page 388.

GlancePlus PRM-controlled volume group data

GlancePlus PRM by volume group data provides information on volume
groups that are controlled by PRM.
Examples of PRM by volume group metrics are:
PRM_BYVG_GROUP_UTIL
A group’s current percentage of disk bandwidth
relative to other PRM groups’ usage of the same
volume group.
PRM_BYVG_REQUEST
The number of Kbytes (or Mbytes if specified) the PRM
group requested to have read from or written to the
logical volumes in the current volume group during the
interval.
For a full list of the available data, see the GlancePlus online help,
available through gpm.

Appendix H 491
Advanced WLM usage: Using performance metrics
Supplying data to WLM

To extract PRM by volume group data (PRM_BYVG_* metrics), use

wlmrcvdc with the glance_prm_byvg command in the configuration file.
For example:
tune vg_util {
...
coll_argv = wlmrcvdc glance_prm_byvg
PRM_BYVG_GROUP_UTIL # Metric to monitor
Grp17 /dev/vg03;
# Name of workload (PRM) group
# and logical volume group
...
}
For wlmrcvdc conceptual information, see “Sending data with wlmsend
and wlmrcvdc: How it works” on page 509. For wlmrcvdc syntax
information, see “wlmrcvdc” on page 388.

Oracle database data

Oracle database data provides SQL values or elapsed time (walltime)
resulting from executing SQL statements against an Oracle instance.
Examples of Oracle database metrics are:

• Number of users connected to an instance

• Number of processes in an instance
• A particular user is connected
• A particular job is active
To extract Oracle database data, use wlmrcvdc with the wlmoradc
command in the configuration file:
tune oracle.instance1.user_cnt {
coll_argv =
wlmrcvdc
wlmoradc
--configfile /opt/wlm/toolkits/oracle/config/user_cnt.oradc
--home /oracle/app/oracle/product/8.1.5
--instance instance1
;
}
For more ideas on the metrics you can collect, as well as information on
wlmoradc, see “Integrating with Oracle® databases” on page 426 or see
wlmoradc(1M).

492 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

For wlmrcvdc conceptual information, see “Sending data with wlmsend

and wlmrcvdc: How it works” on page 509. For wlmrcvdc syntax
information, see “wlmrcvdc” on page 388.

Existing metrics
If you already maintain application-specific metrics or system metrics,
you can send that data to WLM in one of two ways:

• Using the wlmsend utility

• Using the WLM API
Both the wlmsend utility and the API are explained in the section “What
methods exist for sending data to WLM?” on page 493.

What methods exist for sending data to WLM?

The section focuses on how you want to get data to WLM, then
determines what data is available for the given type of transport.
There are several methods for sending data to WLM:

• Sending data from the command line

• Sending data from a shell script
• Sending data from a perl program
• Sending data via stdout
• Sending data from a collector written in C
• Sending ARM transaction data from a modified C program
• Sending ARM transaction data from a script with simulated
transactions
As your data collector gathers data, it must send the data to WLM. The
easiest way to send data is by using the wlmrcvdc utility. Alternatively,
you can send this data using the WLM API.
How you send the data is generally decided by how you collect the data.
If you collect data using shell scripts or perl programs, the wlmsend and
wlmrcvdc utilities provide the most convenient route for sending data.
However, when using C programs to collect data, the WLM API is
typically better.

Appendix H 493
Advanced WLM usage: Using performance metrics
Supplying data to WLM

Table H-2 provides an overview of how to send your data to WLM. For
more information on the transport methods, read the sections following
the table.
Table H-2 Available transport methods

For sending data from The transport method is

Command-line/shell script On the command line or in a loop in a script:

wlmsend metric value
or
cmnd1 | cmnd2 | [... |] wlmsend metric
In combination with a tune structure in the
configuration file:
tune metric {
...
coll_argv = wlmrcvdc;
...
}

Perl In a loop in a perl program:

system “wlmsend $metric $value”;
or an open statement with the print statement in a
loop
open(WLM, “|wlmsend $metric”);
print WLM “$value\n”;
In combination with a tune structure in the
configuration file:
tune metric {
...
coll_argv = wlmrcvdc;
...
}

494 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

Table H-2 Available transport methods (Continued)

For sending data from The transport method is

stdout of command A tune structure in the configuration file:

tune metric {
...
coll_argv = wlmrcvdc command;
...
}

program that uses A tune structure in the configuration file:

WLM API (libwlm.sl)
tune metric {
...
coll_argv = program;
...
}

Sending data from the command line

If you have data you want to send to WLM from the command line, use
wlmsend on the command line and an associated wlmrcvdc in your
configuration file. This method of sending data works for a single metric
value that is specified on the wlmsend command line or for a stream of
metric values that is piped to wlmsend, as shown in the following
example:
/opt/wlm/bin/wlmsend metric value
or
cmnd1 | cmnd2 | [... |] /opt/wlm/bin/wlmsend metric
Place a wlmrcvdc in the configuration file that is associated with the
wlmsend by metric:
tune metric {
...
coll_argv = wlmrcvdc;
...
}
In the following example, we have an slo structure to specify our goal.
The tune structure invokes wlmrcvdc to monitor job_time values
forwarded by wlmsend:

Appendix H 495
Advanced WLM usage: Using performance metrics
Supplying data to WLM

# Set up the SLO

slo data_cruncher {
pri = 3;
mincpu = 15;
maxcpu = 25;
entity = PRM group crunch;
goal = metric job_time < 2.0;
}

# Set up wlmrcvdc
tune job_time {
coll_argv = wlmrcvdc;
}
On the command line that follows, some program is updating logfile.
With the tail command, wlmsend gets the latest updates to the file and
sends them to a rendezvous point for wlmrcvdc to collect:
# tail -f logfile | /opt/wlm/bin/wlmsend job_time
This rendezvous point is created by wlmrcvdc.
For background information on how wlmsend and wlmrcvdc work
together to get your data to WLM, as well as a warning about I/O
buffering, see “Sending data with wlmsend and wlmrcvdc: How it works”
on page 509.

Sending data from a shell script

If you have data you want to send to WLM from a shell script, use
wlmsend in the shell script and an associated wlmrcvdc in your
configuration file. This method of sending data works for a single metric
value that is specified as an argument to wlmsend or for a stream of
metric values that is piped to wlmsend, as shown in the following
example.
In this example, start in the configuration file by defining an slo
structure to keep the metric job_time under 2.0, and then set up
wlmrcvdc to receive the job_time metric values from wlmsend:
# Set up the SLO
slo data_cruncher {
pri = 3;
mincpu = 15;
maxcpu = 25;
entity = PRM group crunch;
goal = metric job_time < 2.0;

496 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

# Set up wlmrcvdc
tune job_time {
coll_argv = wlmrcvdc;
}
Next, set up wlmsend in a loop in a shell script. Here, the function
get_value provides the metrics to feed wlmsend. Alternatively the script
itself could be interacting with the workload to gather performance data.
Add a sleep command to slow down how often metrics are retrieved. The
loop might look like the following:
while (true)
do
value = ‘get_value‘
/opt/wlm/bin/wlmsend job_time $value
sleep 60
done

NOTE Run your data collection script in the group PRM_SYS to ensure it receives
the proper resources.

For background information on how wlmsend and wlmrcvdc work

together to get your data to WLM, as well as a warning about I/O
buffering, see “Sending data with wlmsend and wlmrcvdc: How it works”
on page 509.

Sending data from a perl program

If you have data you want to send to WLM from a perl program, use
wlmsend in the perl program and an associated wlmrcvdc in your WLM
configuration file. This method of sending data works for a single metric
value that is specified as an argument to wlmsend or for a stream of
metric values that is piped to wlmsend, as shown in the following
example.
In this example, start in the configuration file by defining an slo
structure to keep the metric job_time under 2.0, and then set up
wlmrcvdc to receive the job_time metric values from wlmsend:
# Set up the SLO
slo data_cruncher {
pri = 3;

Appendix H 497
Advanced WLM usage: Using performance metrics
Supplying data to WLM

mincpu = 15;
maxcpu = 25;
entity = PRM group crunch;
goal = metric job_time < 2.0;
}

# Set up wlmrcvdc
tune job_time {
coll_argv = wlmrcvdc;
}
Next, set up wlmsend in a loop in a perl program. Here, the function
get_value provides the metrics to feed wlmsend. Alternatively the
program itself could interact with the workload to gather performance
data. Add a sleep command to slow down how often metrics are
retrieved. The loop might look the following:
while (1) {
$value = &get_value;
system “/opt/wlm/bin/wlmsend job_time $value”;
sleep(60);
}
The loop could also look like the following loop, using a print statement
instead of a system statement:
open(WLM, “| /opt/wlm/bin/wlmsend job_time”);
# make the new file descriptor unbuffered
select ((select(WLM), $|=1)[0]);
while (1) {
$value = &get_value;
print WLM “$value\n”;
sleep(60);
}

NOTE Run your data collection script in the group PRM_SYS to ensure it receives
the proper resources.

For background information on how wlmsend and wlmrcvdc work

together to get your data to WLM, as well as a warning about I/O
buffering, see “Sending data with wlmsend and wlmrcvdc: How it works”
on page 509.

498 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

Sending data via stdout

You can use wlmrcvdc to forward the stdout of a command to WLM. If
your data collector program prints its metrics to stdout, you can run the
program by invoking it with wlmrcvdc in the WLM configuration file.
wlmrcvdc automatically forwards stdout to WLM.

NOTE If the command exits with status zero, you can use wlmsend to continue
feeding data to the rendezvous point for wlmrcvdc. (wlmrcvdc creates the
rendezvous point when it is invoked by WLM.)

Consider the following example in which an instance of wlmrcvdc starts

a data collector named ordercounter. As ordercounter writes values to
its sdtout, wlmrcvdc reads those values and forwards them to the WLM
daemon on behalf of the metric order_cnt:
tune order_cnt books {
coll_argv = wlmrcvdc /opt/books/ordercounter;
...
}
WLM provides a number of commands to use with wlmrcvdc to forward
GlancePlus metrics to WLM. For information on those commands, see:

• “ARM transaction data” on page 488

• “GlancePlus application data” on page 488
• “GlancePlus global data” on page 489
• “GlancePlus PRM-specific application data” on page 490
• “GlancePlus PRM-controlled volume group data” on page 491
• “Oracle database data” on page 492
For background information on how wlmrcvdc gets your data to WLM,
see “Sending data with wlmsend and wlmrcvdc: How it works” on
page 509.

Sending data from a collector written in C

To send metric information to WLM from a data collector written in C,
you can:

Appendix H 499
Advanced WLM usage: Using performance metrics
Supplying data to WLM

• Develop a program that writes its data to stdout and use it with
wlmrcvdc
For information on this approach, see “Sending data via stdout” on
page 499.
• Use the WLM API
This section discusses the API.

NOTE You can also write a program that invokes the wlmsend command.
However, if you are writing a program, it is recommended that you use
wlmrcvdc to capture stdout or you use the API.

For information on how to set up your WLM configuration to receive this

data, see Table H-2 on page 494.
This API includes three functions. The function prototypes and return
codes are defined in the following include file:
/opt/wlm/include/wlm.h
The three C functions are:

• wlm_mon_attach()
Opens communication to the WLM daemon.
• wlm_mon_write()
Writes data to the WLM daemon.
• wlm_mon_detach()
Closes communication to the WLM daemon.
The compile line for a program using these functions is:
% cc -I/opt/wlm/include -L/opt/wlm/lib -lwlm [ flag ... ]
file ...

NOTE The stdout and stderr for each data collector that WLM starts are
discarded. However, WLM provides the coll_stderr tunable that allows
you to log each collector’s stderr. In addition, data collectors can
communicate using either syslog(3C) or logger(1) with the daemon
facility.

500 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

For information on signal handling, see “Handling signals in data

collectors” on page 515.
Run your data collection program in the group PRM_SYS to ensure it
receives the proper resources.

Each data collector should send data to WLM once per WLM interval, if
possible. (For information on this interval, see “Specifying the WLM
interval (optional)” on page 215.) If the data collector sends data to WLM
less than once per interval (meaning an entire interval passes with no
new data), the associated controller requests the same allocation as it did
for the previous interval. When your data collector sends data more than
once per interval, WLM only receives the last data sent before the
interval ended. All the other data sent during the interval is lost. In this
case, your data should reflect performance over a period of time rather
than at a single point in time.

NOTE WLM runs data collectors with UID set to root. If a data collector that
uses the WLM API changes its UID, all subsequent calls to the WLM API
will fail.

NOTE If a data collector exits unexpectedly, restart it by re-activating the

configuration:
# wlmd -a configfile
Re-activating the configuration resets all resource allocations, causing
WLM to reconverge on the allocations needed to meet the configuration’s
SLOs.

The API functions are described in the following sections.

Opening communications with wlm_mon_attach() The data

collector uses the wlm_mon_attach() function to open a connection to the
WLM daemon to send performance data to the daemon.
To use this function, you must reference the following include file:
/opt/wlm/include/wlm.h

Appendix H 501
Advanced WLM usage: Using performance metrics
Supplying data to WLM

NOTE This function is not thread-safe: Multiple threads cannot call the
function at the same time.

The syntax is:

int wlm_mon_attach(char *metric);
where
metric
Is the name of the metric being passed on this
connection. This string must exactly match the metric
string used in the configuration file, in the specification
of the goal.
For convenience, when the WLM daemon starts the
data collector executable, it places the name of the
metric it is expecting from the collector in the
WLM_METRIC_NAME environment variable. Using this, a
collector that is capable of providing multiple metrics
can determine which metric the daemon is expecting.
The exit status values for wlm_mon_attach() are:
>= 0 Success. Identifies the communication channel for
passing data for the metric specified in the metric
argument.
Use this handle in subsequent calls to the API.
-1 Failure
Example:
handle_id = wlm_mon_attach(getenv(“WLM_METRIC_NAME”));
if (handle_id == -1) {
fprintf(output, “wlm_mon_attach failed: %s\n”, strerror(errno));
exit(1);
}

Sending data with wlm_mon_write() The data collector uses the

wlm_mon_write() function to write messages to the communication
channel specified by the supplied handle_id parameter.
To use this function, you must reference the following include file:

502 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

/opt/wlm/include/wlm.h

NOTE This function is not thread-safe: Multiple threads cannot call the
function at the same time.

The syntax is:

ssize_t wlm_mon_write(int handle_id, void *buf, size_t
numbytes);
where
handle_id
Is the handle identifier returned by the
wlm_mon_attach() call.
buf
Is a pointer to the double-precision floating-point value
to be transferred to the data queue.
numbytes
Is the number of bytes to write to the data queue. The
data must be of type double. Thus, the value of this
parameter must be sizeof(double).
The exit status values for wlm_mon_write() are:
>= 0 Success (number of bytes written)
-1 Failure—if errno is not EAGAIN, your data collector
should exit
Example:
if (metric_cnt > 0) {
metric_avg = metric_sum / metric_cnt;
if (wlm_mon_write(handle_id, &metric_avg,
sizeof(double)) == -1) {
fprintf(output, “wlm_mon_write failed: %s\n”, strerror(errno));
exit(1);
}
}

Appendix H 503
Advanced WLM usage: Using performance metrics
Supplying data to WLM

Closing communications with wlm_mon_detach() The data

collector uses the wlm_mon_detach() function to close (detach from) a
communication channel with the WLM daemon.
To use this function, you must reference the following include file:
/opt/wlm/include/wlm.h

NOTE This function is not thread-safe: Multiple threads cannot call the
function at the same time.

The syntax is:

int wlm_mon_detach(int handle_id);
where
handle_id Is the communication channel identifier returned by
the wlm_mon_attach() call.
The exit status values for wlm_mon_detach() are:
0 Success
-1 Failure

Sending ARM transaction data from a modified C program

ARM, or Application Response Measurement, was developed to provide
an open, vendor-neutral approach for measuring end-to-end application
response time. ARM consists of six library calls that are inserted in
application source code. These calls isolate transactions so that you can
collect data on and manage these transactions proactively.
If you have the C source code to an application and are inclined to modify
the source, you can instrument the application with ARM API calls to
measure the events or transactions that are most important to your
business.

NOTE The HP ARM implementation is available through GlancePlus. Install

GlancePlus on each system where you want to track ARM data.

504 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

If you are using the HP ARM implementation, you can send transaction
data to WLM using wlmrcvdc with the glance_tt command.
Figure H-1 presents an overview of how an application that is
instrumented with ARM API calls works with WLM. First, the
application invokes the ARM API calls, made available through libarm.
libarm then feeds the data from the ARM calls to an
implementation-specific storage facility. An ARM collection agent, in this
case GlancePlus, then picks up this data. Next, wlmrcvdc / glance_tt or
a user-written data collector sends the relevant data to WLM to use in
determining CPU allocations. The new allocations then affect the
application’s performance, which is again tracked by the ARM API calls.

Figure H-1 Interaction of WLM and ARM-instrumented applications

arm_start() Implementation-
Application libarm specific
arm_stop() database/kernel

CPU
resources wlmrcvdc /
glance_tt or
HP-UX WLM user-written ARM collection agent
data collector

Examples of transaction metrics are:

TT_WALL_TIME
The total time, in seconds, of all transactions completed
during the last interval for this transaction.
TT_WALL_TIME_PER_TRAN
The average transaction time, in seconds, during the
last interval for this transaction.
For a list of metrics, see:

• The Transaction Metrics subsection of the Performance Metrics

section in the GlancePlus online help, available through gpm
• One of the /opt/perf/paperdocs/gp/C/metrics.* documents

Appendix H 505
Advanced WLM usage: Using performance metrics
Supplying data to WLM

• The glance_tt(5) manpage, which lists some of the more frequently

used metrics (manpage also available at http://www.hp.com/go/wlm)
The ARM API consists of six routines, which are described in the
following table. For complete usage information on these routines, see
arm(3), which is installed when you install GlancePlus. (To see this
manpage, be sure “/opt/perf/man” is part of your MANPATH environment
variable.)
Table H-3 ARM API routines

ARM API routine Description

arm_init Initializes the ARM environment for the

application

arm_getid Names each transaction that is to be monitored

arm_start Indicates the start of a transaction

arm_update Updates statistics for a long-running

transaction

arm_stop Indicates the end of a transaction

arm_end Prepares the ARM environment for the

application’s exit

You add the API calls to your source, isolating the desired transactions.
For example, consider the following pseudo-code that tracks individual
times for various tasks and also gets a time for all three processes
together:
arm_init(“application_name”, “user_name”)
arm_getid(“total_time”)
arm_getid(“pull_data”)
arm_getid(“process_data”)
arm_getid(“report_data”)

loop until end of program

arm_start(total_time)

arm_start(pull_data)
(get the data)
arm_stop(pull_data, status)

arm_start(process_data)

506 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

(process the data)

arm_stop(process_data, status)

arm_start(report_data)
(generate report)
arm_stop(report_data, status)

arm_stop(total_time, status)
end loop
arm_end
To use ARM transaction data with WLM:

Step 1. Modify your program to use the ARM API calls described previously. To
use these calls, you must reference the include file
/opt/perf/include/arm.h.

Be sure to:

• Register ARM_app with ARM through the arm_init API call

• Mark the start and stop of each transaction in which you are
interested

Step 2. Compile your program, specifying the locations for the ARM header file
and library—being sure to link against the ARM library.

For HP-UX 11.0 and HP-UX 11i v1 (B.11.11), the compile/link line is:

% /opt/ansic/bin/cc -Ae prog.c -I /opt/perf/include -L

/opt/perf/lib -larm

The -Ae option ensures you compile using the extended ANSI mode.

For HP-UX 11i v2 (B.11.23) and HP-UX 11i v3 (B.11.31) on

IntelItanium-based platforms, the compile/link line for 32-bit IA
ARMed programs is:

% /opt/ansic/bin/cc -Ae prog.c -I /opt/perf/include \

-L /opt/perf/lib/hpux32 -larm

For HP-UX 11i v2 and HP-UX 11i v3 (B.11.31) on Itanium-based

platforms, the compile/link line for 64-bit IA ARMed programs is:

% /opt/ansic/bin/cc -Ae +DD64 prog.c -I /opt/perf/include \

-L /opt/perf/lib/hpux64 -larm

Appendix H 507
Advanced WLM usage: Using performance metrics
Supplying data to WLM

Step 3. Ensure that ttd is configured and running. For more information, see
ttd(1).

Step 4. Start the program you instrumented with ARM calls.

The start and stop times for your transactions will now be made
available through the HP ARM implementation. For more information,
see ttd(1) and midaemon(1).

Step 5. Edit your WLM configuration to pick up the transaction data.

To extract ARM data (from the HP ARM implementation) and forward it

to WLM, use wlmrcvdc with the glance_tt command in the
configuration file:
tune metric {
...
coll_argv = wlmrcvdc glance_tt
TT_*_metric # Metric you choose to monitor
ARM_app # Application registered with ARM
transaction [user]; # Transaction in the
# application to get the metric for, along
# with an application user
...
}

The metric you choose, generically referred to as TT_*_metric

previously, is typically from the Transaction metric class (TT_*), but can
also be an expression that combines a transaction metric with metrics
from the Global (GBL_*) and Table (TBL_*) metric classes.

You can fine-tune transaction tracking in the /var/opt/perf/ttd.conf file if

desired. This file has an entry (tran=*) that enables all transactions to
be tracked. However, you may want to fine-tune what is tracked. For
more information, see ttd(1) and the ttd.conf file or ttd.conf(4).

For more information on the wlmrcvdc utility, see “Sending data via
stdout” on page 499.

Step 6. Activate your WLM configuration:

# wlmd -a configfile

For information on the ARM API and the ARM software developer’s kit,
see:
http://www.cmg.org/regions/cmgarmw

508 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

Sending ARM transaction data from a script with simulated

transactions
Using transactions that simulate the key transactions of your workload
can simplify data collecting. These transactions may not provide the fine
granularity that you can achieve by placing ARM API calls in the source
code. However, you do avoid modifying the application with
instrumentation.
Set up simulated transactions as follows:

Step 1. Create a simulation. For example, use remote terminal emulation (RTE)
software to capture sessions in which key transactions of the workload
(that WLM is going to manage) are executed.

Step 2. Save each captured session to a file, then add ARM API calls to the file.
(In some cases, the RTE software produces files that are editable as C
code.)

Step 3. Edit the WLM configuration file so that:

• Your data collector tracks the performance of the script

• The script is assigned to the same workload group as the application

that is to be managed

Step 4. Run the script and the application to be managed.

Step 5. Send the ARM data to WLM using the wlmrcvdc utility described in the
section “Sending ARM transaction data from a modified C program” on
page 504.

For additional information on using RTE software, see the white paper
“Service Management Using the Application Response Measurement
API Without Application Source Code Modification” on the following Web
site:
http://www.cmg.org/regions/cmgarmw

Sending data with wlmsend and wlmrcvdc:

How it works
The simplest way to get data to WLM is to use wlmsend and wlmrcvdc, or
in some cases, just wlmrcvdc. These utilities allow you to send data to
WLM from the command line, shell scripts, perl programs, and stdout.

Appendix H 509
Advanced WLM usage: Using performance metrics
Supplying data to WLM

Use wlmsend on the command line, in a shell script, or in a perl program.

Use wlmrcvdc in the WLM configuration file.

NOTE Avoid the process overhead of using wlmsend in a compiled data collector;
let wlmd invoke your data collector through the configuration file if
possible. Use the API described in “Sending data from a collector written
in C” on page 499 to write such a data collector.

The wlmrcvdc utility creates a rendezvous point and forwards data from
that rendezvous point to WLM. Use wlmsend to send data to a
rendezvous point to be collected by a wlmrcvdc invocation.
If you use wlmsend, you must also use wlmrcvdc. You can, however, use
wlmrcvdc without wlmsend if you specify wlmrcvdc with a data-collecting
command.
The syntaxes for the commands follow:
wlmrcvdc [-h] [-V] [-u user] [-g group] [command [args...]]
wlmsend [-h] [-V] [-w wait_time] metric [value]
For an explanation of the syntaxes, see Appendix A, “WLM command
reference,” on page 363.

NOTE Be careful of I/O buffering when feeding data to wlmsend. For example,
the following line works as expected:
tail -f logfile | /opt/wlm/bin/wlmsend job_time
However, adding awk or other utilities that buffer I/O can result in data
being delayed, or not even sent, to wlmsend—depending on when the
buffer is flushed:
tail -f logfile | awk ‘{print $1}’ | /opt/wlm/bin/wlmsend
job_time
Always check the file /var/opt/wlm/wlmdstats, created by wlmd -l
metric as explained in wlmd(1M), to ensure that your data gets to WLM
in a timely fashion.

510 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

Figure H-2 illustrates the command-pipe mode of operation for

wlmrcvdc. In this mode, wlmrcvdc starts a command, reads its stdout,
and forwards that data to the WLM daemon, wlmd.

Figure H-2 wlmrcvdc: command-pipe mode (wlmrcvdc command [args])

➊ wlmrcvdc creates ➋ stdout is read ➌ wlmrcvdc forwards

a child process by wlmrcvdc the data to wlmd
running command

stdout
command wlmrcvdc wlmd

Consider the following example, in which an instance of wlmrcvdc starts

a data collector named ordercounter. As ordercounter writes values to
its sdtout, wlmrcvdc reads those values and forwards them to the WLM
daemon on behalf of the metric order_cnt:
tune order_cnt books {
coll_argv = wlmrcvdc /opt/books/ordercounter;
...
}
While using the program ordercounter to send data, you can also use
wlmsend to forward data for the metric order_cnt.
Figure H-3 illustrates the FIFO-file mode of operation for wlmrcvdc. In
this mode, wlmrcvdc monitors a FIFO rendezvous point it created.
wlmsend makes data available at the rendezvous point. wlmrcvdc picks
up the data and forwards it to the WLM daemon.
Each wlmrcvdc process has its own FIFO rendezvous point based on the
metric name used in the tune structure that invokes that particular
wlmrcvdc process. wlmsend determines the correct rendezvous point
from its metric argument.

Appendix H 511
Advanced WLM usage: Using performance metrics
Supplying data to WLM

Figure H-3 wlmrcvdc: FIFO-file mode (wlmrcvdc)

➊ wlmrcvdc creates a rendezvous point ➌ wlmrcvdc collects the

based on the metric name data and forwards
it to wlmd

Rendezvous
point wlmrcvdc wlmd

wlmsend

➋ wlmsend feeds data into

the rendezvous point

In this next example, when the WLM configuration file is activated,

wlmrcvdc creates a rendezvous point, with a name based on the metric
name resp_time. The rendezvous point is owned by the user admin in
the group sys:
tune resp_time {
coll_argv = wlmrcvdc -u admin -g sys;
}
Now all that remains is for you to use wlmsend in a data collector script
to forward values to the established FIFO rendezvous point.
Figure H-4 illustrates the command-output mode of operation for
wlmsend. In this mode, wlmsend forwards its stdin to the rendezvous
point that wlmrcvdc monitors. wlmrcvdc then sends the data on to WLM.

512 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

Figure H-4 wlmsend: command-output mode (command | wlmsend metric)

➊ wlmsend continuously feeds its ➋ wlmrcvdc collects the

stdin to the rendezvous point data and forwards it to wlmd

Rendezvous
wlmsend point wlmrcvdc wlmd

data piped to wlmsend

command

This example of wlmsend’s command-output mode shows how to set up

the WLM configuration file and wlmsend to work together to forward the
data to WLM.
First, in the configuration file, we define an slo structure to keep the
metric job_time under 2.0. Also, we set up wlmrcvdc to receive the
job_time metric values from wlmsend:
# Set up the SLO
slo data_cruncher {
pri = 3;
mincpu = 15;
maxcpu = 25;
entity = PRM group crunch;
goal = metric job_time < 2.0;
}

# Set up wlmrcvdc
tune job_time {
coll_argv = wlmrcvdc;
}
Second, we set up wlmsend in a data collector shell script, a perl
program, or on the command line to feed data to the rendezvous point. If
the data is coming from a file, say logfile, we can forward the data to
WLM as follows:
# tail -f logfile | /opt/wlm/bin/wlmsend job_time

Appendix H 513
Advanced WLM usage: Using performance metrics
Supplying data to WLM

Figure H-5 illustrates the single-value mode of operation for wlmsend. In

this mode, wlmsend is repeatedly invoked with a single metric value.
However, it is invoked in a loop in a shell script or a perl program that
updates that metric value.

Figure H-5 wlmsend: single-value mode (wlmsend metric value)

➊ wlmsend feeds single value ➋ wlmrcvdc collects the

to the rendezvous point data and forwards it to wlmd

value

Rendezvous
wlmsend point wlmrcvdc wlmd

In this example, the setup is the same as in the previous example. Thus,
in the configuration file, we define an slo structure to keep the metric
job_time under 2.0, and we set up wlmrcvdc to receive the job_time
metric values from wlmsend:
# Set up the SLO
slo data_cruncher {
pri = 3;
mincpu = 15;
maxcpu = 25;
entity = PRM group crunch;
goal = metric job_time < 2.0;
}

# Set up wlmrcvdc
tune job_time {
coll_argv = wlmrcvdc;
}
Next, we set up wlmsend in a loop in either a shell script or a perl
program. The function get_value provides the metrics to feed wlmsend.
We add a sleep command to slow down how often metrics are retrieved.
For a shell script, that loop might look like the following:
while (true)
do
value = ‘get_value‘

514 Appendix H
 Advanced WLM usage: Using performance metrics
Supplying data to WLM

/opt/wlm/bin/wlmsend job_time $value

sleep 60
done
In a perl program, the loop might look like one of the following:
while (1) {
$value = &get_value;
system “/opt/wlm/bin/wlmsend job_time $value”;
sleep(60);
}
Using a print statement instead of a system statement:
open(WLM, “| /opt/wlm/bin/wlmsend $metric”);
# make the new file descriptor unbuffered
select ((select(WLM), $|=1)[0]);
while (1) {
$value = &get_value;
print WLM “$value\n”;
sleep(60);
}

Handling signals in data collectors

When a data collector is spawned, it inherits the signal handling actions
that the WLM daemon inherits. (Ordinarily, these would be the default
actions described in signal(5).) Additionally, when the data collector
process begins execution, its inherited signal mask should be 0, so that
no signals are currently being blocked.
Currently, SIGTERM is the only signal that is delivered by WLM to the
spawned data collectors.
WLM uses the signal SIGTERM to terminate a spawned data collector
when it is no longer required. A well-behaved data collector will install a
handler function for SIGTERM, so that wlm_mon_detach() can be called
(if attached) as part of its cleanup. This is the recommended approach,
though it is not required to explicitly detach. In any case, SIGTERM should
not be ignored (that is, set to SIG_IGN).

Appendix H 515
Advanced WLM usage: Using performance metrics
Supplying data to WLM

516 Appendix H
Glossary

absolute CPU units In WLM alternate group A workload group other

configurations, absolute CPU units are than the user’s initial group that a user can
specified in terms of 100, where 100 access using prmrun or prmmove. These
represents one core. For example, 50 groups are listed in the user records (or their
absolute CPU units represents half of a core; netgroups’ user records) in the configuration
200 absolute CPU units represents 2 cores. file following the initial group, as shown in
Absolute CPU units are useful when the the following example:
number of active cores changes due to WLM
management of Instant Capacity (iCAP), users = user : init_group [alt_group1
Temporary Instant Capacity (TiCAP), Pay alt_group2 ...] [, ...];
per use (PPU), or virtual partition resources.
Regardless of the number of active cores, the application manager A PRM daemon that
absolute CPU units represent the same polls the configuration and the running
amount of CPU resources. See also relative processes to ensure all processes are in the
CPU units. proper workload groups.

active workload group A workload group API Application Program Interface. WLM
with at least one active SLO. provides an API so that your data collectors
can send it metrics for your workloads.
active SLO An SLO is active under either of
the following situations: ARM Application Response Measurement. A
standard for transaction-based (bounded
• It has no condition or exception events) response-time instrumentation.
statements specified
controller A control algorithm that
• Its condition statement is true and/or requests new CPU resource allocations for
its exception statement is false, workload groups.
allowing WLM to try to enforce the SLO
core The actual data processing engine
You might set an SLO to be active, for
within a processor. A single processor might
example, based on time of day or day of week
have multiple cores, and a core might
or whether a Serviceguard package is
support multiple execution threads. See
running on the local host.
also Hyper-Threading.
alternate name Other names assigned to
CPU manager WLM uses the fair share
processes spawned by an application. This is
scheduler (FSS) to manage CPU resources
most common for complex programs such as
for FSS workload groups. (PSET workload
database programs that launch many
groups are assigned whole cores and do not
processes and rename them.
require the CPU manager.)

Glossary 517
Glossary
deactivated processor

deactivated processor A processor that percentage is either the number of CPU

either has not yet been activated or that has shares the workload group is assigned
been turned off by the Instant Capacity relative to the number of cores multiplied by
software (formerly known as iCOD software) 100 (absolute CPU units are enabled)—or
and returned to the pool of inactive the number of CPU shares a workload group
processors. These processors are available is assigned relative to the total number of
for activation. CPU shares assigned (absolute CPU units
are not being used). For memory, you can
default PSET In configurations managing specify this percentage directly in the WLM
PSET-based and FSS workload groups, the configuration file. For disk bandwidth, the
default PSET, when created at system percentage is based on a workload group’s
initialization, consists of all of your system’s number of shares relative to the total
processors. Afterward, the default PSET number of shares assigned.
consists of only those processors that were
not assigned to other PSET groups. All FSS file ID ID used by the application manager
groups reside in the default PSET, which is to place processes in the appropriate
where all FSS group CPU resource workload groups. The file ID is based on the
allocation occurs. The system administrator file system device and inode number.
can create additional PSET groups and
assign processors, applications, and users to FSS workload group A WLM workload
those groups. Applications and users that group that has its CPU use managed by the
are assigned to a PSET workload group have fair share scheduler (FSS). See also PSET
dedicated CPU resources from the cores workload.
assigned to the group. Competition for CPU
resources within the processor set are goal A measure of workload performance or
handled using the HP-UX time-share resource utilization that must be achieved to
scheduler. See also PSET workload. meet an SLO. See also stretch goal.

disk manager A kernel routine that global arbiter A WLM daemon used in
monitors bandwidth at the logical volume managing WLM instances on various virtual
group level, rearranging I/O requests as partitions.
needed to ensure disk bandwidth shares.
Hyper-Threading The logical CPU feature
EMS Event Monitoring Service. An HP that allows multiple execution threads
product for monitoring system resources and (logical CPUs) within a single core. See
sending/receiving notifications when events also core, logical CPU.
occur. WLM uses the EMS notification
framework to send alarms. initial group The first workload group
listed in a user’s record in a configuration
entitlement The minimum percentage file. Typically, the applications a user
(lower limit) of a resource that a workload
group receives. For CPU resources, this

518 Glossary
 Glossary
nPartitions

launches run in the user’s initial Capacity software or during installation.

group—assuming those applications are not Processors are activated with the
specified in application records. icod_modify or icapmodify command while
HP-UX is running.
This is the group prmconfig, prmmove -i,
Previous versions of iCAP were referred to
login, at, and cron use to determine where
as Instant Capacity on Demand, or iCOD.
to place user processes. If a user does not
have a user record or is not in a netgroup See also Pay per use (PPU), Temporary
that has a user record, the user default Instant Capacity (TiCAP).
group OTHERS becomes the user’s initial
group. The initial group is shown as logical CPU An execution thread contained
init_group in the following example: within a core. With Hyper-Threading
enabled, each core can contain multiple
users = user : init_group [alt_group1 logical CPUs. Logical CPUs are available
alt_group2 ...] [, ...]; starting with HP-UX 11i v3 and the
Hyper-Threading feature. See also core,
inode number HP-UX uses data structures Hyper-Threading.
known as inodes to store data about files in a
file system. The file system device combined logical volume group A single logical disk
with an inode number uniquely identifies a device under Logical Volume Manager
given file. (LVM) formed from one or more physical
disk drives. WLM manages disk bandwidth
Instant Capacity (iCAP) An HP Utility on a logical volume group basis.
Pricing Solutions product whose pricing
model is based on purchasing components logical Volume Manager (LVM) A
(processors, cell boards, and memory). disk-management tool used to partition
Instant Capacity allows you to purchase and physical disk drives.
install additional components at a discount
from the regular purchase prise, as the memory manager A daemon that
usage rights are not included. These Instant monitors use of real memory on the system
Capacity components are inactive but to ensure that workload groups are granted
installed and ready for use. When extra their memory shares. This daemon also
capacity is needed, you pay the remainder of enforces memory capping.
the regular purchase price for the usage
rights (through purchasing a Right to Use nPartitions Also known as nPars. HP
codeword) to activate the components. (If the nPartitions offer both hardware and
regular price for the component is reduced software isolation among different instances
by the time the usage rights are purchased, of an operating system running on a single
the remainder price is proportionally server.
reduced, providing additional savings.) After
obtaining usage rights, Instant Capacity
processors can be turned on by the Instant

Glossary 519
Glossary
OTHERS group

OTHERS group The reserved workload creator. When you create a job, the shell
group OTHERS with ID 1. WLM uses this assigns all the processes in the job to the
group as the initial group for any user who same process group. Signals can propagate
does not have a user record in the WLM to all processes in a process group; this is a
configuration file. principal advantage of job control.

partitions See the definition for nPartitions process group ID Each process group is
and virtual partitions. uniquely identified by an integer called a
process group ID. Each process group also
Pay per use (PPU) For customers has a process group leader. The process
interested in leasing CPU capacity from HP group’s ID is the same as the process ID of
Finance, Pay per use is supported on the process group leader. Every process in a
cell-based Integrity servers and is part of the process group has the same group ID.
HP Utility Pricing Solutions program. It is a
product that provides CPU (core) capacity as process ID An integer, assigned to a process
needed, basing payment on actual metered at creation, that uniquely identifies the
or monitored use of that capacity. You process to HP-UX.
acquire a particular hardware platform and
number of processors, and are charged for process map A powerful and flexible tool
usage of the processors based on demand. that allows you to establish your own
criteria for how processes are placed in
See also Instant Capacity (iCAP), Temporary
workload groups rather than using WLM’s
Instant Capacity (TiCAP).
default criteria (application, user, Unix
group, or secure compartment records).
PID Process ID.
PSET workload A WLM workload that is
PRM Process Resource Manager. An HP
assigned CPU resources based on the
product used to dynamically divide resource
processor set (PSET) upon which it is
utilization among different applications and
defined. See also FSS workload group.
users. WLM builds on the features of PRM
and provides automatic resource allocation.
real memory Real memory is shared by all
processes. The data and instructions of any
PRM_SYS group The reserved workload
process (a program in execution) must be
group PRM_SYS with ID 0. WLM places all
available to the core by residing in real
system processes in this group by default.
memory at the time of execution.
System processes are processes started by a
user with UID 0.
relative CPU units In WLM
configurations, relative CPU units represent
process group Every process (except
a percentage of the system’s total CPU
system processes, such as init and
resources. Consequently, the number is
swapper) belongs to a process group. A newly
relative to the number of active cores. For
created process joins the process group of its
example, 50 relative CPU units is 50% of the

520 Glossary
 Glossary
system administrator

system’s CPU resources, which is half of 1 shares Shares are the amounts of CPU
core on a system with only 1 active core, but resources, real memory, or disk bandwidth
8 cores on a system with 16 active cores. assigned to workload groups. A CPU share is
1/100 of a single core or 1/100 of each core (or
See also absolute CPU units.
1/1000 of each core) on the system,
depending on the WLM operating mode.
rendezvous point A designated location for
holding performance data. The wlmsend
SLA Service-level agreement. An agreement
utility forwards data for a given metric to a
or contract between an IT group or a data
rendezvous point. The wlmrcvdc utility
center and its customer, based upon
monitors the rendezvous point, receiving the
measurable service-level objectives (SLOs).
data and sending it the WLM daemon.
SLO Service-level objective. Generally a
secure compartment See the definition for
specific, measurable item/objective within a
Secure Resource Partition.
broader, more comprehensive service-level
agreement (SLA) contract.
secure mode The mode of operation in
which WLM (the daemons and the
SLO violation An SLO violation occurs
monitoring GUI) can communicate securely
when the performance of a workload does
with certain other systems. Each system has
not meet the stated goal for that workload.
a security certificate that can be distributed
When such a violation happens, WLM
to the security repositories (truststores or
adjusts CPU resource allocations, based on
keystores) of other systems with which it
SLO priorities and available CPU resources,
will communicate securely. WLM can
to better meet the SLO’s performance goal.
communicate securely with any system for
which it has a security certificate in its
stretch goal Any goal that is not the
truststore. For more information on security
highest priority goal for the associated
certificates and setting up secure
workload. Stretch goals are met only after
communications, see wlmcert(1M).
the higher priority goals have been met. A
stretch goal indicates desired performance,
Secure Resource Partition If you use the
whereas a goal indicates required
HP-UX feature Security Containment, you
performance. See also goal.
can create secure compartments to isolate
files and processes. WLM allows you to place
Strictly host-based A WLM configuration
your secure compartments in workload
is strictly host-based when it does not
groups, providing automatic resource
include a prm structure.
allocation control to the compartments as
well. This combination of secure
system administrator A person
compartments and workload groups is
responsible for day-to-day system
known as Secure Resource Partitions.
configuration and maintenance. This person
has root user capabilities.

Glossary 521
Glossary
Temporary Instant Capacity (TiCAP)

Temporary Instant Capacity (TiCAP) user default group The reserved workload
group OTHERS with ID 1. WLM uses this
An HP product option included with Instant
group as the initial group for any user who
Capacity (iCAP) that enables you to
does not have a user record in the WLM
purchase prepaid processor/core activation
configuration file.
rights for a specified (temporary) period of
time. Temporary capacity is sold in
virtual machine A software entity
increments such as 20-day or 30-day
provided by HP Integrity Virtual Machines
increments, where a day equals 24 hours for
(Integrity VM). This technology allows a
a core. TiCAP was formerly referred to as
single server or nPartition to act as an
TiCOD. See also Instant Capacity (iCAP),
Integrity VM Host for multiple individual
Pay per use (PPU).
virtual machines, each running its own
instance of an operating system (referred to
total CPU The maximum amount of CPU
as a guest OS). Virtual machines are servers
resources (cores) on the system. With
in theVirtual Server Environment (VSE).
absolute CPU units, total CPU is 100
multiplied by the number of cores. When
virtual partitions Also known as vPars.
using relative CPU units, total CPU is 100.
HP-UX Virtual Partitions offer a unique
Absolute CPU units are advantageous on
granularity of partitioning. For each single
systems where the number of active cores
core, you can create one virtual partition
change due to Instant Capacity, Temporary
running its own “instance” of the HP-UX
Instant Capacity, Pay per use (PPU)
operating system. Complete software
(versions prior to B.05.00), or virtual
isolation is provided between virtual
partitions. On such systems, the CPU shares
partitions. In addition, HP-UX Virtual
you specify remain the same amount of cores
Partitions provides the ability to
regardless of the number of cores that are
dynamically move cores across virtual
active.
partitions.
transient group A workload group that is
Virtual Server Environment (VSE) . An
temporarily removed from the active WLM
integrated virtualization offering for HP-UX
configuration because it has no active SLOs
and Linux servers. VSE provides a flexible
and the transient_groups keyword is set
computing environment that maximizes
to 1. (Workload groups associated with a
utilization of server resources. VSE consists
process map always remain active.)
of a pool of dynamically sizable virtual
servers, each of which can grow and shrink
user A user is any person using the system.
based on service-level objectives and
Each user has a unique name and ID,
business priorities.
corresponding to their login and real user ID
defined in password files (such as
/etc/passwd).

522 Glossary
 Glossary
workload group

WLM Workload Manager. HP-UX WLM You assign critical applications to workload
provides automatic resource allocation and groups. WLM then manages the
application performance management performance of FSS workload groups by
through the use of prioritized service-level adjusting their CPU resources, while
objectives (SLOs). assigning PSET workload groups whole
cores for their dedicated use. See also
WLM daemon See wlmd. active workload group.

WLM interval The frequency at which

WLM checks for new performance data for
the managed workloads and then adjusts
CPU resource allocations. The length of the
interval is configurable, but defaults to 60
seconds.

wlmd The WLM daemon, which is used to

activate WLM configurations.

wlmpard The WLM global arbiter daemon,

which is used to activate WLM
configurations for cross-partition
management.

wlmemsmon The WLM EMS monitor, which

collects WLM and SLO status information
and then makes that information available
to EMS clients.

workload A collection of processes running

in an nPartition, virtual partition, Integrity
Virtual Machines (Integrity VM) host, PSET,
or FSS group and whose performance is
managed as a single unit. Examples include
the processes that belong to an application
or all the processes owned by a user. A
workload based on PSETs or FSS groups is a
workload group, which is defined in a PRM
structure.

workload group Any group defined in the

prm structure with the groups keyword. A
workload based on PSETs or FSS groups.

Glossary 523
Glossary
workload group

524 Glossary
 Index

A enabling at reboot, 254

absolute CPU units example wlmaudit report, 250
described, 54 format of audit data files, 253
enabling, 217 generating audit data
absolute_cpu_units keyword, 217 wlmd -t, 376
and Serviceguard, 417 wlmpard -t, 386
acctcom command suggested interval for global arbiter
support for WLM, 402 daemon, 271
allocating CPU resources suggested wlm_interval for WLM daemon,
fixed amount, 92 216
for given time, 96 wlmaudit command for viewing data, 249
granularity of, 219 averaging
rising tide model, 122 disabling in usage controllers, 223
alternate name
pattern matching and, 457 B
PRM group assignments based on, 460 billing, 249
ApacheTK, 434 buffering of I/O in data collectors, 394, 484,
API 510
for sending performance data, 493
wlm_mon_attach() function, 501 C
wlm_mon_detach() function, 504
wlm_mon_write() function, 502 C data collector interface to send data to
application records WLM, 499
defining, 166 capping (memory), 450
cntl_avg keyword, 223
workload group placement precedence, 459
cntl_base_previous_req keyword, 233
applications in setting up cross-partition management,
assigning to workload groups, 83, 166
260
controlling, 81 cntl_convergence_rate keyword, 230
manager cntl_kp keyword, 227
determining workload group default value (1), 227
assignments, 459 cntl_margin keyword, 231
how PRM manages applications, 454 default value (0.1), 231
records, 83 cntl_smooth keyword, 223, 480
for shell scripts, 169, 173 coll_argv keyword, 215, 477
pattern matching (regular expressions) coll_stderr keyword, 223, 479
in, 456, 457 command-line interface to send data to
resetting to assigned group (wlmd -i), 375 WLM, 495
techniques for placing in workload groups, commands
80 acctcom
apps keyword, 83, 167, 172 support for WLM, 402
ARM at
adding ARM API calls to an application, 504 support for WLM, 401
at command cron
support for WLM, 401 support for WLM, 401
auditing, 249 id
data file location (/var/opt/wlm/audit/), 253 support for WLM, 402

525
Index

login fixed, 92
support for WLM, 401 for time period, 96
ps rising tide model, 122
examples, 73 de-allocating, 233
support for WLM, 402 management
smooth, 428 how PRM manages CPU resources, 448
wlmgui, 347 maximum
communications specifying for workload group, 177
securing migrating across partitions, 89, 255
automatically at reboot, 244 real-time processes, 448
compartment records units
defining, 171 absolute, 54, 217
workload group placement precedence, 459 relative, 54, 217
condition keyword, 206 upper and lower bound requests for an SLO
configuration file specifying, 196
activating cpushares keyword, 205, 472
global arbiter (wlmpard -a filename), 265, not using with goal keyword, 200, 471
384 providing fixed or additive allocations, 204
WLM (wlmd -a filename), 241, 376 providing shares per metric allocation, 205,
characters allowed, 136 472
configuration wizard (wlmcw command), cron command
138 support for WLM, 401
conventions, 136 cross-partition management, 255
creating, 136 recommendations and restrictions, 257
getting started, 78 setting up, 260
examples, 233, 283
location, 79 D
global arbiter (cross-partition daemon status EMS resource, 356
management), 265 data
specifying file to use when starting sending from a data collector written in C,
automatically at reboot, 242 499
specifying file to use when starting global sending from a perl program, 497
arbiter automatically at reboot, 243 sending from a shell script, 496
syntactic conventions, 136 sending from stdout, 499
syntax overview, 395 sending from the command line, 495
validating (wlmd -c filename), 376 data collector
configuration wizard (wlmcw command), 138 ARM-instrumented applications, 504
configuring WLM, 135 buffering of I/O, 394, 484, 510
with a wizard (wlmcw command), 138 communicating performance to WLM, 493
with the WLM GUI (wlmgui command), 140 dummy transactions, 509
controllers GlancePlus application data, 488
limiting CPU allocation request values, 197
GlancePlus global data, 489
role in WLM, 115, 256
GlancePlus PRM-controlled volume group
tuning allocation requests, 224, 229, 231
data, 491
CPU resources GlancePlus PRM-specific application data,
allocation
490

526
 Index
how to write, 482 /etc/rc.config.d/wlm, 245
independent, 484 /opt/prm/shells (and scripts in application
monitoring to ensure it is running, 131, 469 records), 170
native, 485 audit data (/var/opt/wlm/audit/), 253
Oracle data, 492 configuration (global arbiter)
sending existing metrics to WLM, 493 activating (wlmpard -a filename), 91, 92,
SIGTERM signal, 515 263
specifying in the configuration file, 215, 477 configuration (WLM)
stderr (capturing), 223, 479 activating (wlmd -a filename), 241
white paper, 483 example configuration
data collector stream, 484 (/opt/wlm/examples/wlmconf/), 283
de-allocating CPU resources when not included with WLM, 60
needed, 233 log (global arbiter statistics),
disk bandwidth /var/opt/wlm/wlmpardstats, 63, 113
manager log (message), /var/opt/wlm/msglog, 63, 113
and swap partitions, 452 log (statistics), /var/opt/wlm/wlmdstats, 63,
how PRM manages disk bandwidth, 452 113, 376, 387
disk bandwidth shares, specifying, 174 firewalls, 66
disks keyword, 174 fork system call
distribute_excess keyword, 179, 218 support for WLM, 401
default value (0—do not distribute), 219
FSS workload groups, 159
interaction with weight keyword, 182 defining
DMZ, 66 manually, 159
dummy transactions, 509
with the WLM GUI (wlmgui command),
157
E
minimum CPU allocation, 176
EMS process placement, 222
configuring notification, 360
monitoring WLM with, 354 G
resources
daemon status, 356 glance_app, 488
glance_gbl, 489
overview, 354
glance_prm, 490
SLO status information, 357 glance_prm_byvg, 491
time of last configuration activation, 356 glance_tt, 508
entity keyword, 196 GlancePlus
environment variables application data, 488
WLM_INTERVAL, 216 global data, 489
WLM_METRIC_NAME, 502 PRM-controlled volume group data, 491
exception keyword, 206 PRM-specific application data, 490
exec system call transaction data, 508
support for WLM, 401
global arbiter
extended_shares keyword, 219 disabling, 134
specifying host
F in WLM configuration file, 264
feedback starting
sending feedback to WLM development automatically at reboot, 242
team, 29 in passive mode, 91, 263
file name on the command line, 92, 263
pattern matching and, 456 stopping, 134
files

527
Index

global tune structure, 210 Instant Capacity (Temporary)

gmaxcpu keyword, 177 integrating with WLM, 410
default value (total CPU resources), 178 instrumenting your code for data collection,
gmaxmem keyword, 184 504
default value (100%), 184 integrating WLM
gmincpu keyword, 175 Apache, 434
default value (1% of system CPU HP Systems Insight Manager, 420
resources), 176 nPartitions, 407
gminmem keyword, 183 OpenView, 413
default value (1% of system memory), 183 Oracle, 426
goal Pay per use, 410
compared to stretch goal, 203 PRM, 404
determining for workload, 87 processor sets (PSETs), 405
keyword, 200 SAP, 438
not using with cpushares and ’more’, 200, SAS, 440
471 Security Containment, 412
specifying for an SLO, 199 Servicecontrol Manger, 420
types Serviceguard
performance, 200 overview, 414
usage, 200 sg_pkg_active command, 416
goal-based SLOs, 118 steps, 416
groups keyword, 82, 159 SNMP, 442
Temporary Instant Capacity (TiCAP), 410
H Virtual Machines (Integrity VM), 408
hmaxcpu keyword, 147 virtual partitions, 407
hmincpu keyword, 147 WebLogic, 436
hweight keyword, 148 interval
Hyper-Threading, 42 for checking data and changing allocations,
defined, 518 215
LCPU state, 161 for global arbiter (cross-partition
management), 270
I
icod_filter_intervals keyword, 146 K
icod_thresh_pri keyword, 145 kernel parameters, 247
id command keywords
support for WLM, 402 absolute_cpu_units, 217
_IDLE_ group (used when apps, 83, 167, 172
transient_groups=1), 222
cntl_avg, 223
inactive SLOs (removal of workload group),
220 cntl_base_previous_req, 233
independent data collector, 484 in setting up cross-partition management,
Instant Capacity (iCAP) 260
defined, 519 cntl_convergence_rate, 230
icod_filter_intervals keyword, 146 cntl_kp, 227
icod_thresh_pri keyword, 145 default value (1), 227
requesting notification with the cntl_margin, 231
icod_thresh_pri keyword, 144 default value (0.1), 231

528
 Index
cntl_smooth, 223, 480 weight, 178
coll_argv, 215, 477 default value (1), 179
coll_stderr, 223, 479 interaction with distribute_excess
condition, 206 keyword, 182
cpushares, 204, 205, 472 wlm_interval, 216
not using with goal keyword, 200, 471 default value (60 seconds), 216
disks, 174 wlmdstats_size_limit, 224
distribute_excess, 179, 218 default value (0—do not trim file), 224
default value (0—do not distribute), 219 wlmpardstats_size_limit, 272
interaction with weight keyword, 182 default value (0—do not trim file), 272
entity, 196
exception, 206 L
extended_shares, 219 LCPU keyword, 161
gmaxcpu, 177 log file
default value (total CPU resources), 178 /var/opt/wlm/msglog, 63, 113
gmaxmem, 184 /var/opt/wlm/wlmdstats, 63, 113, 376, 387
default value (100%), 184 trimming automatically, 224
gmincpu, 175 /var/opt/wlm/wlmpardstats, 63, 113
default value (1% of system CPU trimming automatically, 272
resources), 176 logging
gminmem, 183 wlmd statistics
default value (1% of system memory), 183 enabling on the command line, 376
goal, 200 wlmpard statistics
not using with cpushares keyword, 200, enabling on the command line, 387
471 logical CPU
groups, 82, 159 defined, 519
hmaxcpu, 147 login command
hmincpu, 147 support for WLM, 401
hweight, 148
icod_filter_intervals, 146 M
icod_thresh_pri, 145 management
LCPU, 161 application
maxcpu, 197 how PRM manages applications, 454
memweight, 184 CPU resources
default value (1), 185 how PRM manages CPU resources, 448
mincpu, 197 disk bandwidth
pri, 193 and swap partitions, 452
primary_host how PRM manages disk bandwidth, 452
in WLM configuration file, 264 memory
procmap, 85, 172, 438 how PRM manages memory, 449
scomp, 85, 171 nPartitions, 255
transient_groups, 220 PSET, 159
caution when using with conditions, 207 virtual partitions, 255
effect on minimum CPU allocation, 176 virtual partitions (inside nPartitions), 277
users, 83, 164 maxcpu keyword, 197
utility_reserve_threshold, 274 memory
utilitypri, 273 allocation
uxgrp, 84, 166 granularity of, 219
version, 144 available, 449

529
Index

capping, 450 OpenView

lockable, 450 integrating with WLM, 413
manager viewing workload groups as applications,
how PRM manages memory, 449 413
specifying minimum for workload group, Oracle data, 492
183 integrating with WLM, 426
memweight keyword, 184 OTHERS group
default value (1), 185 as a reserved workload group, 163
metric
goals, 471 P
configuring, 467 parser version
making available to WLM, 483 specifying, 144
smoothing, 223, 480 partitions
specifying in a condition statement, 207 and WLM, 50, 89, 255
metric/SLO-specific tune structure, 210 overview, 255
metric-based SLOs, 467 recommendations and restrictions, 257
metric-specific tune structure, 210 example nPartition scenario, 56
migrating to WLM from PRM, 465 example virtual partition scenario, 56
mincpu keyword, 197
minimum CPU allocation migrating CPU resources across, 89, 255
for FSS groups, 176 releasing unneeded CPU resources, 233
for PSET-based groups, 176 setting up management of, 260
monitoring setting up the WLM configuration files, 90,
data collectors, 131, 469 260
overview of techniques, 105 WLM management across, 265
SLO violations, 121 passive mode
wlmgui command, 347 and cross-partition management, 90, 261
wlminfo command, 343 and WLM, 130, 468
msglog file, 63, 113 compared to regular WLM management,
multiple servers, using WLM on, 58 238
enabling WLM in, 375
N enabling wlmpard in, 385
getting started, 75
native data collector, 485
trying a configuration, 236
nested management, 277
netgroups, in user records, 164 patches
network operating environment, 66 policies, 30
notification, configuring, 360 pattern matching
nPartitions (nPars), 50, 255 in an application’s alternate names, 457
and management of virtual partitions in an application’s file name, 456
inside, 277 Pay per use (PPU)
and WLM, 407 integrating with WLM, 410
integrating with WLM, 407 optimizing, 57
managing CPU resources across, 255 global arbiter configuration, 265
specifying priority for resource usage, 273
O utilitypri keyword, 273
performance
ODBTK, 426 controlling methods, 36

530
 Index
data procmap keyword, 85, 172
sending to WLM, 500 identifying SAP processes, 438
goals, 471 ps command
management, overview, 34 examples, 73
monitoring methods, 34 support for WLM, 402
perl interface to send data to WLM, 497 PSET-based workload groups, 159
ports defining
used by WLM, 66 manually, 159
pri keyword, 193 defining with the WLM GUI (wlmgui
primary_host keyword command), 157
in WLM configuration file, 264 minimum CPU allocation, 176
PRM process placement, 222
integrating with WLM, 404 releasing unneeded CPU resources, 233
migrating from PRM to WLM, 465 PSETs
not using with WLM, 59 and WLM, 405
utilities, 445 integrating with WLM, 405
prm structure pstat system call
configuring, 151 support for WLM, 401
PRM_SYS group
as a reserved workload group, 163 Q
prmmove, 86
prmrun, 86 quick reference
process ID (PID) finder getting started, 65
and process maps, 172
and SAP processes, 438 R
process map, 44 ratio (allocation-to-weight), 179
defining, 172 real-time processes, 448, 450
described, 85 reboot
specifying securing communications automatically at,
to identify SAP processes, 438 244
workload group placement precedence, 459 starting global arbiter automatically at, 242
process placement starting WLM automatically at, 242
according to application names, 83, 166 starting wlmcomd automatically at, 243
according to process IDs, 85, 172 reconfiguring WLM, 133
according to secure compartments, 85, 171 records
according to Unix group IDs, 84, 85, 165 application
according to user IDs, 83, 164 pattern matching (regular expressions)
default, 87 in, 456, 457
inactive FSS groups, 222 using shell scripts in, 169, 173
methods, 81 workload group placement precedence, 459
PSET-based groups, 222
process priorities, 448 records
processes compartment, 171
assigning to workload groups, 85 regular expressions
moving, 86 in an application’s alternate names, 457
starting, 86 in an application’s file name, 456
suppressing, 449 relative CPU units
processor sets described, 54
and WLM, 405 enabling, 217
integrating with WLM, 405 releasing unneeded CPU resources, 233

531
Index

rendezvous point SIM

and wlmsend, 393 integrating with WLM, 420
creation, 510 SLO
reserved workload groups, 163 associating with a workload group, 195
rising tide model of CPU allocation, 122 defining with the slo structure, 186
rtprio goal-based, 118
interaction with PRM, 448 inactive, 220
rtsched metric-based, 467
interaction with PRM, 448 name, how to specify, 192
overview, 48
S priority
SAPTK, 438 how to specify, 193
SASTK, 440 introduction, 49
SCM shares-based, 118
integrating with WLM, 420 specifying a fixed or additive CPU
scomp keyword, 85, 171 allocation, 204
secure compartments, 44 specifying a goal, 199
assigning to workload groups, 85, 171 specifying a shares per metric allocation,
secure mode 205, 472
default, 244
specifying lower and upper bound CPU
Secure Resource Partitions, 412
resource requests, 196
creating, 171
specifying when active (conditional), 205
Security Containment, 171, 412
integrating with WLM, 412 status information from EMS, 357
service management, 40 times when active, 207
Servicecontrol Manager violations, 120
integrating with WLM, 420 monitoring with wlminfo, 121
Serviceguard slo structure
and absolute_cpu_units, 417 configuring with WLM GUI, 187
and transient_groups, 417 smooth command, 428
HP_UX WLM sg_pkg_active command, 416 smoothing metric values, 223, 480
overview of integrating with WLM, 414 SNMPTK, 442
software
steps for integrating with WLM, 416
associated
service-level agreements, 40 GlancePlus, 23
service-level objectives, 40
setting, 220 Process Resource Manager (PRM), 23
sg_pkg_active (integrating with included
Serviceguard), 416 HP-UX WLM Toolkits (WLMTK), 23
shares-based SLOs, 118 statistics
shares-per-metric allocation wlmd, 376
specifying, 205, 472 wlmpard, 387
shell scripts stderr
interface to send data to WLM, 496 redirecting stderr of data collectors with
specifying in application records, 169, 173 coll_stderr, 223, 479
signals stdout, connecting to WLM, 499
handling in a data collector, 515 stream data collector, 484
SIGTERM signal, 515 stretch goal, 203
support

532
 Index
command and system call, 401 workload group placement precedence, 459
policies, 30 Unix groups
swap partitions, not placing under PRM assigning to workload groups, 84, 85, 165
control, 452 usage controllers
system calls disabling averaging, 223
exec usage goals, 200
support for WLM, 401 user records
fork assigning to workload groups, 83
support for WLM, 401 defining, 164
pstat workload group placement precedence, 459
support for WLM, 401 users
System Management Homepage (SMH), 360 assigning to workload groups, 83, 164
Systems Insight Manager users keyword, 83, 164
integrating with WLM, 420 utilities, PRM, 445
utility_reserve_threshold keyword, 274
T utilitypri keyword, 273
uxgrp keyword, 84, 166
Temporary Instant Capacity (TiCAP) uxgrp records
integrating with WLM, 410 assigning to workload groups, 84, 85
optimizing, 57, 102
global arbiter configuration, 265 V
specifying priority for resource usage, 273
validating
specifying reserve threshold, 274 a configuration file (wlmd -c filename), 376
temporary_reserve_threshold keyword, 274
a global arbiter configuration file (wlmpard
utilitypri keyword, 273
-c filename), 265
time ranges for SLOs, 207 version keyword, 144
Toolkit
Apache, 434 version of WLM (wlmd -V), 374
version of WLM documented, 23
HP-UX WLM Oracle Database (ODBTK), violations of SLOs, 120
426 Virtual Machines (Integrity VM), 42
SAP, 438 and WLM, 58, 408
SAS, 440 integrating with WLM, 408
SNMP, 442 virtual partitions (vPars), 255
WebLogic, 436 and WLM, 50, 407
training available from HP, 30 inside nPartitions, 277
transient_groups keyword, 220 integrating with WLM, 407
and effect on minimum CPU allocation, 176 Virtual Server Environment (VSE), 42
and Serviceguard, 417
caution when using with conditions, 207 W
trimming
the wlmdstats statistics log file WebLogicTK, 436
automatically, 224 weight keyword, 178
default value (1), 179
the wlmpardstats log file automatically, 272
interaction with distribute_excess
tune structure, 210 keyword, 182
configuring, 210
white papers
tuning the controllers, 224, 229, 231 Apache (apache_wlm_howto.html), 435
data collectors, 483
U
how to perform WLM tasks, 63
Unix group records SAP (sap_wlm_howto.html), 439
defining, 165 SAS, 441

533
Index

tuning WLM, 228 networking, 66

WebLogic (weblogic_wlm_howto.html), 437 new features, 27
wildcards not using with PRM, 59
alternate names for applications, 168 partition management, 50, 89, 255
application file names, 167 recommendations and restrictions, 257
in an application’s alternate names, 457 setting up, 260
in an application’s file name, 456 ports, 66
WLM reconfiguring, 133
activating solution examples, 52
a configuration (wlmd -a filename), 241, starting, 77
374 automatically at reboot, 242
a global arbiter configuration (wlmpard -a on the command line, 241
filename), 265, 384 stopping, 77, 134
and metric goals, 467 training available from HP, 30
and multiple servers, 58 uses of, 46
and PRM, 59 WLM ApacheTK Toolkit (ApacheTK), 434
and Virtual Machines, 58 WLM BEA WebLogic Toolkit (WebLogicTK),
API for sending performance data, 493 436
common tasks, 89 WLM communications daemon
configuration file syntactic conventions, 136 starting
configuration wizard, 138 automatically at reboot, 243
configuring, 135 WLM ODBTK, 426
cross-partition management, 255 WLM Oracle Database Toolkit (ODBTK), 426
graphical overview, 256 WLM SAP Toolkit (SAPTK), 438
recommendations and restrictions, 257 WLM SAPTK, 438
WLM SAS Toolkit (SASTK), 440
setting up, 260 WLM SNMP Toolkit (SNMPTK), 442
disabling, 134 WLM_INTERVAL environment variable, 216
environment, 51 wlm_interval keyword, 216
example configuration, 233 default value (60 seconds), 216
location, 79 WLM_METRIC_NAME environment
example configurations directory variable, 502
(/opt/wlm/examples/wlmconf/), 283 wlm_mon_attach() API function, 500, 501
example of WLM in use, 124 wlm_mon_detach() API function, 500, 504
files, 60 wlm_mon_write() API function, 500, 502
getting started, 65 wlmaudit
command syntax, 364
graphical overview, 115
example report, 249
how it works, 112
usage, 249
how to use, 127
installation location, 75 wlmcert command syntax, 366
wlmcomd command syntax, 369
interval wlmcw command syntax, 372
for checking data and changing wlmd command syntax, 374
allocations, 215 wlmd statistics
for global arbiter (cross-partition disabling, 246
management), 270 enabling logging at reboot, 245
monitoring, 343 wlmdstats file, 63, 113, 376, 387
nested management, 277 wlmdstats_size_limit keyword, 224

534
 Index
default value (0—do not trim file), 224 assigning Unix groups to, 165
wlmgui assigning users to, 164
monitoring WLM, 347 CPU weight assignment, 178
wlmgui command syntax, 379 described, 44
wlminfo FSS, 159
command syntax, 381 giving users access to, 164, 166
display examples, 106 maximum memory, 184
monitoring data collectors, 131, 469 memory
monitoring SLO violations, 121 specifying minimum, 183
monitoring WLM, 343 memory weight, 184
wlmoradc (integrating with Oracle), 428 PSET, 160
wlmpard reserved, 163
configuration file, 265
specifying, 159
disabling, 134
with no active SLOs, 220
starting, 242
workload management
stopping, 134 described, 39
wlmpard command syntax, 384 workloads
wlmpard statistics described, 44
enabling logging at reboot, 246
how WLM manages, 111
wlmpardstats file, 63, 113 SAP, 438
wlmpardstats_size_limit keyword, 272
default value (0—do not trim file), 272 separation
wlmprmconf command syntax, 465 by application name, 83
wlmrcvdc by customized criteria, 172
how it works, 509 by customized criteria (process ID), 85
syntax, 388 by process Unix group ID, 84, 85
wlmsend by process user ID, 83
how it works, 509 by secure compartments, 85
syntax, 393 writing a data collector, 482
WLMTK
ApacheTK, 434
ODBTK, 426
SAPTK, 438
SASTK, 440
SNMPTK, 442
WebLogicTK, 436
wlmwlsdc (integrating with BEA WebLogic),
436
workload groups
assigning applications to, 83, 166
assigning processes by process IDs, 85
assigning processes by secure
compartments, 85
assigning processes by Unix group IDs, 84,
85
assigning processes by user IDs, 83
assigning processes to (customized
criteria), 172
assigning secure compartments to, 171
assigning to SLO, 195

535
Index

536