<story><title>Understanding Linux CPU Load - when should you be worried?</title><url>http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages</url></story><parent_chain></parent_chain><comment><author>molo_</author><text>There are two contributions to the load factor: number of processes/threads on the ready-to-run queue and the number blocked on I/O.  The processes blocked on I/O show up in the &quot;D&quot; state in ps and top and also contribute to this number.&lt;p&gt;This article entirely ignores the number of processes blocked on I/O.  A load average exceeding the number of CPUs (cores, whatever) does not automatically mean the CPUs are overloaded.</text></comment>
<story><title>Understanding Linux CPU Load - when should you be worried?</title><url>http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages</url></story><parent_chain></parent_chain><comment><author>kbob</author><text>Three comments.&lt;p&gt;1. I can&apos;t comment on the original article.  Are comments closed, or am I dumb?&lt;p&gt;2. The author seems to have assumed a web server responding to bursty traffic.  Several people have pointed out workloads to which the 0.7 heuristic doesn&apos;t apply - compute servers, I/O bound servers, compile jobs, desktops.  He should have stated that assumption up front.&lt;p&gt;3. Hyperthreads.  For purposes of load monitoring, you should be counting the number of threads, not the number of cores.  Yes, hyperthreads are slower than cores, but that doesn&apos;t matter.  The load average is the ratio of work available to work being done (oversimplified, I know), and, as such, it&apos;s scaled to the actual throughput of the threads available.&lt;p&gt;Fortunately, the author suggested counting CPUs by reading /proc/cpuinfo, and /proc/cpuinfo lists threads, not cores.  So those two errors cancel out. (-:</text></comment>