Re: Performance Monitoring

One problem with this method would be that the observation would enhance
the problem (one reason to secure WRKACTJOB, WRKSYSSTS and WRKSYSACT -
when performance is bad, if more than one person goes into any of those,
it could make things much worse).  

Pfrmon itself cause a big system hit when starting and stopping
(esecially if it is set to dump the trace data).

My suggestion would be to run pfrmon over longer periods, then go back
and look at reports for just the times that were bad.  You should
collect trace data, but dump it during off-peak hours.  Until you've got
it refined, try running pfrmon from a half hour before most users signon
until a half hour after they are off.  Just remember to clear the
performance data library after reporting - you might want to point
pfrmon to something other than QPFRDATA, so you can just clear the
library without the chance of wiping out the monitor settings (which are
stored in QPFRDATA) - this might be easier than DLRPFRDTA.    

Leo Lefebvre wrote:
> 
> Hi everybody,
> 
> I was thinking: when we have a performance problem on the AS/400 for a
> certain period of time, one way to see what is going on is to start the
> Performance Monitor program. Running the results through some other
> programs, we will, 'maybe', see where the problems are.This is not a
> foolproof method since the problems may (and will, most of the time)
> come up 'in between' the sample periods (the minimum length of a period
> is 5 minutes).  Our chances to really figure out where the problem(s)
> is(are) are minimal.
> 
> Has anybody seen a program that would basically 'wake up' ONLY when the
> situation is critical (ie the system is bugged down) and gather
> information to save for later evaluation. If the system never gets into
> trouble, no data is recorded. If the system is constantly bugged down, a
> lot of data is collected.  Today, when we think we have a problem, we do
> a 'WRKACTJOB' (if we can get a terminal that has a reasonable response
> time and if we are on location at the time of the problem).
> 
> Think about it.
> Maybe I gave some ideas to some people!
> 
> TIA.
> 
> --
> 
> Leo Lefebvre
> leo@tug.on.ca
> Toronto Users Group for Midrange Systems
> Ph: (416) 606-5960   ---   Fx: (416) 495-0100
> 
>     ---------------------------------------------------------------
> 
>                                Name: vcard.vcf
>               Part 1.2         Type: text/x-vcard
>                            Encoding: 7bit
>                         Description: Card for Leo Lefebvre
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---