Bitesize Blogging: MQ V8 – z/OS Buffer Pools, to fix or not to fix
PeteSiddall 110000AAJG Visits (3101)
Another in the series of bitesize blog posts about features in MQ V8. Check out the whole series here.
All messages stored in MQ on z/OS private queues are associated with pages in a pageset. In turn you can think of these pages as being cached in real storage by so called buffer pools. Every MQPUT and every MQGET will touch pages in the buffer pool, and, if the queue size exceeds the buffer pool size, MQ will write (spill) the messages to the pageset, and read them back in as required. MQ also periodically checkpoints the pagesets by updating current persistent data on to the pageset. Checkpointing is infrequent compared with puts and gets, so a given page will have been reused for many different messages between these writes.
It's obvious that if the data you want isn't in the real storage cache, it takes longer and costs more CPU to read it in from pagesets on disks. It's less obvious that if z/OS decides to page some of your bufferpool out, then there is an equivalent disk read required to pull it in from auxilliary storage, but most systems are configured so that they don't page. The ideal buffer pool never pages.
There is a counter argument that says real storage is a valuable resource and we should let the system allocate it to the processes which can most benefit. Maybe, but not in the way it used to be: sure in 1984 my uni supported 100s of us with a 32MB 3081, but in 2014 my phone has 2GB real, and my laptop 16GB – it's a reasonable expectation to use a bit more in a mainframe that supports an entire business, after all, a zEC12 supports TB of storage. Moor's law has pushed the differential between processor speed and disk speed to be so huge, we need more real storage everywhere to buffer that difference.
In MQ V8, buffer pools can be configured to use page-fixed storage with the new PAGECLAS(FIXED4KB) attribute, effectively dedicating some of the machine's real storage to this piece of MQ cache. Using it means:
Use it where you want the optimum performance. Maybe not for you if you have a cyclic workload and sometimes MQ isn't the most important component in your system and you get more value from the real storage by letting it go elsewhere.
If you've got this far, I'm sure you'll agree MQ is always the most important ;-) and thanks for your attention.