Performance Tuning

From MidrangeWiki
Revision as of 07:49, 13 June 2005 by Al Mac (talk | contribs) (Data Slicing)
Jump to: navigation, search

This is one of the things you might look at while trouble shooting Degradation, but in fact ought to check periodically, to avoid a problem developing and not being spotted. Doubtless someone may update this article to reflect improvements in IBM eServers in later models. The reality of what is needed will vary greatly by what you have on your 400 hardware, in terms of system load, and which version of OS/400 or i5/OS.

Al Mac has similar notes at work in FIXTUNING, an SEU "document." Some of the terminology used by Al Mac may not be the correct stuff ... instead sometimes Al Mac has assigned names to a technique learned, or figured out outside formal 400 education, and not known what name would be better.

Brain Overload

This is a collection of complicated topics that can take a while to wrap our mind around and thoroughly "Grok", so pick one area, study it, leave the others alone, until ready to move on to something else.

Choices

Pre Requisites

What prior knowledge of the 400 is is smart for you to have some of, to help you swim in these waters?

Symptoms Told Computer Doctor

Errors and other Clues

Communications Lines

Data Base Monitor

File hit Maximum records

Data File
Spool File

Hogging System Resources

JOBLOG

Job Tracking

Library List vs. Qualified Calls

Messages Management

Performance Measurement

Users work day

Workload Job Accounting

Application Software Review

Typically software is written "Ok" but then demands on the system, and the nature of the data, leads to an evolution in how programs are used, such that they are no longer optimized for current usage, and some kind of review worthwhile.

Some software, or modifications, may have been written under rushed conditions, in which there is inefficiency that can be reduced, by reprogramming. When we are drowning in individual programs, obviously this effort ought to be directed towards programs that are both identifiable has having serious inefficiencies, and are run very frequently.

Notice that we can dump information about software executables to an *OUTFILE for Query or other analyis. One factoid is number of days software was used after creation. Highest numbers means used almost every day.

Batch Considerations

CPU Intensive

Blocking

CPU Sharing

Call Frequency

Data Slicing

This is a technique Al Mac figured out during performance tuning, in which Al has no idea what the correct terminology is, and came up with this to describe the process.

Al Mac has applied this thinking to several BPCS programs, some that came from SSA, some from consultants, and some that we developed in-house.

Data Slicing Theory

This is a program modification to altered software design. The issue is identifying where it can improve performance sufficiently to justify the effort of doing so.

Most BPCS RPG programs, in Al Mac experience, are supplied by a Prompt Screen where the user supplied what criteria the user is interested in, such as facility, warehouse range, item range, customer range, many other factors, then the program either selects that stuff using OPNQRYF or launches a program that looks at an entire file, rejecting from consideration those that are not relevant to the selection criteria.

We can compare several programs that in theory are looking at similar data. How long do they take to run. We can send DSPLOG data to an *OUTFILE capturing when Batch jobs started and ended, to get typical statistics on how long they take to run, sorted by program name, or run time. If we have two or more programs that in theory ought to be looking at the same data, but have wildly different run times, then the ones that take longer are perhaps candidates for some kind of performance improvement.

How much faster might a program execute if it did not look at records that are outside the criteria of the user Prompt Screen? How much of a drain can this reduce disk space access vs. all other 400 users?

If particular combinations are rarely to be repeated, consider creating a temporary logical on the fly, based on the Prompt Screen selection criteria.

Debug

Disk Access

Logicals

Access Path Sharing

Dimensions

Message Over Load

Open Query File Optimization

Program Performance Optimization

Query

CHGQRYA rules

Finite World

Query Indexing

Query Messages

Random Inefficiency

Read Slowly

Run Priority

Screen Restructuring

SQL ADVISOR

Start Stop Start Stop to Infinity

Update Productively

Write Slowly

Backup Management

Protection Schemes

Disk Space Cleaning

File Size Fluctuation

Archival

Management Central

System Values

Allocations

Active Jobs

Automatic System Tuning

Cache vs. Bottlenecks

Memory Moving

Sign on Faster

Sub System Tinkering

Time Slicing

Task Scheduling

Wee Idea

Other Resources

Books and Manuals