|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.