Over the past few months, we've discussed how to use the Work with Active Jobs (WRKACTJOB) and the Work with Disk...
Status (WRKDSKSTS) commands to do basic performance monitoring and performance tuning of/for your system. In this and the next installment, we'll take this process one step further as we discuss how to use the Work with System Status (WRKSYSSTS) command to monitor your system's performance. This, in turn, will be followed-up with an in-depth look at how to use WRKSYSSTS command to do more specialized tuning.
Understanding pools and activity levels (the resources that affect performance)
Like any computer, your AS/400-iSeries has a limited amount of main storage (i.e., RAM) with which to work. As with all multi-user, multi-tasking computers, the RAM must be shared by all users and tasks. On the iSeries, the RAM is actually divided up into pools, which are then dedicated to certain types or categories of work.
The most important type of work on the iSeries is machine-related work (i.e., the programs that run the computer). This type of work is done in a specialized pool appropriately called the machine pool. The machine pool is always the first pool listed on the WRKSYSSTS display (i.e., pool 1). Tuning this pool properly is of the utmost importance.
Pools can be shared -- like the machine pool -- which means jobs from multiple subsystems can share the pool (the machine pool is shared by all jobs without needing to specify it in the subsystem description). Pools can also be private to a particular subsystem, meaning only jobs running in that subsystem can use that pool.
Within each pool is a limited number of activity levels. Activity levels are job slots, or the maximum number of jobs that can be actively running at any given moment in that particular storage pool. (Actively running refers to a job that is actually executing, not -- for example -- an active job that is sitting idle waiting for user input.) You can think of activity levels as the car bays at an automotive repair shop; only one car can be in each bay at any given time being serviced. Cars waiting to be serviced must wait for an available bay.
Don't confuse active in an activity level with active in a subsystem. Using the automotive repair shop analogy again, when a job enters a subsystem, it does so through a job queue. This job queue is like the line (or queue) of cars outside the repair shop waiting to get "written-up" and dropped off. Once a car gets written-up and admitted into the repair shop it becomes active like a job becomes active when it gets off the job queue and into the subsystem. But like that car, even though the job is active in the subsystem (in this analogy, the subsystem is the repair shop premises), it may not be getting actively worked upon (i.e., the car may not be in a repair bay).
Three job states define job execution
There are three states that an active job (i.e., admitted to the repair shop premises, but not necessarily an actively running job) can be in:
- Active state. This is the state a job is in when it is actively running (i.e., in a repair bay being work upon). A job in the active state occupies an activity level. There is a sub-state of the active state called the short wait state that is used when a job is waiting for some resource, such as data from auxiliary storage, that usually becomes available in a short amount of time (i.e., 2 seconds or less). If, after 2 seconds, the resource is still not available, the job is put into the wait state. This is analogous to a car that is in a repair bay and waiting for a part; the mechanic is not working on the car -- instead, he is checking if they have the part needed in inventory.
- Wait state. A job is in the wait state because of one of three reasons. 1) It was put there after a short wait because the resource was not available within 2 seconds (called a short wait extended). This is analogous to the mechanic having to order the part, so he pulls the car out of the bay and pulls another in. 2) The job was put there immediately from the active state because it is waiting on a resource that usually takes longer that 2 second to become available (called a long wait). 3) The job is waiting for user input (called a key/think wait). Jobs in a wait state do not occupy an activity level.
- Ineligible state. This state actually consists of an ineligible queue. Jobs get put on this queue in one of two ways: if a job is ready to begin executing after a wait state, but there are no activity levels available, or an active job exceeds its time slice, and there are other jobs on the ineligible queue waiting for an activity level.
In the next installment, we'll discuss how to read, understand and interpret all the numbers on the Work with System Status screen and what implications they have in improving your system's performance.
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.
- 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.
- How to track response times with the WRKACTJOB tool
To obtain maximum productivity from computer users, it is essential to limit the computer's interactive response time to 1 second or less. Using the Work with Active Jobs screen you can see detailed performance data for each job listed.
- Old recommendations for WRKACTJOB no longer true
In the Oct. 1 Administrator Tip there was an article on the proper way to end WRKACTJOB. Vernon Hamberg says it is in error, as WRKACTJOB has been changed since this information was correct. What's the correct way? Click over and find out.