(Originally posted 2017-10-24.)
It’s been a month since I last did a screencast – and boy what a busy month I’ve had.
And in that month I had the privilege of working with a very nice customer, exercising my DDF Analysis code.1
As so often happens, a graph or two come together to tell a nice story. One I shared with the customer, and one I’m sharing with you.
Because graphs are involved the natural medium for sharing it is a short video, so that’s what I made. You can find it here.
I think the background to the topic is quite important, so I preface the actual customer case with some educational material. Indeed there is a key point I’m keen to get across:
Guarding against ill-behaving (or “feral”, as I like to call it) is important. It’s insufficient to rely on Security mechanisms and DB2 controls to avoid feral DDF misbehaving. And misbehaviour matters. In the example I give it’s CPU – both GCP and zIIP – that is consumed by the engineful2. But it might be precious DBATs, or other DB2 resources.
To clarify, while most people are interested in CPU as it relates to capacity planning (and software cost), I’m more worried about bursts of CPU affecting critical infrastructure. Though, I’ll admit, a (thick) veneer of “low value” DDF usage through a protracted period is worth managing down.
But this isn’t an easy phenomenon to control, particularly for egregious short-commit-scope work (aka bursts of small transactions).
One of the key sources of data is DB2 Accounting Trace (SMF 101) because it gives much finer timestamp granularity than RMF SMF. Further, the ability to identify a spiky consumer is pretty good. I advocate summarising at the 1-minute level, perhaps breaking out by IP address or Authid. This is realistic for me as I’ve built some nice DFSORT-based code to do the analysis.
The graphs come from CSV files created by this code. The question is whether you, dear reader, have access to a way of summarising individual 101 records in this way. I would assume, for example, MXG would allow you to. But I can say that the DFSORT code I use is very fast and very light.
Anyhow, I hope you enjoy the video (and the others in the series).