Home > AS/400 Tips > iSeries administrator tips > Using WRKSYSSTS to tune your system
iSeries 400 Tips:
EMAIL THIS
 TIPS & NEWSLETTERS TOPICS 

ISERIES ADMINISTRATOR TIPS

Using WRKSYSSTS to tune your system


Ron Turull
01.21.2004
Rating: -4.79- (out of 5)


Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us   


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.

==================================
MORE INFORMATION
==================================


Rate this Tip
To rate tips, you must be a member of Search400.com.
Register now to start rating these tips. Log in if you are already a member.


Submit a Tip




Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us   



RELATED CONTENT
iSeries administrator tips
Translating Linux for IBM i admins: Using GUI to make it easy
Translating Linux for IBM i admins: Working with jobs and networking
OpenOffice: What to know before making the transition from Microsoft Office
OpenOffice: An enterprise open source solution
Database performance comparisons on IBM i
Translating Linux for IBM i admins: User profile commands
Modern System i reports using Client Access
Tips for installing Lotus Domino server on a System i partition
The iSeries Blog has a new home on IT Knowledge Exchange
Virtualization for IBM i: Backups

Systems Management
Can you trust all those trigger programs?
Are your backups complete?
Controlling remote command processing
Watch your profiles
Avoid locking issues
Send message to users at a remote site
Security journal receiver management
Top 10 backup commands
Tracking critical file access in real time
Create an iSeries Access image and update it with the latest Service Pack

OS/400
Top 10 backup commands
Take control of your iSeries
How to save time using the CPYTOPCD and CPYFRMPCD commands
Top Q&A's on the OS/400
Top 10 security tips
Use caution when providing access to file shares
How to set up an autostart job
How does Sarbanes-Oxley affect you?
Automated disaster recovery revisited
Top 10 Administrator Tips

RELATED RESOURCES
2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
Search Bitpipe.com for the latest white papers and business webcasts
Whatis.com, the online computer dictionary

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.



iSeries Security - Security Tools, Physical Security and System Security
HomeNewsTopicsITKnowledge ExchangeTipsBlogsAsk the ExpertsMultimediaWhite PapersProducts
About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites, events and online magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Site Map




All Rights Reserved, Copyright 1999 - 2009, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts