On 3/26/2013 2:58 PM, John Mathew wrote:

Can some one please suggest below queries.


How to find out which job is taking more CPU% and running for a long time.

WRKACTJOB

How to do performance tuning, is there any program .....

thanks in advance.

Generally speaking, I would not recommend that a newcomer to any
platform try to tune performance on that platform. However, we all
started somewhere, so...

1) Measure. Then measure some more. Then measure it again. Understand
what the measurements mean by comparing 'well performing' jobs against
'poor performing' jobs. DO NOT give in to the temptation to make
changes before you understand which numbers indicate better or worse
performance.

2) Measure the same jobs tomorrow. Or next week. Whenever they run
again. Measurements are almost worthless with a sample size of 1. You
need to see the same jobs run at least 5 times before you can really
believe the numbers. See #1.

3) Post the configuration you have, the performance numbers you have and
the change (ONE and ONLY ONE) you intend to make here. If you can't
figure out what numbers to post, go to step 1 and measure more jobs
until you understand the numbers well enough to explain your ideas to
someone else.

4) Measure the system just before you make the change. Keep these
numbers! Write down the settings you started with! Change ONE and ONLY
ONE thing. Measure the system again. The change might have made the
one job better and really hurt the rest of the system.

5) Measure. Monitor the system for a period of time to make sure the
overall throughput is acceptable. If the overall performance is worse,
undo the change you made and go to step 3.

6) If the job you want to make better is not better, go to step 2.

Performance tuning is a skill that takes a long time to master. Do not
be disappointed that you don't get it perfect in one round of changes.
I've been doing this for 30 years and it takes me several rounds to get
where I want to be. Be very aware that you can make performance very,
very bad if you make the wrong change (like starving the machine pool).
Keep immaculate records of everything you do so you can instantly go
back to any prior (working) configuration.

Spend many hours looking at all of the topics in
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frzahx%2Frzahx1.htm

Infocenter -> Systems Management -> Performance. Many hours. Print
them out. Take them home. Cut your internet time in half and use the
time to read about IBM i performance. Look up Performance Explorer and
use that often. Use WRKACTJOB, WRKSYSACT and WRKDSKSTS every day -
every hour - to see how the machine reacts under various loads.

I cannot stress enough that tuning is much more about measuring and
understanding than it is about making changes. I never and I mean NEVER
make a system tuning change without completely understanding why that
change will do what I expect. I will measure for a week and think about
what I'm seeing and how it got that way and only then will I decide on
what to tweak. Every machine is unique; every performance situation is
unique. The number of disk arms, the OS level, the number of people
reading records in your customer master file, the number of ODBC
transactions, the pool sizes and activity levels - it's all unique to
your machine. There are general guidelines but if you are having
performance problems you are probably past general advice and into
making changes that will benefit your particular machine.

Finally, be aware of the very significant difference between a problem
with system performance, a starved subsystem and one long running
program. Measuring performance will tell you what you are suffering
from (WRKACTJOB, sort on interactions and look at the response time is a
quick snapshot of interactive performance for the busiest interactive
users). Don't try to change the whole machine because you have one RPG
program that takes half an hour reading a million rows of a purchase
history table! Measure and understand - this is the key to performance
tuning on any scale.

--buck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.