zIIP And DB2 Version 10 DBM1

(Originally posted 2014-04-14.)

This post adds some additional DB2 Version 10 specifics to what I mentioned in New zIIP Capacity Planning Presentation. I said this would be a living presentation, and so it has proven to be. It’s had two outings so far and there are a couple more confirmed.

First the times I’ve given it:

• On 9 April 2014 I was very pleased this was the very first presentation given at the GSE/UKCMG zCapacity Management and zPerformance Analysis Working Group in IBM South Bank.
• This past week I tried it out as the jumping off point for a single-company discussion on zIIPs.

Now what’s ahead:

• I’m using the material again in another single-company setting. I’m quite keen the material can be used this way as I think a lot of installations will want to think the subject through.
• At the System z Technical University, 12 – 16 May in Budapest, I’m presenting to a (hopefully) much larger audience. Do come along if you can!

So since after these two outings I’ve extended the presentation by a couple of slides – and it’s these new topics I want to discuss in this post. They are:

• Subcapacity General Purpose Engines (GCPs)

and

• DB2 DBM1 zIIP Eligibility levels in DB2 Version 10

Subcapacity General Purpose Engines

I’m seeing quite a few installations with “subcapacity general purpose engines” – such as zEC12 Model 6xx processors. As you probably know with these the effective capacity of the GCPs is less than that of a 7xx but the zIIP (and ICF and IFL) engine capacity is the same as that of a 7xx GCP engine.

For example a z196–6xx has GCPs that are roughly half the speed of the zIIPs. And a zEC12–5xx would be a little more than 1/3 the speed of the zIIPs[1].

Having a faster zIIP than GCP can be good news as each zIIP could process CPU-intensive work faster and has more capacity. On the other hand when zIIP-eligible work runs on a GCP (as it might do in times of zIIP Pool stress) stuff (maybe “CPU Stringent” stuff) will run slower – introducing variability.[2]

It’s tempting to configure fewer zIIPs than you might if they’re, say, three times faster than the GCPs. I’d be cautious about that – because of the queuing effects[3] and the drop in performance that running zIIP-eligible work on a GCP might bring.

DB2 Version 10 zIIP Eligibility

One discussion I had was about an imminent migration from DB2 Version 9 to Version 10. In this case the use of zIIP by DBM1 is entirely new. My off-the-cuff response was to estimate the whole of DBM1 going to zIIP upon migration. This is, as you would probably guess, an overestimate. But it’s good enough for checking you have enough zIIP capacity to take the additional demand.

But I went back to the data I have from two DB2 Version 10 customers:

• Client A has no zIIPs.
• Client B has zIIPs.

After a head scratching moment I was pleased that I had both cases: The data appears to behave differently in the two cases, but in reality it’s consistent.

Here’s the unifying piece of information – that got me beyond head scratching:

Field SMF30CPT – which contains TCB and similar – includes zIIP-eligible work that runs on a GCP. It doesn’t contain zIIP-eligible work that actually does run on a zIIP.

Client A

The following is a graphic I already had in the presentation. (You might want to pop it into a separate tab in your browser.)

As I said they have no zIIPs so all zIIP-eligible work is included in the TCB number in the table.

If you look at the “DSNRDBM1” row in the table you see the TCB is 1.0% of an engine and the zIIP-on-GCP number is 0.84% of an engine. All the Dependent Enclave CPU is zIIP-eligible[4].

So somewhere between 80 and 85% of all the DBM1 CPU is zIIP-eligible – dividing 0.84 by 1.0 or so.

By the way, SRB is tiny so I’ve not displayed it.

Client B

Remember Client B does have a zIIP.

Again, any zIIP-on-GCP CPU would appear in the TCB number – but here it’s tiny. All the zIIP-eligible work does indeed run on a zIIP, so isn’t included in the TCB value.

As a one-off [5] I’ve created the following graph that explores zIIP-eligibility by time of day. I’ve added it to the presentation.

It shows generally zIIP-eligibility is in the region of 70 – 80 % of the total, consistent with Client A. The reason for creating it was to see how much the zIIP-eligibility varies. For this customer there is some variation and indeed a few sekips[6]. These, if one were to take the trouble to explain them, would probably turn out to be periods of low Prefetch and low Deferred Write. One might hazard a Direct and Read-Only situation could lead to a much lower level of zIIP-eligibility.

So, I would think it reasonably important to measure what proportion of DBM1’s CPU is zIIP-eligible but expect it to be in the region of 3/4. If you’re going to Version 10 from Version 9 I would provision enough zIIP CPU to support 100% but expect rather less.

---

I’ve enhanced the presentation with the above and that’s what I intend to give in Budapest and use in this next customer discussion. It might evolve a bit in the meantime – and that’s OK. The next version going up on Slideshare will probably be after Budapest, so mid May.

And I already know I need to do some work on the changes on DB2 Version 11 which promise more DB2 zIIP eligibility: I haven’t done the research yet.