Storr Consulting - sc510-ada006


Home	The Company	Publications	Products	Links	Tips

ADABAS and the Workload Manager (WLM)

Source: Software AG

Last update: 30 May 2004

Short Introduction to the Concepts of the Workload Manager

History before Workload Manager

This is now also known as Compatibility Mode. It is supported only up to z/OS 1.2.

The system programmer specified priorities (and sometimes assigned system resources like memory) for workload according to business requirements in a parmlib member called IPS.

Priorities could vary (e.g. time sliced; mean-time-to-wait), but otherwise were static. The system resource manager (SRM) would give access to workload contending for a resource in priority order.

Basic Idea of the Workload Manager

Goal mode:

The system programmer arranges workload according to business importance into service classes and defines goals (typically response or elapsed time thresholds) for these workloads according to business needs (e.g. service level agreements).

The Workload manager uses this as input to check whether goals are met. Goals are checked in importance sequence from most important to discretionary.

The Workload Manager ‘knows’ of two basic types of goals:

Response time (easy to understand)
E.g. 90% of all CICS transactions should finish in 0.5 seconds
The TP monitor reports actual results to the WLM via an interface
Velocity (not as self-explanatory as response time goal)

This is defined as percentage of access to a (hardware) resource managed by the system resource manager (SRM), typically and most important access to the CPU.

E.g. if a workload should use up to 70% of a processor at a time define velocity=70
Velocity does not look at idle periods, so velocity for this type of work can be highly variable over short time intervals
SRM informs the WLM about resource usage and delays directly

For service classes defined by users goals can be classified into

Percentile Response Time
Average Response Time
Velocity
Discretionary

The WLM has some service classes with predefined goals

SYSTEM
SYSSTC
SMALL consumer

The Workload Manager compares the actual result with the goal definition. It computes the result into a performance index (PI)

If the PI (performance index) is lower than one the result is better than the goal. The goal is “overachieved”.
If the PI is equal to one the result reported matches the goal.
If the PI is greater than one the result is worse than the goal. The goal is not met.

If all goals are met or “overachieved” the Workload Manager goes to bed.

So let us assume one or more goals are not met. (PI>1)

The Workload Manager will want to deal with these unmet goals in importance sequence: The lower the service class of a workload is the more important the goal.

Example:

If service class 3 is the lowest (most important) service class, which is not achieving its goal, and service class 3 is “waiting for CPU” some of the time, then the WLM will try to raise the dispatching priority of service class 3 relative to others.
If service class 1 (more important) is overachieving its goal (PI<1), say velocity=40, but is using 60% CPU in the measured time interval (PI=0.66), then the Workload Manager will raise the dispatching priority of Service Class 3 and lower the dispatching priority of Service Class 1, quite possibly below the dispatching priority of service class 3.

Thus the Workload Manager tends to reduce the priority of workloads overachieving their goals (PI<1) and raises the priority of workloads, which do not meet their defined goal (PI>1).

The objective is to meet as many goals in importance sequence as possible, not to “over-achieve” goals for workload in the most important service classes. Thus correct definitions of goals tend to matter more for the performance of workloads than importance classification.

One major difference to compatibility mode is, that priorities are now dynamically managed and demand driven. The performance of all subsystems (e.g. CICS) deteriorate when load increases and the capacity level is reached. However the WLM may help by adjusting priorities dynamically, thus giving better access to hardware resources when demand is high.

Experience and Observations

If goals are properly defined, the WLM may do a good job in allocating hardware resources to accomplish business needs. Priorities will be dynamically raised or reduced according to fluctuating load.

Even high importance workload (e.g. online transaction) may get low priority if it meets its goal and less important workload (e.g. batch) does not.

However, if the goals are not properly defined, the WLM may play havoc with the performance of the system in peak periods, when the system is fully loaded.

The result of good workload definitions can only be judged under heavy load. In underutilized systems, priorities do not matter much. Low utilized resources give good access even to workload with low priority.

Workload Definitions for Adabas

Like many other Service Address Spaces Adabas has no good response time metrics, which it could report to the Workload Manager. The Adabas task acts on behalf of workloads (e.g. batch and online) with different goals and of different importance. What could Adabas sensibly report to the WLM? The conclusion is that velocity goals have to be defined to the WLM for Adabas. This works well in practice when done properly, but is sometimes viewed as somewhat inadequate for no good reason.

To quote from IBM WSC Workload Management Overview about the nature of “Velocity goals”

Measure of acceptable delays while work is capable of running
- Delays measured for CPU and storage, optionally for I/O and JES Queue time
Used for long-running and non interactive workloads
High velocity can be interpreted as:
- “When this workload is ready to run, make sure it runs without delay”
Low velocity can be interpreted as:
- “When this workload is ready to run, keep it plodding along to ensure that it will eventually finish”
Velocity is not equal to dispatch priority

Limitation of the Workload Manager

Response time goals make no sense for service address spaces. Therefore the limitation is not in Adabas.

The effectiveness of the WLM depends to a large extent on which types of wait reasons, which cause delays in the execution of workloads, the WLM can detect and influence.

What would really be “nice to have” is a more sophisticated concept of the WLM, which allows for interrelationships between tasks of different address spaces:

If there would be a metric, where CICS would not only report transaction response times and Batch not only elapsed time to the WLM, but also what percentage of this time was due to “Waiting for an external address space (ADABAS)”, then the WLM could inspect the external address space (ADABAS) and decide to do something about this on behalf of the CICS or Batch goal. Most CICS performance monitors are already capable of collecting this type of information.

Thus service address spaces like Adabas, JES, VTAM etc. could (in my view) be dynamically managed in accordance with the goal requirements of the requestors (clients)

It is, however, important to realize, that this type of information accrues only in the client address space and can only be collected by the requestor and not by the server Adabas. Adabas does not know (nor care), which calls comprise a CICS transaction nor does it know what the goals for CICS are.

Pitfall

Normally the WLM definitions are done by system programmer, who sometimes have neither fully grasped the concepts of the WLM nor ADABAS. They will assign a somewhat high but arbitrary velocity to Adabas, e.g. Velocity=70.

Adabas is a server that is completely demand driven. As long as the arrival rate of Adabas calls from users requires less than 70% of the logical processor capacity of the LPAR, where Adabas executes, the goal is not met

-> Then the WLM will assign a good CPU dispatching priority to ADABAS. This may well be true most of the time.

The problem arises, when the load increases:

That usually happens in peak periods (e.g. month end processing) or only after time, when new users and / or applications go into production. Suddenly so many calls arrive that Adabas would require say 85% of the capacity of a processor in the LPAR.

The WLM will now give additional CPU to ADABAS only, if there is no other workload (Batch), which requires additional CPU to achieve its goal. This scenario is not likely in peak periods.

Once Adabas requires more than 70% of a processor and the performance index drops below 1, the WLM will tend to reduce the dispatching priority. In other words, during peak demand the WLM starts to reduce the priority of Adabas, precisely at the moment when it is most urgently required for reasonable performance.

Conclusion

There is no good fixed goal for Adabas, because the resource requirements fluctuate with outside demand. What is important, however, is that the WLM should never believe that a specified goal has been overachieved (PI<1) and blocks access of Adabas to the CPU by reducing the priority of Adabas relative to less important workload. How to accomplish this? Simple! Either put Adabas into service class SYSSTC or give Adabas the highest possible velocity! Set Velocity to 99 or at least close to this value! You may put Adabas into a less important service (higher) class, so that resources may be shifted from Adabas to workload with unmet goals considered more important by the business, but do not lower the velocity, which might cause resources to be shifted to less important workload at peak periods.

In addition from OS390 R10 onwards the WLM allows you to specify long-term CPU protection to a critical workload like ADABAS by marking it as CPU Critical=YES. This is strongly recommended and particularly important when the velocity goal of a mission critical ADABAS is not set to a very high value, because it should ensure that workload in service classes of lower importance, even if their goal is unmet, will not run at a higher dispatch priority than Adabas.

Sometimes system programmers are concerned that the WLM has no fair chance to accomplish a very high velocity goal. True, but does it matter? The answer is no!

Unlike humans the WLM can not get confused. The WLM will not play havoc to the system, just because you assign an unattainable velocity goal for ADABAS with the objective that the performance index for ADABAS will never drop below one. It will protect Adabas from some of the options the WLM in general has and which may be more appropriate for different workloads, e.g. batch. Goals of other workloads will not be threatened by this definition. The WLM does what it has been asked to do.

However, the WLM realizes that goals may not be met for reasons not under its control. For example a workload may wait for events like ECB, or it may relinquish control voluntarily just like Adabas. The WLM will raise the priority only if the goal is not met and the workload was in fact waiting to get dispatched.

Use a lower velocity only if you want deliberately to restrict the maximum number of calls executable by Adabas! This may sometimes make sense for test databases, but rarely for production!

Of the above recommendations putting Adabas into service class SYSSTC is the most radical, because it will exempt Adabas completely from any goal considerations, while a high velocity goal and / or long-term CPU protection would still allow resources to shift from Adabas to workload assigned to more or equal important service classes. But sometimes system programmers are easier to convince to put Adabas into SYSSTC than to raise the velocity goal for Adabas in a user service class.

What is the right importance service class?

Considerations are similar to priority settings in compatibility mode:

Production before Test / Development
Online before Batch
Specific goals for response times may be considered more important than velocity

Goal importance can be set in a range from very important (1) to desirable (5). What sets the importance is the relative, not the absolute, value. The significance of meeting goals says nothing about how easy or difficult the goal is to achieve, e.g. a batch job with velocity of 5 but importance 1.

The WLM uses this to

Identify critical workloads
Make tradeoffs to protect critical workloads
React to changing capacity
Scarce resources will cause WLM to degrade equally work with goals of lower importance

Recommendations for Adabas

If an Adabas nucleus gets generally CPU constrained, that is it approaches the processor capacity limit and if you are not yet ready to try Parallel Services:
Otherwise
- If Adabas processes a substantial share of calls originating from Batch during high Online periods:
  - Put Adabas into a higher service class of somewhat lower importance than the response time goals of the TP monitor. However this is not recommended, when the TP monitors concurrently executes transactions, which access other databases like DB2. A high CPU consumption in DB2 could then delay transactions doing Adabas calls!
- Else with not much batch activity during online periods Adabas and CICS could be in the same importance service class

It should be noted that the above recommendations have been implemented in a variety of heavy Adabas production sites with good results.