Re: /proc/loadavg Misleading on 2.2.14-12.

[Erik Mouw <J.A.K.Mouw@ITS.TUDelft.NL>]

On Mon, Apr 02, 2001 at 11:53:56PM +0100, Ralph Corderoy wrote:
> I use uptime(1) quite a lot on a busy web server.  This is really just
> giving me numbers from /proc/loadavg.  Most of the time they match well
> how busy the machine is;  the three numbers correlate with number of
> hits, idle time in vmstat, etc.
> 
> However, when the machine gets really loaded, and vmstat's idle column
> is zero for most of an hour I find /proc/loadavg reports a misleadingly
> low figure for the last minute's average number of processes in the run
> queue.

Which means that most of the processes on your machine are NOT in the
run queue, but are waiting for I/O or are swapped in or out. IMHO I/O
is quite a normal situation for a web server; swapping is not.

> I know there are many httpds, mysqlds, etc., running and using strace I
> can see they're very busy.  So it isn't a case of one process consuming
> all the CPU.  vmstat shows many processes in the run queue too.
> 
> I've looked at timer.c:calc_load
> 
>     http://lxr.linux.no/source/kernel/timer.c#L623
> 
> and the related /proc/loadavg read routine and I'm wondering if the
> fixed point arithmetic used can lead to overflow or some over problem
> in certain situations, which happen to match mine.

Very unlikely. I'll explain:

We have 11 bits of precision (FSHIFT in include/linux/sched.h). The
load average is an unsigned long, sizeof(unsigned long)=32 bits on an
i386 platform, so we have 21 bits left for the part before the decimal
point. 2^21 is slightly more than 2 million (2.097e6). 

The mathematical load average formula is (for the 1 minute load):

  new_load = current_load * (1/exp(5/60)) +
             active_tasks * (1 - 1/exp(5/60));

Assume current_load = 1 and there is one active task, this would mean
that new_load = current_load. In general, new_load = current_load if
and only if current_load = active_tasks.

Now lets go back to the fixed point calculations in CALC_LOAD() (see
include/linux/sched.h). The part that overflows first is load *= exp in
the case of the five minute load average. This will overflow if the
result doesn't fit in 32 bits, IOW if load > (2^32 / 2037), which is if
load > 2108476. Remember that 11 bits from this figure are used for the
precision, so if we shift that number 11 bits to the right, we get
1029. In the steady state situation where current_load = active_tasks
the load average will not overflow as long as the number of active
tasks is kept below 1029.

Going back to your question: no it doesn't overflow unless you push
your web server to have more than 1029 active tasks, which is very
unlikely because the machine will be brought to a crawling halt because
of memory problems.

> I'm also puzzled as to the addition of 0.05 in
> 
>     http://lxr.linux.no/source/fs/proc/proc_misc.c#L86
> 
> Why?  Is it a fudge factor?  What's it for?

It's a standard trick for proper rounding in an integer or fixed point
situation (actually, it's 1/200 = 0.005). It's the easiest to see with
double --> int conversion, which just truncates the numbers behind the
point:

  1.1     --> 1
  1.49999 --> 1
  1.5     --> 1
  1.99999 --> 1

Now add (smallest integer)/2 to the floating point figure (1/2=0.5):

  1.1     + 0.5 = 1.6     --> 1
  1.49999 + 0.5 = 1.99999 --> 1
  1.5     + 0.5 = 2.0     --> 2
  1.99999 + 0.5 = 2.49999 --> 1

And we get proper rounding.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
-
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/
IRC Channel:   irc.openprojects.net / #kernelnewbies
Web Page:      http://www.surriel.com/kernelnewbies.shtml