wlmconf(4)wlmconf(4)NAMEwlmconf - HP-UX Workload Manager (WLM) configuration file
DESCRIPTION
The Workload Manager (WLM) configuration file is the primary user
interface for controlling WLM. It is an ASCII file that specifies ser‐
vice-level objectives (SLOs), tuning parameters, and Process Resource
Manager (PRM) settings. The syntax is free-form, allowing white space
to be used freely in formatting the file. Comments are preceded with
the hash mark (#) and continue to the end of the line.
The WLM configuration file has the following components:
WLM parser version
The keyword, placed at the beginning of a configuration file,
ensures that WLM uses the correct version parser for a configu‐
ration file.
Request for notification of `Instant Capacity needed'
The keyword has WLM set an EMS resource to inform you when the
activation of Instant Capacity resources might help meet SLOs.
(Instant Capacity was formerly called iCOD.) This is only noti‐
fication--no changes to resource allocations are made based on
your use of this keyword. For information on how WLM can actu‐
ally make changes to resource allocations, refer to the section
"HOW TO USE wlmpard TO OPTIMIZE TEMPORARY INSTANT CAPACITY AND
PAY PER USE SYSTEMS" in the wlmpard(1M) manpage.
Name of host running the WLM global arbiter
The keyword specifies the host name for the system that is run‐
ning WLM's global arbiter, which provides WLM's cross-partition
management as well as its management of Temporary Instant Capac‐
ity resources (v6 or later) and Pay per use (v4, v7, or later)
resources. The global arbiter can run on any HP-UX system that
has network connectivity to the partitions being managed by WLM.
System-wide settings
The and keywords allow you to set various values for a host when
you manage partitions.
structure
Use this structure if you plan on managing FSS groups or PSETs.
If you plan on managing only virtual partitions or nParti‐
tions--with no FSS groups or PSETs inside them, you need not
specify this structure. If you plan on running WLM on an HP
Integrity Virtual Machines (Integrity VM) Host, do not use this
structure. WLM will not run with FSS groups or PSETs on
Integrity VM Hosts where an Integrity VM (guest) is running.
The structure defines the PRM configuration, which includes the
workload groups, the application records, the user records, the
Unix group records, the compartment records, the process maps,
and the disk bandwidth shares. This structure does not allocate
CPU shares or memory shares for workload groups, although it
does allow you to specify lower and upper bounds on the CPU and
memory usage by processes in the groups.
structures
The structures specify service-level objectives and assign pri‐
orities to those objectives.
structures
The structures allow you to tune metrics and SLOs. In particu‐
lar, structures allow you to specify data collectors to gather
data on your applications, the frequency at which WLM checks for
new data, and how aggressively WLM converges on a new CPU shares
allocation, among other features.
ACCEPTABLE CHARACTERS
In your WLM configuration file, you can use the characters below in the
names that you supply.
· Uppercase letters (A-Z)
· Lowercase letters (a-z)
· Digits (0-9)
· The underscore character (_)
Do not begin a name with an underscore; names beginning with
underscores are reserved for WLM use.
· The plus character (+)
· The hyphen character (-)
· The forward slash (/)
Do not use slashes in the names of structures or metrics.
· The period (.)
· Quoted characters
You can use any printable character (except white space, <,
>, &, ', ", \, and =) by enclosing them in quotes (for exam‐
ple: groups = "my@group":2;). You cannot use the slash char‐
acter (/) in the names of structures or metrics, even when
quoted.
The hash character (#) comments out the rest of the line, unless quoted
as part of a name.
An unquoted number can never be a name.
USING THE WLM CONFIGURATION WIZARD OR THE WLM GUI
If you prefer not to work directly with a configuration file, you can
use the:
· WLM Configuration Wizard
Be sure to set your environment variable before invoking the
wizard.
Invoke the wizard using the following command:
The wizard requires Java Runtime Environment (JRE) version
1.5 or later, and for PRM-based configurations, PRM C.03.00
or later. 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 cre‐
ating 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.
· WLM Graphical User Interface (GUI)
Be sure to set your environment variable before invoking the
WLM GUI.
Invoke the GUI using the following command:
allows you to create, modify, and deploy WLM configurations
both locally and remotely. In addition, it provides monitor‐
ing capabilities.
You can run on a system where WLM is running or on any remote
system with the appropriate JRE (Java Runtime Environment)
version installed. (JRE version 1.5 or later is required
where WLM is running or on any remote system. For JRE version
requirements, refer to the the wlmgui(1M) manpage.)
The version of must match the version of the WLM configura‐
tion it will manage. You can install multiple versions of on
a Microsoft Windows PC.
Also, on the system being managed by WLM, requires the WLM
communications daemon to be running as well as 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.) For more
information, see the wlmgui(1M) manpage or the wlmcomd(1M)
manpage.
PARSER VERSION
Place the optional keyword at the beginning of your configuration file
to specify which version of the WLM configuration file parser to use
with that particular configuration. 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 keyword, you are
telling WLM which parser to use for the configuration file.
The default and only valid value is 0:
Specify the keyword at most once in any configuration, at the beginning
of the configuration, outside all and structures.
NOTIFICATION OF INSTANT CAPACITY NEEDED / PPU OPTIMIZATION
Instant Capacity (formerly known as iCOD), offers the ability to acti‐
vate reserve CPU (core) capacity that is already on your system. (A
core is the actual data-processing engine within a processor, where a
processor might have multiple cores.) You do not pay for the Instant
Capacity cores until they are activated. You would activate the Instant
Capacity cores either to increase the active cores on the system or to
replace the cores of a failing processor on that system. In either
case, action can be taken--with no waiting for new cores to
arrive--because the Instant Capacity cores are already on the system.
If you plan on using Instant Capacity in combination with WLM's virtual
partition management, use vPars version A.03.01 or later.
Also, HP offers a Pay per use (PPU) feature. PPU provides the capacity
to support peak anticipated demand, but with payment for the HP server
based on actual usage of that capacity. WLM integrates with PPU v4 and
v7. 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 the features of PPU v5, 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 an Instant Capacity system (using any version
of Instant Capacity) or a PPU system (v4, v7, or later), you can con‐
figure WLM to let you know that SLOs are failing and the reserves are
needed. WLM only notifies you of the situation; you must manually acti‐
vate the reserves if you feel it is appropriate. (Independent of this
keyword though, you can use to automate activation of these reserves.)
WLM notifies you using the EMS resource This resource can take the val‐
ues or
To enable this notification, use the keyword in your WLM configuration.
Specify this keyword outside all and structures. The syntax is:
icod_thresh_pri = integer;
where
Is an optional keyword.
integer Is an integer value greater than or equal to 1. If
Instant Capacity reserves exist (formerly known as
iCOD reserves), they are considered needed whenever
SLOs with a priority from 1 to integer (inclusive) 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.
Based on the value, you can have EMS notify you so you can acti‐
vate Instant Capacity reserves if you feel it is appropriate.
When using you can also use another global keyword that must be
outside all and structures. The syntax is:
icod_filter_intervals = integer;
where
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 Similarly, it is the number of
intervals over which Instant Capacity reserves
are not required before the EMS resource is
changed to
WLM uses a data collector named to provide this EMS resource.
You may see it in error messages. This collector provides only a
single metric. This metric is named _icod_valid_config. You may
see it in the statistics log file /var/opt/wlm/wlmdstats or in
output.
HOST OF GLOBAL ARBITER
You can run WLM within and across virtual partitions and nPartitions.
You can even have WLM manage virtual partitions inside nPartitions, as
discussed in the WLM User's Guide (/opt/wlm/share/doc/WLMug.pdf). WLM
provides a global arbiter that can take input from the WLM instances on
the partitions. The global arbiter then moves cores across partitions,
if needed, to better achieve the SLOs specified in the WLM configura‐
tion files that are active in the partitions. (Given the physical
nature of nPartitions, WLM only simulates core movement--as described
in the wlmparconf(4) manpage.)
In each partition, you activate a WLM configuration that indicates the
host name for the partition running the WLM global arbiter. Indicate
the host of the global arbiter as follows, specifying this keyword out‐
side all and structures.
primary_host = hostname [ : port_number ] ;
where
Is an optional keyword that identifies the host name of the sys‐
tem
running the global arbiter.
hostname Is the name or IP address of the host running the
arbiter, which can be any HP-UX system that has net‐
work connectivity to the partitions being managed by
WLM.
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, you must specify the same port number in
the WLM global arbiter configuration file and in the
WLM configuration file in each partition.
For information on how a port is chosen, refer to the
wlmparconf(4) manpage.
If a configuration includes the keyword, it automatically uses absolute
CPU units. 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, on an 8-core system, 200 represents 2 cores. For more
information on absolute CPU units, refer to the section on the tunable.
You can specify the keyword and define workload groups in the same WLM
configuration.
For more information on the global arbiter and its configuration file,
see the wlmpard(1M) and wlmparconf(4) manpages.
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 par‐
tition or nPartition).
hmincpu
To specify the minimum number of CPU shares a host receives, use the
keyword and the following syntax:
hmincpu = min;
where
Is an optional keyword.
You cannot use this keyword in a configuration that
includes a structure.
min Is the host's minimum number of CPU shares. The value
must be an integer between 0 and the host's 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.
For information on the effect of this keyword in passive mode, refer to
the section PASSIVE MODE VERSUS ACTUAL WLM MANAGEMENT in the wlm(5)
manpage.
hmaxcpu
To specify the maximum number of CPU shares a host receives, use the
keyword and the following syntax:
hmaxcpu = max;
where
Is an optional keyword.
You cannot use this keyword in a configuration that
includes a structure.
max Is the host's maximum number of CPU shares. The value
must be an integer between the host's value and the
system's total CPU, inclusive. Total CPU is 100 mul‐
tiplied by the number of cores (absolute CPU units are
implied).
For information on the effect of this keyword in passive mode, refer to
the section PASSIVE MODE VERSUS ACTUAL WLM MANAGEMENT in the wlm(5)
manpage.
hweight
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 keyword and the following syn‐
tax:
hweight = wt;
where
Is an optional keyword.
You cannot use this keyword in a configuration that
includes a 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.
STRUCTURE FORMATS
The WLM structure formats are discussed in the following sections.
prm structure
If you plan on managing only virtual partitions or nPartitions--with no
FSS groups or PSETs inside them, you need not specify a structure. You
can go immediately to the next section, which discusses the structure.
Likewise, if you plan to run WLM on an HP Integrity Virtual Machines
(Integrity VM) Host, you can go immediately to the next section. To run
WLM on an Integrity VM Host, WLM must use a strictly host-based config‐
uration (a WLM configuration for moving CPU resources (cores) across
nPartitions or activating Temporary Instant Capacity or Pay per use
cores; WLM does not run with FSS groups or PSETs on Integrity VM Hosts
where an Integrity VM runs). You can run WLM within an Integrity VM
(as guest), but WLM does not support Instant Capacity, Pay per use, and
vPar integration within VMs. (However, guests will take advantage of
cores added to the VM host by Instant Capacity, Temporary Instant
Capacity, and Pay per use.) For other restrictions pertaining to WLM
use with Integrity VM machines, see wlmpard(1M) or wlm(5).
Use a structure to define the PRM configuration. The structure takes
the following format:
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 [: LCPU = { ON | OFF } ]
Here is an example structure:
prm {
groups = finance : 2,
sales : 3,
marketing : PSET;
users = jdoe : finance,
pdoe : sales,
admin : finance sales marketing;
uxgrp = treasurer : finance,
forecaster : sales;
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;
}
groups
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 alloca‐
tion for an FSS group based on the group's progress toward an SLO.
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. WLM
can automatically adjust the number of cores assigned to a PSET group
based on its progress toward an SLO. WLM supports the Hyper-Threading
feature for PSET-based groups. See the discussion of the attribute
below.
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 groups using the required keyword and 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. The name should be less
than eight characters long for proper display by the
command. It cannot start with an underscore (_).
The group is the default group for processes run by
the root user. You can specify it as an FSS group
(group_ID must be 0) and use it with the and keywords
in a structure. You cannot, however, use it with the
or keywords, in an structure, or as a PSET group.
Use only as needed. Do not load processes into indis‐
criminately.
The 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 as an FSS group (group_ID must be 1), but
not as a PSET group. It does not require an structure,
but you can create one or more for it if you wish.
If you specify or for any group in your configuration,
be sure to specify a for any group, including for
which 1% of the memory is not sufficient for its users
and applications (or if the tunable is enabled, for
which 0.2% of the memory is not sufficient).
After WLM allocates CPU resources to groups with SLOs,
by default receives any remaining CPU resources.
For any other FSS group you define, you must define an
structure that references that group.
group_ID Is the workload group ID and must be a uniquely
assigned integer value between 0 and 63 (inclusive) or
starting with HP-UX 11i v2 Update 2, between 0 and 255
(inclusive).
ID 0 is reserved for the system group, If it is not
specified, it is created automatically.
ID 1 is reserved for the user default group If the
group is not specified, it is created automatically.
A PSET_group_def has the syntax:
group : PSET [: LCPU = { ON | OFF } ]
where
group Is the workload group name. The name should be less
than eight characters long for proper display by the
command. It cannot start with an underscore (_).
group cannot be either the group.
If you specify or for any group in your configuration,
be sure to specify a for any group, including for
which 1% of the memory is not sufficient for its users
and applications (or if the tunable is enabled, for
which 0.2% of the memory is not sufficient).
With PSET groups, you can define one or more struc‐
tures 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 logical CPU (Hyper-Threading) feature is available
starting with HP-UX 11i v3 (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 log‐
ical 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 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 before 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 command. For example, to enable Hyper-
Threading on the system, use the following command:
For more information about this command, see the
kctune(1M) manpage. Do not use this command to modify
a PSET while WLM is running. Whenever possible use WLM
to control PSETs.
You can override the default Hyper-Threading state for
cores assigned to a specific PSET-based group by using
the LCPU attribute. The LCPU attribute is based on an
attribute value that you can also examine and set
using the option with the command. For more informa‐
tion about this command, see the psrset(1M) manpage.
Do not use the command to modify a PSET while WLM is
running. Whenever possible, use WLM to control PSETs.
The PRM configuration generated by the WLM configura‐
tion file reflects the per-PSET Hyper-Threading
attribute currently specified for the affected work‐
load groups.
You can define workload groups (FSS and PSET-based) and use WLM's par‐
tition management (by specifying the keyword) in the same WLM configu‐
ration. Certain software restrictions apply to using PSET-based groups
with HP-UX Virtual Partitions (vPars), Instant Capacity, and Pay per
use. For more information, refer to the WLM Release Notes
(/opt/wlm/share/doc/Rel_Notes).
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 Fur‐
thermore, if there are more PSET-based groups than cores and 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 CPU resources.
users
To specify the workload groups in which users' processes can run and
that users can access, use the keyword and the following syntax:
users = user : init_group [alt_group1 alt_group2 ...] [, ...];
where
Is an optional keyword that can appear, at most, once in a con‐
figuration.
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 +netgroup_name. Netgroups are
defined in /etc/netgroup. WLM ignores any line in
/etc/netgroup that has an empty user field. For more
information on netgroups, refer to netgroup(4).
init_group
Is the name of the initial workload group for the user
or netgroup. This is the group selected when launch‐
ing the user's login shell.
For information on a user's group placement when the
user belongs to multiple netgroups, refer to the
Process Resource Manager User's Guide
(/opt/prm/doc/PRM.ug.pdf).
alt_group1 [alt_group2 ...]
(Optional) Is the name 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. Move
existing processes to, or start new processes in,
alternate groups using the or commands. For more
information, refer to prmmove(1) and prmrun(1).
If you assign processes that would typically run in to another group,
be sure that group has sufficient resources. (For example, if you are
using memory records, be sure the group gets enough memory.) Take par‐
ticular care when creating user records for root as such records will
move essential system processes, such as
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. How‐
ever, WLM will eventually move the process to the workload group speci‐
fied in its users record.
When determining the workload group assignment for a process that
matches multiple records, WLM gives highest precedence to assignments
defined in process maps (or to assignments made using the or commands).
The precedence given to the various records that define workload group
placement is described in the section "Precedence of records for group
assignments" below.
uxgrp
When the number of users in an organization or enterprise is substan‐
tial, 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 sup‐
ports Unix group records only if PRM C.03.02 or later is installed on
the system.
You can assign a Unix group to one workload group only; however, multi‐
ple 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.
Place Unix groups in workload groups by defining the keyword in the
structure. The 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.
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. How‐
ever, WLM will eventually move the process to the workload group speci‐
fied in its Unix group record.
When determining the workload group assignment for a process that
matches multiple records, WLM gives highest precedence to assignments
defined in process maps (or to assignments made using the or prmrun
commands). The precedence given to the various records that define
workload group placement is described in the section "Precedence of
records for group assignments" below.
apps
Each workload group defines a workload. One or more applications can be
assigned to the workload group. WLM then dynamically allocates CPU
shares or whole cores to a workload group to achieve the goal specified
in the workload group's SLO.
The system is polled every 30 seconds to ensure that processes are run‐
ning in the appropriate workload groups. If a process forks child pro‐
cesses and immediately exits, the polling will likely miss the parent
process. As a result, the parent process is never placed in its work‐
load 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 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 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.)
Specify the application's group assignment using the keyword and the
following syntax:
apps = group : application [alt_name1 alt_name2 ...] [, ... ];
where
Is an optional keyword that can appear, at most, once in a
configuration.
group Is the name of the workload group (that is, PRM group)
in which the application should run.
application
Is the full pathname of the application, starting with
a slash (/). The pathname must be to a binary or
shell/interpreter.
For information on how to specify scripts in an state‐
ment, refer to the section SCRIPT EXAMPLE below.
Wildcards and pattern matching in application file
names
You can use wildcards ([,],?,*) to specify the file
name, but not the directory name. If using wildcards,
enclose the full pathname in quotes. Beginning with
WLM A.03.01, you can use wildcards in both the file
name and the alternate name in a single application
record. For more information on wildcards, refer to
the PATTERN MATCHING NOTATION section in regexp(5).
File names are expanded to their complete names when a
PRM configuration is loaded by WLM. Explicit applica‐
tion 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.
alt_name1 [alt_name2 ...]
(Optional) Is an alternate name the application is
assigned when executed. For example, a program may
rename itself causing its process name, as seen in
ps(1) output, to be different from the file name of
the program. Alternate names allow you to place such a
program into different workload groups based on its
process names, even though the executable file name is
the same.
With shell scripts, the alt_name is the name of the
script, and the shell/interpreter is the application.
For an example showing how to specify scripts in an
statement, refer to the section SCRIPT EXAMPLE below.
For an example showing how to specify an application
that renames itself, refer to the section RENAMED
APPLICATION EXAMPLE below.
Wildcards and pattern matching in alternate names
You can use wildcards ([,],?,*) when specifying alter‐
nate names. Beginning with WLM A.03.01, you can use
wildcards in both the file name and the alternate name
in a single application record. If using wildcards,
enclose the alternate name in quotes. For more infor‐
mation on wildcards, refer to the PATTERN MATCHING
NOTATION section in regexp(5).
Beginning with WLM A.03.02, when it is running with
PRM C.03.02 or later, you can use Extended Regular
Expressions (EREs) for the alternate name field in the
application record (see the EXTENDED REGULAR EXPRES‐
SION section in regexp(5)). However, note that such a
regular expression must be the only alternate name in
that particular record and should be within single
quotes. For an example of an ERE used for the alter‐
nate name field in an application record, see the
RENAMED APPLICATION EXAMPLE section below.
Other records can still have non-ERE alternate names
for the same application. Note that while non-ERE
alternate names are matched against non-dash command-
line arguments, ERE alternate names are matched
against the entire available command line. Note also
that commas within an ERE are not separators for
alternate names; they must match commas in the command
line. If an ERE alternate name and a non-ERE alter‐
nate name both exist for the same application, the
non-ERE alternate name takes priority. If multiple ERE
alternate names match, the "first" record to match
takes precedence.
If there are multiple application records with alter‐
nate 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 dictio‐
nary order), the application abb would be assigned to
the workload group GroupB.
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. How‐
ever, WLM will eventually move the process to the workload group speci‐
fied in its application record.
When determining the workload group assignment for a process that
matches multiple records, WLM gives highest precedence to assignments
defined in process maps (or to assignments made using the or prmrun
commands). The precedence given to the various records that define
workload group placement is described in the section "Precedence of
records for group assignments" below.
To place a script in a workload group using an statement:
1. Specify the full path of the shell or interpreter used in the
script as the application.
2. Specify the name of the script (just the name--no path) as
the alt_name.
Because the full pathname is not required for the script, a
rogue user can get access to workload groups--that would oth‐
erwise not be accessible--by using the name of the script for
new scripts or wrappers.
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 statement to place the script in group would
be:
apps = scripts_grp : /opt/perl/bin/perl myscript.pl;
To place a renamed application in a workload group using an statement:
1. Specify the full path of the application as the application.
2. Specify the new name the application takes once it is running
as the alt_name.
For example, here is an 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 workload group. Similarly, pro‐
cesses matching the pattern ´ora*Sales´ go into the workload group
Here is an example showing the use of an ERE with the alternate name in
the application record:
apps = Finance_Sales : /opt/oracle/bin/oracle 'ora.*(Finance|Sales)';
The ERE expression is enclosed in single quotes. Any processes begin‐
ning with the string 'ora.' followed by any strings that include
'Finance' or 'Sales' are placed in the workload group.
scomp
The HP-UX feature Security Containment, available starting with HP-UX
11i v2, provides "secure compartments," which allow you to isolate pro‐
cesses and files. You can place one or more secure compartments in a
single workload group to manage the resource allocation for your secure
compartments. To place secure compartments in workload groups, use the
keyword and the following syntax:
scomp = compartment : group [, ...];
where
Is an optional keyword.
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.
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. How‐
ever, WLM will eventually move the process to the workload group speci‐
fied in its compartment record.
When determining the workload group assignment for a process that
matches multiple records, WLM gives highest precedence to assignments
defined in process maps (or to assignments made using the or prmrun
commands). The precedence given to the various records that define
workload group placement is described in the section "Precedence of
records for group assignments" below.
procmap
Use this keyword to define process maps. A process map is a powerful
and flexible tool that allows you to establish your own criteria for
how processes are placed in workload groups rather than using WLM's
default criteria (apps, or records).
To specify process maps, use the keyword and the following syntax:
procmap = group : PID_finder [, group1 : PID_finder1",...];
where
Is an optional keyword that can appear, at most, once in a
configuration.
group Is the name of the PRM workload group in which the
processes identified 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 identi‐
fiers (PIDs) of processes meant to be placed in group.
The command line can specify, for example, a 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. For an example showing how to
specify the command line in the PID_finder statement,
refer to the section PID FINDER EXAMPLES below.
In conjunction with HP Serviceguard Extension for
SAP (SGeSAP), the HP-UX WLM SAP Toolkit (SAPTK)
provides a script (wlmsapmap) that identifies SAP
processes and uses WLM's process map (procmap) fea‐
ture to place them in specific workload groups.
SAPTK is part of the freely available product WLM
Toolkits (WLMTK) available at /opt/wlm/toolkits/.
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 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.
You can specify more than one PID_finder for a group,
but you must specify each PID_finder in a separate
group : PID_finder statement.
There is no expansion of wildcards specified in the
PID_finder string.
The PID_finder is a single command. Pipes are not directly sup‐
ported unless embedded in a shell command (see the third example
provided in the section PID FINDER EXAMPLES below).
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.
Process maps take precedence over WLM's standard criteria for
process placement. That is, if a PID listed by the PID_finder
script matches an or record, the process map determines the
placement of the process. If a PID is specified by multiple
PID_finder commands or scripts, the process's assignment might
change from group to group with each successive spawning of the
PID_finder.
To follow are examples showing three different ways to specify
PID_finder, from the most desirable method to the least. All
three PID_finder specifications provide similar functionality.
1. Run the command in an appropriate environment to
gather PIDs matching the application named pid_app.
This method of specifying PID_finder is the best
because it does not mask the functionality and does
not fork additional shells.
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 preceding 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 command with a pipeline inside 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}'";
Precedence of records for group assignments
When determining the workload group assignment for a process that
matches multiple PRM 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 that of a process associated with a compartment, applica‐
tion, user, or Unix group record, the process map determines the place‐
ment 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, refer to the "Placement of processes"
sections in the discussion of structures below.
If you use the or command to place a process in a workload group, that
assignment takes precedence over any of the assignments defined by the
PRM records.
disks
WLM does not dynamically allocate disk bandwidth to volume groups.
However, to ensure that a workload group receives a guaranteed minimum
amount of disk bandwidth for a specified volume group, it can be
assigned disk bandwidth shares. You can specify shares for a given log‐
ical volume group, managed by HP's Logical Volume Manager (LVM).
Specify the disk bandwidth shares for workload groups using the keyword
and the following syntax:
disks = group : volume shares [, ...];
where
Is an optional keyword that can appear, at most, once in a
configuration.
group Is the workload group name.
You cannot specify a PSET group in a 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 band‐
width 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.
For example, consider a system with two volume groups: /dev/vg01 and
/dev/vg02. Assume the group needs shares on both volume groups. As a
result, all the groups get shares on both volume groups:
disks = OTHERS : /dev/vg01 1,
finance : /dev/vg01 50,
sales : /dev/vg01 49,
OTHERS : /dev/vg02 1,
finance : /dev/vg02 60,
sales : /dev/vg02 39;
gmincpu
To specify the minimum number of CPU shares a group receives, use the
keyword and the following syntax:
gmincpu = group : min [,group1 : min1, ...];
where
Is an optional keyword.
group Is the workload group name.
min Is group's minimum number of CPU shares. The value
must be an integer between 0 and the group's value,
inclusive.
min is out of the total CPU resources, which is 100
multiplied by the number of cores (if you set the tun‐
able 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
enabled, you would specify:
For more information on absolute CPU units, refer to
the section on the tunable.
If you specify a min greater than the total CPU
resources, WLM treats it as equal to the total CPU
resources.
By default, the minimum CPU allocation for a workload
group with no active SLOs is the min value. If this
value is not set, the group gets the minimum alloca‐
tion possible. For FSS groups, this value is 1% of the
default PSET (the default PSET consists of all the
processors that are not assigned to other PSET
groups). If the tunable is set to 1, the minimum is
0.2%. The default minimum allocation for a PSET group
is one core. If the keyword is 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 value of if defined and resources
are available). However, groups associated with
process maps always remain active even if the groups
have no active SLOs.
If you specify a min value that is less than 1% of the
total CPU resources, an FSS group receives 1% of the
CPU resources in the default PSET; if the tunable is
enabled, the group receives 0.2% (with incremental
allocations of 0.1%). For example, in the WLM config‐
uration on an 8-core system, the system's total CPU
resources can be divided into 800 shares (100 for each
core), assuming is enabled. With disabled and no
PSETs, 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.
With enabled in this scenario, the minimum allocation
value would be 6.4 or 7.2, which are the two nearest
multiples of .8.
For information on the effect of the keyword in pas‐
sive mode, refer to the section PASSIVE MODE VERSUS
ACTUAL WLM MANAGEMENT in the wlm(5) manpage.
If the sum of all the values is greater than the sys‐
tem's total CPU resources, the values are treated as
CPU requests that are to be met before any other
requests are considered. values do apply.
When configuring WLM on a partition, be sure to select
a value for min that makes sense in terms of the lim‐
its placed on the partition when it was cre‐
ated--namely its minimum and maximum number of cores.
This minimum is a hard lower limit; group receives less than this mini‐
mum only if it has no active SLOs and is set to 1. (However, if group
is associated with a process map, it remains active and continues to
receive the minimum even if it has no active SLOs.) This hard limit is
different from the value in structures, which merely specifies a lower
bound on the CPU request generated by that SLO.
gmaxcpu
To specify the maximum number of CPU shares a group receives, use the
keyword and the following syntax:
gmaxcpu = group : max [,group1 : max1, ...];
where
Is an optional keyword.
group Is the workload group name.
max Is group's maximum number of CPU shares. The value
must be an integer between the group's value and the
system's total CPU, inclusive. Total CPU resources is
100 multiplied by the number of cores (if you set the
tunable 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
enabled, you would specify:
For more information on absolute CPU units, refer to
the section on the tunable.
When configuring WLM on a partition, be sure to select
a value for max that makes sense in terms of the lim‐
its placed on the partition when it was cre‐
ated--namely its minimum and maximum number of cores.
This maximum is a hard upper limit; group will never receive more than
this maximum, as opposed to the value in structures, which merely spec‐
ifies an upper bound on the CPU request generated by that SLO. (The
group may receive more than its if other groups have received their and
there are still CPU resources left.)
There is no default value for a group. If you do not specify a value,
WLM takes the system's total CPU resources, in shares, as the value.
For information on the effect of this keyword in passive mode, refer to
the section PASSIVE MODE VERSUS ACTUAL WLM MANAGEMENT in the wlm(5)
manpage.
weight
The larger a 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 the extra CPU
resources to go to your workload groups, you must set the tunable in
your configuration file. If you do not set this tunable, all the excess
CPU resources go to the default workload group
To specify a group's CPU weight, use the keyword and the following syn‐
tax:
weight = group : wt [,group1 : wt1, ...];
where
Is an optional keyword.
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.
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 prior‐
ity, 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 fol‐
lowing 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 equal to 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 values and distri‐
bution of excess (when the tunable is set). The ultimate consequence of
this policy is that, in the absence of other SLO requests, any two
requests at the same priority level that are not fully satisfied will
have the same ratio between their respective allocations as between
their respective weights (in other words, the ratio of group A's allo‐
cation to group B's allocation equals the ratio of group A's weight to
group B's weight).
For an example demonstrating this policy for distributing CPU resources
based on weight, refer to the HP-UX Workload Manager's User's Guide
(/opt/wlm/share/doc/WLMug.pdf).
gminmem
When specifying a workload group's minimum memory, be very careful of
resource interactions, which are explained in the section "How resource
allocations interact" in the HP-UX Workload Manager's User's Guide
(/opt/wlm/share/doc/WLMug.pdf). In particular, be sure the workload
groups get the memory they need. (When setting values for and ensure
that the groups get sufficient memory even when all groups are active.)
To specify the minimum percentage of memory a group receives, use the
keyword and the following syntax:
gminmem = group : min [,group1 : min1, ...];
where
Is an optional keyword.
group Is the workload group name.
If you specify or for any group in your configuration,
be sure to specify a for any group, including for
which 1% of the memory is not sufficient for its users
and applications (or if the tunable is enabled, for
which 0.2% of the memory is not sufficient).
You cannot specify the group in a statement.
min Is group's minimum percentage of memory. The value
must be an integer between 1 and the group's value,
inclusive.
The default min value is 1.
This minimum is a hard lower limit; group receives less than this mini‐
mum only if it has no active SLOs, is set to 1, and group is not asso‐
ciated with a process map.
gmaxmem
When specifying a workload group's maximum memory, be very careful of
resource interactions, which are explained in the section "How resource
allocations interact" in the HP-UX Workload Manager's User's Guide
(/opt/wlm/share/doc/WLMug.pdf). In particular, be sure the workload
groups get the memory they need. (When setting values for and 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
keyword and the following syntax:
gmaxmem = group : max [,group1 : max1, ...];
where
Is an optional keyword.
group Is the workload group name.
You cannot specify the group in a statement.
max Is group's maximum percentage of memory. The value
must be an integer between the group's value and 100,
inclusive.
The default max value is 100.
This maximum is a hard upper limit; group will never receive more than
this maximum. (The group may receive more than its if all other groups
have received their and there is still memory left.)
memweight
The larger a memory weight value you assign a group, the more memory it
receives when there is not enough memory to satisfy all requests.
To specify a group's memory weight, use the keyword and the following
syntax:
memweight = group : wt [,group1 : wt1, ...];
where
Is an optional keyword.
group Is the workload group name.
You cannot specify the group in a statement.
Assigning a to a PSET workload group is not useful
because WLM grants the group memory when the configu‐
ration is activated, but never adjusts its memory
allocation.
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.
Consider the following example. We have four groups, with one being a
PSET group. The serves as an allocation (Alloc) for the groups because
each group gets the amount of memory represented by its value.
Group Alloc (gminmem) Weight Final alloc
───────────────────────────────────────────────────────────────
A (PSET) 10 Unspecified 10
B 30 3 42
C 20 2 28
OTHERS 20 1 20
First, A gets its because it is a PSET group. That leaves 90% of the
memory to distribute. Next, is granted its memory. It has a of 1, and
the sum of the values is 6. As a result, gets 1/6 * 90, or 15%. How‐
ever, 15 is less than its so it gets its of 20 instead. Now there is
70% left. However, WLM guarantees the for the groups and 30 and 20
respectively. So, there is only 20% to distribute between the two
groups and This 20% is distributed so that the groups' final alloca‐
tions are proportional to their weights.
slo structure
Use structures to specify the service-level objectives and assign pri‐
orities to those objectives.
The structure takes one of the two following 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 structure uses the statement. This statement can‐
not be used with a statement.
slo slo_name {
pri = priority;
[ entity = PRM group group_name; ]
[ mincpu = lower_bound_request; ]
[ maxcpu = upper_bound_request; ]
cpushares = value { more | total } [ per metric met [ plus offset
]];
[ condition = condition_expression; ]
[ exception = exception_expression; ]
}
slo_name must not contain any slashes or start with an underscore (_).
Here are several example structures. These first two examples are
strictly host-based, which means there are no PSETs or FSS groups being
managed on the host.
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;
}
These next two examples are based on PRM groups. They use statements to
indicate the associated PRM groups.
slo analyzing {
pri = 2;
mincpu = 10;
maxcpu = 20;
entity = PRM group analyze;
goal = usage _CPU 75 90;
}
slo developing {
pri = 3;
entity = PRM group developers;
cpushares = 2 more per metric developer_count plus 10;
}
pri
Each SLO must have a priority so WLM can determine CPU allocation when
the combined CPU requests of all SLOs exceed 100%.
Specify an SLO's priority using the keyword and the following syntax:
pri = priority;
where
Is a required keyword.
priority Is an integer greater than or equal to 1. The value 1
represents the highest priority. Multiple SLOs can be
assigned the same priority.
entity
If you plan on managing only virtual partitions or nPartitions--with no
FSS groups or PSETs inside, the keyword is not needed.
SLOs govern workloads that are based on workload groups. Each workload
group must, therefore, be assigned an SLO. Specify the PRM group to
which the SLO applies using the keyword and the following syntax:
entity = PRM group group_name;
where
Is a required keyword when managing PSETs or FSS groups.
Is the mechanism used to control the resource allocation to
the workload groups. Currently, is the only supported
mechanism.
Is the part of the control mechanism that represents the work‐
load group
and can be individually controlled via resource allo‐
cation. Currently, is the only supported attribute.
group_name
Is the name of the PRM group to which this SLO
applies.
You cannot specify in an structure.
mincpu
maxcpu
WLM automatically changes CPU share allocations to enforce SLOs. How‐
ever, you can limit allocations by specifying a minimum share alloca‐
tion and a maximum share allocation for an SLO. Specify these values
using the following syntax:
mincpu = lower_bound_request;
maxcpu = upper_bound_request;
where
lower_bound_request
Is an integer value from 0 to upper_bound_request,
inclusive. lower_bound_request is the minimum number
of CPU shares the SLO is allowed to request, while the
SLO is active.
If an SLO does not also contain a statement or a
statement, the lower_bound_request value is used as
the SLO's shares request. If an SLO does not contain a
statement, 0 is used as the SLO's shares
request--although a value or value may keep the allo‐
cation 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 to 1 or it is implied by other ele‐
ments in your configuration)--or just 100 by default.
To have a minimum request of 2 cores on an 8-core sys‐
tem with enabled, you would specify:
If you specify a lower_bound_request greater than the
total CPU resources, WLM treats it as equal to the
total CPU resources.
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
cores.
The lower_bound_request value is not a hard limit:
Higher priority SLOs may consume all CPU resource
before all SLOs are granted CPU resources. However,
the associated workload group's value is a hard limit.
It serves as the group's minimum CPU allocation when
it represents more CPU resources than the values used
in the group's SLOs. The value is also used to deter‐
mine the group's minimum CPU allocation in SLOs with
statements but no statements. For information on the
default value, refer to the discussion above. Simi‐
larly, described above, is a hard limit for allocation
to a host.
For information on the effect of this keyword in pas‐
sive mode, refer to the section PASSIVE MODE VERSUS
ACTUAL WLM MANAGEMENT in the wlm(5) manpage.
upper_bound_request
Is an integer value greater than or equal to
lower_bound_request. upper_bound_request is the maxi‐
mum number of CPU shares the SLO is allowed to
request, while the SLO is active.
upper_bound_request is out of the total CPU resources,
which is 100 multiplied by the number of cores (if you
set the tunable to 1 or it is implied by other ele‐
ments 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 sys‐
tem with enabled, you would specify:
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
cores.
An upper_bound_request may be ignored if the associ‐
ated workload group's CPU resources are already lim‐
ited by the group's value. In the case of SLOs with
statements but no statements, the group's value is
still used to limit CPU allocation. For information
on the default value of refer to the discussion above.
Similarly, described above, can limit CPU allocation
to a host.
For information on the effect of this keyword in pas‐
sive mode, refer to the section PASSIVE MODE VERSUS
ACTUAL WLM MANAGEMENT in the wlm(5) manpage.
For more information on absolute CPU units, refer to the section on the
tunable.
goal
An SLO can have a goal that it attempts to achieve. Specify an SLO's
goal using the keyword and the following syntax:
goal = goal_expression;
where
Is an optional keyword. If neither the
nor the keywords are specified, the SLO is allocated
resources according to its setting.
You cannot specify both a statement and a statement in
the same SLO. Similarly, you cannot have a workload
group with one SLO that has a statement and another
SLO that has a statement that includes
goal_expression
Indicates either a usage goal or a metric goal. Use a
usage goal to ensure a workload group's utilization of
its allocated CPU falls within a given percentage
range. Usage goals are especially beneficial when you
have a workload that cannot provide performance data.
Usage goals are relatively easy to implement. WLM mon‐
itors CPU utilization and can detect when applications
are busy or idle. Metric goals are based on perfor‐
mance 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. For
details specific to metric goals, refer to the section
"ADVANCED WLM USAGE: CONFIGURATION DETAILS FOR METRIC
GOALS" below. Also, refer to the appendix in the WLM
User's Guide (/opt/wlm/share/doc/WLMug.pdf), entitled
"Advanced WLM: Using performance metrics."
The syntaxes for these expressions are described below. 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 allo‐
cation, the group's utilization is 20/50 or 40%. WLM attempts to keep a
workload group's utilization between a low and high bound.
Typically, you should set to 5 when your WLM configuration contains a
usage goal.
Specify a usage goal as follows:
low_util_bound high_util_bound
where
low_util_bound
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
number of shares requested whenever utilization drops
below this value.
Setting low_util_bound at or near 0 can result in an
SLO that never reduces its number of requested shares.
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 number of shares
requested whenever utilization surpasses this value.
When not specified, this value defaults to the speci‐
fied low_util_bound; when both are not specified, this
value defaults to 75.
Setting high_util_bound at or near 100 can result in
an SLO that never requests a larger number of CPU
shares.
When WLM requests a change in the number of shares, the request is pro‐
portional to how far the current utilization is below low_util_bound or
above high_util_bound. Use or in a 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
value of 10 will cause the utilization to move in larger jumps than
will a value of 0.1.
For an idea of how such a structure would look, consider a workload
group named buy. Its structure would look like the following:
tune _CPU_buy {
cntl_kp = 0.1;
}
You can specify metric goals if performance data is available. Metric
goals are based on performance data and require understanding of that
data. For each metric goal, you select a performance metric (such as a
response-time goal) to measure the extent to which the goal is being
met, exceeded, or underachieved. You also select how the performance
data is collected for WLM. For more information on metric goals, refer
to the section "Specifying a metric goal in an SLO" below.
cpushares
An SLO can directly express a request for CPU shares using the keyword.
For more information, refer to the section "Specifying a shares-per-
metric request in an SLO" below.
condition
exception
Specify when an SLO is active by using the and keywords and the follow‐
ing syntax:
condition_expression;
exception_expression;
where
Is an optional keyword that specifies an expression that must be
true
for the SLO to be active.
Do not create a statement that attempts to detect pro‐
cesses in a transient group using tools such as or
Whenever the group is deleted (FSS group) or assigned
zero CPU resources (PSET-based group), it is impossi‐
ble for the system to place processes in the group.
The condition will then never detect the processes it
is looking for.
Is an optional keyword that specifies an expression that must be
false
for the SLO to be active.
condition_expression
exception_expression
Is a Boolean expression containing logical statements
that specify one or more of the following components:
· metric met > numeric_value
· metric met < numeric_value
· metric met
· A date
· A date range
Combine Boolean expressions by using the && (AND), || (OR), and ! (NOT)
operators. The order of precedence for these operators is: !, &&, and
||. Parentheses can be used to alter the order of evaluation. Example
combinations follow.
In this example, the SLO is active only if the day is a Monday or a
Friday:
condition = Mon || Fri;
Here, the SLO is active only if there are more than 5 active processes
and it is between 8pm and 11pm:
condition = (metric process_count > 5) && (20:00 - 22:59);
The met value must have an associated structure. The 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.
Specify a date using the following syntax:
where
Is the name of the weekday: Mon, Tue, Wed, Thu, Fri, Sat,
or Sun.
Is the date that takes
values 1-12, values 1-31, and values as four-
digit years. An asterisk (*) can be used in
place of or to indicate that all valid values
are accepted.
Is the time and represents the hours and minutes on a
24-hour clock.
An asterisk (*) can be used in place of or to
indicate that all valid values are accepted.
A date range is specified by a start-date and an end-date separated by
a dash character (-). There are 10 valid date formats in a range, and
both start and end dates must use the same format. Those formats are
shown below with examples:
01/07/2000 -- The author's 39th birthday.
15:30 -- Every day at 3:30pm.
Mon -- Every Monday.
01/07/2000 08:30 -- January 7th, 2000 at 8:30am
Mon 08:00 -- Every Monday at 8:00am.
01/07/* -- Every January 7th.
*/15/* -- The 15th of every month every year.
*:00 -- Every hour at the top of the hour.
01/07/* 08:30 -- Every January 7th at 8:30am.
*/07/* 11:30 -- The 7th of every month every year at 11:30am.
tune structure
Use structures to specify the data collector and its command-line argu‐
ments for SLOs, set the WLM daemon's interval for checking for new
data, distribute excess CPU resources to your defined workload groups,
enable automatic log file trimming, and to set various controller vari‐
ables.
There are three types of structures. They are given below, ordered from
most generic to most specific. Note that many of the elements are com‐
mon among the three different types of structures.
Global structure
This structure applies to all metrics and SLOs. It does not ref‐
erence the name of any metric or SLO. It can be specified, at
most, once in the configuration file.
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 }; ]
}
Metric-specific structure
This structure applies to all SLOs that use the specified met‐
ric. It can be specified, at most, once per metric.
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 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 structures could apply, the more specific
structure type takes precedence.
Here are some example structures:
tune {
wlm_interval = 30;
distribute_excess = 1;
extended_shares = 1;
transient_groups = 1;
}
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;
cntl_margin = 0.2;
}
tune reports_app.resp_time {
coll_argv = wlmrcvdc /opt/reports_app/rptmon;
cntl_kp = 1.5;
}
coll_argv
Valid in: global and metric-specific structures
Whenever you use a metric in your WLM configuration, you need to supply
a value for that metric. The statement launches a data collector to
gather values for a metric. You can specify a data collector in a met‐
ric-specific structure to gather values for that one metric. For more
information, see the section "Specifying a data collector in a tune
structure" below.
wlm_interval
Valid in: global structures
The WLM daemon periodically checks for new performance data from the
data collectors. It also automatically adjusts CPU shares on that
interval. The default interval is 60 seconds, however, that can be
altered using the following tuning construct. Specify the WLM interval
using the tunable and the following syntax:
wlm_interval = number_of_seconds;
where
Is an optional tunable.
number_of_seconds
Number of seconds, ranging from 1 to 86400 (1 day),
that the WLM daemon waits before checking for new data
from the data collectors and adjusting CPU shares if
needed.
Typically, number_of_seconds should be 5 when your WLM
configuration contains a usage goal.
When generating audit data (with the option), num‐
ber_of_seconds should be no more than 60 to ensure the
audit data sampling rate is sufficiently frequent to:
· Minimize the amount of audit data lost if the WLM
daemon exits unexpectedly
· Minimize the effect of changes in the number of
available cores (due to WLM's management of virtual
partition, nPartition, Instant Capacity, Temporary
Instant Capacity, and Pay per use cores)
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.
The tunable is valid only in global structures.
absolute_cpu_units
Valid in: global structures
With the tunable, you can control whether the CPU units used by the
following keywords/tunables are absolute or relative:
·
·
·
·
·
·
·
With absolute CPU units enabled (absolute_cpu_units = 1), you specify
CPU units in terms of 100, where 100 represents an entire core of CPU
resources. So, if you want a of half a core, you would specify:
mincpu = 50;
If you want a of two cores, you would specify:
maxcpu = 200;
Absolute CPU units are used when the number of active cores changes due
to WLM's management of Instant Capacity, Temporary Instant Capacity,
Pay per use, Virtual Partition, or nPartition resources. Regardless of
the number of active cores, the absolute CPU units represent the same
amount of cores. HP recommends using absolute CPU units.
With relative CPU units the units you specify represent a percentage of
the system's total CPU resources (cores) 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.
Relative CPU units is the default. To set it explicitly, use the fol‐
lowing statement:
absolute_cpu_units = 0;
Several conditions involving can cause your WLM configuration file to
be invalid:
· Setting equal to 0 and setting
· Setting equal to 0 in a configuration that does not have a
structure
· In a configuration with a structure:
* Setting equal to 0 and specifying a PSET group
· In a configuration without a structure:
* Setting equal to 0 and setting
* Setting equal to 0 and setting
* Setting equal to 0 and setting
distribute_excess
Valid in: global structures
By default, if any CPU resources remain after satisfying all SLOs, the
remainder is given to the group. To distribute this excess to the work‐
load groups you have defined, set the tunable to 1 in a global struc‐
ture:
tune {
distribute_excess = 1;
}
Only workload groups with active SLOs receive the excess CPU resources.
This distribution is based on balancing the weight-to-allocation ratios
for the workload groups. These ratios are discussed in the keyword
description in this manpage.
The distribution is subject to the group CPU maximum values specified
by the keyword. If the excess CPU is not fully distributed because of
group CPU maximum values, the excess is given to the group as
usual--even if giving this excess places it over its value.
The default value for is 0.
extended_shares
Valid in: global structures.
By default, allocations to FSS groups are based on 100 shares per core
of CPU resources. The minimum allocation to groups with inactive SLOs
is one share or 1% of a core. If you are using WLM memory management,
the group receives 1% of memory. You can refine the granularity for
minimum allocations by setting the tunable to 1 (true) in a global
structure:
tune {
extended_shares = 1;
}
In this way, CPU minimum allocations are based on 1000 shares per core.
This requires that you use absolute CPU units, which is also recom‐
mended (set to 1). Minimum allocations of memory are also based on 1000
units instead of 100.
With enabled, the minimum allocation for a group with no active SLOs
(assuming 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 enabled, WLM can sup‐
port 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 is 0.
Enable if:
· You want finer granularity of allocation to FSS groups. This
might be preferred when the number of FSS groups or cores is
large.
· You want to use more than 63 FSS workload groups.
Enable instead of if you want to prevent groups from being removed when
they become inactive, while providing smaller minimum allocations to
these groups.
Regardless of the value of all configuration file values and all values
that are output by are based on hundredths (when using absolute CPU
units). Enabling affects the granularity for all allocations and makes
possible smaller minimum allocations.
transient_groups
Valid in: global structures
By default, all workload groups are always present--even those with no
active SLOs. An FSS group with no active SLOs still requires 1% of the
total CPU resources for FSS groups (if the tunable is enabled, an FSS
group requires 0.2%). A PSET-based group with no active SLOs requires
at least a whole core. However, if the value requests more than the
minimum allocation required for the group, the group receives the num‐
ber of CPU resources specified by that value. Similarly, if you are
using WLM's memory management, the workload with no active SLOs
receives 1% of the memory (or 0.2% of the memory if the tunable is
enabled), unless the workload has a value requesting more.
If you prefer groups with no active SLOs to go away temporarily (as
long as they have no active SLOs) and consume no CPU or memory
resources, set the tunable to 1 in a global structure:
tune {
transient_groups = 1;
}
Setting equal to 1 in a configuration that does not have a structure
results in an invalid configuration.
With the 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. However, groups associated with process maps always
remain active even if the groups have no active SLOs.
Using the 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 below.
The group is never removed, regardless of its number of active SLOs.
If an FSS workload group has been temporarily removed, its and values
(if any) are ignored.
To prevent groups from being removed when they become inactive, while
providing them smaller minimum allocations, enable the tunable instead
of the tunable.
Do not create a statement that attempts to detect processes in a tran‐
sient group using tools such as or Whenever the group is deleted (FSS
group) or assigned zero CPU resources (PSET-based group), it is impos‐
sible for the system to place processes in the group. The condition
will then never detect the processes it is looking for. With if an FSS
workload group, say 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 This group has only the minimum CPU and memory resources
and can greatly restrict the progress of a process. When has active
SLOs again, the processes placed in by records are moved back to
If a process is not assigned to a group by a record, it is moved to or
if its current group is removed. The process remains in or even when
the group has active SLOs again. For this reason, be cautious when
using only or to place a process in an FSS group that may be removed.
Using user records, Unix group records, application records, or com‐
partment records for processes that go into transient FSS groups
ensures those processes return to the desired groups when the groups
return. However, note that groups associated with process maps always
remain active even if the groups have no active SLOs. (For information
on how WLM determines which group assignment takes precedence when the
same process matches multiple records, see the "Precedence of records
for group assignments" section.) The placement of processes in a PSET-
based group depends on whether the group has CPU resources assigned to
it. With the group can have 0 cores if you request it or if the group
has no active SLOs.
Assume a PSET-based workload group, say has no cores. Any processes in
the group when its last CPU is taken away, as well as processes you try
to place in the group using or when the group has no cores, are placed
in the group.
To minimize the number of processes moved to assign at least one core
to PSET-based groups that have running processes.
When has CPU resources again, the processes placed in by user records,
Unix group records, application records, or compartment records are
moved back to Similarly, any processes you attempted to place in the
group with or are moved to the group. (For information on how WLM
determines which group assignment takes precedence when the same
process matches multiple records, see the "Precedence of records for
group assignments" section.) When WLM is managing PSETs, do not change
PSET settings by using the command. Whenever possible, use WLM to con‐
trol PSETs.
coll_stderr
Valid in: global and metric-specific structures
Use the tunable to capture the stderr of your data collectors. For more
information, refer to the section "Capturing your data collector's
stderr" below.
cntl_smooth
Valid in: global and metric-specific structures
Use the keyword to get a running average of a metric from a data col‐
lector, smoothing out dips and spikes in the metric before it is used
by WLM. For more information, refer to the section "Smoothing metric
values" below.
cntl_avg
Valid in: global and metric-specific structures
Use the tunable to control averaging in usage controllers. By default,
averaging is enabled With averaging disabled 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.
wlmdstats_size_limit
Valid in: global structures
Use the tunable to enable automatic trimming of the file
/var/opt/wlm/wlmdstats, which is created when you use the option. The
syntax is:
wlmdstats_size_limit = number_of_megabytes;
where
Is an optional tunable. Specify this tunable in a global
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 auto‐
matic 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.
cntl_kp
Valid in: global, metric-specific, and metric/SLO-specific structures
The tunable allows you to tune a workload group's convergence on an
SLO. You can also tune convergence with the tunable discussed in the
next section. The tunable, which uses normalization to arrive at a new
CPU allocation, is typically easier to use--requiring less analysis
than
WLM starts a performance controller for each goal-based SLO. It also
starts a usage controller for each usage goal. Each controller calcu‐
lates new CPU shares requests if the reported data indicates the work‐
load group is overachieving or underachieving its goal. The controller
then requests the new number of CPU shares. To determine the new allo‐
cation (number of CPU shares), the controller effectively performs an
algorithm that, when plugging in (as opposed to cntl_convergence_rate),
is represented as follows:
New CPU allocation = (Allocation last interval) + cntl_kp * P
WLM calculates P based on the goal type, as indicated below:
Metric 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.
Metric 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
Specify the proportional term of the controller's expression using the
tunable and the following syntax.
cntl_kp = proportional_term;
where
Is an optional tunable. NOTE: Although this tunable is optional,
you
should fine-tune each controller to the characteris‐
tics of its workload.
proportional_term
Is a floating-point value between 0 and 1,000,000
(inclusive) used on the proportional term in the con‐
troller's expression. The default value is 1.
Change this value according to how sensitive the SLO's
associated workload is to changes in its CPU alloca‐
tion and based on the magnitude of the goal being mea‐
sured.
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 propor‐
tional_term.
With absolute CPU units enabled, your propor‐
tional_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 using absolute CPU units.
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 allocation = (Allocation last interval)
which leads to no change in an SLO's allocation
request.
For more information on how to tune, refer to the white paper "Tuning
HP-UX Workload Manager" at /opt/wlm/share/doc/howto/tuning.html.
cntl_convergence_rate
Valid in: global, metric-specific, and metric/SLO-specific structures
The tunable allows you to tune a workload group's convergence on an
SLO. You can also tune convergence with the tunable discussed in the
previous section. (If is not zero, it is used instead of Using the tun‐
able changes the allocation algorithm to take the goal value into con‐
sideration, effectively normalizing the result by the goal's magnitude.
Given the normalization that provides, as well as the greater analysis
required to fine-tune the tunable, you may want to use first. In many
cases, setting 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 cre‐
ates a controller for each such goal.
To determine the new CPU shares allocation, each controller effectively
executes an algorithm that, when plugging in (as opposed to cntl_kp),
is represented as follows:
New CPU allocation = (Allocation last interval) +
(cntl_convergence_rate / 0.10) * (P / goal)
P is the deviation from the goal and is calculated as shown in the pre‐
vious section. There are two special cases to consider in the formula
above:
· 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"
As a tunable, can be specified in a global, metric-specific, and slo-
specific structure. Its value is inherited from a higher level struc‐
ture if you do not specify it at a given level. Its syntax is:
cntl_convergence_rate = number_of_shares;
where
Is a tunable parameter for the controller indicating the number
of CPU
shares by which to adjust a workload group's alloca‐
tion when it differs from its goal. It is specified in
the WLM configuration file. NOTE: Although this tun‐
able is optional, you should fine-tune each controller
to the characteristics of its workload.
number_of_shares
Is a floating-point value that represents the number
of shares (either absolute or relative) by which a
workload group'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 propor‐
tionally smaller than number_of_shares. Similarly,
when the difference is greater than 10%, the adjust‐
ment is proportionally larger than number_of_shares.
The larger number_of_shares is, the larger WLM's
adjustments to the workload group'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 num‐
ber_of_shares.
With absolute CPU units enabled, 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 num‐
ber_of_shares depends on the number of available
cores, which could produce undesirable effects. HP
recommends enabling absolute CPU units.
cntl_margin
Valid in: global, metric-specific, and metric/SLO-specific structures
Specify the margin of error in attaining the specified metric goal
using the tunable and the following syntax.
cntl_margin = margin_value;
where
Is an optional tunable.
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, representing 10 per‐
cent.
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 percent‐
age to create a buffer zone. This adjustment prevents
small fluctuations in the service level from causing
SLO violations.
For more information on how to use the tunable, refer to the white
paper "Tuning HP-UX Workload Manager" at /opt/wlm/share/doc/howto/tun‐
ing.html.
cntl_base_previous_req
Valid in: global, metric-specific, and metric/SLO-specific structures
By default, this keyword is set to 1, which can be beneficial when you
are using WLM's global arbiter to manage virtual partitions or nParti‐
tions or when your WLM configuration has at least one PSET-based work‐
load group with an SLO.
WLM creates a controller for each structure that has a statement. Con‐
trollers make requests to the WLM arbiter for shares allocations. Set‐
ting can result in some controllers requesting CPU resources more
aggressively; however, the distribution of CPU resources may become
unfair due to artificially high resource requests.
ADVANCED WLM USAGE: CONFIGURATION DETAILS FOR METRIC GOALS
This section includes miscellaneous information about configuring WLM
to use performance metrics and to satisfy metric goals. You provide
metric data to WLM so that it can:
· Determine new resource allocations, allowing the workload
groups to achieve their SLOs
· Set shares-per-metric allocations
· Enable or disable SLOs
Sources for metric data
Sources for metric data include:
· Existing metrics (from log files, scripts, or commands you
already have in place)
· ARM-instrumented applications
· GlancePlus
· Oracle databases
· C source code modified to use the WLM API
For more information on these sources as well as background information
on metric collection, refer to the wlm(5) manpage or the appendix in
the WLM User's Guide (/opt/wlm/share/doc/WLMug.pdf) entitled "Advanced
WLM: Using performance metrics." For information on how to provide met‐
rics to WLM, refer to the section "Specifying a data collector in a
tune structure" below.
Specifying a metric goal in an SLO
Specify a metric goal in an SLO as follows:
met relation value
where
met Is the text string naming the metric to be used for
the SLO. The metric string must also be specified in
a structure that indicates the path to the data col‐
lector executable providing the metric. met cannot
contain the slash (/) character, start with an under‐
score (_), or be more than 255 characters.
relation Is if met is supposed to be less than value, or if met
is supposed to be greater than value.
value Is a numeric goal value, either an integer (greater
than or equal to 1) or a floating-point number, not
expressed in exponential notation.
Specifying a shares-per-metric request in an SLO
An SLO can directly express a request for CPU shares in the form "x
shares of CPU resources for each metric y." To define an SLO to
request CPU shares in this way, specify the keyword, using the follow‐
ing syntax:
cpushares = value { more | total } [ per metric met [ plus offset ]];
where
Is an optional keyword for making a CPU shares request.
Using the variables in the syntax statement shown
above, 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 keyword and abso‐
lute when using the keyword. You must specify either
or with the keyword.
You cannot specify both a statement and a statement in
the same SLO. Similarly, you cannot have a workload
with one SLO that has a statement and another SLO that
has a statement that includes
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.
Makes additive shares requests by adding the
request_value (discussed in the keyword description)
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 value, which is 1% of the system's
total CPU resources by default. If the tunable is
enabled (absolute_cpu_units = 1), the workload group's
value is 0.2% of the system's total CPU resources by
default.
request_value is bounded by the SLO's and values, if
specified.
If the workload group can get a larger allocation of
shares from an SLO with an absolute shares request at
that priority, it does so. This absolute request can
come from an SLO that uses with or from an SLO that
uses only the and keywords.
Makes absolute shares requests starting from 0. The request is
exactly
equal to request_value (discussed in the keyword
description), within the bounds formed by the SLO's
and values, if specified.
If the associated workload group can get a larger
allocation of shares from higher priority SLOs or from
other SLOs at the same priority making absolute shares
requests, it does so.
Is an optional clause.
Using includes the result of multiplying value by the
metric met in request_value (discussed in the keyword
description).
met Is the text string naming the metric to be used. The
metric string must also be specified in a structure
that indicates the path to the data collector exe‐
cutable providing the metric. met cannot contain the
slash (/) character, start with an underscore (_), or
be more than 255 characters.
Is an optional clause, for use only with the
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 keyword
description.
offset Is a floating-point value (either positive or nega‐
tive) specifying the number of shares to use as an
offset in the request_value (discussed in the keyword
description).
Here are some request_value expressions and the corresponding state‐
ments:
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 shares 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 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 pro‐
cesses the application has running plus 20 shares from
The next example shows an absolute shares request. It is the same as
the additive example above--except it uses in place of
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 abso‐
lute request, the request starts from 0, not the previous shares
request. Consequently, the request is 5 CPU shares for each of the 3
application processes in workload group App1 for a total of 15. How‐
ever, the request is ignored as the group already has 20 shares because
of its setting.
Specifying a data collector in a tune structure
Whenever you use a metric in your WLM configuration, you need to supply
a value for that metric. To gather values for a specific metric, launch
a data collector in a metric-specific or global structure by using the
statement. This statement is valid in global and metric-specific struc‐
tures. If multiple metrics use the same command, such as to collect
values, you can specify the command in a global structure, instead of
specifying it separately for each metric in its own metric-specific
structure.
The syntax is:
coll_argv = data_collector_and_arguments;
where
Is a required keyword if the SLO has a metric goal.
data_collector_and_arguments
Is the absolute path to a data collector, plus any
arguments. Separate arguments with white space. Use
double quotes to form single arguments to an option or
when using special characters.
Data collectors are spawned when the configuration is
activated by
stdout and stderr for each data collector are sent to
/dev/null; however, you can capture a collector's
stderr using the tunable.
There is no expansion of wildcards in the data_collec‐
tor_and_arguments string.
WLM provides a data collector named You can use with
to feed data you collect to WLM. You can also use to
send metrics from GlancePlus, Oracle, and various
other products to WLM. For more information, refer to
wlmrcvdc(1M). For an example using see the one below.
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. Further‐
more, Hewlett-Packard shall not be liable for any
security breaches resulting from the use of said data
collectors.
Here is a partial WLM configuration showing the use of in a global
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:
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 in a
global structure with to check the status of all the Serviceguard pack‐
ages on the current system. For more information, refer to
sg_pkg_active(1M).
Capturing your data collector's stderr
Because data collectors are started by a daemon process, they do not
have a stderr on which to communicate errors. The tunable allows you to
capture these errors. You can specify in a metric-specific or global
tune structure. Use the following syntax:
coll_stderr = file;
where
Is an optional tunable with a default value of /dev/null. Spec‐
ify this
tunable in global or metric-specific structures.
file Is either (which corresponds to syslog on the system
through the command) or the full path to a file. For
example:
tune num_users {
...
coll_stderr = syslog;
...
}
tune load_average {
...
coll_stderr = /logs/load_average.stderr;
...
}
There are no restrictions on the file specified. How‐
ever, specifying system files or files created by
applications on your system (such as WLM's
/var/opt/wlm/msglog and /var/opt/wlm/wlmdstats) is not
recommended as it can damage the files.
Smoothing metric values
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, use the
keyword in a metric-specific or global structure. Use the following
syntax:
cntl_smooth = smoothing_value;
where
Is an optional tunable that provides exponential smoothing.
smoothing_value
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.
For example, assume your workload generates the met‐
rics 1, 7, and 8--in that order. With a smooth‐
ing_value of 0.4, the values WLM gets are 1, 4.6, and
6.64. With a smoothing_value of 0.8, the values are
more smoothed, with WLM getting 1, 2.2, and 3.36.
Do not use for metrics that are expected to equal zero in SLO expres‐
sions. For example, do not use smoothing globally if your configuration
uses the collector to indicate a Serviceguard package is active (1) or
inactive (0). You could use in metric-specific 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.
AUTHOR
was developed by HP.
FEEDBACK
If you would like to comment on the current HP-UX WLM functionality or
make suggestions for future releases, please send email to:
wlmfeedback@rsn.hp.com
FILES
Workload Manager daemon
Workload Manager global arbiter daemon
optional statistics log
SEE ALSOwlmd(1M), wlmpard(1M), wlm(5), wlmcw(1M), wlmgui(1M), wlmsend(1M), wlm‐
rcvdc(1M), libwlm(3), netgroup(4), wlmparconf(4), prmrun(1), prm‐
move(1), prm(1)
HP-UX Workload Manager User's Guide (/opt/wlm/share/doc/WLMug.pdf)
HP-UX Workload Manager homepage (http://www.hp.com/go/wlm)
wlmconf(4)