Comments on: MySQLTuner v0.8.6 is now available http://rackerhacker.com/2008/02/26/mysqltuner-v086-is-now-available/ Words of wisdom from a server administrator Sat, 11 Oct 2008 15:30:21 +0000 http://wordpress.org/?v=2.6.2 By: Luuk http://rackerhacker.com/2008/02/26/mysqltuner-v086-is-now-available/#comment-492 Luuk Thu, 03 Apr 2008 16:18:10 +0000 http://rackerhacker.com/2008/02/26/mysqltuner-v086-is-now-available/#comment-492 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.... ;-) 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…. ;-)

]]> By: breun http://rackerhacker.com/2008/02/26/mysqltuner-v086-is-now-available/#comment-461 breun Mon, 17 Mar 2008 22:40:03 +0000 http://rackerhacker.com/2008/02/26/mysqltuner-v086-is-now-available/#comment-461 Also, I was thinking: does MySQLTuner warn about buffers/values/etc. being set too high (possibly consuming an unnecessary large amount of memory)? Also, I was thinking: does MySQLTuner warn about buffers/values/etc. being set too high (possibly consuming an unnecessary large amount of memory)?

]]> By: breun http://rackerhacker.com/2008/02/26/mysqltuner-v086-is-now-available/#comment-460 breun Mon, 17 Mar 2008 22:38:20 +0000 http://rackerhacker.com/2008/02/26/mysqltuner-v086-is-now-available/#comment-460 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?). 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?).

]]> By: sceaton http://rackerhacker.com/2008/02/26/mysqltuner-v086-is-now-available/#comment-457 sceaton Mon, 17 Mar 2008 12:58:17 +0000 http://rackerhacker.com/2008/02/26/mysqltuner-v086-is-now-available/#comment-457 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? 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?

]]>