Re: Auto Tuning

I don't agree at all - that's what autotuning does - robs Peter to pay Paul.
The only time I would leave this on is where the customer does not have
enough memory overall.(Recommended for BPCS sites at least 2Gb per
processor.)

Tuning a pool (reducing the activity level etc) is crucial where an
application uses SQL, and since I usually tune for BPCS this is where huge
performance improvements can be achieved. The SQL optimizer looks at many
factors before deciding how to process a statement, including the size of
the pool divided by the activity level. Changing this can mean the
difference between an inefficient way of processing, and a way that uses
more memory but is many times faster.

Obviously index creation is also crucial for SQL, and it is also worth
remembering that if the SQL Optimizer decides to dynamically create an index
that doesn't exist, this process (creation of an index) is dedicated and
does not look at any timeslice - if the file is large it can take many
seconds to complete.

Also, I can verify that for most BPCS sites (mostly complex processing) the
appropriate timeslice is between 200ms and 300ms, rather than 50ms, although
this may prove different on the latest hardware. I imagine this would also
apply to similar applications using SQL rather than straight RPG.

But if you're not doing complex commercial workloads, then maybe autotune
will work for you....

cheers,

Clare



----- Original Message -----
From: "Nathan M. Andelin" <nandel@xxxxxxxxxxxxxxxxxxx>
To: <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, February 03, 2004 9:54 PM
Subject: RE: Auto Tuning


> > 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.
>
> 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.
>
> No matter how low the pool activity level is set, it doesn't reduce the
> number of threads competing for pool resources.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Nathan.
>
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>