(Originally posted 2007-09-27.)
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:
- Those without the Reference Bit set (regarded as “old” pages).
- Those with the Reference Bit set (regarded as “new” pages).
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…
- If the Reference Bit is set we reset it.
- If the Reference Bit was not set we reuse the page frame. If the Changed Bit is set we page out the contents. If not we discard them.
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?
- I recognise that the “state of the art” is evolving – so this is subject to revision / abandonment etc…
- I still recommend understanding how many pages are free.
- The UIC still has value in that a low value is still meaningful. Therefore I would want to keep track of the MINIMUM value during your focus window (perhaps prime shift) as that’s the worst memory constraint gets.
- Paging rates are still important.
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…
- System Memory Performance Management
- Subsystem and Application Memory Performance Management
2 thoughts on “Memory Metrics Now That z/OS Release 8 Is Upon Us”