Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have several ubuntu 12.04 VMs running on a ubuntu 12.04 KVM host. Those of the virtual machines that are totally idle with no services (except syslog and the other "small" standard stuff of a fresh installation) show a constant load of "0.00 0.01 0.05" in top/htop as average 1/5/15.

When there are "real" applications running, the load averages behave perfectly normal but they never fall below the mentioned values.

While this doesn't affect performance at all and could easily be ignored, it screws up the monitoring graphs in a very annoying way:

(Notice how load15 behaves nicely if > 0.05 for a short time in the right half of the pic)

Unfortunately I don't know what diagnostic outputs might be helpful for you, so here's some default stuff:

# top
top - 16:31:01 up  1:05,  1 user,  load average: 0.00, 0.01, 0.05
Tasks:  62 total,   1 running,  61 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  0.2%sy,  0.0%ni, 99.2%id,  0.5%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1019464k total,    73452k used,   946012k free,     6140k buffers
Swap:        0k total,        0k used,        0k free,    22504k cached


# free -m
             total       used       free     shared    buffers     cached
Mem:           995         72        923          0          6         21
-/+ buffers/cache:         43        951
Swap:            0          0          0   


# iostat -x /dev/vda
Linux 3.2.0-32-virtual (vm3)         11/15/2012      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.25    0.00    0.65    0.20    0.24   98.66

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.14     0.12    0.51    0.22     6.74     1.46    22.50     0.02   23.26   20.64   29.30   7.63   0.56

Need something else?

Has anyone ever seen this behavior? Might this be a bug in kvm/ubuntu/kernel 3.x in the end?

Thanks a lot!

share|improve this question
Maybe I'm misunderstanding something, but why do you think this is abnormal? A fully idle install still does stuff like checking cron, OOM killers, etc. Your monitoring graphs look just fine. – ceejayoz Nov 15 '12 at 16:05
I would still expect the values to be far less than that. Maybe I just don't get the math behind it, but if there is 0.01 over 5 minutes (constantly) can there really be 0.05 over 15 minutes (constantly)? – Karma Fusebox Nov 15 '12 at 16:40
It's not 0.01 over 5 minutes constantly. Your own load graph shows the maximum 5 minute load as 0.19 and an average of 0.09. – ceejayoz Nov 15 '12 at 16:52
@KarmaFusebox This is seriously a first-world problem. The first Unix machines that I had the privilege of using were Solaris boxes shared between dozens of concurrent users dialed in from all over campus. The load averages tended to be in the range of 3-6+. Most of us were just checking e-mail, and sometimes pine ran awfully slowly. The solution to your problem is to make your servers busy. Once you have a scaling challenge on your hand, you will find that an average load of 0.05 is every bit as insignificant as it looks numerically. – Skyhawk Nov 15 '12 at 16:53
Indeed. While thinking about it I realized that you hardly ever have such a no-load machine. As I stated myself, when minimal action starts, the loads are behaving fine. So my assumption of having "0-0-0" then seems to have been wrong from the start on. Thank you, I will mark this as solved. – Karma Fusebox Nov 15 '12 at 17:32
up vote 2 down vote accepted

Actually the real reason for that is how load averages are calculated in linux.

As of these days it's implemented as

static unsigned long
calc_load(unsigned long load, unsigned long exp, unsigned long active)
    load *= exp;
    load += active * (FIXED_1 - exp);
    load += 1UL << (FSHIFT - 1);
    return load >> FSHIFT;

which if you perform calculations manually will lead you to the fact that if the value once has increased over 93 (93 / 2048 = 0.04541015625 (which is rounded to 0.05 on output)) will never go below that value (here I'm referring to LA15, for LA5 the value is presumably different).

Some more details:


share|improve this answer

Those of the virtual machines that are totally idle with no services running

In reality, this does not happen; there are always services running on a *nix system:

  • syslog
  • systemd/udev
  • upstart
  • hald/dbus
  • cron/at
  • +any number of kernel threads

Expecting any combination of the above to yield a totally idle system is fantasy.

Besides that, the logic behind calculating the load averages may cause the 1min to show 0.00 while the 5min is 0.01 on average.

share|improve this answer
I am fully aware of that. By "idle with no services" I was referring to a fresh install without any real work to do. And yes, I see your point, but how come the values are so totally constant? – Karma Fusebox Nov 15 '12 at 16:35
On a modern system, the granularity is too coarse to see what's really happening; you may be right, and it may be a bug somewhere that causes these constant minimums, of course. But I suspect it is merely a measurement artifact. – adaptr Nov 15 '12 at 16:44
The services, if they have no real work to do, will probably just run some scheduled actions in regular intervals. This, when averaged and rounded, will cause a 'constant' load. – Jacek Konieczny Nov 15 '12 at 16:45
Also agreed. You could try changing the kernel scheduler algorithm and see if that changes the values :) – adaptr Nov 15 '12 at 16:45
Actually this answer is wrong: those numbers are because of that's how the LA calculation formula in linux is implemented, see It has nothing to do with real load, just maths. – zerkms Nov 30 '15 at 6:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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