A lot of wakeups happen when you interleave CPU/local operations with the read/write calls. So you have your thread waking up intermittently for one or two additions before sleeping again.

To me an ideal CPU/IO graph would be a lot of 10%’s while the necessary data to render the page is being brought in, then a sudden burst of 100% (or whatever the OS can possibly allocate), and then back down to 10-20% which would be kee-alive mode.

The only reason I posted this was because I did write code once which exactly met these conditions, and put three testers and two developers on a wild goose chase finding out why we were getting such bad numbers and such good response times.

Regarding your comment on caching – This is especially relevant in today’s large web services where almost the whole system runs off of RAM. More than just latency – it is the variability in latency that kills disk. There is an excellent paper called RAMClouds by some stanford people if you are interested.

“100% CPU usage over _what_ time?” There are places where you’re doing computations (coercing lists, rendering charts, computing results, etc.) where the data is available and in RAM (think building the facebook home feed from front-end caches every few seconds). All I’m saying is, artificially making attempts in application code to reduce usage really go against the efforts the OS is making at optimizing. If the system really does need to do something, the OS wouldn’t allocate a large slice to your CPU-intensive process anyway, and when it does allocate it, it means there was no better operation really waiting for it.

I/O wait state problems also really arise from just bad coding. Once more, I’ve seen a lot of super-coders trying to do all sorts of Async calls without understanding the underlying mechanism and polling for responses. Counter-intuitively, if they depended on a blocking synchronous call, the OS could have taken care of the waiting efficiently, and timed out appropriately to provide responsiveness.

Actually the fact that nobody runs static pages is precisely why a 100% CPU state for short bursts is a good thing – your backend/IO responses are being cached to RAM until you have enough actionable data before waking up a thread for just one or two operations (unless they are conditional) before sleeping again, and your CPU is being utilized properly by other threads in the meantime.response and every thread proceeds a little bit (yes, a lot of webservers are configured with an unnecessary number of worker threads).

Did I mention that the solution to this problem is to context switch more rapidly between the busy wait processes?