ISERIES ADMINISTRATOR TIPS
Performance tuning for IBM i: The basics and beyond
Raymond Johnson, Contributor
11.06.2008
Rating: -4.33- (out of 5)
[IMAGE]
[IMAGE][IMAGE]
Raymond Johnson
[IMAGE]
[IMAGE]
Disclaimer: The following information is based on over 20 years of experience with small AS/400's and over 30 years working with computers. The guidelines presented here that have served me well. Your mileage will vary depending upon factors such as hardware, software, users, time of day and possibly the phase of the moon.
The high performance of today's machines along with the improvements of the operating system in general and the Automatic Performance Tuner in particular have made most of these suggestions much less important than with earlier machines and operating system release levels.
Below are five questions that were posed by a Search400.com reader. I have provided very brief answers immediately following the questions. At the end of the questions I have provided some additional details about Question 2.
- Top 5 quick hits you can implement or check to improve performance that would give you the fastest noticeable improvement?
- Add more system memory.
- Make better use of the existing memory by performance tuning.
- Separate batch from interactive work in memory pools.
- Keep frequently used large file in memory all the time.
- Keep disk utilization below 70%.
- What should the DB and non-DB Faults normally be on the WRKSYSSTS screen?
- The lower the better.
- For good performance numbers should be 10 or less.
- IBM used to publish specific numbers for specific processor models with specific amounts of memory.
- My experience has been that keeping the numbers below 50 is usually good, and below 10 is excellent.
- What is the "normal" range of jobs in the system, as also listed on the WRKSYSSTS screen?
- What is a normal system? Some system have 1 user, some system have 200,000 users or more.
- I suspect that the real question is what is normal for 'MY' system? Well that depends.
- My system is a 170. The machine is used strictly for testing. It does server my web page. I have 103 spool files of disk utilization history, one for the last 103 weeks.
- Fact: Every spooled file remaining on the system has a job, and thus a job count associated with it. If you have 200,000 spooled files created by 200,000 different jobs, you will see all 200,000 on the WRKSYSSTS screen.
- Based on my current system, the 'normal' number of jobs would be 170'.
- I arrived at this number by deleting all the spool files on my system and seeing what was left. Currently on my system I have 273 jobs listed in WRKSYSSTS. With my one interactive job running, one web server running, and 103 spool files of historical disk utilization data and no other spool files on the system my empirical evidence says 170 jobs is normal.
- Your mileage will vary.
- Usually the most confusing part of this number is the number of spooled files left around.
- How important is it to ...
To continue reading for free, register below or login
To read more you must become a member of Search400.com
remove the DELETED records from files in terms of performance?
- Again, that depends on several things.
- If the file is very large, and the file has very many deleted records and the file is opened and read very many times throughout the day, then it is very important.
- If the file is very small and opened once a month, then it could be 90% deleted records and probably no one would even notice.
- How important is it to run the RGZPFM command on PFs and how does one determine the LF to use in the KEYFILE parameter?
- This is actually a few questions: How important is it to run RGZPFM? How big is the file? How many records re in the file? How big are the records in the file? How many deleted records are in the file?
- The bigger the file, the more deleted records, the more important it is. If you have a file that has10, 000 records with 1000 deleted records, you probably won't notice any difference with a RGZPFM. However if each record is more than 10,000 fields long and the file is opened and closed every 2 minutes of the day, you will probably see a large difference.
- The real key here is to know your data.
- The command Display Data Base Relations (DSPDBR) would be the command to use to identify the logical files based on the physical file. I have never use the KEYFILE parameter on the RGZPFM,
Additional details for Question 2:
Recommendations:
- Sign on with the user profile QSECOFR when making these changes.
- Take notes or screen shots of all the values on your WRKSYSSTS screen so you can return these values to their original values is your tuning makes things worse. ( First, do no harm )
- Record the current value of the system value QPFRADJ and then set = 0 before making any tuning adjustments. If you do not change this setting, the system will be constantly changing the values when you aren't looking.
Below are two screen shots of the WRKSYSSTS screen that I will use when discussing the particular columns. The views of this screen shown were obtained by pressing the F21 key and selecting Advanced Assistance Level (shown first).
[IMAGE]
Selecting Advance Assistance Level. Click on image for larger version.
[IMAGE]
WRKSYSSTS screenshot 1. Click on image for larger version.
[IMAGE]
WRKSYSSTS screenshot 2. Click on image for larger version.
Basic interactive tuning:
Before making any changes, I recommend taking a screen shot of the current configuration and setting the system value QPFRADJ = 0. On the WRKSYSSTS screen shots above I have labeled the columns A-G to clearly identify which column I am referring to.
The goals for good performance are:
- Column A - DB page faults all will be less than 10.0
- Column B - Non-DB faults will all be less than 10.0
- Column C - Active to Wait - The higher the better. These are processed transactions.
- Column D - Wait to Ineligible - 1.0 or less.
- Column E - Active to Ineligible - Always 0.0.
The Columns "Pool Size" and "Max Active" are your adjusting knobs. Everything from here on is predicated on how much memory the system has. The fix for many performance issues is more memory. The following will help you make the best use of the memory you have for your particular environment.
- DB page faults occur when a program is manipulating data files in memory and the next record in the data file is not in memory when the CPU is ready to execute on the next program step. The CPU then must wait for the system to move the data from disk into memory.
- Non-DB page faults occur when the next lines of code of an executing program have not already been moved to memory. The CPU then must wait for the system to move the next lines of code of the program from disk into memory.
- If a pool has a high faulting rate, first move more memory into that pool. (The memory you give to that pool will be removed from pool 2 by definition).
- If you don't have memory move to the pool you can reduce the max active jobs.
- If you increase the max act jobs too high, you will see first the value of column D then column E increase. You never want to see 'Active to Ineligible' (E) numbers above 0. Wait to ineligible is not as bad, but you want the number to be 0. Increase the Max Act values until you start seeing the Wait to Ineligible values increase above 0. Then reduce the Max Act values until the Wait to Ineligible go back to 0. Now the system is performing as best as it can with the resources it has.
- Don't forget to press F5 to refresh the screen again and again.
Additional questions and answers regarding performance tuning were submitted following the publication of this tip. Ray has answered these questions specific to fault rates and pools in performance tuning on the AS/400 in a blog post.
ABOUT THE AUTHOR: Raymond G. Johnson is owner of and consulant at iSolutions Consulting Inc. in Eugene, Ore. He has over 30 years of experience with IBM hardware and software systems and provides technical support for i5, System i, iSeries and/or AS/400. If you have further performance tuning questions, Ray is available to answer them. Please submit your question to editor@search400.com.
|
|
|
|
|
|
