In daily life, you may encounter such a scenario, a SQL statement, the normal execution speed is very fast. However, sometimes it becomes very slow, difficult to reproduce, high randomness, and short duration. What is the situation?
In the previous article, we said that every update of MySQL is not written to disk every time. InnoDB engine will write the record to the redo log first, and then update the record to disk when appropriate.
When the content of the memory data page is inconsistent with the disk data page, we call this memory page a "dirty page". After the memory data is written to the disk, the contents of the data pages on the memory and the disk are the same, which is called a "clean page".
So, there is reason to suspect that it is caused when redo log is written to disk.
When is redo log written to disk?
1. When the redo log is full, the system will stop all update operations and flush dirty pages to disk;
2. If the system has insufficient memory and need to eliminate dirty pages, the dirty pages must be written to disk;
3. When the system is idle, Dirty pages will be cleared;
4. When the system shuts down abnormally;
The impact of these scenarios on system performance:
Scenario 3 is operated when it is idle and has no impact on the system. Scenario 4 is when the system is shut down, so there is no need to consider it.
Scenario 1: At this time, the redo log is full and the system no longer accepts updates directly. All updates are blocked. This situation needs to be avoided as much as possible.
Scenario 2: Insufficient memory. Since InnoDB's strategy is to use memory as much as possible, when the data to be read is not in the memory page, a new data page needs to be applied. At this time, it is necessary to eliminate the longest unused data page from the occupied memory Data page. If it is a clean page to be eliminated, it is directly eliminated; if it is a dirty page to be eliminated, it needs to be flushed to the disk first and then eliminated.
Therefore, the following two situations will cause the query to suddenly slow down:
1. The query needs to be eliminated with more dirty pages;
2. The redo log is full and the update is all blocked;
InnoDB needs a mechanism to control the proportion of dirty pages to try to avoid the above two situations.
InnoDB flushing dirty pages control strategy
innodb_io_capacity
By setting this parameter, tell the disk capacity of the InnoDB host so that InnoDB knows how fast it can flush dirty pages when it needs to flush dirty pages.
To avoid this situation as much as possible, you must set the value of innodb_io_capacity reasonably, and pay more attention to the ratio of dirty pages at ordinary times, and don't let it often approach 75%.
Among them, the ratio of dirty pages is obtained by Innodb_buffer_pool_pages_dirty/Innodb_buffer_pool_pages_total. For specific commands, refer to the following code:
mysql> select VARIABLE_VALUE into @a from global_status where VARIABLE_NAME = 'Innodb_buffer_pool_pages_dirty';
select VARIABLE_VALUE into @b from global_status where VARIABLE_NAME = 'Innodb_buffer_pool_pages_total';
select @a/@b;
innodb_flush_neighbors
This parameter indicates whether to flush dirty pages together with "neighbors".
When the value is 1, there will be the above-mentioned "continuous sitting" mechanism. When the value is 0, it means that you don't find neighbors and brush your own.
If it is a mechanical hard disk, it can be set to 1 to reduce random IO; if it is a high IOPS device such as SSD, it can be set to 0.
Follow this official account and reply "2018" in the background to get the latest Python and Java tutorials of Chuanzhi Podcast 2018.
The public account provides free download services of CSDN resources!