As discussed in my presentation to NYLUG, I wanted to provide system administrations with some really quick analysis and performance fixes if you had limited knowledge of MySQL.
One of the most important things with MySQL is to tune memory properly. This can be complex as there are global buffers, and per session buffers, memory tables, and differences between storage engines. Even this first tip has conditions.
Configuration of MySQL can be found in the my.cnf file (How can I find that). Some variables are dynamic and some are not, and these can change between versions. Check out The most important MySQL Reference Manual page that everybody should bookmark for reference.
Here is a great example for the key_buffer_size found in the [mysqld] section of my.cnf. This is also historically known in legacy config files as key_buffer. This older format has been removed in 5.7. This is a global buffer that is responsible for caching the MyISAM Index data only. Two important things here, this is for the MyISAM storage engine only, and it’s only for indexes. MyISAM data relies on the OS file system cache.
We can confirm the current value in a running MySQL instance with:
mysql> SELECT LOWER(variable_name) as variable, variable_value/1024/1024 as MB
FROM information_schema.global_variables
WHERE variable_name = 'key_buffer_size';
+-----------------+------+
| variable | MB |
+-----------------+------+
| key_buffer_size | 16 |
+-----------------+------+
1 row in set (0.00 sec)
The following query will give you the current size of MyISAM indexes stored on disk in your instance.
mysql> SELECT FORMAT(SUM(data_length)/1024/1024,2) as data_mb,
FORMAT(SUM(index_length)/1024/1024,2) as index_mb
FROM information_schema.tables
WHERE engine='MyISAM';
+--------------+--------------+
| data_mb | index_mb |
+--------------+--------------+
| 504.01 | 114.48 |
+--------------+--------------+
1 row in set (2.36 sec)
NOTE: This is all MyISAM indexes in all schemas. At this time we have not determined what is “hot” data, “cold” data, backup tables etc. It’s a crude calculation, but in absence of more information, seeing that MyISAM is being used, and the buffer is not configured (default is generally 8MB), or is configured poorly as in this example shows that changing this value is an important step to consider. However, The first part of solving the problem is identifying the problem.
Tuning the buffer is hard. You have to take into consideration the amount of system RAM, is the server dedicated for MySQL only, or a shared server for example with a web container such as Apache. Are other storage engines used (for example InnoDB) that requires it’s own buffer size, are there multiple MySQL Instances on the server.
For this example of tuning, we are assuming a dedicated MySQL server and no other storage engines used.
Determining the system RAM and current usage can be found with:
$ free -m
total used free shared buffers cached
Mem: 3955 3846 109 0 424 1891
-/+ buffers/cache: 1529 2426
Swap: 1027 0 1027
With this information, we see a system with 4G of RAM (plenty of available RAM), a key_buffer_size of 16M, and the current maximum size of indexes is 114M. For this most simple case it’s obvious we can increase this buffer, to say 128M and not affect overall system RAM usage, but improve MyISAM performance.
Here are the same numbers for a different system to give you a comparison of what you may uncover.
mysql> SELECT LOWER(variable_name) as variable, variable_value/1024/1024 as MB
-> FROM information_schema.global_variables
-> WHERE variable_name = 'key_buffer_size';
+-----------------+------+
| variable | MB |
+-----------------+------+
| key_buffer_size | 354 |
+-----------------+------+
1 row in set (0.00 sec)
mysql> SELECT FORMAT(SUM(data_length)/1024/1024,2) as data_mb,
-> FORMAT(SUM(index_length)/1024/1024,2) as index_mb
-> FROM information_schema.tables
-> WHERE engine='MyISAM';
+------------+------------+
| data_mb | index_mb |
+------------+------------+
| 150,073.57 | 122,022.97 |
+------------+------------+
1 row in set (3.71 sec)
As I follow up in my next post on the innodb_buffer_pool_size, I will further clarify the complexity of MySQL memory tuning, and show that this information gathering is only a guide, and first step to a more complex analysis and tuning operation.
