29

Until recently I thought the load average (as shown for example in top) was a moving average on the n last values of the number of process in state "runnable" or "running". And n would have been defined by the "length" of the moving average: since the algorithm to compute load average seems to trigger every 5 sec, n would have been 12 for the 1min load average, 12x5 for the 5 min load average and 12x15 for the 15 min load average.

But then I read this article: http://www.linuxjournal.com/article/9001. The article is quite old but the same algorithm is implemented today in the Linux kernel. The load average is not a moving average but an algorithm for which I don't know a name. Anyway I made a comparison between the Linux kernel algorithm and a moving average for an imaginary periodic load:

load graph.

There is a huge difference.

Finally my questions are:

  • Why this implementation have been choosen compared to a true moving average, that has a real meaning to anyone ?
  • Why everybody speaks about "1min load average" since much more than the last minute is taken into account by the algorithm. (mathematically, all the measure since the boot; in practice, taking into account the round-off error -- still a lot of measures)
Improve this question
1
  • 5
    It's an exponential moving average (EMA), also used for example in finance (technical analysis). The advantages are presumably the same - the EMA can be calculated from just the previous and current value, and recent values are given more weight than older values. In a standard MA the oldest value contribute just as much to the average as the most recent one, and sometimes we think that the more recent values are more important.
    – j-g-faustus
    Mar 10, 2011 at 3:57

1 Answer 1

Reset to default
24

This difference dates back to the original Berkeley Unix, and stems from the fact that the kernel can't actually keep a rolling average; it would need to retain a large number of past readings in order to do so, and especially in the old days there just wasn't memory to spare for it. The algorithm used instead has the advantage that all the kernel needs to keep is the result of the previous calculation.

Keep in mind the algorithm was a bit closer to the truth back when computer speeds and corresponding clock cycles were measured in tens of MHz instead of GHz; there's a lot more time for discrepancies to creep in these days.

Improve this answer
5
  • 2
    Ok, that explains the choice of implementation. Do you know why a lot of people think the three load average are computed over the last 1min/5min/15min ? I think it's wrong, the algorithm computes an average over all the last values. I understand that old values have less importance that new values but nevertheless, values older than 1 minute still have a non-negligible influence in the 1min load average. So in my opinion "1min/5min/15min" have no sense, but i may be wrong (?)
    – user368507
    Mar 9, 2011 at 7:06
  • 5
    Because that's what the documentation, and every program that reported them starting with the original BSD uptime and w, claimed; you had to look at the kernel sources to find out that it wasn't actually true.
    – geekosaur
    Mar 9, 2011 at 7:10
  • 1
    that's really a pity
    – user368507
    Mar 9, 2011 at 7:47
  • 3
    @user5528 The times 1min/5min/15min do have sense. They determine the time after which the influence of the current load drops by some fixed factor (probably e=2.71.. or maybe 2). Just try it out.
    – maaartinus
    Mar 11, 2011 at 9:47
  • 2
    @maaartinus Yes. 1min/5min/15min determine the time after which older measures have a weighting less or equal to 1/e in the EMA computation. This precision does not appear in man uptime or man top.
    – user368507
    Mar 12, 2011 at 20:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.