RE: Auto Tuning -- MIDRANGE-L

I've resisted jumping into this thread, but can't anymore ... I think that Nathan is advocating several misconceptions here. (see below)

The fast processors and inexpensive memory that we have today often hide basic mistakes / misconceptions in resource allocation that people make ... more than anything else, tuning is about making resource allocation decisions ... and, outside of religious beliefs, static decisions are rarely the best!

John

At 04:54 PM 2/3/2004, you wrote:

> from: "Ingvaldson, Scott"
> Speaking only for myself, I will never turn off
> QPFRADJ.  If you set appropriate limits it does
> its job well and there is no way manual tuning
> can keep abreast of your system as it changes
> throughout the day.

From: "Nathan M. Andelin" ...

I tend to agree.  About the only thing we can do with manual tuning anyway
is to rob Peter to pay Paul.  Paul's performance may improve, but at the
expense of Peter.  Auto tuning helps establish some overall equity between
jobs of similar classes.

No matter how much memory manually allocate to a pool, overall memory
remains the same.  Adding memory to one pool always takes from another.

This is true only if you make the assumption of a totally constant workload ... unfortunately, few shops are in that situation.

If your workload varies significantly as a function of the time of day, dynamic tuning can make a significant impact. Many shops need all of their resources for web & interactive jobs at 10am, but emphasize batch at 10pm ... these are very different types of jobs in terms of resource usage. Having CL programs that reallocate system resources (DAY and NIGHT, for example) is often very useful.

You would be shocked how many iSeries machines that I've seen over the years that have had as much as 40% of machine memory sitting in pools that aren't in use!

No matter how low the pool activity level is set, it doesn't reduce the
number of threads competing for pool resources.

But it does change the amount of resources available to individual tasks at any one instant!

No matter how high the activity level is set, it doesn't increase resources
required to support concurrently active threads.  Higher activity levels
increase the probability of paging.

... only if you have reached the constraints of the memory allocated ...

No matter how low or high a time slice is set, the overall CPU time required
to complete a process remains the same.  Adjusting the time slice always
makes somebody wait longer for their chance to run.

A job that reaches timeslice end without an available activity level requires CPU usage to page it out of memory ... the amount depends on whether the job is purge yes/no.

Manual tuning may be considered a black art because it creates the illusion
of better performance.  Someone will say their performance improved.
Hopefully the guy who was adversely affected never shows up to complain.

Try running three batch jobs in a memory pool with 1 or 2 activity levels and then tell me that tuning gives an illusion of better performance!

Bottom line, tuning is practically irrelevant in comparison to writing
efficient code, and using efficient interfaces.  Tuning creates an illusion
of performance, while efficient interfaces actually reduce CPU time and
memory requirements within applications, often dramatically so.

You must design applications for performance ... but ...

... on the other hand, I am a firm believer in Moore's Law and that machine and programmer prices have (in the past) moved in vastly different directions. That's why I jumped on the Case tool bandwagon.

John Myers
Strategic Business Systems, Inc.
17 S. Franklin Turnpike, Ramsey, NJ 07446  USA
E-mail: mailto:jmyers@xxxxxxxxxx   Phone: +1 (201) 327-1780 x131
Web:    http://www.sbsusa.com      Fax:   +1 (201) 934-5684

Free Sports League Management Tools - Powered by IBM iSeries
     http://www.ScoreBook.com

Get intelligence from your IBM AS/400 web site - WebSurvey/400
     http://www.WebSurvey400.com