zIIP / zAAP Capacity Planning

(Originally posted 2012-08-04.)

I’m not a capacity planner but I play one on TV¹ sometimes.

A customer asked me about the subject of zAAP Capacity Planning so I thought I’d post a few thoughts here. (Almost everything I say here is equally true of a zIIP.)

The main point is I don’t think it terribly different from regular CPU Capacity Planning. But there are some quirks:

• While we do have queuing we also have Crossover. But at least we have good numbers for the latter.
• We have numbers for potential use – through the "Project CPU" mechanism.³.

One thing I’ve said consistently since Processor Pools became a meaningful concept (with the advent of ICF⁴ engines in 1998) is "Report and Manage Processor Pools Separately".

I still think that’s right but there are some considerations with that, most notably in when work eligible for one runs on another:

1. Crossover – where work that’s eligible on a zIIP or zAAP runs (partially) on a GCP⁵. These GCPs might well run slower than the zIIPs or zAAPs, of course. And that eventuality is catered for by RMF.
2. zAAP on zIIP – where zAAP-eligible work runs on a zIIP⁶
3. No zIIPs or zAAPs – where work has to run on GCPs instead.

Actually Cases 1 and 3 are quite similar, even if the mechanisms are different.

I’ll confess I took a decision a while back not to become too obsessed by what the various parameters that control crossover actually do. This is because they evolved somewhat over a short period of time. These days I prefer to see what the data says is happening in a given situation and think about how that could be improved. Usually it’s a trade-off between degree of offload to zIIP or zAAP versus responsiveness. (I’ve seen problem cases in both categories.)

At this point I’ll note that I’ve written a lot about zIIPs and zAAPs in the past. Here are the posts that spring to mind…

• When Good Work Doesn’t Go To zIIP / zAAP Heaven (2007)
• zAAP and zIIP Revisited (At Last) (2011)
• zAAP and zIIP Delay (2011)

So, all of the things I’ve talked about are things to bear in mind when doing zIIP and zAAP Capacity Planning, over and above the usual. So let’s talk about “the usual”…

You can readily figure out how much of the zIIP (or zAAP) pool is being used and by which address space. Many exploiters will tell you well below the address space level. For instance DB2 and DDF – using Accounting Trace. And much of that (via PROJECTCPU) is available for currently-running eligible workloads. So current usage is no problem.

Assuming your application isn’t changing its profile of e.g. zAAP vs GCP then forward projection is as it ever was. But, here are two cases where the ratio may well change:

1. Over time DB2 has changed the way its offload to zIIP function has worked – both eligibilitywise and how it actually distributes the benefit.
2. If you were to, say, replace JNI methods with native java then the offload proportion would change. In this case for the better. Maybe a different JDBC driver could cause that.⁷

So the assumption that an application doesn’t change its profile is probably right most of the time, but certainly worth keeping an eye on.

Maybe this post doesn’t answer the original customer’s question directly – but in an informal medium such as this I hope it contributes to the discussion. As I said at the start, this is pretty much “same as it ever was”⁸ but with a few wrinkles.

1. Mainly on Channel z². 🙂
2. OK I’ve done this joke before: The B-52’s – Channel Z Lyrics
3. I’m sure I’m stating the obvious when I say that this only works for workloads already running. Other estimation techniques are necessary for fresh ones. The most notable example of this is IPSec which most customers didn’t use prior to the advent of zIIP support.
4. Internal Coupling Facility, introduced with G5 processors.
5. General purpose processor.
6. But only if there are zIIPs but no zAAPs in the processor complex.
7. I think this happened with Type-2 to Type-4 driver conversions. Someone correct me if I’m wrong, please.
8. Second song reference in the one post. 🙂