The branch, master has been updated via 9b2570b0cfa73860fd150d741535991308b5b199 (commit) via 9be1bad63ca9eb61ed8dcc249b45079f018f73ad (commit) from 80daf344942c5b60b0c244771b7c18c309edf06d (commit)
- Log ----------------------------------------------------------------- commit 9b2570b0cfa73860fd150d741535991308b5b199 Author: Piotr Przybylski piotrprz@gmail.com Date: Sat Aug 20 00:59:11 2011 +0200
Advisor: mark that 'Rate of reading fixed position' may be wrong, requires further investigation
commit 9be1bad63ca9eb61ed8dcc249b45079f018f73ad Author: Piotr Przybylski piotrprz@gmail.com Date: Sat Aug 20 00:56:06 2011 +0200
Advisor: link to MySQL 5.5 documentation, it's better and more complete
-----------------------------------------------------------------------
Summary of changes: libraries/advisory_rules.txt | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/libraries/advisory_rules.txt b/libraries/advisory_rules.txt index 97f4454..c3445e0 100644 --- a/libraries/advisory_rules.txt +++ b/libraries/advisory_rules.txt @@ -131,7 +131,7 @@ rule 'Query cache usage' [!fired('Query cache disabled')] Questions / Uptime value > 100 Suboptimal caching method. - You are using the MySQL Query cache with a fairly high traffic database. It might be worth considering to use <a href="http://dev.mysql.com/doc/refman/5.1/en/ha-memcached.html">memcached</a> instead of the MySQL Query cache, especially if you have multiple slaves. + You are using the MySQL Query cache with a fairly high traffic database. It might be worth considering to use <a href="http://dev.mysql.com/doc/refman/5.5/en/ha-memcached.html">memcached</a> instead of the MySQL Query cache, especially if you have multiple slaves. The query cache is enabled and the server receives %d queries per second. This rule fires if there is more than 100 queries per second. | round(value,1)
rule 'Query cache efficiency (%)' [Com_select + Qcache_hits > 0 && !fired('Query cache disabled')] @@ -214,6 +214,7 @@ rule 'Rate of reading first index entry' This usually indicates frequent full index scans. Full index scans are faster than table scans but require lots of CPU cycles in big tables, if those tables that have or had high volumes of UPDATEs and DELETEs, running 'OPTIMIZE TABLE' might reduce the amount of and/or speed up full index scans. Other than that full index scans can only be reduced by rewriting queries. Index scans average: %s, this value should be less than 1 per hour | PMA_bytime(value,2)
+# This rule may be applicable to MyISAM-only workloads, but completely wrong for InnoDB - http://www.mysqlperformanceblog.com/2010/06/15/what-does-handler_read_rnd-me... rule 'Rate of reading fixed position' Handler_read_rnd / Uptime value * 60 * 60 > 1 @@ -247,19 +248,19 @@ rule 'Temp disk rate' Created_tmp_disk_tables / Uptime value * 60 * 60 > 1 Many temporary tables are being written to disk instead of being kept in memory. - Increasing {max_heap_table_size} and {tmp_table_size} might help. However some temporary tables are always being written to disk, independent of the value of these variables. To eliminate these you will have to rewrite your queries to avoid those conditions (Within a temprorary table: Presence of a BLOB or TEXT column or presence of a column bigger than 512 bytes) as mentioned in in the <a href="http://dev.mysql.com/doc/refman/5.0/en/internal-temporary-tables.html">MySQL Documentation</a> + Increasing {max_heap_table_size} and {tmp_table_size} might help. However some temporary tables are always being written to disk, independent of the value of these variables. To eliminate these you will have to rewrite your queries to avoid those conditions (Within a temprorary table: Presence of a BLOB or TEXT column or presence of a column bigger than 512 bytes) as mentioned in in the <a href="http://dev.mysql.com/doc/refman/5.5/en/internal-temporary-tables.html">MySQL Documentation</a> Rate of temporay tables being written to disk: %s, this value should be less than 1 per hour | PMA_bytime(value,2)
# I couldn't find any source on the internet that suggests a direct relation between high counts of temporary tables and any of these variables. # Several independent Blog entries suggest (http://ronaldbradford.com/blog/more-on-understanding-sort_buffer_size-2010-0... and http://www.xaprb.com/blog/2010/05/09/how-to-tune-mysqls-sort_buffer_size/) # that sort_buffer_size should be left as it is. And increasing read_buffer_size is only suggested when there are a lot of -# table scans (http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_r... and other sources) though +# table scans (http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_r... and other sources) though # setting it too high is bad too (http://www.mysqlperformanceblog.com/2007/09/17/mysql-what-read_buffer_size-v...). #rule 'Temp table rate' # Created_tmp_tables / Uptime # value * 60 * 60 > 1 # Many intermediate temporary tables are being created. -# This may be caused by queries under certain conditions as mentioned in the <a href="http://dev.mysql.com/doc/refman/5.0/en/internal-temporary-tables.html">MySQL Documentation</a>. Consider increasing {sort_buffer_size} (sorting), {read_rnd_buffer_size} (random read buffer, ie, post-sort), {read_buffer_size} (sequential scan). +# This may be caused by queries under certain conditions as mentioned in the <a href="http://dev.mysql.com/doc/refman/5.5/en/internal-temporary-tables.html">MySQL Documentation</a>. Consider increasing {sort_buffer_size} (sorting), {read_rnd_buffer_size} (random read buffer, ie, post-sort), {read_buffer_size} (sequential scan).
# # MyISAM index cache
hooks/post-receive