This section discusses some of the steps that a system administrator takes to configure WLM.
Define your superclasses first. To define which classes you need, you must know your users and their computing needs, as well as the applications on your system, their resource needs and the requirements of your business (for example, which tasks are critical and which can be given a lower priority).
Setting priorities is dependent on what function WLM serves in your organization. In the case of server consolidation, you might already know the applications, the users and their resource requirements, and you might be able to skip or shorten some of the steps.
WLM allows you to classify processes by user or group, application, type, tag, or a combination of these attributes. Because WLM regulates the resource utilization among classes, system administrators should group applications and users with the same resource utilization patterns into the same classes. For instance, you might want to separate the interactive jobs that typically consume very little CPU time but require quick response time from batch-type jobs that typically are very CPU- and memory-intensive. This is the same in a database environment in which you need to separate the OLTP-type traffic from the heavy-duty queries of data mining.
This step is done using Web-based System Manager, SMIT, or command-line interface. For the first few times, it is probably a good idea to use Web-based System Manager or SMIT to take you through the steps of creating your first WLM configuration, including defining the superclasses and setting their attributes. For the first pass, you can set up some of the attributes and leave the others at their default value. This is the same for the resource shares and limits. All these class characteristics can be dynamically modified at a later time.
You can then start WLM in passive mode, check your classification, and start reviewing the resource utilization patterns of your applications.
Verify your configuration, using the wlmcheck command or the corresponding SMIT or Web-based System Manager menus. Then start WLM in passive mode on the newly defined configuration. WLM will classify all the existing processes (and all processes created from that point on) and start compiling statistics on the CPU, memory, and disk I/O utilization of the various classes. WLM will not try to regulate this resource usage.
Verify that the various processes are classified in the appropriate class as expected by the system administrator (using the -o flag of the ps command). If some of the processes are not classified as you expect, you can modify your assignment rules or set the inheritance bit for some of the classes (if you want the new processes to remain in the same class as their parent) and update WLM. You can repeat the process until you are satisfied with this first level of classification (superclasses).
Running WLM in passive mode and refreshing WLM (always in passive mode) involves low risk, has low overhead operation, and can be done safely on a production system without disturbing normal system operation. To activate and refresh WLM, use the wlmcntrl command, invoked either from the command line or from SMIT or Web-based System Manager.
Run WLM in passive mode to gather statistics by using the wlmstat command. The wlmstat command can be used at regular time intervals to display the per-class resource utilization as a percentage of the total resource available, for superclasses). This allows you to monitor your system for extended periods of time to review the resource utilization of your main applications.
With this data, and your business goals defined in step 1, decide which tier number will be given to every superclass and what share of each resource should be given to the various classes.
You are now ready to start WLM in active mode. Monitor the system using the wlmstat command and verify that the regulation done by WLM is in line with your goals and if applications are not unduly deprived of resources while others get more than they should. If this is the case, adjust the shares and refresh WLM.
For specific cases, you might have to use minimum or maximum limits. Adjust the shares and tier numbers to reach your resource-allocation goals. Reserve limits for cases that cannot be solved only with shares.
Monitor and adjust the shares, limits, and tier numbers until you are satisfied with the system behavior.
Decide whether you need to use subclasses and if you want to delegate the administration for the subclasses for some or all of the superclasses. When creating and adjusting the parameters of subclasses, you can refresh WLM only for the subclasses of a given superclass that do not affect users and applications in the other superclasses.
The administrator of each superclass can repeat this process for the subclasses of each superclass. The only difference is that WLM cannot run in passive mode at the subclass level only. The subclass configuration and tuning has to be done with WLM in active mode. One way not to impact users and applications in the superclass is to start the tier number, and the shares and limits for the subclasses at their default value ('-' (hyphen) for shares, 0% for minimum, and 100% for soft and hard maximum). With these settings, WLM will not regulate the resource allocation between the subclasses.
The administrator can then monitor and set up the subclass shares, limits, and tier number.
Repeat steps 1 through 6 to define other configurations with different parameters, according to the needs of the business. When doing so, you can save time by copying and modifying existing configurations.
You can specify the properties for the WLM subsystem by using Web-based System Manager, SMIT, an ASCII-oriented user interface, or by creating flat ASCII files. The Web-based System Manager and SMIT interfaces record the information in the same flat ASCII files. These files are called the WLM property files and are named classes, description, rules, limits, and shares. The WLM property files can only be loaded by the root user.
You can define multiple sets of property files, defining different configurations of workload management. These configurations are usually located in subdirectories of /etc/wlm. A symbolic link /etc/wlm/current points to the directory containing the current configuration files. This link is updated by the wlmcntrl command when WLM starts with a specified set of configuration files.