Stan Sieler wrote:
>
> Wirt writes:
> > Bill's comments rekindle one of my primary disgruntlements with simple
> > performance analyses. We manufacture a report writer, QueryCalc, in which we
> > do everything we can to drive CPU utilization to 100%. In fact, if we were to
> > do anything else, we would be derelict in our duty. One hundred per cent CPU
> > utilization is not a sin in a report writer, it is a profound virtue.
>
> I beg to differ.  To paraphrase Bill, "it depends".
>
> If your process is using 100% of the CPU, and nearly 100% of the
> theoretical maximum number of I/Os per second, you might at first
> glance say "this is good".

To slightly paraphrase Stan's following detailed analysis (snipped),
the above scenario was the "ideal" in the old batch-driven or single
user environments.  It simply isn't true for multiprocessing timeshare
systems.  If everybody is maxxing out the machine, simply switching
tasks in normal multiprocessing adds some degree of overhead.  On the
other hand, if your process has some implicit impediment (pause), then
the other processes have time to do useful work, provided they are
ready to launch.

In an interactive environment, 100% CPU is generally "not" a good idea
unless you have some benign batch activity.  A better indicator is the
unix concept of a "load average" - the number of processes ready to run
but waiting on the CPU.  When the load average exceeds the number of
processors in the machine, you're CPU bound.  In MPE terminology, this
is the number of processes in the "Ready" column of SHOWQ;ACTIVE.

If there were a "disk wait load" figure - the number of processes
waiting on disk - it would be similarly valuable.

Similarly for memory.

Interactive, multi-user tuning is not an exact science.  If you look
hard enough, you can find a "perceived" bottleneck most of the time.
But when you are impeding > "n" processes due to some resource, there
is a problem.

I don't want to nit-pick further since there isn't a magical answer to
all environments.  You make very efficient processes and you end up
expiring your quantum and increasing the load average.  You make rather
inefficient or I/O bound processes, and enough of them, and now you are
context-switching rapidly and reducing the average quantum value per
process and burdening the dispatcher.  You optimize I/O for excellent
prefetch and you may flush out pages valuable to other processes.

It's a dark science :-)

Jeff Kell <[log in to unmask]>