Re: Interactive activity approaching capacity of installed feature

["Jim Franz" <franz400@xxxxxxxxxxxx>]

I recently helped a customer avoid the interactive upgrade by looking
at two areas of interactive processing.
There were a large number of interactive queries. One part of the fix
was that 95% of the queries already had predefined selections, that users
were overriding at run time (runqry ...rcdslt = *yes) but there were not
existing logical view for the selects & sorts run over & over again, so
building some logical views really cut down the run time. Many qry's not
involving rcdslt were move to batch, or in the case of queries with
selection
run over millions of records to select a few hundred records, I use rpg to
created the
"dreaded" qtemp files (in seconds) and ran qry over qtemp version. 10 minute
runs
became a few seconds. Any interactive query or even rpg over 10 seconds
should
be looked at.

We also found many rpg reading way too many records interactively.
Performance
tools found the pgms with the most database activity. In almost every case
better access path or sqlrpg, and/or move to batch solved the problem.
Moving to
batch & not fixing bad logic will still hurt your system.

If you have poor performing programs, even a bigger processor will get
bogged down.
btw-how much memory & how is it distributed?
are you using sysval qpfradj (performance adjuster) ?  (i do, but have
reserved memory for
several pools)
jim

----- Original Message -----
From: "Burns, Bryan" <burnsbm@Echoincorporated.com>
To: <midrange-l@midrange.com>
Sent: Tuesday, April 02, 2002 4:21 PM
Subject: Interactive activity approaching capacity of installed feature


> I started receiving the message below on an almost daily basis about six
> weeks ago. It is a QSYSOPR message with message ID CPI1479.
>
>  Message . . . . :   Interactive activity approaching capacity of
installed
>
>   feature.
>
> Cause . . . . . :   The interactive feature installed on this system is
>
>   capable of using 37.8 percent of the total system processing power for
>
>   interactive work (applications that use a 5250-like datastream to
>
>   communicate with the workstation).  Interactive activity on this system
> has
>   exceeded the threshold value of 32.4 percent of the total system
> processing
>   power.  If the interactive workload is allowed to increase, interactive
>
>   response times may become erratic and total system throughput may be
>
>   diminished due to the overhead incurred when the interactive threshold
is
>
>   exceeded.
>
>   This message will be repeated every 60 minutes until the amount of
> interactive activity on the system is reduced below the threshold value.
> Recovery  . . . :   Examine the interactive work on the system and
determine
>
>   if it can be reduced.  If not, an upgrade of the interactive feature may
> be
>   required to achieve optimal throughput as the interactive workload
grows.
>
>     Additional interactive analysis can be achieved using the Performance
>
>   Monitor capabilities of Management Central in the AS/400 Operations
>
>   Navigator product.
>
> Of course, I have been away from my desk or in another application on my
PC,
> every time the message has appeared so I have been unable to determine
what
> job(s) is sucking up the interactive CPU.  I have not received the message
> more than once (maybe twice) in one day.
>
> 1) Should I spend the time to pursue the root cause of this?  We have
> had no performance issues since we upgraded from a 620-2179 to an
> 820-2395-1523 last fall.
>
> 2) Could this be caused by queries?  We have over 6,000 queries and 275
> users on our box and most users run their queries interactively.
>
> 3) Could this be caused by SQL?  We recently started some applications
> that use SQL through ODBC.  I turned the SQL monitor in OPS NAVIGATOR on
for
> a few hours one day and did an analysis but did not find anything
> significant.
>
> Thanks in advance for any replies.
>
>
> Bryan Burns
> AS/400 System Operator
> ECHO  Incorporated
> 847-540-8400  ext. 493
> <Burnsbm@echoincorporated.com <mailto:Burnsbm@echoincorporated.com> >
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>