In the first installment, we discussed memory pools, activity levels and job states. To use the Work with System Status (WRKSYSSTS) utility effectively to monitor and tune your system's performance, it is vital to have a thorough understanding of those concepts. That is because they underlie the key performance indicators on the WRKSYSSTS screen.
Understanding performance indicators
There are two "meters" of performance on the WRKSYSSTS display: page fault rates and job transition rates. Making sure those fall within acceptable levels is the essence of using the display to tune your system.
A page fault occurs when a job requests a page of data (i.e., a 4096-byte block of data) from auxiliary storage (i.e., DASD) that is not already in main storage (i.e., RAM). Allow me to digress here just a bit. Application programs do not typically go around requesting 4096-byte blocks data; they usually request one record at a time, which is usually smaller than 4096 bytes. However, since programs often access data (both database data and their own code data) sequentially and since sequential records are usually stored on disk consecutively, these relatively large blocks of data are brought into memory to save time. (Remember from our discussion of hard disks and how slow they are.)
Back to page faults: There are two categories of page faults, database and non-database. Database faults are related to pages of data that contain database data, while non-database pages are everything else (e.g., programs, libraries, user profiles, etc.). Page faults can occur, for example, when one of two things happens:
- A new job starts running and begins accessing data that is not already in memory.
- When a job transitions from the active state to either the wait or ineligible state and the data it was using when it left the active state gets paged-out of (i.e., removed from) memory before the job returns to the active state. That can happen to make room for other jobs, and when it does, the data must be brought back in from auxiliary storage.
- Three basic system tools to help you tune your iSeries
The best time to use the performance management tools offered on the iSeries is before crisis erupts. More often than not, however, performance management is used only in crisis situations, when the system grinds to a halt and you need to determine the cause and remedy. That means these tools are often left idle during the "normal" times when they could instead be used to create a more efficient system.
.Rqn1a2Q1JoI.3@.ee84638/3829> DASD and memory on the iSeries
One Search400.com member wondered what the best way to calculate memory and DASD on the production system was. Fortunately, some Search400.com members had some advice for him.
- Tuning the iSeries
Is there a simple way to tune up the iSeries? Site expert Tim Granatir says if interactive performance is your issue, then check the faulting rates in the various pools by using the WRKSYSSTS command.
- Perfecting iSeries performance
Looking to rev up your disk performance or tune your system? It isn't always an easy task. We've rounded up the latest news, tips, white papers and webcasts to help you achieve maximum performance on your iSeries.
The page fault rate is the average number of page faults per second during the measurement period. This number is shown under the Fault columns on the sample WRKSYSSTS display shown below in Figure 1. (Recall from our discussion of the Work with Active Jobs and the Work with Disk Status utilities that the F5 key is used to update the statistics.)
The Pages columns show the total number of pages per second referenced by the jobs running in each pool, averaged over the measurement period. The total number of pages is the sum of pages that have to be brought in from auxiliary storage (remember, these are called faults) and the number of pages referenced by job that were already in main storage.
The job transition rate is the rate per minute that jobs transition from one state to another. Three transition rates are shown, active-to-wait, wait-to-ineligible, and active-to-ineligible. You will need to press the F11 key to switch the WRKSYSSTS display from page fault information to job transition information (the F11 key also cycles through two other data displays, pool information data and paging option data). See Figure 2 below.
For our purposes, the two key job transition rates are the wait-to-ineligible and the active-to-ineligible. The active-to-wait transition rate is also important because it tells us the average number of transactions per minute. A transaction is the processing that a program performs between wait states. Example: When a program (and job) is waiting for input from a user it is in a wait state. When the user presses Enter (or some other function key), the program (and job) becomes active, does some processing, then goes back to the user and waits again -- that's one transaction.
A wait-to-ineligible transition happens when a job is ready to start executing (e.g., the user pressed Enter) but an activity level is not available. The job is put on the ineligible queue where it will wait for an available activity level. Jobs on the ineligible queue get first dibs on open activity levels and are prioritized within the queue by run priority (a job's run priority is set by the class used by the job). Although wait-to-ineligible transitions are something to avoid, they are almost an inevitable part of life during peak usage.
An active-to-ineligible transition happens when a job processing a transaction exceeds its time slice and another job is waiting for an activity level on the ineligible queue. The active job is stopped mid-transaction and put on the ineligible queue. Active-to-ineligible transitions should be kept to a minimum, but at the same time, you should not have an excessive number of jobs that exceed their time slice during a transaction. (In some cases, a program's transaction may be too complicated.)
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.
This was first published in December 2003