I'm using gentoo and anytime I do uptime, my "Load average" is stuck at 7.0 across the board. When using top or htop or dstat the CPU usage is always idle. The computer is used to run a Java program which uses a lot of NIO and java.util.concurrent packages (there could be a lot of spin-locks). Could that drive false load average numbers up? Actually, how does one start debugging this? The computer does not appear to be under any load as its performance is quite normal. Any suggestions?

uptime: " 10:56:50 up 327 days, 21:01,  4 users,  load average: 7.00, 7.03, 7.00"
uname -a: "Linux host 2.6.30-gentoo-r6 #1 SMP Tue Oct 6 12:08:22 EDT 2009 i686 Intel(R) Xeon(R) CPU X5550 @ 2.67GHz GenuineIntel GNU/Linux"
  • Can you add a screenshot of top here somewhere in the web?
    – ott--
    Apr 19, 2013 at 15:16
  • As you can see, its all idle yet the average is 7.00
    – Daniil
    Apr 19, 2013 at 17:24
  • I wanted to see the top screenshot in order to see any cpu consuming processes.
    – ott--
    Apr 19, 2013 at 19:50
  • It could be the network traffic, check serverfault.com/questions/365061/…
    – ott--
    Apr 22, 2013 at 13:16
  • Hey there! We are running into this at Stack Exchange, believe it or not. Can you share with us what type of hardware you're using? We're experiencing this on Dell Gen-12 hardware. I've done some googling and it looks like people have run into this problem since 2004! Aug 22, 2013 at 17:36

1 Answer 1


Your numbers appear to be valid and below over-utilization. A fully utilized system with eight cores (or CPUs) would have a load average of 8.0. Currently the load average is at roughly 88%. This is why the system does not exhibit any performance issues.



From wikipedia

An idle computer has a load number of 0. Each process using or waiting for CPU (the ready queue or run queue) increments the load number by 1. Most UNIX systems count only processes in the running (on CPU) or runnable (waiting for CPU) states. However, Linux also includes processes in uninterruptible sleep states (usually waiting for disk activity), which can lead to markedly different results if many processes remain blocked in I/O due to a busy or stalled I/O system[1]. This, for example, includes processes blocking due to an NFS server failure or to slow media (e.g., USB 1.x storage devices). Such circumstances can result in an elevated load average, which does not reflect an actual increase in CPU use (but still gives an idea on how long users have to wait).

This means that your Java threads are responsible for the load because (guessing) most things in util.concurrent are seen by the OS as IO-blocking. You can begin investigating these processes with tools that are mentioned answers to this question: how-to-find-out-which-process-is-consuming-wait-cpu?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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