RE: Automatic Performance adjustment -- MIDRANGE-L

I still see the performance adjuster doing odd things even at V5R1
CUM2134.  

Example:  It's a Saturday and I'm doing some maintenance on our dev box
(720).  I'm the only user signed on and I've submitted some big batch
jobs.  While waiting for the batch jobs to finish, I'm occasionally
hitting F10 on a WRKACTJOB and/or WRKSYSSTS display.  With the perf
adjuster on, my activity will be allocated about 200MB of main storage
with the remainder being split between *MACHINE & *BASE.  The box has
2GB total.  Page faulting in *MACHINE will be higher than in *BASE.  So
I drop *INTERACT to 50MB but over time it moves it back up.

There's no reason for a single interactive job that uses under 2% of the
CPU load to be allocated 10% of main storage, especially when the
program stack isn't really changing and I'm only refreshing the display
every couple of minutes.

I manually tune our production system, but leave the dev box at
QPFRADJ=3 to see if the auto tuner improves as new PTFs/releases are
loaded.

- John

-----Original Message-----
date: Thu, 27 Feb 2003 20:31:01 -0500
from: qsrvbas@xxxxxxxxxxxx (Tom Liotta)
subject: RE: Automatic Performance adjustment

Scott:

I imagine the only reason "the majority" favored manual is because the
majority of those responding felt comfortable with manual tuning. Those
who most use auto-tuning possibly don't feel comfortable offering an
opinion.

Personally, since somewhere in version 3 of OS/400, I've never seen a
production AS/400 that didn't run better on a day-to-day basis with
auto-tuning active. There'd be no rational way anyone could manually
tune a number of the systems I've worked with to get even decent results
for more than an hour or so.

As far as I know, there's no good reason not to auto-tune most systems,
especially if the system is configured to take advantage of it to begin
with. This means that subsystems should be configured with appropriate
subsystem pools, including private pools where needed, routing and
pre-start job entries should direct work to appropriate subsystem pools
(tuning is almost pointless otherwise), work is started in appropriate
subsystems, sufficient memory for shifting as needed should be
available, basic shared-pool settings are reasonable, etc.

And in a pinch, even if auto-tuning is active, you can still make manual
changes in order to react to exceptional circumstances. That item alone
is enough to suggest trying auto-tuning. By starting with an adjust at
IPL and automatic, you can get an initial set of pool sizes and activity
levels to begin baselining. Then switch to straight automatic once
settings start to fluctuate within a range.

If you need specific adjustments at regular times that anticipate change
and don't want to wait for auto-shifts -- end of day or start of day,
e.g. -- then add job scheduler entries that cause major shifts, perhaps
one or two or more CLRPOOL commands plus related CHGSHRPOOL commands.

In short, I seldom have QPFRADJ at anything but 3 and I have no problem
augmenting it with manual action. I don't see it as either/or nor as
better/worse. Use both.

Tom Liotta

_______________________________________________
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.

This e-mail is for the use of the intended recipient(s) only.  If you have 
received this e-mail in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not use, disclose 
or distribute this e-mail without the author's prior permission.  We have taken 
precautions to minimize the risk of transmitting software viruses, but we 
advise you to carry out your own virus checks on any attachment to this 
message.  We cannot accept liability for any loss or damage caused by software 
viruses.