Messages in this thread | | | From | (Larry McVoy) | Subject | Re: Back in Production mode Again... | Date | Sat, 15 Nov 1997 11:04:40 +0800 |
| |
: My question is this: what -is- a high load average? Over most of the : period of a year of running this system as a production fileserver, The : 'average' load average is probably near .25; so just what -are- reasonable : loads on this system? (disk subsystems as described; dual P-166s, not : overclocked; 32MB of crappy ram (we're cursed with the SIG-11 and so we : compile off of this machine) on an older Tyan II Tomcat.
"load average" in Unix, not just Linux, is a misnomer. All it means is that that is the number of processes waiting (sleeping) in the kernel. On some systems (I think, I'm hazy here) only processes sleeping in disk wait are counted; on others I think it is all sleeping processes.
The point is that you can have a "load average" of 1000 without your system doing very much. If you had a backup program that forked a process per directory (why? I dunno, it's just an example) then you could easily see a high load average.
In general, load average as a metric is heavily overrated.
Switching off whine mode and turning on useful mode: :-)
Wouldn't it be cool if Linux actually defined a "busy average"? Something that took into consideration CPU cycles, disk arms, and networks? Perhaps it needs to be be a weighted triple. How about
For all things, it is a 1/5/15 minute decaying average expressed as a value between 0 and 1, with 0 being idle and 1 being saturated.
CPU: %CPU busy: a value between 0 and 1, with 0 being idle and 1 being saturated DISK: current load average (modified for just disk if need be) NET: %network "full". If IP accounting is on, then full is 100% of bandwidth used. If IP accounting is off, then we have to come up with an "average" packet size and base the fullness on the # of packets.
I realize that there are a million things wrong with this proposal - one can always find flaws. But it is a heck of a lot better than "load average".
--lm
| |