Some Parallel Sysplex Questions, Part 1 - Coupling Facility
MartinPacker 11000094DH Visits (3746)
In Some WLM Questions I outlined my approach to looking at WLM implementations. It was necessarily very high level, but the intention was twofold:
You could argue these two purposes are essentially what this blog is all about.
So, this post does the same thing but for Parallel Sysplex. Actually it’s Part 1 of 2, dealing with Coupling Facility (CF) questions. The other part (covering XCF) will be along presently.
Again, expect a high level treatment. There are plenty of posts in this blog that talk at a more detailed level.
(Perhaps Superfluous) Disclaimer: This isn’t all about performance and capacity, because I’m not either.
I’ll structure this post in two pieces:
That’s how I look at Coupling Facility, so it seems as good a structure for this post as any.
Note: Everything I’m talking about is instrumented with SMF Type 74 Subtype 4.
The difference, though, is in what those resources are and how they behave. For example:
So let’s examine the different types of resources.
A basic metric is CPU utilisation. We talk a lot about how busy a coupling facility should be, both for steady state and for recovery situations. As a rough guideline, a CF that tops 40% is one where I would be concerned about the effects of growth. One above 50% I’d be more immediately concerned about. Here I’m touching on the topic of “white space”.
Usually a sysplex has more than one coupling facility. While I wouldn’t be fetishistic about it, I would investigate the reasons for any significant imbalance.
Which brings us onto a point that strays into the second part of this post: We can readily see which CF structures drive CPU utilisation. So we know which structures might contribute to imbalance. We’ll come back to CF structure-level CPU in a bit.
As with CPU, the memory instrumentation is good; You can, for instance, readily see how much is installed and how much is free. Again, the concept of “white space” exists for memory. Here, we’re more interested in recovering structures from a failing CF into a surviving one.
But most of my discussions with customers about CF memory haven’t been about leaving space. I’m finding quite a few who have tons of free memory; The point has been to encourage them to exploit the memory. The structures discussion below touches on this also.
Talking of structures, my code calculates how much extra memory would be taken (and how much less would be free) if all structures went to their maximum size. Usually there’s plenty free, even if they did.
Links And Paths
I’ve written extensively about CF path statistics. These are now excellent to the point where there’s only one more thing I’d like to see: The number of times a path is chosen.
In the category of “infrastructural understanding” would, of course, be the path latency - a proxy for distance.
Here is an example of a DB2 Data Sharing group, using two CFs. The numbers are the request rates. The obfuscated text is the two CFs’ machine names.
You can, for example, see Group Buffer Pool (GBP) Duplexing but the LOCK1 structure not being duplexed.
There are a number of themes I like to explore:
There is no information on CF links at the structure level, nor do I think there needs to be.
My interest in in coupling facilities is not just performance and capacity; The setup aspects help me get closer to how it is to be a customer with a parallel sysplex (or several).
In the next post I’ll talk about XCF, the other (and original) sysplex component.