[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]

System Management Guide: Operating System and Devices

Getting Started With Workload Manager

This example shows the different steps involved in creating and starting a new WLM configuration. It does not discuss how to determine the values of the shares and limits best suited for your set of business goals. Setting these values is system-, application-, and business-dependent and must be done on a case-by-case basis. WLM Concepts provides tips on how to determine the classification and resource control parameters.

The steps in the following example are completed using the WLM command-line interface. For each step, brief instructions describe how to complete each step using SMIT or the Web-based System Manager.

Step 1: Create the Configuration

Managing WLM configuration and administering the superclasses requires root authority. The first few steps are completed as root user. For more information on root authority, see WLM Concepts.

The easiest way to create a new configuration is by duplicating an existing configuration and then modifying the properties of the new configuration. WLM provides a sample configuration, called template, that defines the predefined superclasses Default, System, and Shared.

Create a new configuration, new_config, by first creating the /etc/wlm/new_config directory and then copying the files from the /etc/wlm/template directory:

Note: You must be logged in as root user to perform this task.

cd /etc/wlm
cp -pr /etc/wlm/template new_config

Verify that the new_config directory is owned by the root user, has read, write, and execute permission only for owner, and has read and execute permission for group and other. For example:

ls -l /etc/wlm/new_config
total 40
-rw-r--r--   1 root    system       423 Jun 29 14:16 classes
-rw-r--r--   1 root    system        55 Jun 29 14:16 description
-rw-r--r--   1 root    system       430 Jun 29 14:16 limits
-rw-r--r--   1 root    system       496 Jun 29 14:16 rules
-rw-r--r--   1 root    system       404 Jun 29 14:16 shares


lsclass -d new_config

The newly created configuration has a set of WLM property files describing the predefined superclasses System, Default, and Shared. Use a text editor to modify description to reflect the new configuration.

Using SMIT, for instance, to do the same thing, go to the Workload Manager's main menu (type wlm on the command line or from the SMIT main menu, select Performance & Resource Scheduling and then Workload Management). Then, select Work on alternate configurations and go to Copy a configuration. Provide template as the name of the configuration to copy and new_config as the name of the new configuration, and press the Enter key.

To continue working on the new configuration, go back to the Configurations menu, and select Select a configuration. Enter or select new_config as the configuration name, and press the Enter key. From this point on, the default configuration for your SMIT WLM session is new_config until you select another configuration from the Select a configuration menu, or until you exit SMIT. If you do not select a configuration, you will be working on the current configuration with the directory tree pointed to by /etc/wlm/current.

Using Web-based System Manager, you must also select the configuration whenever you work on a configuration other than current.

Step 2: Create Your Superclasses

Now create two superclasses with a basic set of attributes and show the delegated administration of subclasses.

For example, as root user, type the following on the command line:

mkclass -a inheritance=yes -a tier=1 -c shares=1 -m shares=1 \
-d new_config super1

This command creates a superclass named super1 in the configuration new_config in superclass tier 1 with the inheritance attribute set to yes. super1 is assigned one share of CPU and one share of memory. All the other attributes, resource entitlements, and limits are set to their default value. For additional information, see WLM Concepts.

To create another superclass, super2, in tier 1 with two shares of CPU and three shares of memory and delegate the administration of its subclasses to the user wlmu0, type the following on the command line:

mkclass -a tier=1 -a adminuser=wlmu0 -c shares=2 -m shares=3 \
     -d new_config super2

Type the following on the command line to verify the settings:

lsclass -d new_config

The results should read:

root #

In this example, the two user-defined superclasses are added to three predefined superclasses created in Step 1.

To create the same superclasses in SMIT, select the configuration in Step 1, use the Add a class submenu to create super1. This menu allows you to create the superclass and set up the general characteristics of the class (attributes description, inheritance, tier, authuser/authgroup, adminuser/admingroup, and rset). Then from the Change/Show Characteristics of a class menu, selectresource management (CPU, memory, and disk I/O) to set up the entitlements listed above.

Repeat these steps for super2. Web-based System Manager requires similar steps.

Step 3: Create Superclass Assignment Rules

Now create a set of assignment rules to assign processes to these superclasses.

There is no command-line interface to add, modify, or delete assignment rules. Use SMIT or Web-based System Manager to modify assignment rules. With SMIT with the configuration still active, select Class assignment rules -> List all Rules to see what is already in the file, then Create a new Rule for each rule that you want to create.

After creating the two rules, type the following on the command line to verify the results:

cat /etc/wlm/new_config/rules

The results should be similar to the following:

* class resvd user       group application  type  tag
super1   -    wlmu[3-6]    -       -         -     -
super2   -    wlmu[0-2]    -       -         -     -
System   -    root         -       -         -     -
Default  -    -            -       -         -     -

The new rules assign all processes with a real user ID of wlmu3, wlmu4, wlmu5, or wlmu6 to super1, and the processes with a real user ID of wlmu0, wlmu1, or wlmu2 to super2.

WLM matches processes by comparing them to the rules in the order that they appear in the file and then assigns the process to the class corresponding to the first rule that is matched. In the preceding example, a process with a real user ID of wlmu1 will be assigned to super2.

When we added our rules, the rules file already contained the assignment rules for the System and Default predefined superclasses.

If the same process used a real user ID of wlmu1, it would be assigned to the Default superclass.

Step 4: Start Workload Manager

All steps up to this point modified WLM property files. Even if we had been working on the current configuration and if WLM was already started, the new classes would not exist in the WLM kernel data structures and the new rules would not be available to the operating system.

The new configuration or changes to the current configuration are loaded into the WLM kernel data structures when WLM is started or when WLM is updated or refreshed. Then WLM starts classifying processes and managing resources according to the rules and policies defined in the new current configuration.

The wlmcntrl command does extensive processing on the WLM configuration files before handing the data down to the kernel. The wlmcntrl command processes the wildcards and pattern-matching characters in the user name, group name, and application file name fields of the rules file. In the case of the rule for superclass2, for instance, we specified wlmu[0-2]. The wlmcntrl command would expand the list to wlmu0, wlmu1, and wlmu2, and pass the corresponding UIDs, for instance 221, 222, and 223, to the kernel. This is also true for any specified group names. For application file path names, wlmcntrl also handles wildcard expansion to build a list of names. After that, prior to passing the data to the kernel, it would try to access every file and get an identification of each file in a format easier to manage by the kernel.

In the following example, WLM is not running. Start WLM on the new configuration using the wlmcntrl command, by typing the following on the command line:

wlmcntrl -d new_config
wlmcntrl -q

The following message appears on the command line:

WLM is running

All existing processes are classified according to the rules defined above. To see how the processes are classified, use the ps command as follows:

ps -e -o pid,ppid,user,class,pri,args

The output should be similar to the following:

    1     0    root System        83 /etc/init
 8634  9860    root System        83 /usr/sbin/inetd
 8958  9860    root System        83 /usr/sbin/hostmibd
 9332     1    root System        83 /usr/sbin/syncd 60
 9606     1    root System        83 /usr/lib/errdemon
 9860     1    root System        83 /usr/sbin/srcmstr
10180  9860    root System        83 /usr/sbin/portmap
11376  9860    root System        83 /usr/sbin/snmpd
11962  9860    root System        83 /usr/sbin/biod 6
12208  9860    root System        83 /usr/sbin/syslogd
12408  9860    root System        83 sendmail: rejecting connections on port
12768     1    wlmu0 super2      159 /tmp/test12
12942  9860    root System        83 /usr/sbin/dpid2
13158     1    root System        83 /usr/ccs/bin/shlap
13432  9860    root System        83 /usr/sbin/rpc.lockd
13682  9860    daemon Default     60 /usr/sbin/rpc.statd
13942     1    root System        83 -ksh
14198     1    root System        83 /usr/sbin/cron
14456     1    root System        83 /usr/sbin/uprintfd
14730  9860    root System        83 /usr/sbin/writesrv
15004  9860    root System        83 /usr/sbin/qdaemon
15224     1    root System        83 /usr/bin/AIXPowerMgtDaemon
15742     1    root System        83 /usr/sbin/getty /dev/tty1
16256     1    root System        83 /usr/lpp/diagnostics/bin/diagd
16788     1    wlmu1 super2      159 /tmp/test14
17062     1    wlmu0 super2      159 /tmp/test2
17802     1    wlmu1 super2      159 /tmp/test15
18318     1    wlmu2 super2      159 /tmp/test19
18834     1    wlmu3 super1      235 /tmp/test9
19350     1    wlmu3 super1      235 /tmp/test0
19866     1    wlmu3 super1      235 /tmp/test1
20382     1    wlmu4 super1      235 /tmp/test11
20898     1    wlmu4 super1      235 /tmp/test4
21414     1    wlmu5 super1      235 /tmp/test7
21930     1    wlmu6 super1      235 /tmp/test7
22446     1    wlmu6 super1      235 /tmp/test17
22962     1    wlmu10 Default     85 /tmp/test17
23478     1    wlmu10 Default     85 /tmp/test8
23750 13942    root System        84 ps -e -o pid,ppid,user,class,pri,args

In the above output, processes are assigned according to the following:

The -c flag for the ps command displays all processes for a given class. To list all the processes that belong to the superclass super1, type the following on the command line:

ps -l -c super1

The output should look similar to the following:

240001 A 224 18834    1  84 235 20 3402ed    68              0  7:24 test9
240001 A 224 19350    1  85 235 20 3c02ef    68              0  7:19 test0
240001 A 224 19866    1  85 235 20 4402f1    68              0  7:15 test1
240001 A 223 20382    1  84 235 20 4c02f3    68              0  7:07 test11
240001 A 223 20898    1  85 235 20 5402f5    68              0  6:58 test4
240001 A 222 21414    1  85 235 20 5c02f7    68              0  6:42 test7
240001 A 221 21930    1  84 235 20 6402f9    68              0  6:14 test7
240001 A 221 22446    1  85 235 20 6c02fb    68              0  6:05 test17

With WLM running, use the wlmstat command to list the per-class resource utilization statistics:


The output should look similar to the following:

Unclassified   0   0   0
   Unmanaged   0   0   0
     Default   8   0   0
      Shared   0   0   0
      System   0   0   0
      super1  33   0   0
      super2  21   0   0

The programs testXX are CPU loops, so memory and disk I/O have no output.

Step 5: Create and Manage Subclasses

Up to this point, all steps were done as root user. Only root can create a new configuration, create and manage superclasses, start and stop WLM, switch between active and passive mode, and change the current configuration.

When creating a superclass for a given configuration, the system administrator working as root user can delegate the authority to create and manage subclasses to a user or group and refresh the WLM kernel data pertaining to the subclasses managed.

For superclass super2, this authority has been delegated to user wlmu0 (attribute adminuser of the superclass super1 of the configuration new_config).

Log in as wlmu0 and type the following on the command line:

mkclass -a tier=0 -a authuser=wlmu2 -c shares=10 -d new_config -S super2 sub1

This command creates a subclass of superclass super2 named sub1, in subclass tier 0, with ten shares of CPU and gives user wlmu2 the authority to manually assign processes to super2.sub1.

Note: super2.sub1 is the fully qualified name of the subclass and uniquely identifies the subclass for a given configuration. Subclasses in different superclasses can have the same short name.

To create the subclass super2.sub1 in tier 3, with 20 shares of CPU, type the following on the command line:

mkclass -a tier=3 -c shares=20 -d new_config -S super2 sub2

For superclasses, all the attributes, resource entitlements, and limits not explicitly specified are assigned the system default value.

The major differences between superclasses and subclasses are in the scope of the resource entitlements and limits:

To verify what has been defined up to this point, type the following on the command line:

lsclass -d new_config -r

The output should look similar to the following:

wlmu0 $

Use the -r flag of the lsclass command to list both superclasses and subclasses.

To create subclasses using SMIT, first set the focus on the superclass with which you want to work. To do this, select the Work on alternate configurations/Select a configuration menu. Select new_config -> Work on a set of Subclasses, then select the superclass super2. At any point during your SMIT session, you can verify which configuration or superclass you are working with by selecting the Show current focus menu. Web-based System Manager has similar options and requirements.

After you select the desired configuration and superclass, create the subclasses using the same Add a class and Change/Show Characteristics of a class menus used for superclasses.

Note: The WLM configuration new_config is the active configuration pointed to by /etc/wlm/current, so you do not need to select new_config in SMIT (or Web-based System Manager). It is, however, good practice to always select the configuration you wish to work with whenever you have several WLM configurations in /etc/wlm. If the system administrator or a cron-initiated script switches the WLM configuration in the middle of your SMIT or Web-based System Manager session, you might end up with part of your changes in one configuration and the rest in another configuration.

As with the superclasses, for processes to be assigned to one of the new subclasses, a set of assignment rules must be provided.

Step 6: Create Subclass Assignment Rules

Use either SMIT or the Web-based System Manager to create subclass assignment rules. First, set the appropriate focus by selecting new_config and super2. The assignment rules for subclasses use the same process attributes and have the same format. Here are the rules we have entered:

cat /etc/wlm/new_config/super2/rules
* class resvd user group application type tag
sub1 - wlmu1
sub2 - wlmu2

The automatic assignment works by comparing a process attribute against the values in the superclass assignment rules file for the active (current) configuration to determine in which superclass the process will be assigned. Then, if there are subclasses, the process attributes are compared against the values in the subclasses rules file to determine the subclass.

For a subclass rule to be effective, it must be compatible with its superclass's rules. For example, in our case, according to the superclass rules, a process is assigned to super2 if its real UID is wlmu0, wlmu1, or wlmu2.

If we had decided that a process of this superclass would be assigned to a given subclass when its real UID is wlmu5, no process assigned to super2 would satisfy this condition. This subclass would therefore remain empty.

Now that the subclass definitions and the corresponding assignment rules are created, you can activate the new subclasses. Recall that the changes take place only in the configuration files. The new classes do not become active until the changes are communicated to the kernel.

To view the WLM statistics at this point, type the following on the command line:


Notice in the following example output that the subclasses are not yet displayed.

           CLASS CPU MEM BIO
    Unclassified   0   0   0
       Unmanaged   0   0   0
         Default   8   0   0
          Shared   0   0   0
          System   0   0   0
          super1  33   0   0
          super2  21   0   0

Step 7: Update WLM

The wlmcntrl command passes the class definitions to the kernel. With WLM already active, you can update the WLM kernel data structures using the -u flag. In addition, as a superclass administrator, you can only update the data corresponding to the subclasses of this superclass. Because you are not logged in as root user, the wlmcntrl command does not start or stop WLM, or load a new configuration, so a superclass administrator cannot affect other superclasses.

To update the superclass, type the following on the command line:

wlmcntrl -u -S super2

To view the updated WLM kernel data structures with the new subclasses, type the following on the command line:

wlmstat -a

The output should be similar to the following:

           CLASS CPU MEM BIO
    Unclassified   0   0   0
       Unmanaged   0   0   0
         Default   8   0   0
          Shared   0   0   0
          System   0   0   0
          super1  33   0   0
          super2  19   0   0
super2.Default    12   0   0
 super2.Shared     0   0   0
   super2.sub1     5   0   0
   super2.sub2     2   0   0

Using the -a flag displays the subclass resource usage as a percentage of the total system resources. In this case, the combined processes in super2 consume 19% of the CPU time and these 19% are decomposed in 12% in the Default subclass, 5% in sub1, and 2% in sub2. Without the -a flag, the percentage shown for the subclasses is a percentage of the resource consumed by the superclass. To view the resource consumed as a percentage of superclass, type wlmstat on the command line and press the Enter key. The result should look similar to the following:

           CLASS CPU MEM BIO
    Unclassified   0   0   0
       Unmanaged   0   0   0
         Default   8   0   0
          Shared   0   0   0
          System   0   0   0
          super1  33   0   0
          super2  19   0   0
super2.Default    63   0   0
 super2.Shared     0   0   0
   super2.sub1    26   0   0
   super2.sub2    11   0   0

This output shows that Default subclass accounts for 63% of the CPU consumed by the superclass, sub1 for 26%, and sub2 for 11%. Recall that the shares and limits for a subclass are relative to the superclass entitlements and not to the total amount of the resource available on the system.

To view the ps output now that the subclasses are active, type the following on the command line:

ps -e -o pid,ppid,user,class,pri,args | grep super2

The output should be similar to the following:

12768     1   wlmu0 super2.Default 170 /tmp/test12 
16788     1   wlmu1 super2.sub1    159 /tmp/test14 
17062     1   wlmu0 super2.Default 170 /tmp/test2
17802     1   wlmu1 super2.sub1    159 /tmp/test15
18318     1   wlmu2 super2.sub2    207 /tmp/test19
23782 13942   wlmu0 super2.Default 168 -ksh
24032 23782   wlmu0 super2.Default 168 grep super2
25040 23782   wlmu0 super2.Default 169 ps -e -o pid,ppid,user,class,pri,args

Examine the WLM property files that we have just created in the /etc/wlm/new_config directory:

-rw-r--r-- 1 root   system  112 Jul  2 17:56   classes
-rw-r--r-- 1 root   system   55 Jun 29 14:16   description
-rw-r--r-- 1 root   system   31 Jun 29 16:35   limits
-rw-r--r-- 1 root   system  544 Jun 29 14:27   rules
-rw-r--r-- 1 root   system   78 Jun 29 16:35   shares
drwxr-xr-x 2 wlmu0  system  512 Jun 29 15:20   super2
-rw-r--r-- 1 wlmu0  staff    72 Jun 29 14:57   super2/rules
-rw-r--r-- 1 wlmu0  staff     0 Jun 29 14:55   super2/limits
-rw-r--r-- 1 wlmu0  staff    40 Jun 29 14:55   super2/shares
-rw-r--r-- 1 wlmu0  staff    98 Jun 29 14:55   super2/classes

Directly under /etc/wlm/new_config, the WLM property files for the superclasses have write permission only for root user. Under /etc/wlm/new_config/super2, the WLM property files for the subclasses of the superclass super2 have write permission for wlmu0. This is expected because wlmu0 was designated as superclass administrator for super2. The owner and permissions would be the same if root user had created the subclasses. If the system administrator had designated a group as superclass administrator using the class attribute admingroup, then the group ID for the files would be set accordingly and the files would have write permission for the group. This can become complex when the system administrator changes a superclass administrator (by changing adminuser, for instance), but the chclass command changes the file ownership and permission automatically.

After you have created your first test configuration, you can experiment with the passive and active modes of WLM, change shares, and set limits. Examine how the system reacts using thewlmstat command and experiment with other features of WLM, such as the manual assignment of processes.

SMIT, Web-based System Manager, and the command line interfaces all perform the steps necessary to manage WLM configurations. Functions of WLM that are not supported by all three interfaces include:

[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]