Operating Systems

A common problem with many Workload Manager (WLM) service definitions is that assigned goals aren’t indicative of the actual desired workload objectives. That is, a WLM administrator may set a goal based on a desired objective, but that objective isn’t based on reality. At a broad level, the most extreme cases include goals that are set way too easy, set way too difficult, or are inappropriate for the workload type. This article discusses when goals are set too easy and further focuses specifically on response time goals.

When WLM Goals Are Too Easy

When a workload’s goal is set too easy, it exposes the workload’s resources to be easily stolen by WLM to help some other workload. That’s OK if the goal was set with that specific intention, but not if you’re still expecting WLM to manage the workload in an effective, predictable manner. When a goal is too easy, the result can be ineffective or unpredictable WLM management of the workload.

It’s OK to assign goals that WLM regularly meets or even exceeds. After all, a WLM administrator should try to help WLM clearly identify workloads from which it can easily steal resources. However, when a goal is much too easily met, WLM is more likely to select the workload as a donor of resources. Before ever stealing resources from a workload, WLM projects the net effect a change will have on donating a workload’s goal. When a goal is way too easy, such a projection could show that the work is still always expected to easily meet its goal objective.

When an assigned goal is too easy but the workload performs well, it isn’t always a result of effective or clever WLM management, but instead occurs because the workload is enjoying a period of low contention for resources. In those periods, the workloads and users become accustomed to “much better than goal” performance. Unbeknownst to them, they’re also vulnerable to having their performance significantly degraded during periods of resource constraint. When constraints occur, WLM may steal resources from such workloads, which could result in degraded workload performance. Yet, because the goal is very easy, when monitoring and managing the workload, WLM may still project that the goal will be met. In this case, there’s a conflict between user-perceived performance and effective WLM management. The goal for the workload isn’t indicative of the desired workload performance objective. From a WLM perspective, the work is still projected to meet its goals, but from a user or workload perspective, the system is performing poorly.

Typical Scenarios When Goals May Be Too Easy   

Consider some typical scenarios when WLM administrators set response time goals too easy.

Some goals are unintentionally set too easy. A common case is when response time goals for (usually interactive) workloads are based on Service Level Objectives (SLAs). SLA-oriented response time objectives tend to be contractual values of worst-case expectations and not based on the workload’s day-to-day reality. An SLA-oriented goal could be that Time Sharing Option (TSO) period 1 transactions need to achieve a 1 second response time when in reality most TSO period 1 transactions may complete in 0.25 seconds.

Such goals need to be identified and changed to consider the user or SLA objective as well as the actual measured response times for the typical transactions.

Some goals are set easy as a way to rank work in the same importance level. An example would be TSO periods 1 and 2 both being assigned an importance level of 2, but the TSO period 2 transactions are set to a much easier response time goal with the hope they would be considered for resource donation before TSO period 1 transactions.

4 Pages