Information processing device

A multi-threaded Kernel Flusher Thread and dedicated I/O queues for multiple disks enhance I/O efficiency, addressing performance bottlenecks and delays in Linux kernels, particularly on distributed storage and NVMe SSDs, by optimizing write operations and preventing IO-less Dirty Throttling.

WO2025262911A1PCT designated stage Publication Date: 2025-12-26NT T INC
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
PCT/JP2024/022517
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-06-21
Publication Date
2025-12-26

AI Technical Summary

Technical Problem

Conventional Linux kernels perform write operations using a single thread, which limits I/O performance on distributed storage and network-attached storage and does not optimize for ultra-high-speed NVMe SSDs, leading to performance bottlenecks and delays due to communication delays and IO-less Dirty Throttling.

Method used

Implementing a multi-threaded Kernel Flusher Thread and utilizing multiple disks with dedicated I/O queues and Merge Read/Write processing to enhance I/O efficiency, prevent IO-less Dirty Throttling, and improve application performance.

Benefits of technology

Significantly speeds up disk I/O processing, improves application performance, and reduces delays by fully utilizing parallel processing capabilities of NVMe SSDs and distributed storage, while preventing IO-less Dirty Throttling.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure JP2024022517_26122025_PF_FP_ABST
    Figure JP2024022517_26122025_PF_FP_ABST
Patent Text Reader

Abstract

An information processing device 10 includes a buffer 12 for temporarily holding data 11 to be written to a virtual disk 31 by using a plurality of virtual disks 31, allocates any one of the plurality of virtual disks 31 for each piece of data 11 obtained by dividing all the data, and performs processing for writing the data 11 held in the buffer 12 for each of the plurality of virtual disks 31 in parallel.
Need to check novelty before this filing date? Find Prior Art

Description

Information processing device

[0001] The present disclosure relates to an information processing device.

[0002] In the traditional Linux kernel, write processing to the actual disk in Buffered I / O was mainly performed by a single thread. When a Write system call is executed from a user space process, the data is written to a dirty page in memory managed within the kernel and the Write system call processing is completed. A dirty page is a modified page (usually a 4KB memory area) that has not yet been written to the disk. The kernel writes dirty pages to the actual disk periodically or by using the fsync system call. The process of writing dirty pages is handled by a kernel worker called the Kernel Flusher Thread, and is performed by a single thread per device.

[0003] In preparation for the case where the number of dirty pages increases too much, there is an IO-less Dirty Throttling function that intentionally delays write system calls (Non-Patent Document 1). IO-less Dirty Throttling is effective in preventing memory exhaustion.

[0004] Fengguang Wu, "IO-less Dirty Throttling," LINUXCON JAPAN 2012, Internet〈https: / / events.static.linuxfound.org / images / stories / pdf / lcjp2012_wu.pdf〉

[0005] In conventional Linux kernels, the kernel flusher thread runs single-threaded to ensure stable write operations for storage with fast latency and relatively low write bandwidth (e.g., local HDDs and SSDs). As a result, single-threaded operations cannot fully utilize I / O performance on distributed storage or network-attached storage, which have slow latency. It also does not operate optimally for ultra-high-speed NVMe SSDs. Specifically, on storage with slow disk write latency due to communication delays in the network, such as distributed storage or network-attached storage, single-threaded operations require the next operation to wait until one I / O operation is completed, creating a performance bottleneck. Ultra-high-speed NVMe SSDs are capable of processing multiple I / O operations in parallel, and single-threaded write operations do not fully utilize this parallel processing capability.

[0006] In addition, if the number of dirty pages continues to increase due to slow write performance, IO-less Dirty Throttling occurs, causing user-space processes to constantly experience delays in Write system calls.

[0007] The present disclosure has been made in view of the above, and aims to speed up disk I / O processing and improve application performance.

[0008] An information processing device of one embodiment of the present disclosure uses multiple disks, assigns one of the multiple disks to each configuration data that divides the data to be stored into functional units, places the configuration data in a continuous area on the disk, and is equipped with a buffer that temporarily holds update data to be written to the disk and an independent dedicated I / O queue for each of the multiple disks, and for each of the multiple disks, performs a process in parallel to write the update data held in the buffer to the disk via the dedicated I / O queue, and executes multiple I / O commands together for the update data that is continuous on the disk.

[0009] According to the present disclosure, it is possible to speed up disk I / O processing and improve application performance.

[0010] Fig. 1 is a diagram showing an example of the configuration of an information processing device. Fig. 2 is a diagram showing an example of the configuration of a database device. Fig. 3 is a diagram for explaining merge read / write processing. Fig. 4 is a flowchart showing an example of the processing flow for allocating data areas to each disk. Fig. 5 is a diagram showing an example of the hardware configuration of an information processing device.

[0011] In this disclosure, we significantly speed up disk I / O processing by multi-threading the Kernel Flusher Thread and increasing the probability of Merge Read / Write processing, which aggregates small I / O processes and improves I / O efficiency. We also suppress the occurrence of IO-less Dirty Throttling, thereby reducing delays in write system calls. Each optimization approach is explained below.

[0012] [Multithreading of Kernel Flusher Threads] In storage systems such as distributed storage and network-attached storage, which have slow disk write latency due to communication delays, writing data in multiple threads can improve throughput. Furthermore, in ultra-high-speed NVMe SSDs, writing data in multiple threads can fully utilize their high-speed bandwidth. Therefore, multithreading the Kernel Flusher Thread, which is a process in kernel space, is extremely effective in improving Buffered I / O performance.

[0013] There are two possible methods for multi-threading a kernel flusher thread: using multiple devices (hereinafter also referred to as disks or storage) and applying a patch within the kernel.

[0014] Multithreading can be achieved by using multiple devices and running one Kernel Flusher Thread per device. Distributed storage and network-attached storage have the ability to create multiple virtual disks as logical units, so this function can be used. In addition, since each virtual disk is composed of separate disks within the distributed storage, using multiple virtual disks can extract I / O performance from more disks, which is also effective in terms of I / O performance.

[0015] There are three ways to apply patches within the kernel: creating a kernel module to overwrite the functions in the relevant locations; using kernel live patching to incorporate logic that always runs in multithreading; and directly rewriting the kernel code and recompiling it so that only the devices specified in the kernel options always run in multithreading with the specified number of threads.

[0016] [Improving Merge Read / Write Efficiency] Merge Read / Write is a function implemented in the kernel's Buffered I / O that executes multiple I / O commands from a user-space application in a batch. For example, suppose an application issues eight 4KB I / O commands. With Merge Read / Write, if the 4KB I / O commands are in a contiguous area on the storage device, they are processed as a single 32KB I / O command within the kernel. This reduces the number of I / O commands and improves I / O efficiency and performance. Furthermore, since I / O queues that hold I / O commands are created for each device, using multiple devices increases the probability that each I / O queue contains I / O commands in a contiguous area. This also improves the efficiency of searching for contiguous areas within the I / O queue, dramatically increasing the probability of executing Merge Read / Write within the I / O queue. To increase throughput, each I / O queue for each device can be configured with multiple queues.

[0017] This disclosure aims to improve merge read / write efficiency by preparing multiple devices, reserving contiguous areas on each device, and utilizing the contiguous areas in an application-specific manner. A database is used as an example of using contiguous areas in an application-specific manner. In a database, table data, partition tables, and index data are allocated to each contiguous area, and data such as database logs (Write-Ahead Logs: WALs) and backup logs (archive logs) are allocated to each contiguous area. This invention is particularly effective in accelerating WALs. By dramatically improving the efficiency of the merge write described above, WAL performance, which is essential for database performance, is significantly improved, thereby improving the write performance of the entire database. Furthermore, by creating I / O performance margins, this technology has the advantage of maintaining database performance without significantly reducing the latency of ongoing transactions, even during checkpoint operations with high I / O loads. In partitioned tables, range partitioning is recommended to ensure contiguous data allocation. There are several ways to secure contiguous space on a device: by preparing multiple devices and using a device as a functional unit for each database, by partitioning, or by using fallocate.

[0018] [Preventing IO-less Dirty Throttling] IO-less Dirty Throttling is a function to prevent memory depletion caused by an excessive increase in dirty pages in memory, and is an OS function that limits the I / O performance of system calls when a certain number of dirty pages have been generated in memory. IO-less Dirty Throttling often occurs in applications such as databases that write out large amounts of dirty pages at specific times, and has a significant impact on application performance degradation.

[0019] In this disclosure, we propose three methods to suppress the occurrence of IO-less Dirty Throttling: a method to improve I / O performance, a method to apply a patch within the kernel, and a method to change kernel parameters and improve I / O performance.

[0020] Improving I / O performance allows dirty pages in memory to be actively written to the device, preventing data from accumulating in memory. This method can be improved by splitting queues using multiple disks, as mentioned above, to improve merge read / write efficiency, or by using multithreading. In distributed storage and network-attached storage, I / O performance can also be improved by using software RAID to create virtual disks with RAID0 or similar. As mentioned above, network-attached storage allows for the creation of virtual disks consisting of multiple physical disks. Furthermore, by using RAID to break down the I / O after merge read / write into smaller chunks, i.e., by writing data to disk in smaller data units, speed can be improved. For example, if a 200KB I / O is issued using merge write and written to four virtual disks using RAID0, each virtual disk will have a 50KB I / O command, which improves the latency of the I / O command compared to a 200KB I / O command. RAID also improves throughput, particularly in the WAL area.

[0021] Patching within the kernel can be achieved by removing functions and logic related to IO-less Dirty Throttling speed control. This can be achieved by applying a live kernel patch or by modifying the kernel source code.

[0022] To change kernel parameters, change the kernel parameters vm.dirty_ratio and vm.dirty_background_ratio. The default value for vm.dirty_ratio is 20, but increase the value between 40 and 100. The higher the value, the more IO-less Dirty Throttling can be prevented. The recommended value is between 50 and 80. vm.dirty_background_ratio is a parameter that actively writes dirty pages in memory to storage; its default value is 10, but decrease the value by approximately 10-1. It is best to decide this value taking into account both memory size and storage performance. For example, if your memory size is large at 256GB but your storage performance is not very high, it is better to set it smaller. Conversely, if your memory size is small and your storage performance is high, it is better to set it larger.

[0023] [Configuration of the Device] An example of the configuration of an information processing device 10 according to this embodiment will be described with reference to FIG.

[0024] An application runs in the user space of the information processing device 10. Various data 11 written by the application using a Write system call is temporarily stored in a buffer 12 in the kernel space. The data 11 stored in the buffer 12 is written to the virtual disk 31 via an I / O queue 13 that is independent and dedicated for each virtual disk 31.

[0025] In the information processing device 10, the process of creating multiple virtual disks 31 in the distributed storage 30 and writing data thereto is multithreaded, and one of the multiple virtual disks 31 is assigned to each of the constituent data (data 11) obtained by dividing the data stored in the distributed storage 30, thereby utilizing the multiple virtual disks 31 in a manner specialized for the application. For example, if the application is a database, data 11 for each functional unit of the database is stored on each virtual disk 31. A functional unit of the database refers to a basic element or module that performs a specific function or role within the database, and includes elements such as a table, index, partition table, and log. By reserving continuous areas for each functional unit of the database on each virtual disk 31 and storing the data 11 therein, the probability of executing merge read / write is increased, thereby improving the efficiency of merge read / write.

[0026] The distributed storage 30 stores data in a distributed manner across multiple physical servers, each equipped with multiple disks, thereby eliminating single points of failure and achieving high availability. In this embodiment, multiple virtual disks 31 are generated in the distributed storage 30, and a continuous area for storing data 11 is secured on each of the multiple virtual disks 31. The virtual disk 31 may be a single disk formed by combining multiple virtual disks provided by the distributed storage 30 using RAID.

[0027] By using multithreading for the process of writing the data 11 to the distributed storage 30 and making merge read / write more efficient, IO performance is improved, and as a result, the occurrence of IO-less dirty throttling can be suppressed. The occurrence of IO-less dirty throttling may be suppressed by changing kernel parameters or applying a patch within the kernel.

[0028] [Explanation of Buffered I / O and Merge Read / Write] When the Linux kernel accesses data on the disk, the data is not read or written directly to the disk, but is first stored in the kernel's page cache (buffer). In the case of a read, the data is first stored in the page cache and provided to the user space process as needed. In the case of a write, the data is stored in the page cache as a dirty page and later written to the disk asynchronously by the kernel.

[0029] The processing of Buffered I / O is explained with reference to Figure 2. When an application executes a Write system call, the data is written as a dirty page to the page cache managed within the kernel, and the processing of the Write system call is completed. A kernel worker called a Kernel Flusher Thread writes the dirty page to disk periodically or in response to an fsync system call executed by the user. Typically, one Kernel Flusher Thread operates per disk.

[0030] Merge Read / Write is a function that consolidates consecutive dirty pages into a single I / O operation and writes them to disk. By consolidating processes that would normally require multiple I / O operations and writing them out in a single I / O operation, disk I / O can be made more efficient.

[0031] [Example] An example in which the information processing device 10 is applied to a database will be described with reference to Fig. 3. In the example of Fig. 3, by creating multiple virtual disks in distributed storage, each virtual disk is provided with an independent dedicated I / O queue, and the kernel flusher thread is multi-threaded.

[0032] In addition, we improved the efficiency of merge read / write by storing the database on multiple virtual disks by function. Common database products such as PostgreSQL and MySQL have a tablespace function that allows them to run on multiple virtual disks. Tablespaces are a function that creates each table, partition, and index of a database on a specified disk, allowing a single database to span multiple disks. In the example shown in Figure 3, this tablespace function is used to assign the database to each virtual disk by function. For the WAL area, the WAL area created in the database's file directory is linked to one of the virtual disks with a symbolic link, and the actual WAL area is stored on a virtual disk in the distributed storage. By intentionally allocating each table and index to its own device, we can increase the probability of executing merge read / write. It is particularly recommended to prepare a virtual disk and dedicated local storage dedicated to the WAL area.

[0033] In this embodiment, the use of Kernel Flusher Thread in multiple threads and the efficiency of Merge Read / Write improves I / O performance, making it possible to prevent IO-less Dirty Throttling from occurring. Kernel parameters may also be changed to prevent IO-less Dirty Throttling from occurring.

[0034] Although a database has been described as an example here, the information processing device 10 of this embodiment can also be applied to applications other than databases. Also, although an example in which Linux is used as the OS has been described here, the present invention is not limited to Linux and can be similarly applied to any OS that has a similar buffered I / O.

[0035] [Data Placement Processing] On-premises servers, there is almost no limit to the number of virtual disks or devices that can be connected to an OS, but in cloud or virtual environments, there is a limit to the number of virtual disks or devices that can be connected to an instance. For example, for a typical instance size in AWS, the limit is 32. Since the number of connected devices includes disks used in the OS area and NICs, the effective limit to the number of devices that can be added is about 24. Furthermore, using RAID, etc., is expected to further increase the number of connected virtual disks and devices. Therefore, it is necessary to determine the optimal data placement that maximizes performance while limiting the number of connected devices. An example of the process for determining data placement is explained below.

[0036] An example of the flow of processing for allocating application data 11 to each of the virtual disks 31 will be described with reference to the flowchart of FIG.

[0037] In step S11, the information processing device 10 divides all data stored in the device by an application into the smallest divisible data area (e.g., data 11 in FIG. 1 ). For example, in the case of a database, each database table, index table, and database log is divided into tables and logs.

[0038] In step S12, the information processing device 10 performs a benchmark of the application. When performing the benchmark, the iostat command, which displays the usage status of I / O devices, is executed with the extended statistical information option (-x). By executing the iostat command with the extended statistical information option, the amount of merge read / write data can be known in addition to the amount of read / write data.

[0039] In step S13, the information processing device 10 calculates the amount of read / write data and the amount of merge read / write data for each data area.

[0040] In step S14, the information processing device 10 calculates a score for each data area according to the ratio of the amount of read / write data and the amount of merge read / write data to the total. Specifically, the score is calculated using the following formula.

[0041]

[0042] α, β, γ, and δ are coefficients of the score, and for example, α=5, β=0.5, γ=3.5, and δ=1 are used.

[0043] In step S15, the information processing device 10 allocates virtual disks 31 in descending order of the data area with the highest score, and determines whether or not a predetermined number of virtual disks 31 (for example, if 24 virtual disks are connected, four of which are configured as RAID0 for the WAL area, and five more are also configured as RAID0, the total number is 5) is required.

[0044] If a virtual disk 31 with a score equal to or greater than the predetermined value is required, in step S16, the information processing device 10 merges the data area with the lowest score with the data area with the second lowest score, and returns to step S14 to calculate the score again.

[0045] If the number of virtual disks 31 is within the predetermined value, in step S17, the information processing device 10 allocates each data area to each virtual disk 31, and determines the virtual disk 31 that stores the data area.

[0046] The above process allows for optimized allocation of data areas while narrowing down the number of devices. It is also possible to increase the number of virtual disks in a RAID configuration for table areas with higher scores. Optimizing data areas in a database generally involves dividing devices into the following order: database log area, frequently accessed tables, and frequently accessed indexes.

[0047] Distributed storage provided by the cloud offers service options that allow you to obtain higher performance by paying additional fees for IOPS and IO bandwidth. This score can also be used to measure measures such as paying additional fees to improve IO performance for specific data areas. Reducing the number of disks that make up a RAID also increases reliability, so paying additional fees to reduce the number of disks is also effective.

[0048] Additionally, you can increase the performance of fixed-capacity devices by configuring multiple devices in RAID 0 using software RAID. For example, by using four 50GB devices to create a 200GB device in RAID 0, you can get four times the performance of the 200GB device for the same price.

[0049] As described above, the information processing device 10 uses multiple virtual disks 31 and includes a buffer 12 that temporarily stores data 11 to be written to the virtual disks 31. All data is divided into multiple data sets, and each data set 11 is assigned to one of the multiple virtual disks 31. The data sets 11 stored in the buffer 12 are written to each of the multiple virtual disks 31 in parallel. This improves throughput in storage devices characterized by slow disk write latency due to communication delays, and makes full use of the high-speed bandwidth of ultra-high-speed NVMe SSDs. As a result, significant performance improvements can be achieved in middleware, which is heavily affected by the I / O performance of existing databases, object storage, file servers, and the like.

[0050] The inventors conducted a TPC-C benchmark using the HammerDB benchmark tool, a type of OLTP benchmark, and found that it achieved speedups of up to approximately 15 times faster than standard PostgreSQL. Furthermore, when comparing the same instance with a cloud database provided by a cloud vendor with a high market share worldwide, a performance improvement of more than three times was achieved. Furthermore, because the instance performance of the present invention, which achieves performance equivalent to that of a cloud database, can be achieved with a performance several levels lower, it was confirmed that the same or better performance can be achieved at more than 83% less cost. Thus, the information processing device 10 of this embodiment can achieve world-class performance as a cloud database and significantly reduce cloud costs. Furthermore, it achieves approximately 15 times the performance of existing commercial cloud-provided databases, while also reducing costs, including licensing costs, by 74%.

[0051] Conventional approaches to improving database performance have been to separate the storage layer from the compute layer or to scale out by processing multiple instances of a distributed database called NewSQL. While these methods are effective, they require continuous updates and custom patches. The present invention improves performance without requiring database patches or continuous updates. Conventional methods do not store databases on multiple virtual disks by function. In this embodiment, multiple virtual disks are created in distributed storage and the database is stored on each of the multiple virtual disks by function. This multi-threads the kernel flusher thread, improves merge read / write efficiency, and significantly increases the number of available physical disks in the distributed storage, thereby improving I / O performance. This significantly improves database performance.

[0052] The information processing device 10 described above can be, for example, a general-purpose computer system including a central processing unit (CPU) 901, a memory 902, a storage 903, a communication device 904, an input device 905, and an output device 906, as shown in Fig. 5. In this computer system, the information processing device 10 is realized by the CPU 901 executing a predetermined program loaded onto the memory 902. This program can be recorded on a computer-readable non-transitory recording medium such as a magnetic disk, an optical disk, or a semiconductor memory, or can be distributed via a network.

[0053] 10 Information processing device 11 Data 12 Buffer 13 I / O queue and I / O write thread 30 Distributed storage 31 Virtual disk

Claims

1. An information processing device that uses multiple disks, assigns one of the multiple disks to each configuration data that divides data to be stored into functional units, and places the configuration data in a continuous area on the disk, and is equipped with a buffer that temporarily holds update data to be written to the disk, and an independent dedicated I / O queue for each of the multiple disks, and performs a process in parallel for writing the update data held in the buffer to the disk via the dedicated I / O queue for each of the multiple disks, and executes multiple I / O commands collectively for the update data that is continuous on the disk.

2. An information processing device according to claim 1, wherein a score is calculated for each of said configuration data from statistics of I / O processing obtained by benchmarking, and disks are allocated to said configuration data based on said score.

3. An information processing device according to claim 1, wherein the plurality of disks are a plurality of virtual disks created on distributed storage and network-attached storage.

4. An information processing device according to claim 1, which supports at least one of stopping the speed control function of IO-less Dirty Throttling and parallelizing write processing.

5. An information processing device according to any one of claims 1 to 4, wherein a database is allocated to the plurality of disks in units of at least a table, an index, and a log, and a dedicated disk is allocated to a write-ahead log.

Citation Information

Patent Citations

  • Database system, master node device constituting it, and program

    JP2004062566A

  • Cache memory system and method for controlling cache memory

    JP2010160544A

  • Replication techniques using a replication log

    US20230333777A1

  • Method and apparatus for merging contiguous like commands

    US6931501B1