How to Use Performance Data Investigator to Look at Memory and Faulting

Steps

First, we need to understand how the IBMi uses memory and keeps objects in memory. IBMi utilizes Single Level Storage.

See Db2 for i blog on how this works as well as the concept being discussed in the IBM Documentation Center.

Single-level storage (SLS) is a computer storage model that provides "unlimited" storage for objects, pages, or addresses.  Each object has a memory location. Any object that is in the system memory can be accessed by any job/task running on the system. Memory access is also the fastest way to access the information needed. Because of these factors, the system will try to keep the memory more full/utilized than empty.   

For these reasons, memory utilization percentage is not an indicator of efficient performance so we do not worry about memory being full. It would be more concerning to have a large pool with a lot of unallocated memory that could be used somewhere else.

To view the graphs on memory utilization by pool inside of Performance Data Investigator, follow these instructions.

Substitute your system name or IP address of your partition in the following URL: http://system:2002/Navigator/login, then, log in using your credentials. 

Once logged in, click on the system you want to look at (there can be more than one here) and the Actions icon and choose Manage Node.

On the next screen we want to get into the performance data.  Click on the line graph icon then select Investigate Data.

This will bring up the Investigate Data screen where you can choose your library and dataset you want to review.

NOTE: In rare instances, you may not see your library in the list. If this happens, try rebuilding the collection table to resolve. You would go back to the line graph and choose Manage Collections then Collection Service collections. Click on Actions menu then Rebuild Collection Table. 

In the Investigate Data section you can search on Memory and select Memory Usage by Pool
 

This will bring up a series of four graphs you can scroll through. It will show you the Allocated space, the Min and Max space as well as the Unallocated memory per pool. If you have private pools or minimum values set too high inside of the WRKSHRPOOL settings, you could potentially see pools with a lot of unallocated memory. If you see this, the settings may be something you may want to revisit and see about lowering.

Another question that should be asked is, “Am I page faulting too much?” This would be an indication of not enough memory in a pool or on the system and the OS is needing to bring objects in and out of memory. 

To see the page faulting, you would want to focus in on a specific pool or set of jobs to see if a majority of their time is spent faulting or not. 

How much faulting is acceptable? That is the hard question to answer as it really depends on the workload as well as how much memory is on the system or in the pool. In the Performance FAQ, section 7.4 deals with memory questions such as faulting guidelines and when to add more memory. 

A good graph to review for page faulting is the Memory Pool Sizes and Fault Rates. You can also look at Page faults by Job or Task. These can easily be found by setting a perspective filter using the keyword Fault