Paging Subsystem Design

(Originally posted 2005-07-05.)

Periodically on IBM-MAIN I’m caused to revisit something. With the advent of z990/z890 and “supposedly abundant” 🙂 real memory it seems to be time to revisit paging subsystem design.

You might perhaps think that in these days of zero paging you could skimp on paging subsystem design. And you’d be wrong. 😦

I’ve been following an IBM-MAIN discussion on this with interest. The discussion was about not exceeding 25% page data set busy. If you do, the received wisdom is that Auxiliary Storage Manager (ASM)’s Contiguous Slot Allocation algorithm will degrade. In this case utilisation means space rather than device utilisation (in RMF terms).

(There has been a change, which I don’t think materially affects this, round about the 1.2 timeframe, with a line item I’ll call more aggressive slot harvesting. But I don’t think that makes much difference to the argument about utilisation.)

Experiences in the not-too-distant past have caused me to think about page data set design from a different angle. I’ll call this the leave enough room to dump that large DB2/WAS address space argument. Actually, a fortiori, I’d say leave enough space to dump the whole of real storage. So that gives another Rule Of Thumb of leave free page space of about 1.5x the amount of real storage you have.

Note: Both the 25% and the 1.5x ROTs are trying to simplify probabilistic things (as always). So, you know in your shop what happens when you fail the ROT. In the former case paging performance tanks. In the latter it’s a real bad news day when that 6GB DB2 subsystem dumps. (I’ve seen the latter happen and it’s not pretty – when you don’t have the paging space to contain it.)

You don’t really have to choose which of these two considerations to follow. Go for both.

And finally… My friend Alvaro Salla (ex IBM Brazil) used to think the plural of Rule of Thumb was Rule of Thumbs. Makes sense as the plural of ROT must be ROTs. 🙂