> >> The understanding I have is that the load average is really three
> >> numbers. It's the average number of jobs waiting for the CPU over
> >> one minute, five minutes, and fif* minutes. I don't think different
> >> systems use a different calculation method, but I can't say for sure.
> >Isn't load just the average number of jobs on queue +
> >ones blocked for resources + number of processes in the CPU?
> > Or
> Can't be. :-) If my system breaks load average five, it's hard to use,
> and I have a _lot_ more than 5 processes blocked for resources. Looking
> at my man pages, it looks like I was kind of right. It says (of uptime)
> that it prints "the average number of jobs in the run queue over the
> last 1, 5 and 15 minutes." I'm just used to single cpu systems, so for
> a single cpu system, my explanation will give load + 1. Of course,
> multiple cpu systems would be able to handle a higher load average
> reasonably, if this explanation is correct.
Wait for resource meaning process is in CPU, but it cannot
proceed because it has to access resource from other sources.
Something like wio% in sar or paging in vmstat, not waiting
for packet or some keyboard input.
On Solaris machines, waiting for resource is not included in
the load average, but on SunOS machines, it is.
So on a machine with very heavy I/O from paging or just plain
Disk read/writes, a solaris machine might show a light load,
while a SunOS machine will show a load that signifies
that there is activities going on.
It is best to not use uptime as a measuring tool, it is deceptive
and easily misinterpreted.
> >O + R field under process state in the ps command
> >So a 64 CPU CS6400 with a load of 60 means it is not being
> >fully utilized(Of course, there is more to it than that)
> I'd have to see that myself, I just have a hard time not panicking
> when I do "uptime" and see 15 minute load averages around 60-100. Who
> knows, maybe it truly averages it out over each cpu...
> >vmstat's proc fields or sar -q would give also give you
> >the process in queue
> Now if only I could fix my system so that sar would work again.
> Mark McCullough Systems-Programmer