Request processing method and device based on asynchronous storage engine, equipment and storage medium
By creating thread-level I/O instances for each thread and sharing a thread pool, the problems of lock contention and resource contention in asynchronous I/O frameworks are solved, improving storage performance and system stability, and achieving efficient asynchronous request processing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING BAIDU NETCOM SCI & TECH CO LTD
- Filing Date
- 2026-02-27
- Publication Date
- 2026-06-05
AI Technical Summary
Existing asynchronous I/O frameworks suffer from lock contention and cache thrashing when multiple worker threads share the same I/O instance, leading to degraded storage performance and failing to meet high-performance requirements.
Each worker thread and background compression thread creates a thread-level primary coordinated I/O instance and a secondary coordinated I/O instance, respectively. These instances are then processed asynchronously through a thread pool that shares the primary and secondary virtual I/O instances. This achieves isolation and resource sharing between user-side and storage engine-side requests, avoiding lock contention and resource contention.
It significantly improves the read and write performance of the storage engine, reduces long-tail latency, enhances system throughput and concurrency efficiency, and avoids the waste of kernel threads and memory resources.
Smart Images
Figure CN122152234A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of artificial intelligence technology, specifically the field of distributed storage technology. Specifically, it relates to a request processing method, apparatus, device, and storage medium based on an asynchronous storage engine. Background Technology
[0002] With the continuous evolution of the internet, large-scale models are being used more and more widely across various industries, leading to an explosive growth in massive amounts of data. This growth in massive amounts of data has placed unprecedented demands on the high performance of distributed storage systems. Key metrics for measuring storage system performance include throughput, latency, and IOPS (input / output operations per second).
[0003] In storage systems, file read and write operations are often the performance bottleneck, and their efficiency directly affects the overall system performance. Therefore, improving storage performance has become a crucial issue that the industry urgently needs to address. Summary of the Invention
[0004] This disclosure provides a request processing method, apparatus, device, and storage medium based on an asynchronous storage engine.
[0005] According to one aspect of this disclosure, a request processing method based on an asynchronous storage engine is provided, comprising: In user space, in response to the current request obtained by the current thread, the current cooperative I / O instance bound to the current thread is determined; wherein, the current cooperative I / O instance is an asynchronous I / O interface instance; Submit the current request to the submission queue of the current cooperative I / O instance; In kernel mode, the current request is processed asynchronously through the current thread pool; wherein, the current thread pool is the thread pool of the current virtual I / O instance shared by the current cooperative I / O instance.
[0006] According to another aspect of this disclosure, a request processing apparatus based on an asynchronous storage engine is provided, comprising: The current collaborative instance module is used in user space to determine the current collaborative I / O instance bound to the current thread in response to the current request obtained by the current thread; wherein, the current collaborative I / O instance is an asynchronous I / O interface instance; The current request submission module is used to submit the current request to the submission queue of the current cooperative I / O instance; The current request processing module is used to asynchronously process the current request in kernel mode through the current thread pool; wherein, the current thread pool is the thread pool of the current virtual I / O instance shared by the current cooperative I / O instance.
[0007] According to another aspect of this disclosure, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed, enable the at least one processor to perform the request processing method based on the asynchronous memory engine provided in any embodiment of this disclosure.
[0008] According to another aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to execute a request processing method based on an asynchronous storage engine provided in any embodiment of this disclosure.
[0009] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the request processing method based on an asynchronous memory engine provided in any embodiment of this disclosure.
[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description
[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1a This is a flowchart of a request processing method based on an asynchronous storage engine provided according to an embodiment of the present disclosure; Figure 1b This is a schematic diagram illustrating the request processing principle based on an asynchronous storage engine according to an embodiment of this disclosure; Figure 2 This is a flowchart of another request processing method based on an asynchronous storage engine provided according to an embodiment of this disclosure; Figure 3 This is a flowchart of another request processing method based on an asynchronous storage engine provided according to an embodiment of the present disclosure; Figure 4 This is a schematic diagram of the structure of a request processing device based on an asynchronous storage engine according to an embodiment of the present disclosure; Figure 5 This is a block diagram of an electronic device used to implement the asynchronous storage engine-based request processing method according to embodiments of the present disclosure. Detailed Implementation
[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.
[0013] Asynchronous storage engines employ asynchronous I / O frameworks, such as the high-performance asynchronous I / O framework `iouring` provided by the Linux kernel. This framework addresses issues in asynchronous I / O usage and enhances its performance. It utilizes MMAP (Memory Map) technology to share a circular queue between user space and kernel space, significantly reducing the overhead of data copying and context switching. Furthermore, the asynchronous I / O framework supports batch commits, completely avoiding system call overhead in `IORING_SETUP_SQPOLL` mode. This framework supports not only direct I / O but also buffered I / O, providing comprehensive protocol stack coverage and flexible polling modes, effectively reducing the overhead of system calls and interrupt handling.
[0014] However, the storage performance of asynchronous I / O frameworks still struggles to meet business requirements. In particular, when multiple worker threads share the same I / O instance (i.e., a process-level I / O instance), lock safety issues arise when submitting SQE (Submission Queue Entry) or harvesting CQE (Completion Queue Entry). To improve system concurrency and ensure thread safety, developers typically introduce additional mutexes or spinlocks. However, lock contention can lead to thread switching or CPU idling, and sharing can cause cache bouncing across multiple cores, significantly increasing latency and reducing parallel efficiency.
[0015] Figure 1a This is a flowchart illustrating a request processing method based on an asynchronous storage engine according to embodiments of this disclosure. This method is suitable for improving the performance of asynchronous I / O frameworks. The method can be executed by a request processing device based on an asynchronous storage engine, which can be implemented in software and / or hardware and integrated into an electronic device. (In conjunction with...) Figure 1a and Figure 1b A request processing method based on an asynchronous storage engine in this embodiment may include: S101, in user mode, in response to the current request obtained by the current thread, determine the current cooperative I / O instance bound to the current thread; wherein, the current cooperative I / O instance is an asynchronous I / O interface instance; S102, Submit the current request to the submission queue of the current cooperative I / O instance; S103, in kernel mode, the current request is processed asynchronously through the current thread pool; wherein, the current thread pool is the thread pool of the current virtual I / O instance shared by the current cooperative I / O instance.
[0016] In this embodiment, the distributed storage system includes at least two worker threads and at least one background compression thread (not shown). Each worker thread corresponds one-to-one with a primary collaborative I / O instance, and each background compression thread also corresponds one-to-one with a secondary collaborative I / O instance. By creating a primary collaborative I / O instance for each worker thread and a secondary collaborative I / O instance for each background compression thread, thread-local storage (TLS) level I / O instances are implemented. Compared to multiple threads sharing the same I / O instance, this approach eliminates multi-threaded contention, completely achieving lock-free asynchronous request parallel processing, thereby significantly improving the read and write performance of the storage engine.
[0017] In one optional implementation, when the current thread is a worker thread, the current request is a user-side request, and the current thread pool is the main thread pool of the primary virtual I / O instance; when the current thread is a background compression thread, the current request is a storage engine-side request, and the current thread pool is a secondary thread pool of the secondary virtual I / O instance. The number of task threads in the primary thread pool is greater than the number of task threads in the secondary thread pool.
[0018] The current request is a read or write request from the storage engine, such as a real-time read or write RPC (Remote Procedure Call) request from a user, or an engine-side request during storage engine compaction. In this embodiment, the asynchronous I / O framework also includes a primary virtual I / O instance (dummy_uring_high) and a secondary virtual I / O instance (dummy_uring_low). The primary virtual I / O instance provides main thread pool resources for each primary coordinating I / O instance, and the secondary virtual I / O instance provides secondary thread pool resources for each secondary coordinating I / O instance. When the current thread is a worker thread, the current request is a user-side request, and the current thread pool is the primary thread pool of the primary virtual I / O instance in kernel mode; that is, each user-side request shares the resources of the primary thread pool. When the current thread is a background compression thread, the current request is a storage engine-side request, used to execute data merging tasks of the storage engine, such as SSTable (Sorted Strings Table) merging tasks. The current thread pool is the secondary thread pool of the secondary virtual I / O instance in kernel mode, that is, the resources of the secondary thread pool are shared by each storage engine-side request.
[0019] By using primary and secondary virtual I / O instances, resources are provided for user-side requests and storage engine-side requests, respectively, achieving resource sharing among primary and secondary collaborative I / O instances. In related technologies, each io_uring instance (or io_uring object) synchronously creates a corresponding thread pool (io_wq) to handle asynchronous requests upon creation; that is, each io_uring instance maintains its own dedicated thread pool. However, because io_uring instances generate additional auxiliary threads and memory overhead in kernel space, when the number of threads is large, the dedicated thread pool model for each io_uring instance can lead to kernel thread explosion and wasted memory resources, thus dragging down system performance. This additional overhead is not only reflected in the thread pool scheme; if the IORING_SETUP_SQPOLL option is enabled to pursue ultimate performance, each io_uring instance will also start a SQ_POLL core thread, i.e., a kernel thread used to poll the submission queue to reduce the number of system calls. Taking a 256-core device as an example, there are 257 primary coordinated io_uring instances and 257 SQ_POLL polling threads, causing CPU resources to be instantly saturated. This embodiment addresses this by having each primary coordinated I / O instance share an asynchronous main thread pool, and each secondary coordinated I / O instance share an asynchronous secondary thread pool. This allows later-created io_uring instances to bind to existing thread pools, avoiding the creation of new independent thread pools. This mode maintains the lock-free traversal characteristics of TLS while effectively controlling the total number of kernel threads.
[0020] The storage engine simultaneously handles real-time user-side requests (referred to as foreground operations) and compaction operations (referred to as background operations) to promptly process expired and deleted data in order to reduce storage amplification and write amplification. Due to the different characteristics and processing times of foreground and background operations—foreground operations require extreme throughput and low latency, while background compaction operations require timely storage reclamation with limited resources and minimizing the impact on foreground performance—the technical solution provided in this disclosure also implements a foreground-background separation mechanism between user-side requests and storage engine-side requests. By isolating foreground and background thread pools within the storage engine, it avoids mixing strategies for the two types of requests, thereby further reducing resource contention between worker threads and background compaction threads and improving storage performance.
[0021] Taking the current thread as the i-th worker thread (i is a natural number) as an example, the request processing flow is as follows: In user mode, in response to the user-side request obtained by the i-th worker thread, the i-th main cooperative I / O instance bound to the i-th worker thread is determined, and the user-side request is written into the submission queue of the i-th main cooperative I / O instance; In kernel mode, the i-th main cooperative I / O instance asynchronously processes the user-side request through the main thread pool of the main virtual I / O instance.
[0022] Taking the current thread as the j-th background compression thread (j is a natural number) as an example, the request processing flow is as follows: In user space, in response to the storage engine side request obtained by the j-th background compression thread, the j-th secondary cooperative I / O instance bound to the j-th background compression thread is determined, and the storage engine side request is written into the submission queue of the j-th secondary primary cooperative I / O instance; In kernel space, the j-th secondary cooperative I / O instance asynchronously processes the storage engine side request through the secondary thread pool of the secondary virtual I / O instance.
[0023] The technical solution provided in this disclosure achieves complete isolation between user-side and storage engine-side requests by creating thread-level primary and secondary collaborative I / O instances and secondary collaborative I / O instances for each worker thread and background compression thread, respectively. Furthermore, worker threads process real-time user-side requests through a main thread pool sharing the primary virtual I / O instance, while background compression threads process storage reclamation tasks through a secondary thread pool sharing the secondary virtual I / O instance. This avoids lock overhead caused by multi-threaded contention and prevents resource contention through isolation between the front-end and back-end thread pools. Thus, without significantly increasing system load, it fully leverages asynchronous performance, significantly reduces long-tail latency, and improves system throughput.
[0024] In one alternative implementation, the storage engine-side request is generated when the number of user-side requests is less than a preset threshold.
[0025] User-side requests have higher priority than storage engine-side requests. Specifically, when the number of user-side requests reaches or exceeds a preset threshold, the processing of storage engine-side requests will be blocked; only when the number of user-side read / write requests is below the preset threshold will engine-side compression requests be triggered. This mechanism can further improve the processing efficiency of user-side requests.
[0026] Figure 2 This is a flowchart of another request processing method based on an asynchronous storage engine provided according to an embodiment of this disclosure; based on the above embodiments, this embodiment further optimizes "in response to the current request obtained by the current thread, determining the current cooperative I / O instance bound to the current thread", providing an optional implementation scheme. For example... Figure 2 As shown, the method includes: S201, in user mode, in response to the current request obtained by the current thread, determine whether there is a currently coordinated I / O instance bound to the current thread; wherein, the currently coordinated I / O instance is an asynchronous I / O interface instance; if it does not exist, continue to execute S202; if it exists, jump to execute S204; S202, Create a new asynchronous I / O interface instance as the current cooperative I / O instance; S203, based on the type of the current thread, control the current cooperative I / O instance to share the resources of the current virtual I / O instance; S204, Submit the current request to the submission queue of the current cooperative I / O instance; S205, in kernel mode, the current request is processed asynchronously through the current thread pool; wherein, the current thread pool is the thread pool of the current virtual I / O instance shared by the current cooperative I / O instance.
[0027] During the request submission phase, in user space, in response to the current request obtained by the current thread, it is determined whether a current cooperative I / O instance bound to the current thread exists. If a current cooperative I / O instance exists, the current request is directly submitted to the submission queue (SQ) of the current cooperative I / O instance; if no current cooperative I / O instance exists, for example, when the current thread obtains the current request for the first time, a new asynchronous I / O interface instance is created for the current thread as the current cooperative I / O instance, and this instance shares the resources of the existing thread pool.
[0028] Specifically, if the current thread is the i-th worker thread and there is no i-th main coordinated I / O instance, then a new asynchronous I / O interface instance is created as the i-th main coordinated I / O instance, and the i-th main coordinated I / O instance shares the main thread pool of the main virtual I / O instance. If the current thread is the j-th background compressed thread and there is no j-th secondary coordinated I / O instance, then a new asynchronous I / O interface instance is created as the j-th secondary coordinated I / O instance, and the j-th secondary coordinated I / O instance shares the secondary thread pool of the secondary virtual I / O instance. This process dynamically binds the current thread and the current coordinated I / O instance in user space, which can reduce resource overhead and further improve I / O efficiency and system stability.
[0029] In one optional implementation, controlling the current collaborative I / O instance to share the resources of the current virtual I / O instance according to the type of the current thread includes: if the current thread is a worker thread, then passing the file descriptor of the primary virtual I / O instance through the optimization interface flag of the current collaborative I / O instance; if the current thread is a background compression thread, then passing the file descriptor of the secondary virtual I / O instance through the optimization interface flag of the current collaborative I / O instance.
[0030] `IORING_SETUP_ATTACH_WQ` is an optimization flag provided by the asynchronous I / O framework to enable different `io_uring` instances to share the kernel-mode thread pool. Specifically, if the current thread is a worker thread, this flag is set in the parameter structure of the `io_uring_setup` initialization interface, passing in the file descriptor (fd) of the primary virtual I / O instance, so that the newly created current cooperative I / O instance shares the primary thread pool. If the current thread is a background compression thread, this flag is set in the same way, passing in the file descriptor of the secondary virtual I / O instance, so that the newly created current cooperative I / O instance shares the secondary thread pool. This process, using the `IORING_SETUP_ATTACH_WQ` flag to enable different `io_uring` instances to share the kernel thread pool, avoids the overhead of repeatedly creating thread pools, and flexibly reuses primary / secondary thread pool resources according to thread type, significantly improving resource utilization and system performance of asynchronous I / O operations.
[0031] The technical solution provided in this disclosure creates a current collaborative I / O instance on demand when the current thread processes a request for the first time, and associates the thread pool of the current virtual I / O instance with the current thread type through a file descriptor. This avoids the kernel resource explosion caused by each collaborative I / O instance creating its own thread pool, and also achieves resource isolation between the main thread pool and the secondary thread pool by distinguishing thread types, further improving I / O throughput and system stability in high-concurrency scenarios.
[0032] In one optional implementation, before responding to the current request obtained by the current thread, the method further includes: creating N worker threads based on the number of CPU cores N-1 of the device to which the storage engine belongs; creating M background compression threads based on a preset parameter M; where N and M are both positive integers, and N is greater than M; and creating a primary virtual I / O instance and a secondary virtual I / O instance respectively; wherein the primary virtual I / O instance is used to share resources for the collaborative I / O instances bound to each worker thread; and the secondary virtual I / O instance is used to share resources for the collaborative I / O instances bound to each background compression thread.
[0033] During the initialization phase, N worker threads are created based on the number of CPU cores N-1 of the storage engine's device to handle user-side requests. Simultaneously, M background compression threads are created based on the preset startup parameters M to handle the storage engine's data compression tasks. Here, M and N are both positive integers, and N is greater than M (e.g., N-1=256, M∈[1,3]).
[0034] During the initialization phase, two asynchronous I / O interface instances are created. One serves as the head node of the primary virtual I / O instance (i.e., the primary coordinated io_uring instance), bound to the kernel-mode main thread pool resources. The other serves as the head node of the secondary virtual I / O instance (i.e., the secondary coordinated io_uring instance), bound to the kernel-mode secondary thread pool resources. The resources of the primary thread pool are greater than those of the secondary thread pool. This process achieves efficient utilization of computing resources by dynamically matching the number of CPU cores to create worker threads and background compression threads. Simultaneously, by using the primary and secondary virtual I / O instances to separate the thread pool resources for user-side requests and storage engine-side requests, it ensures high-concurrency I / O performance and optimizes the overall system throughput through hierarchical resource management.
[0035] Figure 3 This is a flowchart of another request processing method based on an asynchronous storage engine provided according to an embodiment of this disclosure; this embodiment further introduces request callback logic based on the above embodiments. Figure 3 As shown, the method includes: S301, in user mode, in response to the current request obtained by the current thread, determine the current cooperative I / O instance bound to the current thread; wherein, the current cooperative I / O instance is an asynchronous I / O interface instance; S302, Submit the current request to the submission queue of the current cooperative I / O instance; S303, In kernel mode, the current request is processed asynchronously through the current thread pool; wherein, the current thread pool is the thread pool of the current virtual I / O instance shared by the current cooperative I / O instance; S304, after the current request is processed, the completed request is written to the completion queue of the current collaborative I / O instance through the current collaborative I / O instance; S305, in user space, monitors the completion queue of each cooperative I / O instance in kernel space through the harvesting thread, and distributes completed requests to the callback thread pool.
[0036] refer to Figure 1b During the initialization phase, a harvesting thread (epoll) and a lightweight callback thread pool are also initialized in user space. The harvesting thread is used to poll for completed requests and distribute them to the callback thread pool. The callback thread pool can have a small number of threads (e.g., 4).
[0037] In kernel mode, the current cooperative I / O instance uses the resources of the current thread pool to asynchronously process the current request. After the current request is processed, it is written as a completed request to the completion queue (CQ) of the current cooperative I / O instance. In user mode, the harvesting thread monitors the completion queues of each primary cooperative I / O instance and each secondary cooperative I / O instance in kernel mode. When a new completion event is detected, the completed request is dispatched to the callback thread pool, which then provides feedback on the request result. This process efficiently polls the kernel completion queue through the user-mode harvesting thread, combined with the lightweight callback thread pool for rapid result feedback. This reduces thread scheduling overhead and further improves request processing throughput and response efficiency in high-concurrency scenarios through asynchronous separation between the harvesting thread and the callback thread.
[0038] In one optional implementation, before submitting the current request to the submission queue of the current collaborative I / O instance, the method further includes: binding the current request to a callback function; wherein the callback function is determined according to the request type of the current request, and the request type is read, write, or compression; after distributing the completed request to the callback thread pool, the method further includes: calling the callback thread pool and returning the processing result according to the callback function of the completed request.
[0039] During the request submission phase, the system binds the current request to a callback function and submits the request with the bound callback function to the submission queue. The callback function is determined based on the request type, with three dedicated callback functions configured for read, write, and compression requests. In the request callback phase, the system invokes the user-space callback thread pool and returns the processing result based on the completed callback function binding, including but not limited to error codes, data values, read / write byte counts, or end-to-end latency and other storage performance metrics. This process, through the pre-binding mechanism of requests and callback functions combined with the asynchronous execution of the callback thread pool, decouples request processing from result feedback. This reduces the context switching overhead between kernel and user modes and improves the efficiency of result feedback through refined callback function classification.
[0040] The technical solution provided in this disclosure efficiently polls the kernel completion queue using harvesting threads and combines this with a lightweight callback thread pool to achieve asynchronous result feedback. This avoids the performance overhead of frequent scheduling of a large number of threads and decouples the processing flow through a pre-binding mechanism between requests and callback functions. Dedicated callback functions are configured for read, write, and compression requests, enabling the processing result feedback to accurately carry performance indicators such as error codes and data values. This significantly improves request processing throughput in high-concurrency scenarios while reducing the overhead of kernel-mode and user-mode context switching.
[0041] Figure 4 This is a schematic diagram of a request processing device based on an asynchronous storage engine, according to an embodiment of this disclosure. This embodiment is applicable to situations requiring improved performance of asynchronous I / O frameworks. The device can be implemented in software and / or hardware and can be integrated into electronic devices. Figure 4 As shown, a request processing device 400 based on an asynchronous storage engine in this embodiment may include: The current collaborative instance module 410 is used in user space to determine the current collaborative I / O instance bound to the current thread in response to the current request obtained by the current thread; wherein, the current collaborative I / O instance is an asynchronous I / O interface instance; The current request submission module 420 is used to submit the current request to the submission queue of the current cooperative I / O instance; The current request processing module 430 is used to asynchronously process the current request in kernel mode through the current thread pool; wherein the current thread pool is the thread pool of the current virtual I / O instance shared by the current cooperative I / O instance.
[0042] In one alternative implementation, when the current thread is a worker thread, the current request is a user-side request, and the current thread pool is the main thread pool of the main virtual I / O instance. In the case that the current thread is a background compression thread, the current request is a storage engine-side request, and the current thread pool is a secondary thread pool of the secondary virtual I / O instance.
[0043] In one alternative implementation, the storage engine-side request is generated when the number of user-side requests is less than a preset threshold.
[0044] In one alternative implementation, the number of task threads in the main thread pool is greater than the number of task threads in the secondary thread pool.
[0045] In one alternative implementation, the current collaborative instance module 410 includes: The current instance determination unit is used to determine, in response to the current request obtained by the current thread, whether there is a current cooperative I / O instance bound to the current thread; The new instance creation unit is used to create a new asynchronous I / O interface instance if it does not exist, and use it as the current cooperative I / O instance. The new instance sharing unit is used to control the current cooperative I / O instance to share the resources of the current virtual I / O instance according to the type of the current thread.
[0046] In one alternative implementation, the new instance sharing unit is specifically used for: If the current thread is a worker thread, then the file descriptor of the main virtual I / O instance is passed through the optimization interface flag of the current cooperative I / O instance; If the current thread is a background compression thread, then the file descriptor of the secondary virtual I / O instance is passed through the optimization interface flag of the current cooperative I / O instance.
[0047] In one optional embodiment, the device 400 further includes an initialization module, which specifically includes: The worker thread creation unit is used to create N worker threads based on the number of CPU cores N-1 of the device to which the storage engine belongs; The background thread creation unit is used to create M background compression threads according to the preset parameter M; N and M are both positive integers, and N is greater than M; The virtual instance creation unit is used to create a primary virtual I / O instance and a secondary virtual I / O instance respectively; wherein, the primary virtual I / O instance is used to share resources for the collaborative I / O instances bound to each worker thread; and the secondary virtual I / O instance is used to share resources for the collaborative I / O instances bound to each background compression thread.
[0048] In one optional embodiment, the device 400 further includes a result callback module, which specifically includes: The write completion unit is used to write the completed request to the completion queue of the current collaborative I / O instance after the current request processing is completed; The callback dispatch unit is used in user space to monitor the completion queue of each cooperative I / O instance in kernel space through the harvester thread, and to dispatch completed requests to the callback thread pool.
[0049] In one alternative implementation, the current request submission module 420 is further configured to: The current request is bound to a callback function; wherein the callback function is determined according to the request type of the current request, which is read, write, or compression; The result callback module also includes: The result callback unit is used to invoke the callback thread pool and return the processing result based on the callback function of the completed request.
[0050] The request processing apparatus based on the asynchronous storage engine provided in this disclosure can execute the request processing method based on the asynchronous storage engine provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects for executing the request processing method based on the asynchronous storage engine.
[0051] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.
[0052] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.
[0053] Figure 5 This is a block diagram of an electronic device used to implement a request processing method based on an asynchronous storage engine according to an embodiment of the present disclosure.
[0054] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.
[0055] like Figure 5 As shown, the electronic device 500 includes a computing unit 501, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. The RAM 503 may also store various programs and data required for the operation of the electronic device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.
[0056] Multiple components in electronic device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows electronic device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0057] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as a request processing method based on an asynchronous memory engine. For example, in some embodiments, the request processing method based on an asynchronous memory engine can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the request processing method based on an asynchronous memory engine described above can be performed. Alternatively, in other embodiments, computing unit 501 may be configured to perform a request processing method based on an asynchronous storage engine by any other suitable means (e.g., by means of firmware).
[0058] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0059] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0060] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0061] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0062] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.
[0063] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.
[0064] Artificial intelligence (AI) is the study of enabling computers to simulate certain human thought processes and intelligent behaviors (such as learning, reasoning, thinking, and planning). It encompasses both hardware and software technologies. AI hardware technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, and big data processing. AI software technologies mainly include computer vision, speech recognition, natural language processing, machine learning / deep learning, big data processing, and knowledge graph technologies.
[0065] Cloud computing refers to a technology system that enables access to a shared pool of physical or virtual resources via a network. These resources can include servers, operating systems, networks, software, applications, and storage devices, and can be deployed and managed on demand and in a self-service manner. Cloud computing technology can provide efficient and powerful data processing capabilities for applications such as artificial intelligence and blockchain, as well as for model training.
[0066] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.
[0067] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.
Claims
1. Request processing methods based on asynchronous storage engines, including: In user space, in response to the current request obtained by the current thread, the current cooperative I / O instance bound to the current thread is determined; wherein, the current cooperative I / O instance is an asynchronous I / O interface instance; Submit the current request to the submission queue of the current cooperative I / O instance; In kernel mode, the current request is processed asynchronously through the current thread pool; wherein, the current thread pool is the thread pool of the current virtual I / O instance shared by the current cooperative I / O instance.
2. The method according to claim 1, wherein, If the current thread is a worker thread, the current request is a user-side request, and the current thread pool is the main thread pool of the main virtual I / O instance. In the case that the current thread is a background compression thread, the current request is a storage engine-side request, and the current thread pool is a secondary thread pool of the secondary virtual I / O instance.
3. The method according to claim 2, wherein, The storage engine-side request is generated when the number of user-side requests is less than a preset threshold.
4. The method according to claim 2, wherein, The number of task threads in the main thread pool is greater than the number of task threads in the secondary thread pool.
5. The method according to any one of claims 1-4, wherein, The step of determining the currently coordinated I / O instance bound to the current thread in response to the current request obtained by the current thread includes: In response to the current request obtained by the current thread, determine whether there exists a currently co-located I / O instance bound to the current thread; If it does not exist, a new asynchronous I / O interface instance is created as the current cooperative I / O instance; Based on the type of the current thread, control the current cooperative I / O instance to share the resources of the current virtual I / O instance.
6. The method according to claim 5, wherein, The step of controlling the current cooperative I / O instance to share the resources of the current virtual I / O instance based on the type of the current thread includes: If the current thread is a worker thread, then the file descriptor of the main virtual I / O instance is passed through the optimization interface flag of the current cooperative I / O instance; If the current thread is a background compression thread, then the file descriptor of the secondary virtual I / O instance is passed through the optimization interface flag of the current cooperative I / O instance.
7. The method according to any one of claims 1-4, wherein prior to responding to the current request obtained by the current thread, the method further comprises: Create N worker threads based on the number of CPU cores N-1 of the device to which the storage engine belongs; Based on the preset parameter M, create M background compression threads; Both N and M are positive integers, and N is greater than M; A primary virtual I / O instance and a secondary virtual I / O instance are created respectively; wherein, the primary virtual I / O instance is used to share resources for the collaborative I / O instances bound to each worker thread; and the secondary virtual I / O instance is used to share resources for the collaborative I / O instances bound to each background compression thread.
8. The method according to claim 1, further comprising, after asynchronously processing the current request through the current thread pool in kernel mode: After the current request is processed, the completed request is written to the completion queue of the current collaborative I / O instance through the current collaborative I / O instance; In user space, the harvesting thread monitors the completion queue of each cooperative I / O instance in kernel space and distributes completed requests to the callback thread pool.
9. The method according to claim 8, wherein before submitting the current request to the submission queue of the current cooperative I / O instance, the method further comprises: The current request is bound to a callback function; wherein the callback function is determined according to the request type of the current request, which is read, write, or compression; After dispatching completed requests to the callback thread pool, the method further includes: The callback thread pool is invoked, and the processing result is returned based on the callback function of the completed request.
10. A request processing apparatus based on an asynchronous storage engine, comprising: The current collaborative instance module is used in user space to determine the current collaborative I / O instance bound to the current thread in response to the current request obtained by the current thread; wherein, the current collaborative I / O instance is an asynchronous I / O interface instance; The current request submission module is used to submit the current request to the submission queue of the current cooperative I / O instance; The current request processing module is used to asynchronously process the current request in kernel mode through the current thread pool; wherein, the current thread pool is the thread pool of the current virtual I / O instance shared by the current cooperative I / O instance.
11. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.
12. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-9.
13. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-9.