How I Look At Virtual Storage
MartinPacker 11000094DH Comments (2) Visits (10259)
I thought I’d write about how I begin looking at virtual storage, occasioned by a customer who had a 24-bit virtual storage (878–10) ABEND . Most of this is in our code, so easy for me to do. I hope you’ll find it similarly easy.
The game is really to use product-neutral instrumentation first. Then use the product-specific instrumentation (where available) only where you really need it.
This post won’t talk about the latter; It’s reasonably well documented.
Almost everything I’m about to say is equally true of 24-bit and 31-bit virtual storage; Just the field names are different in the records.
I divide the analysis into two parts:
The data for the former comes entirely from RMF’s SMF Type 78 Subtype 2. For the latter it’s in the SMF Type 30 record (though you can also get SMF 78–2 information for a small number of suitably-chosen specific address spaces.
System Virtual Storage
This is easy to do. In this example the data is all 24 Bit.
The highest level view looks like this:
This is a static picture.
The first thing to notice is that the Common Boundary is at 9MB.
In case you need a larger Private Area examine the largest allocated area of Common Storage and it is, in this case, CSA.
Here’s how I begin to drill down into CSA usage (rather than allocation):
(You might want to pop it out into a different tab - as it’s quite wide.)
Each line, except the first two, represents a different time range. In this case I’m summarising at the half-hourly level. 
The first two lines are maxima and minima. In this case they show only slight variation through the day, which is good to know.
The first thing I notice about this is there is some SQA free (and in the 31-bit case I print a “SQA Overflow Into CSA” column instead - as that’s what’s happening with this set of data). SQA can overflow into CSA but not vice versa - so this is wasted virtual. I recommended decreasing the SQA size by, say, 250KB 
That’s not strictly necessary as the Minimum CSA free (rightmost column) is over 2.5MB. So an easy way to get a 10MB region is to decrease the CSA size by 1MB. 2MB would be pushing it - as the customer wants to allow the whole of Key 7 to be duplicated. 
Talking of which, you can work out which Storage Protection Keys represent the bulk of the CSA usage. In this case it’s Key 0, Key 7 and Key 8+. 
But you can go further. Look at this:
It’s Subpool 241 Key 0 that’s the biggest, then Subpool 228 for Key 8+, then evenly split Subpools 231 and 241 for Key 7.
I’ve deliberately summarised this table over a “shift” - to avoid having to make the table 3-dimensional . But the conclusion is still clear.
If you had to tune CSA usage you’d use this information and drill down further.
For completeness, here’s the Subpool breakdown for SQA:
It’s obvious Subpool 245 dominates.
Two things to note:
But you can see a good breakdown of Common Storage can be had from RMF 78–2 data.
Fortunately, we can already do enough with just a CSA reduction (and perhaps with a SQA reduction) to get us at least 1MB more 24-bit Private.
Address Space Virtual Storage
While it’s possible to examine Private Area virtual storage with SMF 78 Subtype 2 data most customers don’t set up monitoring of individual address spaces.
Instead SMF 30 Interval records tend to be readily available. So from these you can get 24- and 31-Bit “Low Private” and “High Private” numbers.
In the example customer’s case their IMS DL/I SAS (address space) takes almost the whole of the 24-bit Private Area. About half is Low Private and half is High Private.
So, working on the 24-bit virtual storage usage by this address space is strongly indicated. But having a 1MB bigger 24-bit region can’t hurt either. So I’ve advised doing both.
I’d say that - with a few exceptions - you shouldn’t obsess over virtual storage. What you should do is consider setting up some “light touch” monitoring; Perhaps CSA Free and SQA Free (24- and 31-bit) and Virtual Allocated for some key address spaces. That way the usual applies:
And I’m going to make sure in future we always pump out this sort of reporting - assuming the data’s there. And generally it is: You’re collecting it so use it.