Hostdog - mysql https://www.hostdog.eu/tags/mysql en Important variables of a MySQL server https://www.hostdog.eu/blog/important-variables-mysql-server <div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even">Whether you are using a MySQL server or a cluster, one thing is sure among users. To optimize your MySQL server as much as possible. Something that MySQL's developers know about and are giving us access to a series of comprehensive variables, that one can use to monitor in realtime the status and performance of a MySQL server. Those variables are accessible via SHOW STATUS command. Below you can find a list of 10 important variables aiding us to draw conclusions about the status of our MySQL server. <strong>1. Threads_connected</strong> This variable indicates the total number of clients that have currently open connections to the server. It provides real-time information on how many clients are currently connected to the server. This can help in traffic analysis or in deciding the best time for a server re-start. <strong>2. Created_tmp_disk_tables</strong> This variable indicates the number of temporary tables that have been created on disk instead of in-memory. Accessing tables on disk is typically slower than accessing the same tables in memory. So queries that use the CREATE TEMPORARY TABLE syntax are likely to be slow when this value is high. <strong>3. Handler_read_first</strong> This variable indicates the number of times a table handler made a request to read the first row of a table index. If MySQL is frequently accessing the first row of a table index, it suggests that it is performing a sequential scan of the entire index. This indicates that the corresponding table is not properly indexed. <strong>4. Innodb_buffer_pool_wait_free</strong> This variable indicates the number of times MySQL has to wait for memory pages to be flushed. If this variable is high, it suggests that MySQL's memory buffer is incorrectly configured for the amount of writes the server is currently performing. <strong>5. Key_reads</strong> This variable indicates the number of filesystem accesses MySQL performed to fetch database indexes. Performing filesystem reads for database indexes slows query performance. If this variable is high, it indicates that MySQL's key cache is overloaded and should be reconfigured. <strong>6. Max_used_connections</strong> This variable indicates the maximum number of connections MySQL has had open at the same time since the server was last restarted. This value provides a benchmark to help you decide the maximum number of connections your server should support. It can also help in traffic analysis. <strong>7. Open_tables</strong> This variable indicates the number of tables that are currently open. This value is best analyzed in combination with the size of the table cache. If this value is low and the table_cache value is high, it's probably safe to reduce the cache size without affecting performance. On the other hand, if this value is high and close to the table_cache value, there is benefit in increasing the size of the table cache. (Remember: this is one of the checks executed by <a href="https://www.hostdog.eu/blog/optimizing-mysql-database-using-mysqltunerpl" title="Optimizing MySQL database using mysqltuner.pl">mysqltuner script</a>) <strong>8. Select_full_join</strong> This variable indicates the number of full joins MySQL has performed to satisfy client queries. A high value indicates that MySQL is being forced to perform full table joins (which are performance-intensive) instead of using indexes. This suggests a need for greater indexing of the corresponding tables. <strong>9. Slow_queries</strong> This variable indicates the number of queries that have taken longer than usual to execute. A high value indicates that many queries are not being optimally executed. A necessary next step would be to examine the slow query log and identify these slow queries for optimization. <strong>10. Uptime</strong> This variable indicates the number of seconds since the server was last restarted. This value is useful to analyze server uptime, as well as to generate reports on overall system performance. A consistent low value indicates that the server is being frequently restarted, thereby causing frequent interruptions to client service. <a href="http://www.techrepublic.com/blog/opensource/10-mysql-variables-that-you-should-monitor/56" title="10 mysql variables that you should monitor" rel="nofollow">Source</a></div></div></div><div class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above clearfix"><h3 class="field-label">Tags: </h3><ul class="links"><li class="taxonomy-term-reference-0"><a href="https://www.hostdog.eu/tags/monitoring">monitoring</a></li><li class="taxonomy-term-reference-1"><a href="https://www.hostdog.eu/tags/mysql">mysql</a></li></ul></div> Wed, 22 May 2013 12:07:26 +0000 n.stefanis 359 at https://www.hostdog.eu Optimizing MySQL database using mysqltuner.pl https://www.hostdog.eu/blog/optimizing-mysql-database-using-mysqltunerpl <div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even">MySQLTuner is a script written in perl which based to MySQL logs, it generates some pretty safe suggestions about which variables can be changed in MySQL config file for a little extra performance First, we download the script and make it executable: <div class="codeblock"><code>wget https://raw.github.com/major/MySQLTuner-perl/master/mysqltuner.pl<br />chmod +x mysqltuner.pl </code></div> Then we run it: <div class="codeblock"><code> ./mysqltuner.pl</code></div> It is for best, that MySQL has not little uptime when running the script, the longer the more accurate suggestions it will be able to output. As opposed to the "MySQL started within last 24 hours – recommendations may be inaccurate." error message if you attempt to run the script right after a MySQL restart. <div class="codeblock"><code> &gt;&gt;  MySQLTuner 1.2.0 - Major Hayden &lt;major@mhtx.net&gt;<br /> &gt;&gt;  Bug reports, feature requests, and downloads at http://mysqltuner.com/<br /> &gt;&gt;  Run with '--help' for additional options and output filtering<br /><br />-------- General Statistics --------------------------------------------------<br />[--] Skipped version check for MySQLTuner script<br />[OK] Currently running supported MySQL version 5.1.68-cll<br />[OK] Operating on 64-bit architecture<br /><br />-------- Storage Engine Statistics -------------------------------------------<br />[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster<br />[--] Data in MyISAM tables: 1G (Tables: 5367)<br />[--] Data in InnoDB tables: 400M (Tables: 4079)<br />[--] Data in MEMORY tables: 0B (Tables: 33)<br />[!!] Total fragmented tables: 4684<br /><br />-------- Security Recommendations  -------------------------------------------<br />[OK] All database users have passwords assigned<br /><br />-------- Performance Metrics -------------------------------------------------<br />[--] Up for: 15d 10h 40m 6s (68M q [51.568 qps], 1M conn, TX: 794B, RX: 12B)<br />[--] Reads / Writes: 77% / 23%<br />[--] Total buffers: 78.0M global + 7.5M per thread (800 max threads)<br />[OK] Maximum possible memory usage: 5.9G (76% of installed RAM)<br />[OK] Slow queries: 0% (1K/68M)<br />[OK] Highest usage of available connections: 8% (66/800)<br />[OK] Key buffer size / total MyISAM indexes: 36.0M/229.4M<br />[OK] Key buffer hit rate: 98.5% (572M cached / 8M reads)<br />[OK] Query cache efficiency: 70.8% (38M cached / 54M selects)<br />[!!] Query cache prunes per day: 723587<br />[OK] Sorts requiring temporary tables: 0% (4K temp sorts / 2M sorts)<br />[!!] Joins performed without indexes: 109545<br />[!!] Temporary tables created on disk: 31% (1M on disk / 4M total)<br />[OK] Thread cache hit rate: 99% (66 created / 1M connections)<br />[!!] Table cache hit rate: 0% (1K open / 83M opened)<br />[OK] Open file limit used: 3% (1K/48K)<br />[OK] Table locks acquired immediately: 99% (26M immediate / 26M locks)<br />[!!] InnoDB data size / buffer pool: 400.4M/8.0M<br /><br />-------- Recommendations -----------------------------------------------------<br />General recommendations:<br />    Run OPTIMIZE TABLE to defragment tables for better performance<br />    Enable the slow query log to troubleshoot bad queries<br />    Adjust your join queries to always utilize indexes<br />    When making adjustments, make tmp_table_size/max_heap_table_size equal<br />    Reduce your SELECT DISTINCT queries without LIMIT clauses<br />    Increase table_cache gradually to avoid file descriptor limits<br />Variables to adjust:<br />    query_cache_size (&gt; 16M)<br />    join_buffer_size (&gt; 2.0M, or always use indexes with joins)<br />    tmp_table_size (&gt; 16M)<br />    max_heap_table_size (&gt; 16M)<br />    table_cache (&gt; 1024)<br />    innodb_buffer_pool_size (&gt;= 400M)</code></div> You should carefully read the results, especially the recommendations at the end which shows exactly which variables you should adjust in the [mysqld] section of your my.cnf file (/etc/mysql/my.cnf for Debian and Ubuntu). Whenever you change your my.cnf, make sure that you restart MySQL service. After changes to my.cnf file, you can come back after 2 or 3 days and run mysqltuner.pl again, in order to see if there are any additional suggestions to improve the MySQL performance. This way you are able to optimize your MySQL's settings step by step. Give extra attention to "Query cache efficiency" percentage and note down it's change. This method is ideal for learning as well, while you may come up with random configurations across the Internet matching your server's specification, they could become confusing when you have to change a bunch of variables at once or it wouldn't give you the time to study how every variable change affects your MySQL server performance. Please note: We hold no responsibility for any changes you make to your my.cnf config file. Also we strongly suggest you to take backups not only from my.cnf config file itself but take whole database backups as well.</div></div></div><div class="field field-name-field-tags field-type-taxonomy-term-reference field-label-above clearfix"><h3 class="field-label">Tags: </h3><ul class="links"><li class="taxonomy-term-reference-0"><a href="https://www.hostdog.eu/tags/linux">linux</a></li><li class="taxonomy-term-reference-1"><a href="https://www.hostdog.eu/tags/mysql">mysql</a></li><li class="taxonomy-term-reference-2"><a href="https://www.hostdog.eu/tags/mysql-optimization">mysql optimization</a></li><li class="taxonomy-term-reference-3"><a href="https://www.hostdog.eu/tags/optimization">optimization</a></li><li class="taxonomy-term-reference-4"><a href="https://www.hostdog.eu/tags/database-optimization">database optimization</a></li><li class="taxonomy-term-reference-5"><a href="https://www.hostdog.eu/tags/mysqltuner">mysqltuner</a></li></ul></div> Wed, 01 May 2013 12:28:53 +0000 ploupas 352 at https://www.hostdog.eu