Tuning the auto-tuner

The automatic performance adjustment on the iSeries can help you keep your system in step with workload changes. But if your workload changes very quickly, the auto-tuner may need some help from you. Dan Reusche shows you what you can do to assist it.

The automatic performance adjustment on the iSeries can help you keep your system in step with workload changes.

Automatic tuning adjusts the memory pools and the number of active jobs allowed in the memory pools to react to workload changes, and it is accomplished by setting system value QPFRADJ to 2 (Adjustment at IPL and automatic adjustment) or 3 (Automatic adjustment).

Sometimes the auto-tuner needs some help from you. There may be cases when your workload changes very quickly. For example, perhaps your system is primarily interactive during business hours but changes to mostly batch after hours. At the time that your batch run first starts, the majority of the memory may still be in the interactive pool and the tuner may be too slow to react, causing excessive paging in the batch pool(s) until the tuner can catch up. By setting a minimum value for the amount of memory given to both the interactive and the batch pool(s), you can lessen or eliminate the negative impact of a sudden change of interactive to batch load (and back to interactive). In essence, you are putting some restrictions on the auto tuner so that it can't over- or under-commit the amount of memory in a given pool. This is accomplished through the Work with Shared Pools (WRKSHRPOOL) command.

More Information

To get to the screen where you can set the minimum (and maximum) pool sizes, enter the WRKSHRPOOL command and press F11. You will see a screen like the one shown in Figure 1.

______________________________________________________________________________________

                             Work with Shared Pools                            
                                                             System:   SYS1    
 Main storage size (M)  . :        5038.75                                     
                                                                               
 Type changes (if allowed), press Enter.                                       
                                                                               
                       -----Size %-----  -----Faults/Second------              
 Pool        Priority  Minimum  Maximum  Minimum  Thread  Maximum              
 *MACHINE         1     18.00      100    10.00     .00    10.00               
 *BASE            1      5.00      100    12.00    1.00      200               
 *INTERACT        1     10.00      100    12.00    1.00      200               
 *SPOOL           2      1.00      100     5.00    1.00      100               
 *SHRPOOL1        2      1.00      100    10.00    2.00      100               
 *SHRPOOL2        2      1.00      100    10.00    2.00      100               
 *SHRPOOL3        2      3.00      100    10.00    2.00      100               
 *SHRPOOL4        2     11.00      100    10.00    2.00      100               
 
                                                                        More...
 Command                                                                       
 ===>                                                                          
 F3=Exit   F4=Prompt   F5=Refresh   F9=Retrieve   F11=Display text             
F12=Cancel                                                         

Figure 1: WRKSHRPOOL View 2

Note that towards the top of the screen you will see the total amount of memory allocated to this system or partition. In this case, the total is around 5 GB (5038 MB).

The place to start your tuning efforts is always the *MACHINE pool. That is where the majority of the system's jobs and tasks run. If that pool does not have enough memory, it can affect all jobs in the system. There may be some trial and error involved in getting the minimum pool size set correctly, but a good place to start is by observing the pool size at various times of the day by using either WRKSYSSTS or by running a System or Component Report from Performance tools. Try to remember to set the minimum pool size for the *MACHINE pool large enough so that your Non Db page fault rate stays below 10 (the closer to 0, the better).

Once you have the *MACHINE pool sized correctly, you can proceed to setting the sizes of your interactive and batch pools. Again, check the pool sizes at various times of the day, when you know what the workload balance looks like. For example, during the day, when the system is running mostly interactive work, note how much memory is being left in the batch pool(s).

Pay very close attention to what happens to paging in the batch pool(s) during the times immediately following the transition of the workload from interactive to batch (and vice versa). If the paging goes up dramatically for a period of time after the change, that means the auto tuner has taken too much memory away from one set of pools (batch or interactive) and can't give it back fast enough. If you have enough memory in your system, try setting a higher minimum for the pools that are suffering at the transition times so that there is a "buffer" of memory to better handle the workload change from interactive to batch (or vice versa). If your system does not have enough memory to allow that, then you may have to look at other methods of moving the memory quickly at the transition times, such as putting some CHGSBSD commands for the appropriate interactive and batch subsystems on the job scheduler.

One of the best tools I have found to watch how memory is being moved around in the system is the Storage Pool Activity of the Component Report. To create this report, use STRPFRT, option 3, Print Performance Report. Pick a time frame and use option 2 to select a component report. You can run the entire report (which can become very large) or just select the Storage Pool Activity section of the report. Then select the time frames of interest or select all times. What you end up with is a report that shows the pool sizes and activity for each collection interval selected, sorted by pool ID. An example of a report is shown in Figure 2, which shows activity for Pool identifier 2, which is the *BASE pool.

  Pool identifier . . . : 02 Expert Cache . . . :  3                                                                                
          Pool                               Avg                ---------- Avg Per Second -----------    ----- Avg Per Minute ----
 Itv      Size        Act      Total         Rsp      CPU       ------ DB ------   ----- Non-DB -----    Act-      Wait-      Act-
 End      (KB)       Level      Tns          Time     Util      Faults    Pages     Faults     Pages     Wait      Inel       Inel
----- -----------    -----  -----------     -----    -----      -------   ------    -------    ------   ------    ------     -----
00:15   1,728,540      117            0       .00    999.9         18.1      127      275.1       306     2485         0         0 
00:30   1,375,300      117            0       .00    999.9           .4      129       13.1        43     2405         0         0 
00:45   1,470,484      117            0       .00    999.9           .6        3        4.6         9     2416         0         0 
01:00   1,219,280      117            0       .00    999.9           .0        2         .2         1     2395         0         0 
01:15   1,346,920      117            0       .00    999.9           .0        7        1.1         4     2410         0         0 
01:30   1,454,808      117            0       .00    999.9           .1       73         .5         3     2390         0         0 
01:45   1,603,620      117            0       .00    999.9           .0       69         .2         2     2381         0         0 
02:00   1,484,676      140            0       .00    999.9           .2        2       10.3        31     2312         0         0 
02:15   1,130,964      140            0       .00    999.9          1.9       44       84.7       140     2188         0         0 
02:30   2,057,188      140            0       .00    999.9         29.6       50      177.2      1851     2077         0         0 
02:45   2,118,600      140            0       .00    999.9         56.3     2920      162.3      1273    10653         0         0 
03:00   2,092,364      140            0       .00    999.9         24.7     3854      104.2      1850    12386         0         0 
03:15   1,402,300      140            0       .00    999.9          1.6        4       75.0       172     2088         0         0 
03:30   1,258,952      168            0       .00    999.9           .5        2        4.4        20     2328         0         0

Figure 2: Component Report, Storage Pool Activity

In the above section of the component report you can see there are a couple of times during the early morning hours where the pool size is too small and excess paging is occurring. Note the pool size at 2:15 and then again at 2:30. The performance adjuster has moved a lot of memory into the *BASE pool in this 15 minutes, but the paging was still high. If we can afford to set the minimum amount of memory in the base pool closer to 2G, paging will be reduced significantly and jobs running at that time will run faster. However, if the minimum for the *BASE pool comes at the expense of the interactive pool, then we might move the problem to our interactive users at 8 a.m., when they come in and sign on. You'll want to be sure you have a good minimum value there as well.

You will need to know the types of workloads that are on your system, as well as the times that these workloads occur and change. You will also need to make some decisions about which workloads are most important to your business or whether you should buy additional memory to provide the needed cushion against sharp workload changes. Once you have that information and have made your decisions, you can tune your auto-tuner for better overall system performance.

---------------------------
About the author: Dan Reusche is a senior systems administrator at Think Federal Credit Union in Rochester, Minn. He has worked with the IBM AS/400 and iSeries platform since 1988, when he worked at the IBM Rochester Development Lab and support of AS/400 systems used within IBM. You may contact him at dreusche@chartermi.net.


This was first published in November 2005

Dig deeper on Performance

0 comments

Oldest 

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:

SearchEnterpriseLinux

SearchDataCenter

Close