Problem solve Get help with specific problems with your technologies, process and projects.

Using WRKSYSSTS to tune your system

The WRKSYSSTS display provides two ways to tune your system. Using those methods, follow these five steps to bring your system in line.

Once you understand how to assess performance (see the previous two installments, "How to use the WRKSYSSTS to monitor your system -- Part I" and "Part II"), basic tuning of your system is relatively straightforward. There are two ways to tune your system on the WRKSYSSTS display:

  1. Adjust pool size to reduce page faults. Increasing a pool's size reduces page faults because more memory is available to the jobs running in the pool. Since more pages can be stored in memory, the probability that a job's data will get paged-out of memory while the job is in a wait state goes down.
  2. Adjust activity levels to minimize wait-to-ineligible and active-to-ineligible transitions. Increasing the number of activity levels for a pool (listed under the Max Active column on the WRKSYSSTS display) will decrease the wait-to-ineligible and active-to-ineligible job transition rates. Also, by minimizing the active-to-ineligible transition rate, you can reduce the page fault rate. (Jobs that are transitioned from active to ineligible will frequently have their data paged-out of memory before they can get another activity level.)

Ron Turull

Five steps to basic system tuning

The goal is to make sure page fault rates and job transition rates (wait-to-ineligible and active-to-ineligible) fall within acceptable levels for each pool individually and for the system as a whole. (Note: some of these levels differ depending upon the iSeries-AS/400 model.) Use the tuning methods discussed above to achieve the following goals.

  1. Tune the page fault rate in the machine pool. The machine pool is always the first pool listed on the WRKSYSSTS display (system pool 1). It is different than the other pools because it never has database faults. That is because jobs running in the machine pool do not access database pages, only non-database pages. Also, the only way to tune the machine pool is to adjust pool size because there is effectively no limit on the number of activity levels available in the machine pool (evidenced by the +++ in the Max Active column).

    Because the jobs that run in the machine pool "service" all system jobs, it is vital that page faults be kept to a bare minimum in this pool. Best performance is achieved when the page fault rate in the machine pool (remember we are only talking about non-database page faults here) is kept below 2 per second. And, you should never let the page fault rate in the machine pool go higher than 5 for an extended period.

  2. Tune the page fault rate in the other pools. The rest of the pools are all tuned to same target performance levels. The first target is the total page fault rate per pool (i.e., the sum of the database and non-database page fault rate). The target level depends on the average number of active threads in the pool. IBM makes the following recommendations:

    • Interactive pools: 0.5 faults average per thread per second (min 5, max 200).
    • Batch pools: 2.0 faults average per thread per second (min 10, max 100).
    • Spool pools: 1.0 fault average per thread per second (min 5, max 100).
    • *BASE pool: 2.0 faults average per thread per second (min 10, max 100).

    For example, if an interactive pool averages 20 active threads, then the target total page fault rate is 0.5 x 20, or 10.0 total page faults per second.

  3. Tune the systemwide total page fault rate. Add all the page fault rates shown on the WRKSYSSTS display. This systemwide page fault rate should fall below a maximum calculated by multiplying your total interactive pool target rate by 1.5. For example, if we have just one interactive pool and its target rate is 10.0, then the overall total system target rate would be 15 (i.e., 10.0 x 1.5). The maximum system rate is 350. That means you should not, for example, have four different pools all page faulting at or under their target rate while the total systemwide fault rate is more than 15 (or whatever number the calculation determines).
  4. Tune the wait-to-ineligible job transition rate. Adjust the activity level so that less that 10% of transactions go from wait to ineligible. That is, the wait-to-ineligible rate divided by the active-to-wait rate should be less than 0.1.
  5. Tune the active-to-ineligible job transition rate. We really like to see the percentage of jobs going from active-to-ineligible as close to zero as possible, especially in the interactive subsystems, but achieving that can sometimes involve redesigning some of your applications. In the meantime, never allow this percentage (determined by dividing the active-to-ineligible rate by the active-to-wait rate) to get higher that 10%. Tip: If you are having difficulty achieving this target by adjusting activity levels, try increasing the time-slice for jobs running in the pool (the time-slice for a job is determined by the class which is referred to by the routing entry the job uses).

Note on the base pool. The base pool is always the second pool listed on the WRKSYSSTS display (system pool 2). You cannot directly change its pool size because its size is determined by whatever memory is not allocated to the other pools (subject to the minimum size of the base pool as specified by the QBASPOOL system value). Other than that, the base pool is tuned the same as the rest of the pools.

Watch-out for the QPFRADJ system value
This system value can be used to let the system tune itself. While automatic tuning can be quite helpful, there are many complex system and user configurations that demand manual tuning. When manually tuning your system using the above techniques, make sure the QPFRADJ system value is set to 0.

Advanced tuning
We have covered the basics of system tuning. Nearly always, the five tuning steps will bring your system in line. On rare occasions, however, they may not. In the next few installments, we will take a look at some more advanced tuning techniques that you can use in those instances or when you are just trying to squeeze every last drop of performance out of your system.

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.


Dig Deeper on Performance

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.