Tip

How to increase performance by grouping users into separate storage pools -- Part I

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.


Ron Turull

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
==================================


This was first published in February 2004

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.