Integrating RMF 71 Memory & Large Frame Metrics with SMF

Since Db2 is typically the largest exploiter of memory in general as well as of 1 MB and 2 GB large frames, visibility into memory, paging, and large frame metrics from RMF 71 data is of particular interest to Db2 teams.

More Db2 Statistics Videos

1. Exploring Assessments of Key Metrics
2. Db2 Buffer Pool Tuning: Exploring Key Metrics (Part 1)
3. Db2 Buffer Pool Tuning: Exploring Key Metrics (Part 2)
4. Db2 I/O Cache Insights from IFCID 199 and SMF 42 Data
5. Buffer Efficiency from IFCID 199 and SMF 42
6. Measuring Benefits of Db2 Buffer Pool Tuning
7. Exploring Other Db2 Statistics Metrics
8. Walkthrough of Db2 Statistics Dashboard for Buffer Pool Tuning
9. Integrating with RMF Metrics (70, 71, 72, 74)
10. Integrating with RMF 70 and 72 CPU and WLM Metrics
11. Integrating with RMF 71 Memory and Large Frame Metrics
12. Integrating with RMF 74.4 Coupling Facility Metrics

Video Transcript

The insights into memory and large frame metrics provided by RMF 71 data play a very important role in managing Db2 operations. Since Db2 is typically the largest exploiter of memory in general, as well as 1MB and 2GB large frames, visibility into system memory related metrics provided by RMF 71 data is of great interest for managing Db2. We talked a lot about buffer pool tuning earlier, but buffer pool tuning is not just about size. Another way to achieve efficiencies when using large amounts of memory is to use large one megabyte or two gigabyte frames because large frames reduce CPU by making translation of virtual storage addresses to real storage addresses more efficient. So here we’re leveraging the Db2 statistics data to identify buffer pools with the highest get page activity rates. And these would be buffer pools that would benefit most from these efficiencies provided by large frames.

IBM made significant enhancements to the flexibility with which z/OS manages large frames beginning with z/OS 2.3. And this is not a z/OS virtual storage session, but I want to hit a couple of highlights. The big enhancement that directly benefits Db2 is that the one megabyte LF area, large frame area, is now managed dynamically by z/OS up to the size specified in the IEASYS parm light member. So that storage is no longer reserved and set aside at IPL time as it was prior to 2.3. And thus it can be allocated with some headroom and grown into as buffer pool sizes increase, which is particularly helpful since it can only be changed with an IPL.

Now, when a Db2 buffer pool’s defined to be page fixed and z/OS has one megabyte fixed frames available, then that buffer pool will be back with one megabyte large frames, resulting in CPU savings as we said, from more efficient translation of virtual storage addresses. Since the LF area parameter can only be changed with an IPL, it needs to be managed carefully. This is a Goldilocks parameter, right? You want it to be just right; too high can cause the shortage of 4K pages for the rest of the system if those additional pages are used. And that’s likely seen initially in the demand paging rate and possibly more severe symptoms, and set too low and Db2 fails to gain the CPU efficiencies that large frames could provide.

The RMF metrics for managing fixed megabyte frames in the LF area, the large frame area, are not complicated, but Db2 teams will want to have good visibility into them. So one is just the size of the LF area, the upper limit for the one megabyte fixed frames. So here, this set of systems all have limits that are a bit over 400 gigabytes.

Another metric of interest is how much the LF area is currently in use by fixed one megabyte pages, here expressed as a percentage. So utilizations for these systems tend to be running around 60%, just slightly under. Here’s a view that brings together key metrics for one of those systems in that group includes a total central storage that’s allocated to the LPAR, the size of the LF area, and then the fixed one megabyte frames that are in use and the frames that are available. So if some Db2 buffer pools could make good use of additional one megabyte frames there’s capacity on this system without a parameter change requiring an IPL.

A final use of RMF 71 metrics we’ll mention today is to keep an eye on the level of demand paging from disk that may occur as Db2 leverages more and more memory. So one approach to that uses a view like this one that assesses the paging rate in the second column here across all systems in the environment, assessing it to ensure that it doesn’t exceed the defined thresholds. From here then you can also do a system view of domain paging and in this case, that shows the desired outcome of no paging from disk. So again, indicating the potential system capacity to absorb additional memory exploitation by Db2.

Learn More About Analyzing Db2 Statistics and Accounting Data