What will you do if your system working perfectly fine, suddenly starts slowing down to the point where it stops responding? Your first reaction is to check the change in the workload. It is a common culprit for most the sudden slowdowns. Let us say that your workload has no significant change. However, your system is continuously slowing down; where will you check next? The next logical place to check what has changed is the configuration. Let us learn about Tracking Changes in MySQL Configuration.
Let us discuss a very opposite situation. Where will you look if your MySQL server starts to perform better than before and there is no change in its workload? Once again, the place to look for is the configuration. It is critical to know what changed from the previous situation when sudden changes happen.
Today’s blog discusses the importance of keeping the change history of MySQL configuration with a fascinating example of variable innodb_read_ahead_threshold.
MySQL Configuration Tracking
Let us understand why it is essential to track configuration changes. The performance of the system depends on many parameters. Let us discuss one particular parameter – innodb_read_ahead_threshold, which we changed and how configuration change history was critical for us.
MySQL engine has many performance tuning mechanisms built into it. When MySQL reads a certain number of pages from a single extend, it sends an I/O request to prefetch multiple pages in the buffer pool memory from the next extend asynchronously. This request is commonly known as a read-ahead request.
MySQL configuration variable innodb_read_ahead_threshold controls when a read-ahead requests trigger. The default value for this variable is set to 56. If InnoDB reads 56 pages sequentially to an extent, it triggers reading the next page. The minimum value for the variable innodb_read_ahead_threshold can be set to 0, which means disabling the read-ahead requests, and when it is set to a maximum value of 64, it fetches the values from the next extend after it reads it completely.
If the MySQL engine did not read to data prefetched by the read-ahead request, it eventually evicts them from the buffer pool. The number of the pages which are not read and evicted from the buffer pool are counted by the variable Innodb_buffer_pool_read_ahead_evicted. All the pages brought into the buffer pool memories are measured with the variable Innodb_buffer_pool_read_ahead. Both the variables are global and reset when the MySQL server is restarted.
It is always a good sign if all the pages read in the buffer pool are read are ultimately utilized by the MySQL engine. It is desirable to have the ratio of the total pages evicted, and the total pages read ahead near zero. If this ratio value is near 1, it indicates wasted efforts by the engine to optimize the performance.
The page read and evicted ratio depends on the current workload and variable innodb_read_ahead_threshold. Throughout the time, DBAs should monitor the values of ratio can change the value of the threshold to the value that works the best for their workload and other parameters.
Solution: SQL Diagnostic Manager for MySQL
There are many different variables and configuration values which impact the performance of MySQL. When there is a change in any configuration variable, DBA needs to record benchmarking values for the performance. If there is any change in the performance, DBA should compare that with the timeline of the configuration change to do an impact analysis. I recommend using SQL DM for MySQL to track all the configuration changes and map them with the performance issues.
Reference: Pinal Dave (http://blog.SQLAuthority.com)
First appeared on Tracking Changes in MySQL Configuration