Hacker News Reader

Comment by molo_ | Hacker News Reader

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 "D" state in ps and top and also contribute to this number.

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.

View on HN

Thank you, finally someone who managed to mention it. I was at some point thinking that I've misunderstood the whole concept of load, but now you just confirmed my initial doubt, they are trying to sell a product.

How did this end up on HN? You have equally good articles on load at Wikipedia.

Not all processes blocked on I/O are in D state - for a common example, processes blocked on I/O to a network socket or terminal will simply be in the S state, and not count towards load.

In practice, processes typically go into D state ("uninterruptible sleep") when they're blocked on access to a local disk, whether that's explicit I/O (read/write) or implicit (paging). Not coincidentally, this is also the one type of blocking I/O that you can't get knocked out of by a signal.

Actually, they'll get blocked on access to NFS or other network-based disk, too. (but you can configure the NFS mount to allow signals to interrupt) I've seen NFS problems lead to loads over 100.

Reply on news.ycombinator.com