Confidential computer software. Valid license from HP required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor's standard commercial license.
The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express
warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall
not be liable for technical or editorial errors or omissions contained herein.
Intel and Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation.
UNIX is a registered trademark of The Open Group.
Java is a US registered trademark of Sun Microsystems, Inc.
VERITAS, VERITAS SOFTWARE, the VERITAS logo, and all other VERITAS product names and slogans are trademarks or registered trademarks of
Symantec Corporation in the USA and/or other countries.
prmlist displaying PRM configuration file information with prmlistdisplaying user record information
with prmlistdisplaying group/CPU record information with prmlistdisplaying application record
information with prmlistprmlist commandsyntaxcommands prmlistsyntax.......................................109
prmrunapplicationlaunchingprmrun syntaxlaunching an applicationin its assigned grouplaunching
an applicationin a user-specified grouplaunching an applicationin a user’s initial groupprmrun
This document describes Release C.03.05 of HP Process Resource Manager (PRM).
The intended audience for this document is system administrators.
New in this edition
This edition includes information on the following changes and additions:
•Placement of processes in PRM groups based on real user IDs.
The prmconfig -M option now offers two modes for enabling and disabling process
placement based on real user ID: REALUIDON and REALUIDOFF. For more information, see
prmconfig(1).
•Support for IPv6.
Supported platforms
HP Process Resource Manager (PRM) Version C.03.05 supports the:
•HP-UX 11i v1 (B.11.11) operating system on HP 9000 servers
•HP-UX 11i v2 (B.11.23) and HP-UX 11i v3 (B.11.31) operating systems running on either
HP 9000 servers or HP Integrity servers
Notational conventions
This section describes notational conventions used in this document.
bold monospace
monospace
Brackets ( [ ] )
Curly brackets ({}),[LINEBREAK]Pipe
(|)
In command examples, bold monospace identifies input that must be typed
exactly as shown.
In paragraph text, monospace identifies command names, system calls, and
data structures and types. It also identifies PRM group names.
In command examples, monospace identifies command output, including error
messages.
In paragraph text, italic identifies titles of documents.italic
In command syntax diagrams, italic identifies variables that you must provide.italic
In command examples, square brackets designate optional entries.
The following command example uses brackets to indicate that the variable
output_file is optional:
command input_file [output_file]
In command syntax diagrams, text surrounded by curly brackets indicates a
choice. The choices available are shown inside the curly brackets, separated by
the pipe sign (|).
The following command example indicates that you can enter either a or b:
command {a | b}
In command examples, horizontal ellipses show repetition of the preceding items.Horizontal ellipses (...)
Keycap
File->New
8
Keycap indicates the keyboard keys you must press to execute the command
example.
Menu and menu items separated by an arrow (->) indicate a selection of menu
items starting from the menu bar.
NOTE:A note highlights important supplemental information.
Associated documents
Associated documents include:
•HP PRM Version C.03.05 Release Notes
•prm(1) manpage
•prm1d(1) manpage
•prm2d(1) manpage
•prmagt(1) manpage
•prmanalyze(1) manpage
•prmavail(1) manpage
•prmconfig(1) manpage
•prminitconfig(1) manpage
•prmlist(1) manpage
•prmloadconf(1) manpage
•prmmonitor(1) manpage
•prmmove(1) manpage
•prmrecover(1) manpage
•prmrun(1) manpage
•prmconf(4) manpage
•prmsmhconfig(1) manpage
•prm2scomp(1) manpage
•scomp2prm(1) manpage
•srpgen(1) manpage
•HP-UX System Administrator’s Guide (HP-UX 11i v3)
•Managing Systems and Workgroups ( HP-UX 11i v1 and HP-UX 11i v2)
•Managing ServiceGuard
The HP-UX System Administrator’s Guide, Managing Systems and Workgroups, and the
Managing ServiceGuard documents, along with many other Hewlett-Packard documents, are
available on the web at http://docs.hp.com.
Providing feedback
•Email your feedback to the PRM development team at the following address:
prmfeedback@rsn.hp.com
•For a forum with other PRM users, visit the IT Resource Center’s forum for HP-UX
•For the latest patch information, white papers, and documentation, visit the Process Resource
Manager web page:
http://www.hp.com/go/prm/
Associated documents9
Support and patch policies
The http://www.hp.com/go/prm site provides information on PRM’s support policy and patch
policy. These policies indicate the time periods for which this version of PRM is supported and
patched.
Training
HP offers a course in HP-UX resource management using PRM. For information, including a course
outline, visit:
http://www.hp.com/education/courses/u5447s.html
10
1 Overview
This chapter introduces the basic concepts and functions of HP Process Resource Manager. It covers:
•“What is HP Process Resource Manager? ” (page 11)
•“Why use HP Process Resource Manager? ” (page 13)
What is HP Process Resource Manager?
Process Resource Manager (PRM) is a resource management tool used to control the amount of
resources that processes use during peak system load (at 100% CPU resource or 100% memory
resource). PRM can guarantee a minimum allocation of system resources available to a group of
processes through the use of PRM groups.
A PRM group is a collection of users and applications that are joined together and assigned certain
amounts of CPU and memory resource. The two types of PRM groups are FSS PRM groups and
PSET PRM groups. An FSS PRM group is the traditional PRM group, whose CPU entitlement is
specified in shares. This group uses the Fair Share Scheduler (FSS) in the HP-UX kernel within the
system’s default processor set (PSET). A PSET PRM group is a PRM group whose CPU entitlement
is specified by assigning it a subset of the system’s cores (PSET). (A core is the actual data-processing
engine within a processor. A single processor might have multiple cores. A core might support
multiple execution threads.) Processes in a PSET have equal access to CPU cycles on their assigned
cores through the HP-UX standard scheduler.
PRM has four managers:
CPU (processor time)Ensures that each PRM group is granted at least its allocation of
CPU resources. Optionally for FSS PRM groups, this resource
manager ensures no more than its capped amount of CPU
resources. For PSET PRM groups, processes are capped on CPU
resource usage by the number of cores assigned to the group.
MEM (memory)Can manage both private memory and shared memory.
•For private memory:
Ensures that each PRM group is granted at least its share, but
(optionally) no more than its capped amount of memory. You
can also specify memory shares be isolated so that a group’s
assigned memory shares cannot be loaned out to, or
borrowed from, other groups.
•For shared memory:
Ensures a PRM group is allocated a minimum number of
megabytes for use as shared memory.
APPL (application)Ensures that specified applications and their child processes run
in the appropriate PRM groups.
The managers control resources, user processes, compartment processes, and applications based
on records in the configuration. Each manager has its own record type. The most important records
are PRM group/CPU records, because all other records must reference these defined PRM groups.
The various records are described below.
Group/CPUSpecifies a PRM group’s name and its CPU allocation. The two types of PRM
group records are FSS PRM group records and PSET PRM group records. An
FSS PRM group is the traditional PRM group, whose CPU entitlement is specified
in shares. This group uses the Fair Share Scheduler (FSS) in the HP-UX kernel
within the system’s default processor set (PSET). A PSET PRM group is a PRM
group whose CPU entitlement is specified by assigning it a subset of the system’s
What is HP Process Resource Manager?11
cores (PSET). Processes in a PSET have equal access to CPU cycles on their
assigned cores through the HP-UX standard scheduler.
MemorySpecifies a PRM group’s memory allocation, either of private memory or shared
memory. There are two types of memory records:
•Private
Specifies a minimum amount of private memory. Optionally specifies a
cap on memory use as well as memory isolation (so that memory cannot
be loaned out or borrowed from other groups).
•Shared
Specifies a minimum amount of memory in megabytes for use as shared
memory for the processes in that PRM group.
PRM groups without a shared memory record default to PRM_SYS for shared
memory allocation.
ApplicationSpecifies an application (either explicitly or by regular expression) and the PRM
group in which the application should run. Optionally, it specifies alternate
names the application can take at execution. (Alternate names are most common
for complex programs such as database programs that launch many processes
and rename them.)
UserSpecifies a user or a collection of users (through a netgroup) and assigns the
user or netgroup to an initial PRM group. Optionally, it specifies alternate PRM
groups. A user or netgroup member then has permissions to use these PRM
groups with the prmmove and prmrun commands.
Unix groupMaps existing Unix groups to PRM groups.
CompartmentMaps existing secure compartments to PRM groups. (Use the optional HP-UX
feature Security Containment to create the secure compartment configurations.
You can also create compartment configurations using a PRM utility such as
srpgen or prm2scomp.)
For more detailed information on records, see the prmconf(4) manpage.
Introduction to PRM commands
PRM supports the commands below. For more information about a command, see its manpage or
the “Command reference” (page 101).
prmagtPRM’s read-only SNMP agent.
prmanalyzeAllows you to analyze resource usage and contention to help plan PRM
configurations.
prmavailDisplays estimated resource availability to help plan PRM configurations.
prmconfigConfigures, enables, disables, and resets PRM. Also, validates PRM
configuration files and controls PRM’s message logging. You can also perform
these tasks using the PRM graphical interface in HP System Management
Homepage (SMH) or HP Systems Insight Manager (SIM).
prminitconfigConfigure or unconfigure the PRM GUI to be available in HP Systems Insight
Manager (SIM).
prmlistDisplays the current PRM group, memory, user, and application information.
prmloadconfCreates a PRM configuration file or updates an existing configuration file.
prmmonitorMonitors current PRM configuration and resource usage by PRM group.
prmmoveMoves processes or groups of processes to another PRM group.
prmrecoverCleans up processes after abnormal memory manager termination.
12Overview
prmrunRuns an application in its assigned group or in a specified group.
prmsmhconfigConfigure or unconfigure the PRM GUI to be available in HP System
Management Homepage (SMH).
prm2scompGenerates a minimal Security Containment configuration based on a PRM
configuration. (The Security Containment configuration defines secure
compartments. You can also create compartment configurations using the
PRM utility srpgen.)
Available starting with HP-UX 11i v2 (B.11.23).
scomp2prmGenerates a minimal PRM configuration based on a Security Containment
configuration. (The Security Containment configuration defines secure
compartments.You can also create compartment configurations using a PRM
utility such as srpgen or prm2scomp.)
Available starting with HP-UX 11i v2 (B.11.23).
srpgenGenerates Secure Resource Partitions by creating both a minimal Security
Containment configuration and a minimal PRM configuration based on your
input.
Available starting with HP-UX 11i v2 (B.11.23).
Why use HP Process Resource Manager?
The standard HP-UX CPU scheduler and memory manager allocate resources to processes based
on the assumption that all processes are of equal importance. PRM, however, allows the system
administrator to group processes and specify the level of importance for that group. PRM allocates
CPU resources, real memory resources (private and shared) to the group based on its assigned
importance.
Reasons to use PRM:
•Improve the response time for critical users and applications.
•Set and manage user expectations for performance.
•Allocate shared servers based on budgeting.
•Ensure that an application package in a Serviceguard cluster has sufficient resources on an
active standby system in the event of a failover.
•Ensure that critical users or applications have sufficient CPU and memory resources.
Users who at times run critical applications, may at other times engage in relatively trivial
tasks. These trivial tasks may be competing in the users’ PRM group with critical applications
for available CPU and real memory resources. For this reason, it is often useful to separate
applications into different PRM groups or create alternate groups for a user. You can assign
a critical application its own PRM group to ensure that the application gets the needed share
of resources.
•Restrict the CPU and real memory resources available to relatively low-priority users and
applications during times of heavy demand.
•Monitor resource consumption by users or applications.
Assigning a group of users or applications to separate PRM groups can be a good way to
keep track of the resources they are using. For information on various PRM reports, see
“Monitoring PRM groups ” (page 93).
Table 1 lists the resources that PRM can manage. For more information about how a resource is
managed, see “Understanding how PRM manages resources ” (page 17).
Why use HP Process Resource Manager?13
Table 1 Resources managed by PRM
User1
33.3%
33.3%33.3%
User2
Process1
Process2
Process3
HP-UX server
Management algorithmCapSharesResource managed
CPU
Yes (for FSS PRM
groups)
YesReal memory (private)
Standard HP-UX resource allocation
Under standard HP-UX resource allocation, all processes are treated equally. Figure 1 illustrates
how a user, by starting multiple processes, can consume a majority of an available resource
because the processes each get equal amounts. As illustrated, User1 starts two processes and
User2 starts one process. Using HP-UX standard resource allocation, User1 could control two-thirds
of the available resource while User2 gets one-third, regardless of the importance of each process.
Yes[LINEBREAK](on
all groups in
CPUCAPON mode;
on a per-group
basis is also
available for
HP-UX 11i v3 and
later)
Yes
[LINEBREAK](on a
per-group basis)
N/AN/AReal memory (shared)
PRM allocates time slices to FSS PRM groups
proportional to their shares. When CPUCAPON
mode is enabled, the FSS PRM group is given
CPU time regardless of whether the time is
needed. With per-group capping, the CPU time
remains available to other PRM groups.
For PSET PRM groups, PRM allocates entire cores
to the group according to the current
configuration. CPU capping for PSET PRM groups
is a result of the number of cores assigned to the
group.
When the system is paging (real memory is
exhausted), if a PRM group is exceeding its
shares, the Memory Resource Groups (MRG)
kernel causes the process to page.
The amount of memory requested is set aside for
use as shared memory.
Figure 1 HP-UX standard resource allocation
How PRM can improve on standard allocation
Unlike the standard scheduler, PRM allows you to set priorities on your processes. The following
sections illustrate various ways you can use PRM to improve scheduling.
If multiple users or applications within a PRM group are competing for resources, standard HP-UX
resource management practices determine resource allocation.
Balancing resource use between users
Figure 2 shows how PRM can alter standard resource allocation and balance system resource use.
In the following scenario, a service provider wants each customer to have an equal share of the
machine. Each customer is assigned to a separate PRM group, which is given resource shares
equivalent to 50%. The resource being allocated could be either CPU or memory. This configuration
guarantees each PRM group 50% of the resource for any given interval. Thus, Customer2’s process
receives 50% of the resource; however, because Customer1’s group contains two processes, each
14Overview
of Customer1’s processes receive 25% of the resource. This scenario assumes that the three processes
GroupA
Customer1
Customer2
Process1
Process2
Process3
HP-UX server
50%
25%25%
GroupB
MGroup
User2
Process1
Process2
Process3
HP-UX server
75%
25%
EGroup
User1
fully consume the resource allocated to their groups.
Figure 2 Balancing resource use between users
Prioritizing resource use between users
Figure 3 illustrates how users’ access to resources can be prioritized using PRM. In this example,
two university departments both contributed to the purchase of a new computer. The math department
paid 25% of the cost, and the engineering department paid 75%. PRM groups are assigned
accordingly: 25% for the math PRM group MGroup and 75% for the engineering PRM group
EGroup. This implies that EGroup processes have priority over MGroup processes. Each group
has only one user: User1 is in MGroup; User2 is in EGroup. User1 is entitled to 25% of the
available resource, and User2 is entitled to 75%. This scenario assumes that the three processes
fully consume the resource allocated to their groups.
Prioritizing resource use for applications
Figure 3 Prioritizing resource use between users
Figure 4 illustrates a situation where two users and an application are assigned to separate PRM
groups. User1 and User2 are respectively assigned to GroupA and GroupB. Both groups are
given 25%. The critical application is assigned to GroupC, which is given 50%. Because of its
greater resource allocation, GroupC takes priority over GroupA and GroupB. This scenario
assumes that the processes fully consume the resource allocated to their groups.
Why use HP Process Resource Manager?15
Figure 4 Prioritizing resource use for an application
GroupA
User1
User2
Process1
Process2
Process3
50%
25%25%
GroupB
Critical application
and its child processes
HP-UX server
GroupC
Limiting resource consumption
The following example describes a situation where a system administrator needs to limit resource
consumption.
A system administrator has determined that screen savers displaying fractal designs consume as
much CPU resource as permitted. To protect the system from these screen savers during the work
day, the administrator creates a PRM group for them. This PRM group limits CPU consumption—when
the system is at peak load—to 5%. When the system is not fully utilized, the screen savers can use
the available CPU resources. Whenever the CPU cycles are needed for productive work, the screen
savers cannot use more than 5% of the CPU resources.
Isolating resource use for applications and users
The following example describes a situation where a system administrator needs to isolate an
application in order to ensure dedicated memory and CPU cycles.
A system administrator has determined that his company’s credit card purchase system needs
dedicated memory and CPU resources for users who are buying products. To ensure the buyers
dedicated CPU cycles, the system administrator creates a PSET PRM group for buyers and assigns
one of the system’s four cores to the group. This guarantees the CPU cycles will be available to
buyers as needed. In addition, the system administrator chooses the memory isolation option to
prevent memory shares from being loaned out or borrowed from other groups. This ensures
immediate response time, rather than waiting for borrowed memory to be paged back in.
16Overview
2 Understanding how PRM manages resources
This chapter explains how PRM performs resource management. The following topics are covered:
•“How PRM controls resources” (page 17)
•“How PRM manages CPU resources” (page 22)
•“How PRM manages real memory resources” (page 26)
•“How resource allocations interact” (page 31)
•“How PRM manages applications” (page 31)
NOTE:
•PRM does not support disk bandwidth control on VxFS. The reason for this limitation is that
VxFS does not support the implementation of I/O disk bandwidth that PRM relies on. When
HP moved to VERITAS File System 4.1, the daemon invalidated this feature for all the current
HP-UX versions.
•If PRM is unable to start or run properly due to CPU or memory resources not being available,
it cannot manage your system’s resources.
How PRM controls resources
PRM places limits on resource use based on values specified in a configuration file. These values
always indicate a minimum amount and in some cases can indicate a maximum amount of a
resource.
NOTE:Do not use PRM with gang scheduling, which is the concurrent scheduling of multiple
threads from a single process as a group (gang).
PRM groups
PRM groups are integral to how PRM works. These groups are assigned per process and are
independent of any other groups, such as user groups that are defined in /etc/group. You assign
applications and users to PRM groups. PRM then manages each group’s CPU and real memory
resources (private and shared) according to the current configuration. If multiple users or applications
within a PRM group are competing for resources, standard HP-UX resource management determines
the resource allocation.
There are two types of PRM groups:
•FSS PRM groups are the traditional and most commonly used PRM group. These groups have
•PSET PRM groups are the second type of PRM group. In PSET PRM groups, the CPU entitlement
Because resource management is performed on a group level, individual users or applications
may not get the resources required in a group consisting of many users or applications. In such
cases, reduce the number of users and applications in the group or create a group specifically for
the resource-intensive user or application.
CPU and private memory resources allocated to them using the shares model. (Shared memory
is specified in megabytes.) FSS PRM groups use the Fair Share Scheduler in the HP-UX kernel
within the system’s default processor set (PSET).
is specified by assigning them a subset of the system’s cores—instead of using the shares
model. (A core is the actual data-processing engine within a processor. A single processor
might have multiple cores. A core might support multiple execution threads, as explained in
the section “Hyper-Threading” (page 25) ) The private memory allocation is still specified in
shares and shared memory is still in megabytes. Processes in a PSET PRM group have equal
access to CPU cycles through the HP-UX time-share scheduler.
How PRM controls resources17
Resource allocation
Resources are allocated to PRM groups differently depending on the resource and the type of PRM
group. For FSS PRM groups, resources are typically allocated in shares. For PSET PRM groups,
you allocate CPU resources using processor sets. Real memory resources are allocated in shares
(private memory) or megabytes (shared memory).
What are processor sets?
Processor sets allow cores on your system to be grouped together in a set by the system administrator
and assigned to a PSET PRM group. Once these cores are assigned to a PSET PRM group, they
are reserved for use by the applications and users assigned to that group. Using processor sets
allows the system administrator to isolate applications and users that are CPU-intensive, or that
need dedicated on-demand CPU resources.
How processor sets work?
Processor sets are a way of allocating dedicated CPU resources to designated applications and
users. At system initialization time, a default PSET is created. This default PSET initially consists of
all of your system’s cores. All FSS PRM group CPU allocation occurs in the default PSET. The system
administrator can create additional PSET PRM groups and assign cores, applications, and users
to those groups. Once cores are assigned to a PSET PRM group, they cannot be used by another
group until a new configuration is loaded.
NOTE:When you have PRM groups based on PSETs enabled:
•Do not modify the PSETs manually using the psrset command
•Do not adjust CPU counts in virtual partitions using the vparmodify command
•Do not adjust Instant Capacity (iCAP), Temporary Instant Capacity (TiCAP), or Pay Per Use
resources using the icapmodify or ppuconfig commands
•Do not perform online cell operations, using parolrad or any other interface, while PRM is
managing the system (For more information, see the WARNINGS section in the prmconfig(1)
manpage.)
Applications and users that are assigned to a PSET PRM group have dedicated CPU cycles from
the cores assigned to the group. Competition for CPU cycles within the processor set are handled
using the HP-UX time-share scheduler.
Table 2 (page 18) shows a 16-core system that has four FSS PRM groups defined within the default
PSET, and two additional system-administrator-defined PSET PRM groups. The default PSET contains
eight cores, one of which is core 0. This is the only core that is required to be in the default PSET.
The remaining cores in the default PSET are used by the PRM_SYS, OTHERS, Dev, Appl FSS PRM
groups. There are two databases on this system that each have four cores assigned to them. Unlike
the cores in the default PSET, the cores in the database PSET PRM groups are dedicated cores
using the HP-UX time-share scheduler. This creates isolated areas for the databases.
Table 2 Processor sets example
UseCore IDGroup NamePRM Group Type
FSS PRM groups (Default
PSET)
18Understanding how PRM manages resources
Dev, Appl
0, 1, 4, 5, 8, 9 12, 13PRM_SYS, OTHERS,
System processes, general
users, and developers
Sales database2, 3, 6, 7SalesDBPSET PRM group
Financial database10, 11, 14, 15FinanceDBPSET PRM group
What are shares?
Resource shares are the minimum amounts of a resource assigned to each PRM group in a PRM
configuration file (default name /etc/prmconf). For FSS PRM groups, you can assign CPU and real
memory shares, although only CPU share assignments are required. For PSET PRM groups, you
can only assign real memory in shares. For both types of groups, you can also specify shared
memory allocations.
In addition to minimum amounts, you can specify maximum amounts of of some resources that
PRM groups can use. For FSS PRM groups, you can specify maximum amounts of CPU and memory
resources. For PSET PRM groups, you can assign a maximum amount of memory; however, the
maximum amount of CPU resources available to the PRM group is based on the number of cores
assigned to the group. You can assign a maximum amount (known as caps) of memory to a PSET
PRM group. Shared memory allocations are static in size, so no caps are needed.
How shares work
A share is a guaranteed minimum when the system is at peak load. When the system is not at
peak load, PRM shares are not enforced—unless CPUCAPON mode is enabled, in which case CPU
shares are always enforced.
Valid values for shares are integers from one to MAXINT (the maximum integer value allowed for
the system). PRM calculates the sum of the shares, then allocates a percentage of the system resource
to each PRM group based on its shares relative to the sum.
Table 3 (page 19) shows how shares determine CPU resource percentage. The total number of
shares assigned is four. Divide each group’s number of shares by four to find that group’s CPU
resource percentage. This CPU resource percentage applies only to those cores available to FSS
PRM groups. If PSET PRM groups are configured, the cores assigned to them are no longer available
to the FSS PRM groups. In such a case, the CPU resource percentage would be based on a reduced
number of cores.
Table 3 Converting shares to percentages
CPU resource %CPU sharesPRM group
1/4 = 25.00%1GroupA
2/4 = 50.00%2GroupB
1/4 = 25.00%1OTHERS
Shares allow you to add or remove a PRM group to a configuration, or alter the distribution of
resources in an existing configuration, concentrating only on the relative proportion of resources
and not the total sum. For example, assume we add another group to our configuration in
Table 3 (page 19), giving us the new configuration in Table 4 (page 19). To give the new group
50% of the available CPU resource, we assign it four shares, the total number of shares in the old
configuration, thereby doubling the total number of shares in the new configuration.
Table 4 Altered configuration
CPU resource percentage determined by PRMCPU sharesPRM group
12.50%1GroupA
25.00%2GroupB
50.00%4GroupC
12.50%1OTHERS
How PRM controls resources19
Hierarchical PRM groups
In addition to the flat divisions of resources presented so far, you can nest FSS PRM groups inside
one another—forming a hierarchy of groups similar to a directory structure. Hierarchies allow you
to divide groups and allocate resources more intuitively than you can with flat allocations. Note
that PSET PRM groups cannot be part of a hierarchy.
When forming a hierarchy, any group that contains other groups is known as a parent group.
Naturally, the groups it contains are known as child groups. All the child groups of the same parent
group are called sibling groups. Any group that does not have child groups is called a leaf group.
There is also an implied parent group of all groups where the implied parent has 100% of the
resource to distribute.
Figure 5 (page 20) illustrates a configuration with hierarchical groups, indicating the parent, child,
sibling, and leaf PRM groups.
Figure 5 Parent, child, sibling, and leaf PRM groups
In Figure 2-1, parent groups are the Development and Development/Compilers groups.
There is also an implied parent group to the Finance, Development, and OTHERS groups. The
Development group has the children Development/Compilers, Development/Debuggers,
and Development/Profilers. The Compilers group is broken down further with two children
of its own: Development/Compilers/C and Development/Compilers/Fortran. These
two groups are also known as sibling groups. Leaf groups are groups that have no children. In
the illustration above, leaf groups include the Finance, Development/Debuggers, and OTHERS
groups, among others.
You specify resource shares for each group in a hierarchy. If a group has child groups, the parent
group’s resource shares are distributed to the children based on the shares they are assigned. If
a group has no children, it uses the shares. More explicitly, the percentage that a group’s shares
equate to is determined as follows:
1.Start at the top level in the hierarchy. Consider these groups as sibling groups with an implied
parent. This implied parent has 100% of the CPU resource to distribute. (Shares work the
same way for CPU and private memory resources.)
2.Add all the CPU shares of the first level of sibling groups together into a variable, TOTAL.
3.Each sibling group receives a percentage of CPU resources equal to its number of shares
divided by TOTAL.
20Understanding how PRM manages resources
4.If the sibling group has no child groups, it uses the CPU resources itself.
5.If the sibling group does have child groups, the CPU resource are distributed further based
on the shares assigned to the child groups. Calculate the percentages of the resource they
receive by repeating items 2 through 5.
Consider the example in Table 5 (page 21), which shows the PRM groups at the top-level.
Table 5 Hierarchical PRM groups—top level
Percent of system’s available CPU resourcesCPU sharesGroup
30.00%3Finance
50.00%5Development
20.00%2OTHERS
Table 6 (page 21) shows how the CPU resource percentages for the child groups of the Development
group are determined from their shares. It also shows how the child groups for the
Development/Compilers group further divide the CPU resources.
Table 6 Hierarchical PRM groups—Development’s child groups
Percent of system’s available CPU resourcesCPU sharesGroup
5/10 = 50.00% passed to child groups5Development
1Development/Debuggers
1Development/Profilers
2Development/Compilers
4Development/Compilers/C
4Development/Compilers/Fortran
1/4 of its parent’s CPU (50.00%) = 12.50%
of system CPU
1/4 of its parent’s CPU (50.00%) = 12.50%
of system CPU
2/4 of its parent’s CPU (50.00%) = 25.00%
passed to child groups
4/8 of its parent’s CPU (25.00%) = 12.50%
of system CPU
4/8 of its parent’s CPU (25.00%) = 12.50%
of system CPU
There is no requirement that the sum of the shares for a set of sibling groups be less than their
parent’s shares. For example, Table 6 (page 21)shows the Development/Compilers group has 2
shares, while the sum of the shares for its child groups is 8. You can assign any group any number
of shares between one and MAXINT (the system’s maximum integer value), setting the proportions
between groups as you consider appropriate.
The maximum number of leaf nodes is same as the maximum number of PRM groups you can have,
which is 64 or 256 (starting with HP-UX 11i v2 Update 2).
NOTE:Application records must assign applications only to leaf groups – not parent groups.
Similarly, user records must assign users only to leaf groups. For more information on these record
types, see “Controlling applications” (page 65) and “Specifying PRM users ” (page 71).
In group/CPU records, each PRM group—regardless of where it is in the hierarchy—must be
assigned resource shares.
Hierarchies offer a number of advantages, as explained below:
•Facilitates less intrusive changes – Similar to how shares in a flat configuration allow you to
alter one record while leaving all the others alone, hierarchies enable you to alter the hierarchy
in one area, leaving the rest unchanged.
•Enables you to use a configuration template – Create a configuration file that provides each
department access to the system, then distribute the configuration and assign resources giving
preference to certain departments on different machines.
How PRM controls resources21
•Allows continued use of percentages – If you prefer using percentages instead of shares, you
can assign each level in the hierarchy only 100 resource shares.
•Facilitates giving equal access – If you want each PRM group to have equal access to a
resource, simply assign each group the same number of shares. When you add a group, you
do not have to recalculate resources and divide by the new number of groups; just assign the
new group the same number of shares as the other groups. Similarly, removing a group does
not require a recalculation of resources; just remove the group.
•Allows for more intuitive groups – Hierarchies enable you to place similar items together, such
as all databases or a business entity/goal, and assign them resources as a single item.
•Enables making higher-level policy decisions – By placing groups in a hierarchy, you can
implement changes in policy or funding at a higher level in a configuration without affecting
all elements of the configuration.
•Facilitates system upgrades, capacity planning, and partitioning – If you are moving from a
two-core system to a four-core system, you can reserve the two additional cores by adding a
place-holder group at the top level in the hierarchy, assigning it shares equal to 50% of the
CPU resources, and enabling capping. This place-holder prevents users from getting a boost
in performance from the new cores, then being frustrated by poor performance when more
applications are added to the system.
The syntax for hierarchical groups is explained in “Group/CPU record syntax” (page 55).
By default, PRM utilities (prmconfig, prmlist, prmmonitor) include only leaf groups in their
output. Use the -h option to display information for parent groups as well.
How PRM manages CPU resources
This section describes how PRM manages CPU resources. To understand PRM’s CPU management,
it is useful to know how the standard HP-UX scheduler works.
The HP-UX scheduler chooses which process to run based on priority. Except for real-time processes,
the system dynamically adjusts the priority of a process based on resource requirements and
resources used. In general, when processes are not running, the HP-UX scheduler raises their
priorities; and while they are running, their priorities are lowered. The rate at which priority declines
during execution is linear. The rate at which priority increases while waiting is exponential, with
the rate of increase fastest when the CPU load is low and slowest when the CPU load is high.
When a process other than the current process attains a higher priority, the scheduler suspends
the current process and starts running the higher priority process.
Because the rate at which the priority increases is slowest when CPU load is high, the result is that
a process with a heavy demand for CPU time is penalized by the standard HP-UX scheduler as its
CPU resource use increases.
With PRM, you can reverse the effects of the standard scheduler. By placing users with greater
demands for CPU resources in an FSS PRM group with a higher relative number of CPU shares
than other groups, you give them a higher priority for CPU time. In a similar manner, you can
assign an application to an FSS PRM group with a higher relative number of shares. The application
will run in its assigned FSS PRM group, regardless of which user invokes it. This way you can
ensure that critical applications have enough CPU resources. You can also isolate applications
and users with greater demands for CPU resources by placing them in a PSET PRM group and
assigning the desired number of cores to the group. The applications and users will have dedicated
access to the cores in the PSET PRM group, ensuring CPU cycles when needed. This method of
isolating applications and users effectively creates a partition on your system.
PRM manages CPU resources by using the fair share scheduler (FSS) for FSS PRM groups. When
the PRM CPU manager is enabled, FSS runs for FSS PRM groups instead of the HP-UX standard
scheduler. When PSET PRM groups are configured, FSS still runs for FSS PRM groups, but the
standard HP-UX scheduler is used within PSET PRM groups.
22Understanding how PRM manages resources
PRM gives higher-priority FSS PRM groups more opportunities to use CPU time. Free CPU time is
available for use by any FSS PRM group and is divided up between FSS PRM groups based on
relative number of CPU shares. As a result, tasks are given CPU time when needed, in proportion
to their stated importance, relative to others with a demand.
PRM itself has low system overhead.
Example: PRM CPU resource management
Figure 2-2 illustrates PRM’s CPU resource management for two FSS PRM groups.
In this example, Group1 has 33 CPU shares, and Group2 has 66 CPU shares.
Note that the percentage of CPU resources referred to may not be total system CPU resources if
PSET PRM groups are configured. The percentage is of CPU resources available on the cores
assigned to the default PSET. If PSET PRM groups are not configured, then the available CPU
resources are the same as the system CPU resources.
Figure 6 PRM CPU resource management
At Time A:
•Group1 is using 40% of the available CPU resources, which is more than its share.
•Group2 is using 15% of the available CPU resources, which is less than its share.
•45% of the available CPU resource are not used.
•PRM scheduling is not in effect.
At Time B:
•Group1’s processes are now using 80% of available CPU time, which consists of all of
Group1’s shares and an unused portion of Group2’s share.
•Group2 processes continue at a steady 15%.
•PRM scheduling is not in effect.
Between Time B and Time C:
•Group2’s demands start to increase.
•With available CPU resource use approaching 100%, PRM starts to have an effect on CPU
allocation.
•Both groups’ CPU resource use begins moving toward their assigned number of shares. In this
case, the increasing demand of Group2 causes Group1 to be pulled toward the 33% mark
despite its desire for more CPU resources.
How PRM manages CPU resources23
At Time C:
•CPU resource use for Group1 and Group2 is limited to the assigned shares.
After Time C:
•PRM holds each group to its assigned available CPU resource percentage until total available
CPU resource demand is less than 100%. This gives Group2 a priority for CPU resources
over Group1. In contrast, in the standard HP-UX scheduler, CPU time is allocated based upon
the assumption that all processes are of equal importance. Assuming there is one process
associated with each PRM group, the standard HP-UX scheduler would allocate each process
50% of the available CPU resources after Time C.
CPU allocation and number of shares assigned
When managing FSS PRM groups, PRM favors processes in groups with a larger number of CPU
shares over processes in groups with fewer CPU shares. Processes in FSS PRM groups with a larger
number of CPU shares are scheduled to run more often and are given more opportunities to consume
CPU time than processes in other FSS PRM groups. This preference implies that the process in an
FSS PRM group with a larger number of shares may have better response times with PRM than
with the standard HP-UX scheduler.
An FSS PRM group can use more than its configured CPU allocation when the system is at nonpeak
load—unless CPUCAPON mode is enabled or a per-group cap equal to its allocation has been
assigned. (For more information on capping options, see the next section, “Capping CPU resource
use” (page 24).)
Capping CPU resource use
PRM gives you two options for capping CPU resource use by FSS PRM groups:
•On a per-group basis
(Available for HP-UX 11i v3 and later.) For per-group capping, use the MAX field in the FSS
PRM group record (discussed in the section “Group/CPU record syntax” (page 55) ) for only
those groups you want to cap.
•For all FSS PRM groups in the configuration
The CPUCAPON mode, enabled through the prmconfig -M option discussed below, treats
the FSS PRM group’s minimum allocation as its maximum allocation.
When CPUCAPON mode is enabled, CPU capping is in effect for all user-configured FSS PRM
groups on a system—regardless of CPU load. Each FSS PRM group takes its entire CPU
allocation. Thus, no group can obtain more CPU resources.
The PRM_SYS group, however, is exempt from capping. If it gets CPU time and has no work,
the PRM scheduler immediately goes to the next FSS PRM group.
NOTE:Capping based on the CPUCAPON mode overrides per-group capping; however, using
both forms of capping at the same time is not recommended.
For PSET PRM groups, capping is a result of the number of cores assigned to the group.
Capping CPU usage can be a good idea when migrating users and applications to a new system.
When the system is first introduced, the few users on the system may become accustomed to having
all of the machine’s resources. However, by setting CPU caps early after the system’s introduction,
you can simulate the performance of the system under heavier use. Consequently, when the system
becomes more heavily used, performance is not noticeably less. For information on capping CPU
resource use, see “Specifying PRM groups/controlling CPU resource use” (page 54).
24Understanding how PRM manages resources
How PRM manages CPU resources for real-time processes
Although PRM is designed to treat processes fairly based upon their assigned shares, PRM does
not restrict real-time processes. Real-time processes using either the POSIX.4 real-time scheduler
(rtsched) or the HP-UX real-time scheduler (rtprio) keep their assigned priorities because timely
scheduling is crucial to their operation. Hence, they are permitted to exceed their group’s CPU
share and cap. The CPU resources they use are charged to their groups. Thus, they can prevent
other processes in their groups from running.
Hyper-Threading
Hyper-Threading, available starting with HP-UX 11i v3 (B.11.31), enables you to use multiple
execution threads per core. Each execution thread is a logical CPU.
PRM supports the Hyper-Threading feature for PSET PRM groups. When PRM creates new PSETs,
they inherit the Hyper-Threading state the system had before PRM was enabled. You can override
the inherited state, specifying the desired state in the PRM configuration using the PSET_ATTR field
in group records. For more information, see the section “Group/CPU record syntax” (page 55).
PRM sets the Hyper-Threading state for the default PSET, where FSS PRM groups are created, to
optimize workload performance.
NOTE:Do not change the value of a PSET’s LCPU attribute, using either psrset or kctune,
while PRM is running.
Multiprocessors and PRM
PRM takes into account architectural differences between multiprocessor (MP) and single-processor
systems.
In the case of memory management, Hewlett-Packard multiprocessor systems share the same
physical address space. Therefore PRM memory management is the same as on a single-processor
system.
However, in the case of CPU resource management, PRM makes accommodations for MP systems.
The normal HP-UX scheduling scheme for MP systems keeps the CPU load average at a uniform
level across the cores. PRM tries to even the mix of FSS PRM groups on each available CPU. (With
Hyper-Threading disabled, each core is seen as a CPU. With Hyper-Threading enabled, each core
can be seen as multiple, logical CPUs.) This is done by assigning each process in an FSS PRM
group to a different CPU, stepping round-robin through the available CPUs, with the CPUs being
cores or logical CPUs depending on whether Hyper-Threading is enabled. Only processes that
can be run or processes that are likely to run soon are actually assigned in this manner.
For example, on a two-way MP system with Hyper-Threading disabled, FSS PRM Group1 has two
active processes A and B, and FSS PRM Group2 has two active processes C and D. In this example,
PSET PRM groups are not configured. PRM assigns process A to the first core, process B to the
second core, process C to the first core, and finally process D to the second core—as shown in
Figure 7 (page 26).
How PRM manages CPU resources25
Figure 7 PRM’s process scheduling on MP systems (Hyper-Threading disabled)
If a process is locked down on a particular core, PRM does not reassign it, but does take it into
account when distributing other processes across the cores. PRM manages the CPU resource only
for the cores on a single system; it cannot distribute processes across cores on different systems.
As implied above, PRM provides a PRM group its entitlement on a symmetric-multiprocessing (SMP)
system with Hyper-Threading disabled by granting the group its entitlement on each core. If the
group does not have at least one process for each core, PRM compensates by proportionally
increasing the PRM group’s entitlements on cores where it does have processes. For example, a
PRM group with a 10% entitlement on a 4-core system, gets 10% of each core. If the group is
running on only one core because it has only one process, the 10% entitlements from the three
unused cores are given to the group on the core where it has the process running. Thus, it gets
40% on that one core.
NOTE:A PRM group on a system with Hyper-Threading disabled may not be able to get its
entitlement because it has too few processes. For example, if the PRM group above—with only
one single-threaded process—were to have a 50% entitlement for the 4-core system, it would never
get its entitlement. PRM would give the group an entitlement of 100% on two cores. However,
because the group has only the one thread, it can use only one core—resulting in a 25% entitlement.
How PRM manages real memory resources
Memory management refers to the rules that govern real and virtual memory and allow for sharing
system resources by user and system processes.
In order to understand how PRM manages real memory (both private and shared), it is useful to
understand how PRM interacts with standard HP-UX memory management.
How HP-UX manages memory
The data and instructions of any process (a program in execution) must be available to the core
by residing in real memory at the time of execution. Real memory is shared by all processes and
the kernel.
To execute a process, the kernel executes through a per-process virtual address space that has
been mapped into real memory. Memory management allows the total size of user processes to
exceed real memory by using an approach termed demand-paged virtual memory. Virtual memory
enables you to execute a process by bringing into real memory parts of the process only as needed
and pushing out parts of a process that have not been recently used.
26Understanding how PRM manages resources
The system uses a combination of paging and swapping to manage virtual memory. Paging involves
writing unreferenced pages from real memory to disk periodically.
Swapping takes place if the system is unable to maintain a large enough free pool of memory. In
such a case, entire processes are swapped. The pages associated with these processes can be
written out by the pager to secondary storage over a period of time.
The more real memory a system has available, the more data it can access and the more (or larger)
processes it can execute without having to page or cause swapping.
Available memory
A portion of real memory is always reserved for the kernel (/stand/vmunix) and its data structures,
which are dynamically allocated. In addition, memory is reserved for nonkernel system processes.
The amount of real memory that remains is available for user processes. This memory is known as
available memory and is the memory amount reported by prmavail. Available memory varies
over time. Because the size of the kernel varies depending on the number of interface cards, users,
and values of the tunable parameters, available memory varies from system to system.
For example, Table 7 (page 27) shows a system with 1024 Mbytes of physical memory.
Approximately 112 Mbytes of that memory is used by the kernel and its data structures, leaving
912 Mbytes of memory available for all processes, including system processes. In this example,
62 Mbytes are used by system processes, leaving 850 Mbytes of memory available for user
processes. PRM reserves 11% of the remaining memory in the example to ensure processes in
PRM_SYS have immediate access to needed memory. Although you cannot initially allocate this
reserve to your PRM groups, it is still available for your PRM groups to borrow from when needed.
So, in this example, the prmavail command would show 850 Mbytes of available memory before
PRM is configured, and 756 Mbytes of available memory after PRM is configured.
Table 7 Example of available memory on a 1024-Mbyte system
How PRM controls memory usage
PRM memory management allows you to prioritize how available memory is allocated to user and
application processes. This control enables you to ensure that critical users and applications have
enough real memory to make full use of their CPU time.
When PRM first starts and is configuring memory management, the PRM_SYS group (PRMID 0) is
in control of all usable memory on the system. The memory not needed by processes in PRM_SYS,
known as available memory, is the memory reported by prmavail. This remaining memory is
allocated to the other PRM groups, according to their entitlements. The amount of available memory
may fluctuate up or down based on the needs of the kernel, buffer cache, daemons, and other
processes in PRM_SYS.
PRM’s memory management is controlled by the daemon prm2d. This daemon uses an in-kernel
memory feature to partition memory (when a configuration is loaded), with each PRM group getting
a partition. Each partition includes x Mbytes of memory, where x Mbytes is equivalent to the
group’s entitled percent of the available memory or the requested, fixed-size shared memory
allocation. Each partition pages separately.
When system memory use is not at 100%, a PRM group that does not have its memory use capped
or isolated can freely borrow excess memory pages from other PRM groups. If a process requires
Memory typeMbyte
Physical memory available on the system1024
Memory available for all processes912
Memory available for user processes850
Memory available after PRM is configured756
How PRM manages real memory resources27
memory and its memory use is capped, processes in the same PRM group as the original process
are forced to page to free up memory.
When system memory use is at 100%, borrowed memory pages are returned to the owning PRM
groups if needed. The time involved for the borrowed memory pages to be returned is dependent
on the swap rate and the order in which old pages are paged out.
If a group is exceeding its memory shares on a system that is paging, prm2d uses proportional
overachievement logic. Overachievement for a group is the ratio of memory used to memory
entitlement. This value is then compared to the average overachievement of all groups. If a PRM
group is overachieving compared to the average, then the number of import pages for that group
is reduced. This allows other groups to start importing the newly available memory.
Groups are not allowed to exceed their memory caps.
NOTE:When an initial configuration requesting memory management is loaded (after installing
or resetting PRM), PRM initializes memory resource groups (MRGs) giving all usable memory to
PRM_SYS initially. Any free memory is then distributed to other PRM groups. This distribution of
memory for use by your PRM groups can be affected by:
•Heavy paging or swapping
•A single application using over half the lockable memory on the system
Such conditions may exist if memory-intensive applications start immediately after PRM is
configured—as may be the case with applications starting automatically at reboot.
You can possibly avoid these issues by:
•Starting these applications in their designated PRM groups with the prmrun command
•Using the PRM_SLEEP variable in your /etc/rc.config.d/prm file so that the application
manager and memory manager can place processes in their configured groups before the
heavy demand begins.
Reducing memory shares
If a PRM group’s memory share is reduced while the group is using most of its memory pages, the
reduction is not immediately visible. The memory must be paged out to the swap device. The time
involved for the reduction to take effect is determined by the memory transfer rate (for example, 2
Mbytes/second), and the order in which the old pages are paged out.
Therefore, when changing shares, give them time to take effect before implementing new shares
again.
Capping memory use
You can optionally specify a memory cap for a PRM group. This cap is a hard upper bound: a
PRM group cannot exceed its memory cap. Typically, you might choose to assign a memory cap
to a PRM group of relatively low priority, so that it does not place excessive memory demands on
the system. For information on setting a memory cap, see “Controlling memory use” (page 59) .
Implementation of shares and caps
In addition to specifying memory shares (a lower bound) for private memory, you can optionally
specify a memory cap (upper bound) for a PRM group.
It is important to note the difference between memory shares and a memory cap. Shares guarantee
the minimum amount of real memory that a group is allowed to consume at times of peak system
load. The memory cap is an upper bound.
28Understanding how PRM manages resources
Isolating a group’s private memory resources
In addition to specifying private memory shares, the prm2d memory manager allows you to
optionally specify a group’s private memory resources to be restricted from use by other groups
and processes on the system. This type of restriction is called memory isolation.
When a group’s memory shares are isolated, those memory shares cannot be loaned out to other
groups. Memory isolation also means that memory cannot be borrowed from other groups.
PRM allows groups that do not have memory isolation enabled to freely borrow memory from other
groups as needed. The lending groups are restricted in their giving by their physical entitlement
size. A group cannot lend its memory resources if memory isolation is enabled.
Memory isolation can be useful for applications that need dedicated memory resources, or that
tune their own memory needs based on their fixed allocation of resources.
How PRM manages shared memory
By default, all shared memory is allocated in the PRM_SYS group.
Starting with HP-UX 11i v2 Update 2 and PRM C.03.01, PRM can control shared memory allocations
on a PRM group basis. You only control shared memory for the groups that need it—you can omit
control for groups where shared memory control would not be helpful.
PRM does not allow borrowing or lending of shared memory as it is not beneficial. Similarly,
capping is not available for shared memory. You set a minimum size in megabytes for a group’s
shared memory allocation. (This allocation size is usually available from the configuration settings
for the consuming application, as is the case with the Oracle SGA size.)
How PRM manages locked memory
Real memory that can be locked (that is, its pages kept in memory for the lifetime of a process) by
the kernel, by the plock() system call, or by the mlock() system call, is known as lockable
memory.
Locked memory cannot be paged or swapped out. Typically, locked real memory holds frequently
accessed programs or data structures, such as critical sections of application code. Keeping them
memory-resident improves system performance. Lockable memory is extensively used in real-time
environments, like hospitals, where some processes require immediate response and must be
constantly available.
Locked memory is distributed based on the assigned memory shares. For example, assume a system
has 200 Mbytes of available memory, 170 Mbytes of which is lockable. Lockable memory divided
by available memory is 85%. If GroupA has a 50% memory share, it gets 100 Mbytes of real
memory. Of that amount, 85% (or 85 Mbytes) is lockable. Notice that 85 Mbytes/170 Mbytes is
50%, which is the group’s memory share. Figure 8 (page 30) illustrates this idea.
How PRM manages real memory resources29
Figure 8 Locked memory distribution
Example: memory management
This example shows how the PRM memory manager prm2d manages the competing memory
demands of three PRM groups as system memory utilization approaches 100%.
Figure 9 Memory management
At Time A:
•There is plenty of memory available on the system for the processes that are running.
•Group1 is using its share, and Group2 is using slightly more than its share, borrowing excess