How to put an application under WLM control

Application records: Workload separation by binary name

One mechanism for separating workloads is the apps statement. This statement simply names a particular application binary and the group in which it should be placed. You can specify multiple binary-workload group combinations, separated by commas, in a single apps statement.

In the following prm structure, the apps statement causes the PRM application manager to place any newly running /opt/hpws/apache/bin/httpd executables in the group apache_grp.

prm {
    groups = OTHERS : 1,
         servers_grp : 2,
         apache_grp : 3;
 
    apps = apache_grp : /opt/hpws/apache/bin/httpd;
}

For more information on setting up application records, see “Assigning applications to workload groups (optional)”.

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

User records: Workload separation by process owner UID

You can place processes in workload groups according to the UIDs of the process owners. You specify your user-workload group mapping in the users statement. Here is an example:

prm {
    groups = OTHERS : 1,
             testers : 2,
             coders : 3,
             surfers : 4;
 
    users = moe : coders surfers,
            curly : coders surfers,
            larry : testers surfers;
}

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

Unix group records: Workload separation by Unix group ID

You can place processes in workload groups according to the Unix groups the processes run in. You specify your Unix group-workload group mapping in the uxgrp statement. Here is an example:

prm {
    groups = OTHERS : 1,
             testers : 2,
             coders : 3,
             surfers : 4;
 
    uxgrp = sports : surfers,
            shoes : coders,
            appliances : testers;
}

Besides the default OTHERS group, this example has the three workload groups testers, coders, and surfers. The Unix group records cause processes running in Unix group sports to be placed in workload group surfers, while processes running in Unix group shoes are placed in workload group coders, and processes in Unix group appliances are placed in workload group testers. Processes not running in any of the specified Unix groups are placed in OTHERS by default.

WLM supports Unix group records only if PRM C.03.02 or later is running on the system. For more information on setting up Unix group records, see “Assigning Unix groups to workload groups (optional)”.

Secure compartments: Workload separation by secure compartment

You can place processes in workload groups according to the secure compartments the processes run in. The HP-UX feature Security Containment, available starting with HP-UX 11i v2, allows you to create secure compartments. You specify your mapping between secure compartments and workload groups in the scomp statement. Here is an example:

prm {
    groups = OTHERS : 1,
             database : 2,
             webapp : 3;
 
    scomp = db_comp : database,
            wa_comp : webapp;
}

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

Process maps: Workload separation using your own criteria

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

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

prm {
    groups = OTHERS : 1,
         sales : 2,
         mrktg : 3;
 
    procmap = sales : 
               /bin/env /UNIX95= /bin/ps -C pid_app -o pid=,
              mrktg : /scratch/pidsbyapp mrketpid_app;
}

For more information on setting up process maps, see “Specifying process maps to define your own criteria for workload separation (optional)”.

prmrun: Starting a process in a workload group

You can explicitly start processes in particular workload groups using the prmrun command. Given the groups and users statements shown in “User records: Workload separation by process owner UID”, user larry running the following command would cause his job to be run in group testers:

# my_really_big_job &

However, user larry also has permission to run processes in the group surfers. Thus, larry can use the following prmrun command to run his process in the group surfers:

# /opt/prm/bin/prmrun -g surfers my_really_big_job &

prmmove: Moving an existing process to a workload group

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

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

Default: Inheriting workload group of parent process

If a process is not named in an apps statement, a users statement, a uxgrp statement, or an scomp statement, or if it is not identified by a procmap statement, or has not been started with prmrun or moved with prmmove, it simply starts and runs in the same group as its parent process. So for a setup like the following example, if user jdoe has an interactive shell running in group mygrp, any process spawned by that shell process would also run in group mygrp because its parent process was there.

prm {
    groups = OTHERS : 1,
             mygrp : 2;
}

Simple inheritance is the mechanism that determines where most processes run, especially for short-lived processes.