Brian,

It seems like your system is not yet performing to its total capacity. When
you say it is running at 80% or 90%, that would seem to suggest that you
still have some 10% or 20% that could be used to handle your applications.
The CPU% being high is not a measure of good or bad performance.

So, what is it that you see that seems to be a performance problem? Is it
slower interactive response times? More performance spikes? How about longer
running batch jobs? I did not see any of those indicators in your other
emails.

While your system may be ~only~ a P10, there are many steps you can take to
balance your system to reduce interactive response times and remove
performance spikes, and improve throughput to make your system run more
efficiently and perform more work in your 80-90% CPU - and maybe let it run
at its full capacity of 100%.

There are also several work management settings that are probably set at a
shipped value that need to be changed. For example, the numbers of the
prestart QZDASOINIT jobs may be configured very low, and when a new job is
needed, the system has to spend some resources creating that new job. It is
typical that improving the settings for the prestart jobs means that the
system can handle that workload better and spend less time managing jobs,
and more time performing the work for the jobs.

Of course, this is a very small part of the entire work management
configuration for performance, and I think you were asking for help in
something that is very common - how to apply regular performance management
to get the most out of your server. I wrote a complete series of performance
articles for System i Network that will help you. Here are the links.
http://systeminetwork.com/article/out-box-tuning-performance-tuning-basics
http://systeminetwork.com/article/system-values-tuning
http://systeminetwork.com/article/subsystems-and-memory-pools
http://systeminetwork.com/article/work-management-configurations
http://systeminetwork.com/article/tuning-out-box-silver-bullet

Feel free to contact me offlist if you would like more details.
Trevor



On 8/10/09 9:05 AM, "Brian Piotrowski" <bpiotrowski@xxxxxxxxxxxxxxx> wrote:

Hi All,

I'm wondering if anyone can suggest a course of action to help determine out
bottlenecks in our AS400 and a plan to improve performance?

A few years ago we upgraded to a 520-9406 machine. However, I have noticed
over the past two years that our CPU usage has slowly been creeping up as new
programs have been added. As it stands right now, whenever I check CPU usage
I hardly ever see it below 80%. Usually it is in the 90%+ range. I know it
is frustrating to our users, and I can't blame them - I would hate to wait for
jobs to finish for long stretches at a time.

I would like to determine where the bottlenecks are occurring, and I wonder if
the group has any suggestions? Looking at the active jobs, I suspect it may
have something to do with all of the web pages that hit the 400 on a regular
basis - I see an awful lot of QZDASOINIT jobs occupying a fair chunk of CPU
usage. There are other jobs that run regularly that consume a fair amount of
usage as well.

Are there any free / built-in programs I can use to analyze the 400 to see
where and when these bottlenecks occur? I do have a HW/SW contract on the
400, so could I have IBM come in and perform an analysis on the system to
determine our problems? I'd hate to throw a bunch of money upgrading the main
storage/DASD/CPU to P20+ if that isn't really the problem (and I'm sure our
senior management group would be less than happy as well).

Any ideas would be most appreciated!

Thanks!

Brian.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Brian Piotrowski
Assistant Mgr. - I.T.
Simcoe Parts Service, Inc.
Ph: 705-435-7814 x343
Fx: 705-435-6746
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
http://www.simcoeparts.com



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-2019 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].