Re: Automatic Performance adjustment

["Steve Landess" <steve_landess@xxxxxxxxxxx>]

IIRC, WRKACTJOB is one of the most resource-intensive commands that you can
use on the system.  Even though you are only refreshing it occasionally, it
is still collecting statistics in the background.

I see the same behavior on my system when I am the only user, running
WRKACTJOB.

This is one of the reasons that you should limit the use of this command to
only those that need it...definitely not *PUBLIC.

Steve Landess
Austin, Texas
(512) 423-0935

----- Original Message -----
From: "Jones, John (US)" <John.Jones@xxxxxxxxxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Monday, March 03, 2003 11:00 AM
Subject: RE: Automatic Performance adjustment


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