Due to the cost difference between hard disk and memory, the hard disk capacity of a host instance usually far exceeds the memory capacity. For applications such as databases, in order to ensure faster query efficiency, used data is usually placed in memory for accelerated reading.
LRU for data pages and index pages
The purpose of data pages and index pages is to cache a part of table data and index data. The total amount of data usually exceeds the size of the buffer pool, so only frequently used hot data should be buffered in the buffer pool. InnoDB memory management uses the Least Recently Used (LRU) algorithm. To eliminate the oldest unused data.
In the general LRU algorithm, when a certain data in the linked list is read, it will be placed at the head of the queue. When new data is added and the linked list has reached the maximum number, the data at the end of the linked list is removed, and the newly added data is placed at the head of the linked list.
InnoDB's LRU does not use the traditional double-ended linked list, but has made improvements. There are two problems here:
- read-ahead invalidation
- buffer pool contamination
Optimized read-ahead invalidation
Due to read-ahead (Read-Ahead), the page is put into the buffer pool in advance, but in the end MySQL does not read data from the page, which is called read-ahead failure.
Read-Ahead mechanism
Read-Ahead is used to asynchronously prefetch a predictive behavior of multiple pages in the buffer pool.
InnoDB uses two Read-Ahead algorithms to improve I/O performance.
-
Linear read-ahead linear read ahead
If the sequentially read pages in an extent exceed or equal to the innodb_read_ahead_threshold parameter variable, Innodb will asynchronously read the next extent into the buffer pool, and innodb_read_ahead_threshold can be set to any value from 0-64 (Note: in innodb Each extent has only 64 pages), and the default is 56. The larger the value, the stricter the access mode checking.
-
Random read-ahead Random read ahead
If 13 consecutive pages in the same extent are found in the buffer pool, InnoDB will read the remaining pages in the extent into the buffer pool. The control parameter innodb_random_read_ahead is not enabled by default.
How to optimize read-ahead invalidation?
To optimize read-ahead failure, the idea is:
- Let the pages that fail to read ahead stay in the buffer pool LRU for as short a time as possible
- Let the pages that are actually read be moved to the head of the buffer pool LRU
Specific solutions for InnoDB
It can be seen from the above figure that InnoDB divides the LRU List into two parts. By default, the first 5/8 is the New Sublist (new generation) for storing frequently used hot data pages, and the last 3/8 is the Old Sublist (old generation). The newly read data pages are put into the Old Sublist by default, and will be moved into the New Sublist only after certain conditions are met.
The ratio of the new generation to the old generation is controlled by the parameter innodb_old_blocks_pct in MySQL, and the value ranges from 5 to 95. The default value is 37 (that is, 3/8 of the pool).
- If the data page is actually read (read ahead successfully), it will be added to the head of the new generation
- If the data page is not read, it will be evicted from the buffer pool earlier than the "hot data page" in the new generation
For example, the entire buffer pool is shown in the figure
Suppose there is a data page with page number 50 that is read ahead and added to the buffer pool:
(a). The data page with page number 50 will only be inserted from the head of the old generation, and the pages at the end of the old generation (also the overall tail) will be eliminated, that is, data page No. 8 will be eliminated.
(b). If the data page with page number 50 is not actually read, that is, the read-ahead fails, it will be eliminated from the buffer pool earlier than the data in the new generation
(c). If the page 50 is read immediately, for example, SQL accesses row data in the page. It will be added to the head of the new generation immediately, and the pages of the new generation will be squeezed into the old generation at the same time, and no pages will be really eliminated at this time
The improved version of the buffer pool LRU can well solve the problem of "failure to read ahead". But still can't solve the buffer pool is polluted but problem.
buffer pool contamination
When a certain SQL statement scans a large amount of data in batches, all pages in the buffer pool may be replaced, resulting in a large amount of hot data being swapped out, and MySQL performance drops sharply. This situation is called buffer pool pollution.
Solution
The buffer pool has added a "old generation residence time window" mechanism:
(a). Assume that T= old generation residence time window
(b). Even if the page inserted into the head of the old generation is accessed immediately, it will not be placed in the head of the new generation immediately
(c). Only when "visited" and "staying time in the old generation" is greater than T will it be put into the head of the new generation
If batch data is scanned, pages 91, 92, 93, 94, 95, 96, 97, 98, 99, etc. will be accessed sequentially
If there is no "old generation residence time window" strategy, these pages that are accessed in batches will replace a large amount of hot data.
After adding the "old generation residence time window" strategy, the pages that are loaded in a large number in a short period of time will not be inserted into the head of the new generation immediately, but those pages that have only been accessed once in a short period of time will be eliminated first.
It will be inserted into the head of the new generation only if it stays in the old generation for a long enough time and the stay time is greater than T.
The residence time of the old generation innodb_old_blocks_time is controlled by parameters in milliseconds, and the default is 1000
Summarize
- Buffer pools are a common mechanism for reducing disk access
- InnoDB's buffer pool caches data in units of data pages (pages)
- InnoDB optimizes ordinary LRU,
- The buffer pool is divided into the old generation and the new generation. The pages entering the buffer pool are given priority to the old generation, and the pages are accessed before entering the new generation, so as to solve the problem of read-ahead failure.
- At the same time, the old generation residence time window mechanism is adopted. When the data page is accessed and the residence time in the old generation exceeds the configured threshold, it enters the new generation to solve the problem of batch data access and elimination of a large amount of hot data.