zPerformance Pay Attention To SYSSTC And SYSTEM

[Anuj Dhawan]

I was in two minds whether to do this as a screencast or a blog post. Obviously I plumped for the latter. There are a few reasons why:

• This is not terribly visual, there being only one graph.
• It’ll reach a wider audience, and the message is quite important.
• I’m feeling lazy.

Anyway, here we are and I think this is quite an important subject - so I’m glad you’re here.

Usually, when looking at WLM, we tend to ignore service classes such as SYSSTC and SYSTEM. But there are two reasons why you shouldn’t:

• What’s classified to SYSSTC matters.
• It’s not a given that it will perform well.

It’s the latter that concerns us in this post. (The former is touched on in Screencast 12 - Get WLM Set Up Right For DB2.)

From the very same data set in that screencast I saw something I’d not noticed before: SYSSTC velocity is alarmingly low.



The above is one of four systems. Each has a persistently low velocity in the range 25% - 40%.

I didn’t expect this. To be honest, I’ve never looked at SYSSTC Velocity before. And what made me see it was adding the above graph to my kitbag a few months ago 1 . (That and what happens to Importance 1, 2, etc Goal Attainment.)

Never having looked at SYSSTC velocity I have no real basis for an expectation, but this seems alarmingly low. And as I see more customer data I’ll form some “folklore in my head” about it.

So this begs the question “what is it that is making SYSSTC’s velocity so low?” The search for an answer has to start with understanding which Delay component drags the velocity down. In this case it is Delay For CPU (and not zIIP, by the way).

I would’ve thought SYSSTC was relatively protected from CPU queuing 2 but the data tells us otherwise. But consider two things:

• The low velocity is pretty consistent across the day.
• We know - from the previous blog post - there can be substantial CPU in SYSSTC at times.

So, it’s not really workload driven. So I suspect the LPAR set up and other things going on in the machine. A vague diagnosis for now. But at least I suspect something - and that’s quite an advance.

Now why is this important? If you’ve reviewed Get WLM Set Up Right For DB2 you’ll know that key address spaces, such as DB2 / IMS lock managers (IRLM), run there. Without good access to CPU these address spaces will damage performance across a wide range of work.

So this is an unusual situation - until I keep seeing this in customers. But it’s one worth looking out for.

One final thought: I probably should suppress the graph lines for SYSSTC1 - SYSSTC5 if there is no CPU in them. Oh to have some spare time.

• The “PM4050” on the graph refers to the standard graph in our kitbag that covers this ground. ↩
• After all, SYSTEM apparently is. ↩

Source: https://www.ibm.com/developerworks/comm ... EM?lang=en