RE: Automatic Performance adjustment

John:

Scott's response seems to be the one that hit your circumstance, though the 
comments about WRKACTJOB are valid. What you saw is an example of deliberately 
overriding the auto-tuning values for specific events -- a CHGSHRPOOL could've 
been scheduled to reduce off-hours *INTERACT minimum and another CHGSHRPOOL to 
raise it again later. Or, of course, the purely manual change also works.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   9. RE: Automatic Performance adjustment (Jones, John (US))
>
>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-----
>
>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
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertechgroup.com


__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! 
http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at 
http://webmail.netscape.com/