Limits

Processor resources may have minimums, soft maximums and hard maximums, as well as shares. Limits take precedence over shares. A class with a minimum of 10% processor resource will be permitted to take that much resource, even if the shares calculation produces a lower percentage. If it produces a higher value, that will be honored. Thus, a minimum can be used to ensure that an application obtains a minimum service level even if many other applications start.

The soft maximum can be breached if there is no contention for resource, but the hard maximum cannot be breached (at least, over any significant time period, because WLM controls allow short-term peaks in the order of a very few seconds).

The effect of the WLM algorithm can be approximately described as follows:

if used < minimum, increase priority;

else if used > hard maximum, decrease priority;

else if used > soft maximum during contention, decrease priority;

else if used < share, increase priority;

else if used > share, decrease priority.

Memory minimums may reduce the danger of appserver JVMs being paged. A process requesting less memory than the minimum does not prevent other processes using the difference, but if the first process then requests more, memory will be taken from those other processes, thereby causing paging.

A processor maximum may prevent one appserver from monopolizing resources at the expense of another. It can limit its performance to its budgeted resources, rather than giving unnaturally good performance when the LPAR is undercommitted.

Limits are expressed as a percentage of the LPAR's resource. For example, on a 4-processor LPAR, they still range from 0 to 100% (of those 4 processors in aggregate), not 0-400%.

Minimums at the subclass level must total no more than 100%, and apply to the superclass resource. Minimums at the superclass level must total no more than 100%, and apply to the system. Minimums must not exceed the soft maximum, which in turn must not exceed the hard maximum for the same resource. The defaults are 0%, 100%, 100%, so that WLM allocates resource according to shares alone.

On an LPAR dedicated to WebSphere applications, the WebSphere superclass might have a minimum and soft maximum of 85% processor, the subclasses allocated according to their budget share of that. For example, three applications of equal budget might have a hard maximum of 33%.

Allocating actual measures of LPAR resource, for example to ensure that one application has at least 512 Mb memory, needs a program or shell script to calculate the appropriate percentages of the available resources. With static LPARs, this program would need running only at startup. With dynamic LPARs, it would need running after each reconfiguration, or at regular intervals.