True, this calculation has some minor issues, but no more so than the ‘top’ output on a typical *nix system, to be honest. In general, if you start out with the question “what’s the problem you’re trying to solve?”, you can probably get to a better solution than either loadavg or this solution for mysql.

There are two problems here, imho:

1. The calculation is doomed to inaccuracy, though admittedly how accurate you need to be here is also a question worth addressing — I’m sure most people reading this are aware that this is really a “rough idea” kind of figure.

2. The relevance of the information you get back from this is also in question. As both a sysadmin and a DBA, loadavg to me is really only relevant if the server *isn’t* bored, and at that point, it’s just a starting point to determine “ok, the system is busy, but now I need to know what actual resource is being hogged and killing performance”.

With MySQL, my experience has been that the way a lot of people set it up (or… don’t), the problem is IO, which points at all kinds of other issues. The point isn’t what the problem is, here. The point is that loadavg is almost always less relevant than a lot of other data points (like, say, iostat output, for just one example)

So, to that end, I think that the solution presented here is probably “good enough”, and you’d need to question the utility of something that is a whole lot more accurate, unless you just have some downtime to kill between client engagements ;-)

The more status information you’ll retrieve with a query the more the performance of these measurement queries will affect the result.

I am not sure if the bias is significant or not, probably it is because the measurement queries need to access and lock global variables (SHOW GLOBAL STATUS).