MySQLTuner v0.8.6 is now available
Version 0.8.6 of MySQLTuner is now available. It contains a few bug fixes and readability improvements:
Newlines are placed between the sections for increased readability
Each section now contains extra lines to set the sections apart. It makes the output a little longer, but easier to read as well.
Storage engine status color bug
Even if the –nocolor option was passed, the storage engine statuses were being shown in color.
Excluded information_schema from storage engine calculations
The information_schema database was causing extra MEMORY tables to show up in the calculations. They’re now excluded when the calculations are being made.
Shawn Ashlee has also been added as a contributor as he’s been a constant help for the project. He’s recommended implementation ideas and he has worked to create internal MySQLTuner RPM’s for use at Rackspace. Thanks, Shawn!
Greetings!
I’ve recently been using your most excellent MySQL Tuner, and have 2 comments:
1) The script has been constantly suggesting that I increase my tmp_table_size and max_heap_table_size, however doing so hasn’t made any difference. I noticed that your script is based on Matthew Montgomery’s Tuning Primer, so I ran his script to see if it had anything different to say. He has a note in there that BLOB and TEXT columns are not allowed in in memory tables so raising the table_size values might not make a difference. I indeed do have TEXT columns, so it might be helpful to include that note in your script as well.
2) I use Adobe’s Developer Toolkit (formerly Interakt’s MX Kollection) to manage the CMS aspects of our website. It uses a mysql_pconnect statement to connect to the database. This (apparently) causes MySQL to record lots of “aborted connections” and I was receiving the script message that my applications are not closing connections properly. I changed the connection statement to “mysql_connect” so that it would not use persistent connections and the excessive aborted connections, (and thus the script warning) have gone away. I can’t seem to find a consensus on which way is best. Adobe/Interakt apparently think that persistent connections are the way to go. Others opinions online seem to think that not only are they not necessary, but can cause problems on larger, mirrored setups. Comments?
Are the RPM’s really only for internal use? I created my own, but it would be nice if you could provide them. It would be even nicer if the RPM was available from a public yum repository (RPMForge?).
Also, I was thinking: does MySQLTuner warn about buffers/values/etc. being set too high (possibly consuming an unnecessary large amount of memory)?
The reply from sceaton (at March 17th) did not really help me to solv my problem with the recomendations suggested by the script:
——– Recommendations —————————————————–
General recommendations:
Be sure that tmp_table_size/max_heap_table_size are equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
tmp_table_size (> 192M)
max_heap_table_size (> 192M)
outtput from ‘mysqladmin variables | grep table_size’:
| max_heap_table_size | 201326592 |
| tmp_table_size | 201326592 |
so, both values ARE equal….