Mark Wooding <email@example.com> wrote:
| Rob Warnock <firstname.lastname@example.org> wrote:
| > Not a problem. The only reason I was being pretty stubborn about it
| > was that Linux is the *only* place I've ever seen these silly 100+
| > load averages on essentially idle systems!!
| I've seen it on Irix, too.
Really? I believe you; I've just never seen it myself
(and I worked at SGI for 13 years). Maybe I just never
ran the kind of thing that triggered it.
By the way, notice that I'm *not* talking about a system
that is busy doing a whole bunch of work with very little
consumption of CPU time, e.g., a big Lisp app that's
thrashing swap. Tim Bradshaw pointed out that "page-in wait"
is often counted as "runnable" (and thus appears in "load"),
and I can accept that as reasonable (for soem values of
"reasonable"). I'm talking about systems that are *idle*,
running *nothing* but the usual assortment of daemons,
yet with 100+ "load averages".
| I feel a need to set the record straight for Linux, by the way.
| The load average counts
| * processes which are runnable, and
| * processes which are blocked /uninterruptably/.
| The only point where this gets really strange is NFS: if you mount the
| fileserver `hard' then the kernel will block uninterruptably for NFS
| responses, and therefore processes waiting for NFS will appear to be
| `loading' the system.
Hmmm... This may be the clue, or at least related. The Linux
systems that I was complaining about were all NFS *servers*
which implemented server_NFS (or at least portions of it)
in the kernel. So at boot time they'd start up a bunch of
"nfsd" processes which would dive into the kernel and wait
to handle requests. It was probably these processes which
were viewed as "busy" even when they were completely idle.
[And, no, it was not necessary for a client to mount them
for the load average to skyrocket.]
Rob Warnock <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607