Comment 0 for bug 819627

As mentioned in the questions area I am currently in the process of rewriting the rules file for my needs. I'm just half way through but I've noticed some recommendations that could need improvement, which I would like to pass on to your project as well:

> % query cache used|||<80|||Qcache_free_memory / query_cache_size * 100|||The query cache is not being fully utilized.

This calculates the wrong number, this the % of free query cache, not the % of used qc. It should be 100 - [above expr].

>Sort rows|||=~ /second|minute/|||&hr_bytime(Sort_rows/Uptime_since_flush_status)|||There are lots of rows being sorted. Consider using indexes in more queries to avoid sorting too often.

Sort_rows, from what I was able to read, is also increased when sorting with indexes. Thus, this recommendation is incorrect.

> Query cache size|||eq "0 bytes"|||&hr_bytes(query_cache_size)|||The query_cache is not turned on. It may be useful to turn it on.

Query cache might also be turned off by setting query_cache_type to 'OFF' independent of what query_cache_size is set to.

>MySQL Architecture||| !~ /64/|||"version_compile_machine"|||MySQL is not compiled as a 64-bit package.

From what I was able to read, the 64 bit version of mysql has no or even worse performance. The 64 bit version should only be used where the system memory is above 3 GiB, or there will be no gain at all.

>Query cache low memory prunes|||=~ /second|minute/|||&hr_bytime(Qcache_lowmem_prunes/Uptime_since_flush_status)|||Increase query_cache_size -- there are too many low memory prunes.

Maybe this recommendation should note that a very big query cache (3 digit Mb) might cause serious slow down because of the overhead to manage the cache. So increasing it too much will be bad too.