Re: /proc/loadavg

[Jeff Licquia <jeff@licquia.org>]

On Wed, 2002-10-23 at 16:52, Charles Menzes wrote:
> Can someone define just what is being measured in a server's 'load', e.g. 
> /proc/loadavg?  I'm working graphing the 5 minute average throughout the 
> day and I'm curious to know just what a decent threshold should be defined 
> as, for a single cpu machine.

The load average equals the average of the number of tasks running or in
a runnable state at any instant, as opposed to zombie tasks, tasks
waiting on an operation such as I/O, suspended tasks, etc.  The three
different numbers represent that average as measured over the last
minute, the last five minutes, and the last fifteen minutes,
respectively.

Optimally, then, you want to have the load average stay below the number
of CPUs in your machine.  So, on a dual box, it's best if the load
average is below 2.

When the load average goes over the number of CPUs on the system, this
means that there are tasks left sitting and waiting for CPU time.  This
may or may not be a problem depending on what the system is doing, how
good the kernel scheduler is, and other things.  For example, if you're
running something like distributed.net or SETI@home, your load average
will never go below the number of processes you've got running for those
projects; this isn't a problem because the priority for those tasks is
low and there's no deadline for finishing those tasks.

So there's no magic rule about load averages.  You could have two
single-CPU boxes, and the one with a 1.5 load average could perform much
worse than the one with a 4 load average.  I've heard of boxes with load
averages in the three-digit range (before the decimal) that are still
usable.

Incidentally, the same information that's displayed in /proc/loadavg is
also displayed with the "uptime" command; the output from that command
is pretty standard, so your code will be more portable if you parse
uptime's output instead of parsing /proc/loadavg.


-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.