WLM offers commands that allow system administrators to:
Several methods exist for classifying a process, and all operate concurrently. A top-down strictest first-matching algorithm is used to provide for maximum configuration flexibility. You can organize process groupings by user with special cases for programs with certain names, by pathname with special cases for certain users, or any other arrangement.
The following is an example of a top-level rules file for the configuration Config (/etc/wlm/Config/rules file):
* This file contains the rules used by WLM to * assign a process to a superclass * * class resvd user group application type tag db1 - - - /usr/bin/oracle* _DB1 db2 - - - /usr/bin/oracle* _DB2 devlt - - dev - - - VPs - bob,ted - - - - acctg - - acct* - - - System - root - - - - Default - - - - - -
The following is an example of the rules file for the devlt superclass in the /etc/wlm/Config/devlt/rules file:
* This file contains the rules used by WLM to * assign a process to a subclass of the * superclass devlt * * class resvd user group application type tag hackers - jim,liz - - - - hogs - - - - 64bit+plock - editors - !sue - /bin/vi,/bin/emacs - - build - - - /bin/make,/bin/cc - - Default - - - - - -
The following are examples using this rules file. The following examples assume that the superclasses and subclasses described do not have the inheritance attribute set to yes. If inheritance were enabled, new processes would inherit the superclass or subclass from their parent processes.
Assume classes A, B, C, and D have shares of 3, 2, 1,
and 1 respectively. If classes A, C, and D are active, the calculated targets
would be:
target(A) = 3/5 = 60%
target(C) = 1/5 = 20%
target(D) = 1/5 = 20%
If during testing it was found that the applications
in class A perform adequately when allowed to use 50% of the resource, it
might be desirable to make the other 50% of the resource available to the
other classes. This can be accomplished by giving class A a soft maximum
of 50% for this resource. Since the current calculated target of 60% is over
this limit, it will be adjusted down to the soft maximum value. When this
happens, the target or actual consumption (whichever is lower) of class A
is subtracted from the amount of resource available. Since this class now
has a target constrained by its limit (and not its shares), the shares for
the class are also subtracted from the number of active shares. Assuming
class A has a current consumption of 48%, the targets will now be:
target(A) = 3/5 = 60%, softmax = 50, = 50%
target(C) = 1/2 * (100 - 48) = 26%
target(D) = 1/2 * (100 - 48) = 26%
Some time later, all classes
may become active, and the targets will again be automatically adjusted:
target(A) = 3/7 = 42%
target(B) = 2/7 = 28%
target(C) = 1/7 = 14%
target(D) = 1/7 = 14%
The following example examines CPU allocation, assuming that each class can consume all the CPU that it is given.
Two classes, A and B, are in the same tier. CPU limits for A are [30% - 100%]. CPU limits for B are [20% - 100%]. When both classes are running and are using sufficient CPU, WLM first makes sure that they both get their minimum percentages of each second (averaged over several seconds). Then WLM distributes the remaining CPU cycles according to any CPU target share values.
If the CPU target shares for A and B are 60% and 40% respectively, then the CPU utilization for A and B stabilize at 60% and 40% respectively.
A third class, C, is added. This class is a group of CPU-bound jobs and should run with about half (or more) of the available CPU. Class C has limits of [20% - 100%] and CPU target shares of 100%. If C is in the same tier as A and B, then when C is starting, A and B see their CPU allocation decrease steeply and the three classes stabilize at 30%, 20% and 50%, respectively. Their targets in this case are also the minimum for A and B.
A system administrator might not want batch jobs to consume 50% of the CPU when other jobs, possibly of higher priority, are also running. In a situation like the previous example, C is placed in a lower priority tier. C then receives whatever CPU remains after A and B receive their needs. In the above example, C receives no CPU time, because A and B are each capable of absorbing 100% of the CPU. In most situations, however, A and B, in a high-priority tier, are composed of interactive or transaction-oriented jobs, which do not use all of the CPU all of the time. C then receives some share of the CPU, for which it competes with other classes in the same or lower tiers.
The following example examines memory allocation to groups of processes with varying memory targets. Three groups of processes must run: a group of interactive processes that need to run whenever they are used (PEOPLE), a batch job that always runs in the background (BATCH1), and a second, more important batch job, that runs every night (BATCH0).
PEOPLE has a specified memory minimum of 20%, a memory target of 50 shares, and a class tier value of 1. A 20% minimum limit ensures that the desktop applications in this class resume fairly quickly when users touch their keyboards.
BATCH1 has a memory minimum of 50%, a memory target of 50 shares, and a tier value of 3.
BATCH0 has a memory minimum of 80%, a memory target of 50 shares, and a tier value of 2.
Classes PEOPLE and BATCH1 have a total memory minimum limit of 70. Under normal operation (when BATCH0 is not running), both of these classes are allowed to get all of their reserved memory. They share the rest of the memory in the machine about half and half, even though they are in different tiers. At midnight when BATCH0 is started, the memory minimum total reaches 150. WLM ignores the minimum requirements for the lowest tiers until processes in the upper tiers exit. BATCH0 takes memory from the BATCH1 50% reserve, but not from the PEOPLE 20% reserve. After BATCH0 is done, memory reserves for tier 3 processes are honored again and the system returns to its normal memory balance.
When starting WLM with configurations created with versions earlier than AIX 5.1, only superclasses are used. The default output of the wlmstat command lists only the superclasses and is similar to those of previous versions. For example:
# wlmstat
CLASS CPU MEM DKIO
Unclassified 0 0 0
Unmanaged 0 0 0
Default 0 0 0
Shared 0 2 0
System 2 12 0
class1 0 0 0
class2 0 0 0
#
If some of the superclasses have subclasses defined by a WLM administrator, then the subclasses are listed. For example:
# wlmstat
CLASS CPU MEM DKIO
Unclassified 0 0 0
Unmanaged 0 0 0
Default 0 0 0
Shared 0 2 0
System 3 11 7
class1 46 0 0
class1.Default 28 0 0
class1.Shared 0 0 0
class1.sub1 18 0 0
class2 48 0 0
#
The output is the same when you use the ps command. For processes in a superclass without any subclasses, the ps command lists the superclass name as the process class name.