[Arnt]

Sorry, I was sloppy. I meant that it generates CPU load somewhere (or I/O load, for those OSes where those two are cleanly separated).

If you measure the CPU load on half the CPUs that are involved in serving a user, you're not really measuring anything. Ditto if you're outsourcing (parts of) the backend and not measuring the outsourced service level.

[creshal]

> Sorry, I was sloppy. I meant that it generates CPU load somewhere (or I/O load, for those OSes where those two are cleanly separated).

Not necessarily. In the scenario I outlined to icebraining, "load" is generated (on the app server) by simple busy waits due to lock congestion: Full table locks by mysqldump block the database server to clients, so the database server itself is seeing negligible load (it's only serving one client after all).

> If you measure the CPU load on half the CPUs that are involved in serving a user, you're not really measuring anything

I'd rather argue that the Unix/Linux CPU load metric is meaningless either way, except in a vague "something's wrong somewhere, probably" way.

[Arnt]

IMO if there's enough busywaiting that it shows up on the CPU load, then there's so much busywaiting that that is a problem, because a CPU that's busy with such chores is not available for real work. The CPU load is not (as you say) very lucid, a bit like the question mark in the "unix car" joke, but in that particular case it's caused by a real problem: Too much busywaiting.