In the last several installments, we've taken a look at how to monitor your system's performance and the basics behind tuning your system. Now, we will look at some specialized tuning techniques that can make the difference when trying to make your system fall within the standard performance levels specified in the last installment, "Using WRKSYSSTS to tune your system".
Memory pools basics
Every subsystem description includes a list of one to 10 pool definitions. (To see the pool definitions for a subsystem, use the DSPSBSD command and choose option 2 on the resulting screen.) Jobs must execute in one of the pools defined in the subsystem in which the job is running. Jobs are routed to a particular storage pool via the storage pool identifier on the routing entry used by the job.
Shared pools vs. private pools
There are two types of storage pools: shared and private. Shared pools can be shared by (and, hence, are defined in) multiple subsystems. If one subsystem is not making use of a shared pool, another subsystem can use it.
Private pools are private to a particular subsystem. Only jobs running in the subsystem can be routed to that subsystem's private pools. Unlike shared pools, if the memory of a private pool is not being used by the subsystem, it is, in essence, wasted because no other subsystem can use it. However, looking at it from the side of "the glass is half full," because no other subsystem can use a private pool, it is essentially reserved for jobs running in the associated subsystem.
Fourteen predefined shared pools
There are 14 predefined shared pools on the iSeries, all identified with a special name (*MACHINE, *BASE, *INTERACT, *SPOOL, and *SHRPOOL1 through *SHRPOOL10).
- The machine pool (i.e., *MACHINE) is automatically shared by all subsystems without having to be added to the subsystems' pool definitions. It is used by low-level operating system functions.
- The base storage pool (i.e., *BASE) is that special storage pool whose size is defined at any given time by the amount of memory left over by all the other pools. Subsystem descriptions shipped as part of OS/400 all include shared pool *BASE as the first (and sometimes the only) pool defined to the subsystem.
- *INTERACT is meant as a shared pool for interactive jobs, and *SPOOL is meant for spool-related work (e.g., spool writers). However, the system cannot enforce such rules, so you can route any type of job to either one of these shared pools.
- *SHRPOOL1 through *SHRPOOL10 are general-purpose shared pools. You can use them in any way you see fit.
Separating jobs into different pools can improve performance
Separating jobs into different storage pools according to activity type can be an effective way to minimize response times, page faults and wait-to-ineligible transition rates. (For a description of wait-to-ineligible transition, see "How to use the WRKSYSSTS to monitor your system -- Part I" and "Part II".)
The classic scenario involves order-entry personnel or any type of steady data-entry job. The number of interactions (i.e., pressing the Enter key, or other function key) created by these users far exceeds the number of interactions created by other users in a typical shop. And a key ingredient for making data-entry personnel as productive as possible is to make sure they never have to wait on the computer. That means requests by those users must be handled promptly.
Handling a request promptly involves two steps. First, making sure an activity level is available for the requesting job. Second, reducing the number of page faults required to process the request.
Placing data-entry type jobs in their own storage pool can effectively accomplish both steps. The trick is to define the storage pool with enough activity levels and memory. This, of course, will decrease the memory available to other users, but since they are "casual" users making fewer request, they can efficiently get by with less.
Calculating the initial parameters of the pool (i.e., the number of activity levels and the storage pool size) therefore becomes paramount. We will cover that in depth in the next installment. Until then, you might want to take the opportunity to study your system(s) and your users. Group your users into high repetitive use, medium use and seldom use groups. Make sure systems are in place for coordination between the personnel and IT departments, so when employees are moved/transferred around, their grouping can be re-evaluated.
-----------------------------------
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years experience programming for and managing AS/400-iSeries systems.
==================================
MORE INFORMATION
==================================
