Memory Metrics Now That z/OS Release 8 Is Upon Us
MartinPacker 11000094DH Comment (1) Visits (18367)
I was asked an interesting question today by a customer - one with dozens of LPARs and therefore not much time to study each one in excruciating detail...
"Given that System High UIC (hereafter referred to as 'UIC') behaves differently in z/OS R.8 how should I treat it?"
I've posted on this question in MXG-L Listserver, soliciting experiences and opinions.
With z/OS R.8 we replaced the "page-UIC" method of managing memory with one very much like the old expanded storage algorithm. Pages are divided into two categories:
When we need to acquire a new page frame to back a new page request we search through pages (using a cursor) to find old pages...
I hope you'll recognise this is very much like the old expanded storage algorithm.
The consequence of this algorithm is that the UIC is now the time taken to search through the whole of memory. If old pages are scarce we need to search through more pages until we find one - and hence the time to traverse all of memory is lower. So a high UIC means relatively little constraint. A low one means relatively more constraint. In that sense UIC behaves similarly to how it did before.
The difference is that UIC ticks on up in unconstrained times - so its absolute value is less useful for Performance Analysis. So what DO I recommend?
So track all three metrics and develop a view of how your own systems behave.
And do contribute to the folklore - perhaps by replying to my post on MXG-L. There haven't been many visible R.8 customers with memory stories. So I'm hoping that means that going to R.8 was a non-event, memorywise. It has been a year since R.8 GA'ed so I'd expect to see some customers using it.
And, finally, I think this topic has got to be worth another couple of foils in my "Memory Matters in 20xy" presentation. I think it's already getting to the point where I should split it into two...