Coupling Facility Memory

(Originally posted 2014-11-23.)

Or “who made all the pies”? 🙂

I’ve written a number of times about Coupling Facility Performance but I don’t think I’ve written about memory for a while.

In any case I’d like to share with you a couple of graphs I’ve taught my code to make. The first isn’t strictly speaking specific to Coupling Facilities. But it’s useful anyway and does help tell the story.

Machine-Level Memory Allocation

This graph is, as I said, applicable to any machine – whether it has Coupling Facility LPARs or not.

LPAR Memory allocation is more or less static, so a pie chart is appropriate. In fact my code averages over a shift. [1]

What z/OS and RMF don’t know is the amount of memory (purchased) on a machine – so the Unallocated memory can’t be depicted without the analyst (me) manually telling the code.[2] Which is why I’m not showing it here.

In this (confected) example memory usage is dominated by two Linux [3] (probably under z/VM) LPARs and MVSA. There are also two Coupling Facility [4] LPARS – PRODCF1 and PRODCF3.

This data is from SMF 70 Partition Data Report data, having avoided double-counting if e.g. zIIPs are present. In my real code I also group together the small LPARs.

Coupling Facility Memory

So let’s continue with our fictional example by examining one of these two Coupling Facility LPARs and drilling down:

This is from Coupling Facility Activity (SMF 74–4) data.

In this case I do know the Unallocated memory and so show it on the graph. It’s actually useful because it can help drive some conversations like:

• What’s your “white space strategy?”
• Perhaps you could increase the size of, say, GBP 10.

In this example I’ve marked GBP 10 with a *. In my code this denotes the structure is already at its maximum size: When defining a structure you specify its Maximum, Minimum and Initial sizes. Whether by manual intervention or using the AUTOALTER mechanism[5] the structure might grow to the Maximum. RMF documents these sizes so it’s easy to test whether a structure has grown to its limit.

Just because a structure has grown to the limit doesn’t mean you have to increase the size: RMF also documents whether the structure is full and whether this fullness is leading to such things as Directory Entry Reclaims or Data Element Reclaims. The extent to which this matters depends on the structure exploiter.

For example, the two XCF structures have their own instrumentation (SMF 74–2) which could be handy. In this case one could guess that one structure is for standard size (956 byte) messages and the other for large messages – but 74–2 data would confirm this and document the traffic.

“White space” is a complex subject and involves understanding how structures are allocated in Coupling Facilities and are to be recovered. I won’t try and do it justice in this post. But it’s a major reason why memory is left unallocated in Coupling Facility LPARs. Basically you should ask questions like “what happens if this structure fails?” and “how would I recover structures in the event of a failing Coupling Facility LPAR?” White space can be part of the answer.

 

Making Pies

I generally don’t like pie charts. But for the two cases outlined above they’re OK. The data is relatively static, though occasionally the values and names do change.

In this particular case the pie charts fill a niche in “storytelling”: I needed something to talk about where a machine’s memory is going. And I needed something to talk about the memory inside a Coupling Facility image.

What I wouldn’t like is to flash up these two charts and not dig deeper. Well, the data allows for much deeper digging; And I’m not inclined to stay shallow… 🙂

Other Posts on Coupling Facility You Might Like

I’m reminded by a friend’s question a couple of days ago I’ve written a bunch of posts on Coupling Facility. Here are a few:

• Coupling Facility Duplexing Reporting Warm-Over
• The Missing Link?
• Coupling Facility Topology Information – A Continuing Journey
• System zEC12 CFLEVEL 18 RMF Instrumentation Improvements
• Self-Documenting Systems (Actually Coupling Facilities) – One Year On
• A Small Step For RMF, A Giant Leap For Self-Documenting Systems