Workload Manager (WLM) gives you control over the resources used by jobs on your system. A default WLM configuration template exists on every installed AIX operating system. The following procedure updates the WLM configuration template to implement a resource-management policy on a shared server. The resulting configuration can be used as a starting point for testing. Exactly how you configure WLM will depend on the workload and policy requirements for your environment.
The WLM configuration files exist in the /etc/wlm/ConfigurationName directory. Each subclass for each superclass is defined in a configuration file named /etc/wlm/ConfigurationName/SuperClassName. For more information about these files, see the AIX 5L Version 5.2 Files Reference.
In the following procedure, you consolidate the workloads from two separate department servers onto one larger server. This example edits the configuration files, but you can also create a configuration using SMIT (use the smit wlmconfig_create fast path) or Web-based System Manager (select the Workload Manager container, select the Configuration/Classes container, then from the Workload menu, select New Configuration). Briefly, in this procedure, you will do the following:
In this scenario, the workload is typical of what you might see on a database server. Assume the jobs fall into the following general categories:
In addition to this work, scheduled jobs fall into one of the following categories:
The first step of creating a configuration is to define classes and rules. In the following steps, you will use the general job categories listed above to define your classes. Use the following procedure:
mkdir /etc/wlm/MyConfig
cp -pr /etc/wlm/template/* /etc/wlm/MyConfig
System: Default: DeptA: DeptB: SysTools: SysBatch:As a starting point, you define one superclass for each department (because two departments will be sharing the server). The SysTool and SysBatch superclasses will handle the scheduled jobs outlined in the general categories above. The System and Default superclasses are always defined.
Listen: Work: Monitor: Report: Command:
After the classes are identified, in the following step, you create the classification rules that are used to classify processes at the superclass and subclass levels. For the sake of simplicity, assume that all applications run from known locations, that all processes from one department run under the deptA UNIX group, and that processes from the other department run under the deptB UNIX group.
DeptA - - deptA - - DeptB - - deptB - - SysTools - root,bin - /usr/sbin/tools/* - SysBatch - root,bin - /usr/sbin/batch/* - System - root - - - Default - - - - -
Listen - - - /opt/myapp/bin/listen* - Work - - - /opt/myapp/bin/work* - Monitor - - - /opt/bin/myapp/bin/monitor - Report - - - /opt/bin/myapp/report* - Command - - - /opt/commands/* -
wlmcntrl -p -d MyConfigAfter starting WLM in passive mode, you can run each application separately at first to gain a finer perspective of its resource requirements. You can then run all applications simultaneously to better determine the interaction among all classes.
An alternative method of identifying the application resource requirements might be to first run WLM in passive mode on the separate servers from which you are consolidating applications. The disadvantages to this approach are that you would have to re-create the configurations on the larger system, and the required percentage of resources will likely be different on the larger system.
A WLM configuration is an implementation of a resource-management policy. Running WLM in passive mode provides information that helps you determine whether your resource-management policy is reasonable for the given workload. You can now define tiers, shares, and limits to regulate your workload based on your resource-management policy.
For this scenario, assume you have the following requirements:
In the following procedure, you define tiers, shares, and limits:
System: Default: DeptA: localshm = yes adminuser = adminA authuser = adminA inheritance = yes DeptB: localshm = yes adminuser = adminB authuser = adminB inheritance = yes SysTools: localshm = yes SysBatch: tier = 1 localshm = yesThe SysBatch superclass is put in tier 1 because this class contains very low-priority jobs that you do not want to interfere with the rest of the work on the system. (When a tier is not specified, the class defaults to tier 0.) Administration of each department's superclass is defined by the adminuser and authuser attributes. The inheritance attribute is enabled for DeptA and DeptB. All new processes started in a class with inheritance will remain classified in that class.
Listen: Work: Monitor: Report: tier = 1 Command:
DeptA: CPU = 3 memory = 3 DeptB: CPU = 2 memory = 2
Because you assigned a CPU total of 5 shares, DeptA processes will have access to three out of five shares (or 60%) of the total CPU resources and DeptB processes will have access to two out of five (or 40%). Because you did not assign shares to the SysTools, System, and Default classes, their consumption targets will remain independent from the number of active shares, which gives them higher-priority access to resources than the DeptA and DeptB (until their limit is reached). You did not assign the SysBatch class any shares because it is the only superclass in tier 1, and therefore any share assignment is irrelevant. Jobs in the SysBatch class can only consume resources that are unused by all classes in tier 0.
Work: CPU = 5 memory = 5 Monitor: CPU = 4 memory = 1 Command: CPU = 1 memory = 1
Because you did not assign shares to the Listen class, it will have the highest-priority access (in the superclass) to resources when it requires them. You assigned the largest number of shares to the Work class because it has the greatest resource requirements. Accordingly, you assigned shares to the Monitor and Command classes based on their observed behavior and relative importance. You did not assign shares to the Report class because it is the only subclass in tier 1, and therefore any share assignment is irrelevant. Jobs in the Report class can only consume resources that are unused by subclasses in tier 0.
In the following step of this example, you assign limits to classes that were not assigned shares. (You can also assign limits to classes with shares. See Managing Resources with WLM in the AIX 5L Version 5.2 System Management Concepts: Operating System and Devices for more information.)
Default: CPU = 0%-10%;100% memory = 0%-10%;100% SysTools: CPU = 0%-10%;100% memory = 0%-5%;100% System: CPU = 5%-50%;100% memory = 5%-50%;100%
You assigned soft maximum limits to the System, SysTools, and Default classes to prevent them from significantly interfering with other work on the system. You assigned minimum limits to the System class for CPU and memory because this class contains processes that are essential to system operation, and it must be able to consume a guaranteed amount of resource.
Listen: CPU = 10%-30%;100% memory = 10%-20%;100% Monitor: CPU = 0%-30%;100% memory = 0%-30%;100%
You assigned soft maximum limits to the Listen and Monitor classes to prevent them from significantly interfering with the other subclasses in the same superclass. In particular, you do not want the system to continue accepting requests for jobs within the Work class, if the Work class does not have access to the resources to process them. You also assigned minimum limits to the Listen class to ensure fast response time. The minimum limit for memory ensures that pages used by this class will not be stolen by page replacement, resulting in faster execution time. The minimum limit for CPU ensures that when these processes can be run, they will have the highest-priority access (in the superclass) to the CPU resources.
Now that you have fully defined a configuration, you will run WLM in active mode to begin regulating the workload and analyzing how well your resource-management policy is being enforced. Based on your analysis, you might need to fine-tune your configuration to achieve your desired results. For maintenance, you might need to refine your configuration if your workload changes over time.
wlmcntrl -a
wlmcntrl -u