A cache cleaning method for random small IO
By organizing and sorting according to the percentage of dirty data of the block and filling it with holes when needed, the problems of low cache hit rate and high cache pressure in random small IO scenarios are solved, efficient cache cleaning is achieved, and system IO performance is guaranteed.
Patent Information
- Application Number
- CN202411650860.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-19
- Publication Date
- 2025-03-14
- Estimated Expiration
- 2044-11-19
AI Technical Summary
In random small IO scenarios, the cache hit rate is low, the cache pressure is high, and the dirty data occupies capacity, resulting in the cache being easily full, which in turn affects the system IO performance.
By obtaining the percentage of dirty data of each block, move the block to the block group of the corresponding dirty data threshold range, traverse the block group from high to low according to the dirty data threshold range, find cleanable blocks for cache cleaning, and fill them with holes when needed.
This method can efficiently and quickly find relatively continuous dirty data to be cleaned from high to low, reduce IO addressing distance and disk search time, improve cache cleaning efficiency, avoid cache fullness, and ensure system IO performance.
Smart Images

Figure CN119149452B_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present specification relate to the field of storage technology, and in particular to a cache cleaning method for random small IOs. Background Art
[0002] Random small IO is a type of read and write operation involving small data blocks in random order. In order to reduce the number of accesses to storage devices when reading and writing data and improve system performance, a cache mechanism that can temporarily store data is usually used to improve system IO performance. However, in random small IO scenarios, random small IO read and write operations are highly random, making it difficult to effectively predict and cache future IO requests. The cache hit rate is low and the cache pressure is high. At the same time, fragmented data causes a surge in the number of IO requests, and a relatively small cache can easily be exhausted, which in turn affects the IO performance of the entire system. Therefore, an efficient cache cleaning method is needed to clean dirty data in cache nodes in a timely manner to avoid cache overflow and achieve the effect of improving system IO performance. Summary of the invention
[0003] The embodiments of the present specification provide a cache cleaning method for random small IOs, aiming to solve one or more of the above problems and other potential problems.
[0004] In order to achieve the above objectives, the following technical solutions are provided:
[0005] According to a first aspect of the present specification, a cache cleaning method for random small IO is provided, the method comprising:
[0006] Obtaining dirty data percentages of cache nodes under a number of blocks; wherein the blocks are divided by backend devices, the blocks are grouped and managed by a number of block groups, and the number of block groups is less than the number of blocks; the dirty data percentage is the percentage of dirty data in the block to the total data storage capacity of the block;
[0007] Based on the dirty data percentage of each of the blocks, the blocks are respectively moved to the block group corresponding to the dirty data threshold range; wherein the dirty data percentage of the block is within the dirty data threshold range of the block group managing the block;
[0008] The block group is traversed in order from high to low according to the dirty data threshold range, and the cleanable blocks are found for cache cleaning. When cleaning, it is first determined whether the cache node under the found block needs hole filling. If necessary, the hole filling is performed first and then the cleaning process is started.
[0009] The cache cleaning method for random small IO in the embodiments of this specification organizes and sorts the blocks based on the amount of dirty data in the cache nodes under each block. During cleaning, relatively continuous dirty data to be cleaned with a high to low amount of dirty data can be found efficiently and quickly to reduce the addressing distance of IO during the cleaning process and reduce the disk seek time. At the same time, when the cache node needs to fill a hole, it is filled to reduce IO time and avoid disk small write problems. The cache cleaning efficiency is higher, the cache is not easy to be full, and the IO performance of the entire system is guaranteed.
[0010] In some embodiments, traversing the block group in descending order of the dirty data thresholds to find the cleanable blocks for cache cleaning includes:
[0011] Traversing the block group in descending order of the dirty data threshold range to find the cleanable block;
[0012] Searching for cache nodes to be cleaned in the blocks found, and when the number of cache nodes to be cleaned is greater than the maximum number of single cleanings, cleaning the dirty data of the cache nodes to be cleaned, and continuing to traverse and search for other cleanable blocks after the cleaning is completed, until the traversal is completed; wherein the cleaned blocks are moved to the corresponding block group based on their new dirty data percentage;
[0013] When the number of cache nodes to be cleaned is less than or equal to the maximum number of single cleanings, continue to traverse to find other blocks that can be cleaned, and repeat the above cleaning process until the traversal is completed.
[0014] In some embodiments, after the traversal is completed, it is determined whether there is a cache node to be cleaned. If so, the dirty data of the cache node to be cleaned is cleaned, otherwise the cleaning process is terminated.
[0015] In some embodiments, the traversal and cleaning process is started on a timed basis.
[0016] In some embodiments, determining whether the cache node under the block found needs hole filling includes: calculating the hole value and the number of holes of the cache node under the block found, calculating the IO time before and after the hole filling of the cache node, and taking the IO number when the IO time after the hole filling is shorter as the hole filling threshold; when the IO number of the cache node is greater than or equal to the hole filling threshold, the cache node needs hole filling.
[0017] In some embodiments, in a non-redundant array structure composed of n disks, the formula for the IO time S before hole filling is as follows:
[0018]
[0019] in, represents the average seek time, Indicates the synchronization overhead time of n disks. represents the average delay time, Indicates the data transmission time.
[0020] In some embodiments, in a RAID5 array structure composed of n+1 disks, the formula for the IO time before hole filling is as follows:
[0021]
[0022]
[0023] in, It represents the minimum IO time before the hole is filled, that is, the IO time under the optimal distribution of m IOs; It indicates the maximum IO time before the hole is filled, that is, the IO time under the worst distribution of m IOs; m indicates the number of IOs. Indicates 4K byte data transfer time, Indicates the time taken for an XOR calculation.
[0024] In some embodiments, the formula for the IO time after hole filling is as follows:
[0025]
[0026] in, It indicates the time taken for 1M IO after the hole is filled. represents the average seek time, Indicates the synchronization overhead time of n disks. represents the average delay time, express Byte data transfer time, Indicates the time taken for an XOR calculation.
[0027] In some embodiments, the hole filling includes: reading data in the hole space of the cache node into a memory. BRIEF DESCRIPTION OF THE DRAWINGS
[0028] By reading the following detailed description with reference to the accompanying drawings, the above and other objects, features and advantages of the embodiments of the present specification will become readily understood. In the accompanying drawings, several embodiments of the present specification are shown by way of example and not limitation.
[0029] Figure 1 A flow chart of a cache cleaning method for random small IO in an embodiment of this specification is shown;
[0030] Figure 2 A schematic diagram showing a block and blockchain according to an embodiment of this specification is shown;
[0031] Figure 3 A schematic diagram showing the mapping relationship between cache nodes and memory in an embodiment of this specification is shown. DETAILED DESCRIPTION
[0032] The preferred embodiments of the present specification will be described in more detail below with reference to the accompanying drawings. Although the preferred embodiments of the present specification are shown in the accompanying drawings, it should be understood that the present specification can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to make the present specification more thorough and complete, and to fully convey the scope of the present specification to those skilled in the art.
[0033] The term "including" and its variations used in this document represent open inclusion, that is, "including but not limited to". Unless otherwise stated, the term "or" means "and / or". The term "based on" means "based at least in part on". The terms "an example embodiment" and "an embodiment" mean "at least one example embodiment". The term "another embodiment" means "at least one other embodiment". Terms such as "upper", "lower", "front", and "rear" indicating placement or positional relationships are based on the orientation or positional relationships shown in the drawings, and are only for the convenience of describing the principles of this specification, and do not indicate or imply that the referred elements must have a specific orientation, be constructed or operate in a specific orientation, and therefore should not be understood as limitations on this specification.
[0034] Cache is a technology that meets the access requirements of slow storage devices by storing data on a device with a faster access speed than the original data source. When the system needs to read a certain data, it will first check whether the data already exists in the cache. If the required data exists, that is, the cache hits, the data is read directly from the cache, which is faster than reading from the original data source; if the required data does not exist, that is, the cache misses, the system will read the data from the original data source and store the data in the cache for future use. However, the storage capacity of the cache is smaller than the storage capacity of the original data source at the back end. Especially in a random small IO environment, the data on the storage medium is accessed in a random order, and it is difficult to effectively predict and cache future IO requests. The cache hit rate is low and the storage capacity is easy to be exhausted; small IO refers to the relatively small data blocks in the access process, so frequent addressing and data transmission are required, which makes the number of IO requests surge, further speeding up the exhaustion speed of the cache, and limiting the IO performance of the entire system when the cache is exhausted. Therefore, the embodiment of this specification shows an efficient cache cleaning method, and the following is a detailed description of a cache cleaning method for random small IO in the embodiment of this specification in conjunction with the accompanying drawings.
[0035] The method of the embodiment of this specification includes the following steps:
[0036] S1. Obtain the dirty data percentage of cache nodes under several blocks;
[0037] S3, moving the blocks to the block group corresponding to the dirty data threshold range based on the dirty data percentage of each block;
[0038] S5. Traverse the block group in order from high to low according to the dirty data threshold range, and find the cleanable block to perform cache cleaning.
[0039] The embodiments of this specification use blocks as storage management units. The blocks in step S1 are divided by the backend device according to a certain size. For example, a block is 64M in size. Each block is composed of 64 cache nodes of 1M in size. Each block corresponds to a block metadata. The block metadata is used to record the dirty data status of the cache node under the corresponding block. Dirty data in a cache node refers to data stored in the cache node that is inconsistent with the actual data in the original data source or is expired, erroneous, or meaningless. These data need to be cleaned up first. The dirty data percentage is the percentage of the amount of dirty data in the block to the total data storage capacity of the block, reflecting the dirty data storage status of the block. The block is managed by a number of block groups. Specifically, the block groups manage the blocks through blockchains respectively, so that the blocks mounted on the blockchain are arranged in chronological order. The number of block groups is less than the number of blocks, that is, the number of blockchains is less than the number of blocks. Each blockchain corresponds to a different dirty data threshold range, for example: Figure 2 As shown, 11 block groups are set, and the blockchains of the block groups are chunk_list[0]-chunk_list
[10] respectively. The dirty data threshold range of the blockchain chunk_list[0] is (0%, 0%], the dirty data threshold range of the blockchain chunk_list[1] is (0%, 10%], the dirty data threshold range of the blockchain chunk_list[2] is (10%, 20%], and so on. The boundary values of the dirty data threshold ranges of the subsequent blockchains are increased by 10% until the dirty data threshold range reaches (90%, 100%].
[0040] In step S3, each block is mounted under a different blockchain based on its dirty data percentage. As the cache is used and cleaned, the dirty data percentage in the block changes, and then continues to be moved to the corresponding blockchain based on the respective dirty data percentage, so that all blocks are grouped and arranged according to different dirty data situations. For example: the block that has just been cleaned is mounted on the blockchain chunk_list[0]. As the cache in the block is used, the dirty data percentage of the block will gradually increase. When it increases to the range of 10%-20%, the block will be moved and mounted to the blockchain chunk_list[1]. The dirty data percentage continues to increase, and the block will continue to be moved to the corresponding blockchain for mounting based on the dirty data threshold range where the dirty data percentage is located.
[0041] The blocks are organized and arranged according to different dirty data situations, and the blocks with more dirty data can be cleaned first during cache cleaning, thereby reducing the disk addressing distance and seek time during the cleaning process and speeding up the cache cleaning efficiency. The cleaning process of step S5 includes the following steps:
[0042] S51, traversing the block group in descending order according to the dirty data threshold range to find the block that can be cleaned;
[0043] S53, searching for cache nodes to be cleaned in the blocks found, and when the number of cache nodes to be cleaned is greater than the maximum number of single cleanings, cleaning the dirty data of the cache nodes to be cleaned, and after cleaning, continuing to traverse and search for other cleanable blocks until the traversal is completed; when the number of cache nodes to be cleaned is less than or equal to the maximum number of single cleanings, continuing to traverse and search for other cleanable blocks, and repeating the above cleaning process until the traversal is completed.
[0044] Dirty data may include dirty data that has been cleaned or does not need to be cleaned. Blocks with a large percentage of dirty data may also contain cache nodes with less dirty data. Therefore, in step S53, it is necessary to first find cache nodes to be cleaned. Cleaning is performed when the number of cache nodes to be cleaned is greater than the maximum number of single cleanings in order to retain a portion of uncleaned cache nodes, provide a certain amount of pressure for the back-end device, and give full play to the full performance of the back-end device. The cleaned block is moved and mounted to the corresponding blockchain based on its new percentage of dirty data.
[0045] After the traversal process in step S55 is completed, it is determined whether there are still cache nodes to be cleaned to prevent missing some cache nodes from being uncleaned. If there are, the dirty data of the cache nodes to be cleaned is cleaned, otherwise the cleaning process is terminated. The above-mentioned traversal and cleaning processes are started at a fixed time, and the traversal process can also be performed only on the block group with a larger dirty data threshold range to improve the efficiency of a single cleaning.
[0046] In step S53, when cleaning the dirty data of the cache node to be cleaned, it is determined whether the cache node to be cleaned needs hole filling. If necessary, the hole filling is performed first and then the cleaning process is started. The hole filling refers to reading the data in the space corresponding to the hole from the back-end device to the memory, so that all data blocks in the entire cache node space have cache data corresponding to them. After the hole is filled, several small IOs can be constructed into large IOs, reducing the number of IO times to avoid disk underwriting problems, and also avoiding the existence of holes when cleaning dirty data. It can only construct multiple small IOs to fall to the disk, affecting the cache cleaning efficiency. When the IO number reaches a certain number, the IO time after the hole is filled will be less than the IO time before the hole is filled, thereby improving the IO performance.
[0047] Specifically, determining whether the cache node to be cleaned needs hole filling includes the following steps:
[0048] S531, calculating the hole value and the number of holes of the cache node;
[0049] S533, calculating the IO time consumption before and after the hole filling of the cache node, and taking the IO number when the IO time consumption is shorter after the hole filling as the hole filling threshold;
[0050] S535: When the IO quantity of the cache node is greater than or equal to the hole filling threshold, the cache node needs hole filling.
[0051] In step S531, Figure 3 As shown in the figure, each cache node corresponds to a continuous 1M space of the backend device. The cache node is divided into 256 data blocks in units of 4K. When caching, it is mapped in units of data block size. The mapped data blocks will be allocated memory one-to-one. The cache node includes metadata and block index. The metadata includes a status bitmap and node index indicating the status of the block index. The block index records the memory page address corresponding to the block. Each data block uses a valid status bit to indicate whether the data block is valid, that is, whether there is cached data in the data block space. Based on the valid bit of each data block and the valid bit and dirty bit of each sector in the bitmap, the number of IOs and the hole situation in each cache node can be calculated.
[0052] Disk IO time mainly consists of seek time, delay time and transmission time. In the case of small IO, the transmission time can be ignored, and the IO time mainly calculates the seek time and delay time. For example: in a non-redundant array structure composed of n disks, the formula for the IO time S before hole filling is as follows:
[0053]
[0054] in, represents the average seek time, Indicates the synchronization overhead time of n disks. represents the average delay time, Indicates the data transmission time.
[0055] For a RAID5 array consisting of n+1 disks, in a small write scenario, for m write operations, the best case is that m IOs are distributed on different stripes, in which case the host needs to perform m+1 read operations, m+1 write operations, and 2m XOR operations; the worst case is that m IOs are distributed on the same stripe, in which case the host needs to perform 2m read operations, 2m write operations, and 2m XOR operations. Therefore, in a RAID5 array structure consisting of n+1 disks, if m IOs are evenly distributed on the data disks of the array, and the IO size is not larger than the minimum stripe processing unit of 4K, the formula for the IO time before hole filling is as follows:
[0056]
[0057]
[0058] in, It represents the minimum IO time before the hole is filled, that is, the IO time under the optimal distribution of m IOs; It indicates the maximum IO time before the hole is filled, that is, the IO time under the worst distribution of m IOs; m indicates the number of IOs. Indicates 4K byte data transfer time, Indicates the time taken for an XOR calculation.
[0059] The formula for the IO time after hole filling is as follows:
[0060]
[0061] in, It indicates the time taken for 1M IO after the hole is filled. represents the average seek time, Indicates the synchronization overhead time of n disks. represents the average delay time, express Byte data transfer time, Indicates the time taken for an XOR calculation.
[0062] The calculation steps of the hole filling threshold in step S533 are as follows:
[0063] Assume that the IO time after hole filling is shorter, that is:
[0064] Decomposing the formula we get:
[0065]
[0066] m IOs are distributed in 1M space, so m IOs only need one seek, and the average seek time can be ignored. In a commonly used 4+1 disk array, 80 IOs can be sufficient. and , that is, the hole filling threshold at this time is 80. When the number of IOs is greater than or equal to 80, it can be guaranteed that the time taken after the hole filling is shorter than that after the hole filling.
[0067] Although several specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of this specification. Certain features described in the context of separate embodiments may also be implemented in a single implementation in combination. Conversely, various features described in the context of a single implementation may also be implemented in multiple implementations individually or in any suitable sub-combination.
[0068] Although the subject matter has been described in language specific to structural features and / or methodological logical actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims.
[0069] The embodiments of the present specification have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.
Claims
1. A cache cleaning method for random small IO, characterized in that the method include: Obtaining dirty data percentages of cache nodes under a number of blocks; wherein the blocks are divided by backend devices, the blocks are grouped and managed by a number of block groups, and the number of block groups is less than the number of blocks; the dirty data percentage is the percentage of dirty data in the block to the total data storage capacity of the block; Based on the dirty data percentage of each of the blocks, the blocks are respectively moved to the block group corresponding to the dirty data threshold range; wherein the dirty data percentage of the block is within the dirty data threshold range of the block group managing the block; Traversing the block group in order from high to low according to the dirty data threshold range, finding the cleanable block for cache cleaning, and first determining whether the cache node under the found block needs hole filling during cleaning, and if necessary, first filling the hole and then starting the cleaning process; Traversing the block group in descending order of the dirty data thresholds to find the cleanable blocks for cache cleaning includes: Traversing the block group in descending order of the dirty data threshold range to find the cleanable block; Searching for cache nodes to be cleaned in the blocks found, and when the number of cache nodes to be cleaned is greater than the maximum number of single cleanings, cleaning the dirty data of the cache nodes to be cleaned, and continuing to traverse and search for other cleanable blocks after the cleaning is completed, until the traversal is completed; wherein the cleaned blocks are moved to the corresponding block group based on their new dirty data percentage; When the number of cache nodes to be cleaned is less than or equal to the maximum number of single cleanings, continue to traverse to find other blocks that can be cleaned, and repeat the above cleaning process until the traversal is completed; Determining whether the cache node under the block found needs hole filling, including: calculating the hole value and the number of holes of the cache node under the block found, calculating the IO time consumption before and after the hole filling of the cache node, taking the IO number when the IO time consumption is shorter after the hole filling as the hole filling threshold, when the IO number of the cache node is greater than or equal to the hole filling threshold, the cache node needs hole filling; the IO time consumption is determined based on the seek time, delay time and data transmission time required for the IO number operation; The hole filling refers to reading the data in the hole space of the cache node from the backend device to the memory.
2. The method according to claim 1, characterized in that After the traversal is completed, it is determined whether there is the cache node to be cleaned. If so, the dirty data of the cache node to be cleaned is cleaned, otherwise the cleaning process is terminated.
3. The method according to claim 2, characterized in that The traversal and cleaning process is started at a fixed time.
4. The method according to claim 1, characterized in that: In a non-redundant array structure consisting of n disks, the formula for the IO time S before the hole is filled is as follows: in, represents the average seek time, Indicates the synchronization overhead time of n disks. represents the average delay time, Indicates the data transmission time.
5. The method according to claim 1, characterized in that In a RAID5 array structure consisting of n+1 disks, the formula for the IO time before hole filling is as follows: in, It represents the minimum IO time before the hole is filled, that is, the IO time under the optimal distribution of m IOs; It indicates the maximum IO time before the hole is filled, that is, the IO time under the worst distribution of m IOs; m indicates the number of IOs. Indicates 4K byte data transfer time, Indicates the time taken for an XOR calculation.
6. The method according to claim 5, characterized in that The formula for the IO time after hole filling is as follows: in, It indicates the time taken for 1M IO after the hole is filled. represents the average seek time, Indicates the synchronization overhead time of n disks. represents the average delay time, express Byte data transfer time, Indicates the time taken for an XOR calculation.
Citation Information
Patent Citations
Method and equipment for cleaning dirty data of cache
CN112433964A
Data processing apparatus and method for powering down a cache
US20130036270A1