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.
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 System Default Shared
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.
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:
System Default Shared super1 super2 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.
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.
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:
PID PPID USER CLASS PRI COMMAND
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:
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 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:
wlmstat
The output 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 21 0 0
The programs testXX are CPU loops, so memory and disk I/O have no output.
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:
System Default Shared super1 super2 super2.Default super2.Shared super2.sub1 super2.sub2 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.
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:
wlmstat
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
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: