Currently WLM looks for candidate receivers by first examining all the sysplex PIs at a given importance level before moving onto the local PIs at that importance level. But today’s sysplexes tend to be much more heterogenous than originally envisioned 30 years ago, with a mix of production and non-production systems, workload that’s not dynamically distributed across systems, and systems with very different resource allocations. Prioritizing sysplex PIs does not make sense for all workloads.
Common address spaces, utilities, and even TSO will usually be assigned to the same service class (SC) regardless of what system that it's running on. Meaning, for example, that performance of TSO period 1 on a development LPAR might impact the management of TSO on the production LPAR. Or the STC sysplex PIs will influence the selection of what STC SC gets helped first.
While there are opportunities for customers to work around this issue in their WLM service classification rules by assigning STCs (or TSO or OMVS) on different LPARs to different SCs, that can be tedious and, in our experience, not commonly done.
While we occasionally have seen (or suspected) this issue while working on specific performance situations, it can be hard to identify without detailed examination of the SMF 99 data. Fortunately, we have been somewhat successful over the past few years in getting customers to record this useful data.
We analyzed 11 days of 99.1 and 99.6 data for 56 systems across several different customers, looking for occasions where a service class period (SCP) was selected as a receiver candidate but its achieved local PI from the 99.6 data was below 1 but its sysplex PI was above 1, implying that WLM selected the SCP to try to help the sysplex PI. All systems had at least some occurrences. A total of 18 systems (32%) averaged more than 864 (10% of the policy adjustment intervals) occurrences per day. The worse system averaged 5,027 occurrences per day. Because the 99.1 data doesn’t include a definitive record indicating what the final committed change was in the interval, we can’t say for sure that WLM made changes to help all those SCPs. Nonetheless, WLM is at least considering helping locally well-performing SCPs on a regular basis. This is more common than we initially assumed.
The suggested proposal is to change the processing of the two passes of evaluating SCP PIs in each importance level. In examining the SCPs in each pass, decide whether to examine the sysplex or local PI based on a new SC option that indicates whether the first pass is to be either for the sysplex or local PI. That presumably would default to "sysplex" which is the current behavior but could be overridden to "local" for things like STCMED, TSO, etc. where the work exists in those SCs on all systems, but the work isn't necessarily related. (E.G. making the TSO users who logged on to SYSA perform even better than they were doesn't help the TSO users suffering on SYSB.) It might be useful to add a third value for the option ("local-only"?) which would say to never consider the sysplex PI, in which case the SC’s local PI would be examined in the first pass and would not be considered in the second pass. For some work like TSO and some started tasks, that might be the preferred option.
Other submitted WLM ideas reference the need to potentially reduce the 10 second PA interval given modern velocities of work on modern hardware. This proposal may also help those situations where WLM is perceived to not be helping work fast enough in that it may allow WLM to focus sooner on workload that matters to the customer on the local system instead of chasing changes for a potential sysplex-wide benefit that may or may not be practically useful.
This proposal seems like an easy way to address this largely hidden inefficiency and provide better control over how WLM chooses work to help.
Portal Public