Workload Manager (WLM) is designed to provide the system administrator with increased control over how the scheduler virtual memory manager (VMM) and the disk I/O subsystem allocate resources to processes. You can use WLM to prevent different classes of jobs from interfering with each other and to allocate resources based on the requirements of different groups of users.
WLM is primarily intended for use with large systems. Large systems are often used for server consolidation, in which workloads from many different server systems (such as printer, database, general user, and transaction processing systems) are combined into a single large system to reduce the cost of system maintenance. These workloads often interfere with each other and have different goals and service agreements.
WLM also provides isolation between user communities with very different system behaviors. This can prevent effective starvation of workloads with certain behaviors (for example, interactive or low CPU usage jobs) by workloads with other behaviors (for example, batch or high memory usage jobs).
Also, WLM ties into the accounting subsystem (see Accounting Overview) allowing users to do resource usage accounting per WLM class in addition to the standard accounting per user or group.
With WLM, you can create different classes of service for jobs, as well as specify attributes for those classes. These attributes specify minimum and maximum amounts of CPU, physical memory, and disk I/O throughput to be allocated to a class. WLM then assigns jobs automatically to classes using class assignment rules provided by a system administrator. These assignment rules are based on the values of a set of attributes for a process. Either the system administrator or a privileged user can also manually assign jobs to classes, overriding the automatic assignment.
| class | A class is a collection of processes and their associated threads. A class has a single set of resource-limitation values and target shares. class is used to describe both subclasses and superclasses. |
| superclass | A superclass is a class that has subclasses associated with it. No processes can belong to a superclass without also belonging to a subclass. A superclass has a set of class-assignment rules that determines which processes are assigned to the superclass. A superclass also has a set of resource-limitation values and resource target shares that determines the amount of resources that can be used by processes which belong to the superclass. These resources are divided among the subclasses based on the resources limitation values and resource target shares of the subclasses. |
| subclasses | A subclass is a class associated with exactly
one superclass. Every process in a subclass is also a member of its superclass.
Subclasses have access only to resources that are available to the superclass.
A subclass has a set of class assignment rules that determines which of the
processes assigned to the superclass belong to the subclass. A subclass also
has a set of resource-limitation values and resource target shares that determines
the resources that can be used by processes in the subclass.
These resource-limitation values and resource target shares indicate how much of the resources available to the superclass (the target for the superclass) can be used by processes in the subclass. WLM administration can be done using either the Web-based System Manager, SMIT, or the WLM command-line interface. |
| classification mechanism | A classification mechanism is a set of class assignment rules that determines which processes are assigned to which classes (superclasses or subclasses within superclasses). |
| class assignment rule | A class assignment rule indicates which values within a set of process attributes result in a process being assigned to a particular class (superclass or subclass within a superclass). |
| process attribute value | A process attribute value is the value that a process has for a process attribute. The process attributes can include attributes such as user ID, group ID, and application path name. |
| resource-limitation values | Resource-limitation values are a set of values that WLM maintains for a set of resource utilization values. These limits are completely independent of the resource limits specified with the setrlimit subroutine. |
| resource target share | Resource target shares are the shares of a resource that are available to a class (subclass or superclass). These shares are used with other class shares (subclass or superclass) at the same level and tier to determine the desired distribution of the resources between classes at that level and tier. |
| resource-utilization value | A resource-utilization value is the amount of a resource that a process or set of processes is currently using in a system. Whether it is one process or a set of processes is determined by the scope of process resource collection. |
| scope-of-resource collection | The scope-of-resource collection is the level at which resource utilization is collected and the level at which resource-limitation values are applied. This might be at the level of each process in a class, the level of the sum across every process in a class owned by each user, or the level of the sum across every process in a class. The only scope currently supported is the latter. |
| process class properties | The process class properties are the set of properties that are given to a process based on the classes (subclass and superclass) to which it is assigned. |
| class authorizations | The class authorizations are a set of rules that indicates which users and groups are allowed to perform operations on a class or processes and threads in a class. This includes the authorization to manually assign processes to a class or to create subclasses of a superclass. |
| class tier | The class tier value is the position of the class within the hierarchy of resource limitation desirability for all classes. The resource limits (including the resource targets) for all classes in a tier are satisfied before any resource is provided to lower tier classes. Tiers are provided at both the superclass and subclass levels. Resources are provided to superclasses based on their tiers. Within a superclass, resources are given to subclasses based on their tier values within the superclass. Thus, superclass tier is the major differentiator in resource distribution; the subclass tier provides an additional smaller differentiator within a superclass. |
WLM allows system administrators to define classes and define for each class a set of attributes and resource limits. The processes are assigned to classes based on criteria provided by the system administrator. The resource entitlements and limits are enforced at the class level. This method of defining classes of service and regulating the resource utilization of each class of applications prevents applications with very different resource use patterns from interfering with each other when they share a single server.
WLM supports a hierarchy of classes with two levels:
Note: Throughout this discussion of WLM, the term class applies to both superclasses and subclasses. If discussion applies only to a specific class type, that type is explicitly mentioned.
The processes are assigned to a class, using class-assignment rules provided by the system administrator. The classification criteria are based on the value of a set of attributes of the process such as user ID, group ID, name of the application file, type of process, and application tag.
A defined set of rules is used to determine the superclass a process is assigned to. If this superclass has subclasses defined, there is another set of rules for this superclass to determine which subclass is assigned to which process. This automatic assignment process also takes into account the inheritance attributes of both the superclass and the subclass. (For information on class attributes, see WLM Class Attributes.)
The automatic class assignment is done when a process calls the exec subroutine. The class assignment is reevaluated when a process uses a subroutine that can alter a process attribute used for classification purposes. Examples are the setuid, setgid, setpri, and plock subroutines.
In addition to this automatic class assignment, a user with the proper authority can manually assign processes or groups of processes to a specific superclass or subclass.
WLM allows management of resources in two ways: as a percentage of available resources or as total resource usage. Resources that can be controlled on a percentage basis include the following:
Resources that can be controlled on a total usage basis fall into one of two categories: class totals or process totals. The class totals category includes:
The process totals category includes:
WLM allows system administrators to specify per-class resource entitlements independently for each resource type. These entitlements can be specified by indicating the following:
In most cases, soft maximum limits are sufficient to ensure that resource entitlements are met and enforced. Using hard maximum limits may result in unused system resources since these are strictly enforced, even when there is no contention for the resource. Careful consideration must be made when using hard maximum limits since these can greatly affect system or application performance if set too low. Total limits should also be used with caution, since these could result in process termination or failure to function as intended.
In active mode, WLM attempts to keep active classes close to their targets. Since there are few constraints on the values of the various limits, the sum of any of the limits across all classes could far exceed 100%. In this case, if all of the classes are active, the limit cannot be reached by all classes. WLM regulates the CPU consumption by adjusting the scheduling priorities of the threads in the system according to how the class they belong to is performing, relative to its limits and target. This approach guarantees a CPU consumption averaged on a certain period of time, not the CPU consumption on very short intervals (for example, 10 ms ticks).
For example, if class A is the only one active, with a CPU minimum of 0% and a CPU target of 60 shares, then it gets 100% of the CPU. If class B, with a CPU minimum limit of 0% and a CPU target of 40 shares, becomes active, then class A's CPU utilization progressively decreases to 60% and class B's CPU utilization increases from 0 to 40%. The system stabilizes at 60% and 40% CPU utilization, respectively, in a matter of seconds.
This example supposes that there is no memory contention between the classes. Under regular working conditions, the limits you set for CPU and memory are interdependent. For example, a class may be unable to reach its target or even its minimum CPU allocation if the maximum limit on its memory usage is too low compared to its working set.
To help refine the class definition and class limits for a given set of applications, WLM provides the wlmstat reporting tool, which shows the amount of resource currently being used by each class. A graphical display tool, wlmmon, is also provided for system monitoring.
WLM can be used to regulate resource consumption as per-class percentages, per-class totals, or per-process totals. Regulation for all resource types can be enabled by running WLM in active mode.
Optionally, you can start a mode of WLM that classifies new and existing processes and monitors the resource usage of the various classes, without attempting to regulate this usage. This mode is called the passive mode.
The passive mode can be used when configuring WLM on a new system to verify the classification and assignment rules, and to establish a base line of resource utilization for the various classes when WLM does not regulate the CPU and memory allocation. This should give a basis for system administrators to decide how to apply the resource shares and resource limits (if needed) to favor critical applications and restrict less important work in order to meet their business goals.
If CPU time is the only resource that you are interested in regulating, you can choose to run WLM in active mode for CPU and passive mode for all other resources. This mode is called cpu only mode. If you want to regulate per-class percentages, but neither of the total resource types, the total resource accounting and regulation can be disabled for per-class totals, per-process totals, or both. In all modes, you have the option of disabling resource set binding.
When WLM is active, any parameter of the current configuration can be modified at any time, including the attributes of a class, its resource shares and limits, the assignment rules, and adding new classes or deleting existing classes. This can be done in several ways, such as:
Automatic switches to a new configuration at specified times of day can be accomplished using configuration sets. Configuration sets allow the administrator to specify a set of configurations to be used, and a time range for which each will be active.
Use the following WLM commands to display WLM statistics and monitor the operation of WLM:
An Application Programming Interface (API) allows applications to perform any operation that can be done using the WLM command-line interface such as:
In addition, the API allows applications to set an application-defined classification attribute called tag. Setting this tag using a set of values provided by the system administrator (through the application user documentation) allows discrimination between several instances of the same application. The different classes can therefore be classified with different resource entitlements.
The AIX accounting system utility lets you collect and report the use of various system resources by user, group, or WLM class. When process accounting is turned on, the operating system records statistics about the process resource usage in an accounting file when the process exits. Beginning with AIX 5.1, this accounting record includes a 64-bit numeric key representing the name of the WLM class that the process belonged to. (See Accounting Overview for more information about the accounting system utility.)
The accounting subsystem uses a 64-bit key instead of the full 34-character class name to save space (otherwise the change would practically double the size of the accounting record). When the accounting command is run to extract the per-process data, the key is translated back into a class name using the above-mentioned routine. This translation uses the class names currently in the WLM configuration files. So, if a class has been deleted between the time the accounting record was written, when the process terminated, and the time the accounting report is run, the class name corresponding to the key cannot be found, and the class displays as Unknown.
To keep accurate records of the resource usage of classes deleted during an accounting period, do one of the following: