WLM Velocity - Another Fine Rhetorical Device I've Gotten Myself Into
MartinPacker 11000094DH Visits (5312)
Back in 2010 I wrote about a graph I’d developed for understanding how a Service Class Period’s velocity behaves. That post is here: WLM Velocity - “Rhetorical Devices Are Us”.
At the time I was concerned not to show up the customer by displaying the graph. I think that was the right decision. But in the presentation I mention here: Workload Manager And DB2 Presentation Abstract I do have an example. And indeed it’s a significant part of my “zIIP Capacity Planning” presentation (you can get from System z Technical University, Budapest 12–16 May 2014, Slides).
I regard that graph as a nice rhetorical device as it has led to many fine discussions with customers (and I’ve tweaked it a little in the process).
But this blog post is about a very new graph I’ve developed on the theme of Velocity. I hope it, too, will lead to lots of interesting discussions with customers.
But the reason for sharing it with you is that you might well want to do something similar.
The primary purpose of the graph is twofold:
As I write this those two bullets look remarkably similar but they’re not.
The Importance Of Importance
Answer: The one with the higher importance.
It’s a fact that importance is the major distinction in that WLM will try to satisfy the goal of a more important service class period before attempting to satisfy the goal of a less important one.
But note that some goals are unattainable and some velocity calculations are dominated by things WLM can do little about.
So this addresses Bullet 1 - the hierarchy.
The Importance Of Being Earnest
So set goals that are “in earnest” and protective, unless you really don’t care if service drops off.
Flight Level Separation
If possible keep velocities at least 10 apart, or try to merge the service class periods.
So this addresses Bullet 2 - the separation.
And Now To The Graph Itself
The graph has along the x axis WLM importance. On the y axis is the goal velocity. Each marker is a unique combination of importance and velocity. Next to the marker is a list of service class periods defined with that importance and velocity.
At least that was the first implementation.
Then I refined it (and I’m still fiddling with it):
OK. So enough prose; Let’s see some pictures.
Here are some example graphs. I’ve scaled them down to fit into the page column so you’ll find them clearer if you open the picture in a new tab or window.
First a straightforward one.
In this example there are four significant service classes: SERVERS, PRDBATHI, STCMD and PRDBATMD. Here SERVERS (assuming it has the right things in it ) is sensibly located to the right and above everything else. STCMD and PRDBATHI are together in the middle and PRDBATMD is down and to the right.
This looks like a sensible hierarchy and generally the velocity “flight levels” have good separation..
You’ll also notice a couple of (in black) Period 2 data points. Period 1 for these service classes have response time goals.
Now a case where the flight levels are too close together:
Importance 2 and, even more so, Importances 3 and 4 have lots of crowding - with velocity separations down to 2 in some cases. WLM will have a hard time working with this.
Finally a more extreme case:
Here we have several cases where 4 or even 7 service class periods share the same importance and velocity.
Limitations Of The Method
I’m going to have to think about how to plot Response Time goals - on a separate graph. There isn’t an obvious y axis. By the way, in all three examples there are service classes where the first (or first few) periods have Response Time goals and subsequent ones have Velocity goals. This is often observed - and this graph won’t show these early Response Time periods.
Also this is fairly static - being a “shift” summary.
The real question is “what do I do about flight levels that are too close together?” The ones that are identical might be amenable to combination but you can’t really combine PRDBATHI and STCMD (as in the first example) - unless these service class names are misnomers.
So this is why I consider this graphing technique a “rhetorical device”: I really want customers to think about whether it makes sense to combine service classes. And part of the motivation for this is WLM works better when the work in a service class period is sizeable.
This is also a “single system” graph and the constraints of running in a Parallel Sysplex - where there is only one WLM policy in effect for all members - aren’t reflected here. Again, doing the thinking is the important thing.
One, perhaps subtle, issue is the fact RMF records CPU in the Service Class Period where the work ended. You can see this for BATCHMED in the second example: