IO flow speed limit control method and device, electronic equipment and storage medium
By prioritizing and dynamically scheduling IO requests, the problem of mutual interference between IO requests in distributed storage systems is solved, improving processing efficiency and resource utilization, and enhancing system stability and reliability.
Patent Information
- Application Number
- CN202511424499.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-30
- Publication Date
- 2025-11-04
- Estimated Expiration
- 2045-09-30
AI Technical Summary
Existing distributed storage systems lack flexible and dynamic control mechanisms when handling I/O requests. This results in a large number of data recovery I/Os coexisting with other types of I/O after a failure, making it difficult to ensure the priority processing of critical I/Os and affecting the overall performance and stability of the system.
By prioritizing and dynamically scheduling IO requests, configuring the concurrent processing parameters and total capacity parameters of the task pool, identifying the request type and allocating it to the task pool or cache pool, checking the status at preset time intervals and scheduling requests according to priority order, when a high-priority request arrives and the task pool is full, the low-priority request is transferred to the cache pool to limit resource consumption.
It effectively solves the problem of mutual interference between various IO requests in distributed storage systems, improves the system's processing efficiency and resource utilization for IO requests, and enhances the system's stability and reliability.
Smart Images

Figure CN120891990A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of computer data storage, and particularly relates to an IO flow rate limiting control method and device, electronic equipment and a storage medium. BACKGROUND
[0002] In the field of distributed storage, an IO stack needs to handle four types of core IO requests in parallel, including: ordinary business IO corresponding to the read and write operations of actual business of a user, management IO serving the data storage management needs, covering the creation, deletion and other operations of metadata and data, query IO for obtaining data state information, and data recovery IO for recovering data from other normal copies when a fault causes the loss of a data copy.
[0003] In related technologies, most distributed storage systems mainly adopt two types of scheduling methods when processing IO requests: FIFO scheduling method: queuing and processing according to the order of arrival of IO requests, which is simple in logic. Static allocation method based on weight: fixed weights are set for different types of IO requests in advance, and the system statically allocates IO processing resources according to the weight ratio.
[0004] However, the above related technologies lack flexible and dynamic regulation mechanisms, and there is a problem that when a fault occurs, a large number of data recovery IOs coexist with other IOs, it is difficult to ensure the priority processing of critical IOs, and the overall performance and stability of the system are affected. SUMMARY
[0005] The present application provides an IO flow rate limiting control method and device, electronic equipment and a storage medium, which relates to the technical field of computer data storage, and effectively solves the problem of mutual interference of various IO requests in a distributed storage system by classifying and dynamically scheduling IO requests. At the same time, through the cooperative work of the cache pool and the task pool, the processing efficiency and resource utilization of the system for IO requests are improved, and the stability and reliability of the distributed storage system are enhanced.
[0006] In a first aspect, the present application provides an IO flow rate limiting control method, comprising: configuring the concurrent processing parameters and total capacity parameters of the task pool; identifying the request type of a newly arrived input / output request, and distributing the input / output request to the corresponding queue in the task pool or the cache pool according to the request type and the state of the task pool; checking the states of the task pool and the cache pool at a preset time interval, and scheduling the input / output request in the cache pool to the task pool according to the priority order; When a high-priority input / output request arrives and the task pool is full, the low-priority input / output requests in the task pool are transferred to the cache pool, so as to limit the input / output requests to allocate computing resources.
[0007] In a second aspect, the present application provides an IO flow rate limiting control device, comprising: a configuration module configured to configure the concurrent processing parameter and the total capacity parameter of the task pool; an allocation module configured to identify the request type of a newly-arrived input / output request, and allocate the input / output request to a corresponding queue in the task pool or the cache pool according to the request type and the state of the task pool; a scheduling module configured to check the states of the task pool and the cache pool at a preset time interval, and schedule the input / output requests in the cache pool to the task pool according to the priority order; a transfer module configured to, when a high-priority input / output request arrives and the task pool is full, transfer the low-priority input / output requests in the task pool to the cache pool, so as to limit the input / output requests to allocate computing resources.
[0008] In a third aspect, the present application provides an electronic device, comprising at least one processor, and a memory connected with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the IO flow rate limiting control method of the first aspect.
[0009] In a fourth aspect, the present application provides a non-transitory computer readable storage medium storing computer instructions, and the computer instructions are used to enable a computer to execute the IO flow rate limiting control method of the first aspect.
[0010] In a fifth aspect, the present application provides a computer program product storing a computer program, and the computer program is executed by a processor to implement the IO flow rate limiting control method of the first aspect.
[0011] The IO flow rate limiting control method and device, the electronic device and the storage medium provided by the application, wherein the method comprises: configuring the concurrent processing parameter and the total capacity parameter of the task pool; identifying the request type of the newly arrived input / output request, and distributing the input / output request to the corresponding queue in the task pool or the cache pool according to the request type and the task pool state; checking the task pool and the cache pool state at a preset time interval, and scheduling the input / output request in the cache pool to the task pool according to the priority order; when the high-priority input / output request arrives and the task pool is full, transferring the low-priority input / output request in the task pool to the cache pool, so as to limit the input / output request to allocate computing resources. Therefore, the problem that the related art lacks a flexible and dynamic regulation mechanism, and when a fault occurs, a large amount of data recovery IO and other IOs coexist, it is difficult to ensure the priority processing of the key IO, and the overall performance and stability of the system are affected, can be solved, and the technical effects that the mutual interference of various IO requests in the distributed storage system is effectively solved, the processing efficiency and resource utilization of the system are improved, and the stability and reliability of the distributed storage system are enhanced. BRIEF DESCRIPTION OF DRAWINGS
[0012] In order to more clearly illustrate the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.
[0013] Figure 1 A flowchart of an IO flow rate limiting control method provided by an embodiment of the present application; Figure 2 A flowchart of another IO flow rate limiting control method provided by an embodiment of the present application; Figure 3 A flowchart of another IO flow rate limiting control method provided by an embodiment of the present application; Figure 4 A flowchart of another IO flow rate limiting control method provided by an embodiment of the present application; Figure 5 A flowchart of another IO flow rate limiting control method provided by an embodiment of the present application; Figure 6 A flowchart of another IO flow rate limiting control method provided by an embodiment of the present application; Figure 7 A flowchart of another IO flow rate limiting control method provided by an embodiment of the present application; Figure 8 A flowchart of another IO flow rate limiting control method provided by an embodiment of the present application; Figure 9A structural schematic diagram of an IO flow rate limiting control device provided by an embodiment of the present application. DETAILED DESCRIPTION
[0014] The technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.
[0015] It should be noted that, in the description of the present application, the terms “comprise”, “contain” or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such a process, method, article or device. The terms “first”, “second” and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.
[0016] In the field of distributed storage, the IO stack needs to handle four types of core IO requests in parallel, including: ordinary business IO corresponding directly to the read and write operations of the actual business of the user, management IO serving the data storage management needs, covering operations such as creation and deletion of metadata and data, query IO for obtaining data state information, and data recovery IO for recovering data from other normal copies when a fault causes the loss of a data copy. In related technologies, most distributed storage systems mainly use two types of scheduling methods when processing IO requests: First In First Out (FIFO) scheduling method: queuing and processing according to the order of arrival of IO requests, which is simple in logic. Weight-based static allocation method: fixed weights are set for different types of IO requests in advance, and the system statically allocates IO processing resources according to the weight ratio. However, the above related technologies lack flexible and dynamic control mechanisms, and there is a problem that when a fault occurs, a large number of data recovery IOs coexist with other types of IOs, making it difficult to ensure the priority processing of critical IOs, affecting the overall performance and stability of the system.
[0017] Against this background, a new solution is needed to solve the IO request type scheduling problem. This solution needs to be able to prioritize and dynamically schedule IO requests, and to enable the cache pool and task pool to work together to improve the efficiency of processing IO requests and resource utilization, and to enhance the stability and reliability of the distributed storage system.
[0018] In order for those skilled in the art of the present technology to better understand the present application, the present application is further described in detail below in conjunction with the drawings and specific embodiments.
[0019] Figure 1 A flowchart of an IO flow rate limiting control method provided by an embodiment of the present disclosure is shown in FIG. 1, which includes the following steps: Figure 1 Step 101, configure the concurrent processing parameter and total capacity parameter of the task pool.
[0020] In some embodiments, when the distributed storage system IO flow rate limiting module is initialized, the worker parameter and the depth parameter of the IO stack are configured. The worker parameter represents the maximum number of work threads that can be concurrently executed by the IO stack, which determines the parallel processing capability of the system for IO requests. Reasonable setting of this parameter can make full use of the hardware resources of the system, such as CPU cores. It is recommended to set it to the total number of CPUs allocated by the operating system to the distributed storage system, minus the number of CPU cores of the core function of the distributed storage system, and the number of other available CPU cores. The depth parameter represents the maximum number of IO requests that can be processed simultaneously by each work thread. This parameter, together with the worker parameter, determines the total capacity of the task pool, i.e., the total amount of IO requests that the system can process at a certain time.
[0021] Step 102, identify the request type of the newly arrived input / output request, and distribute the input / output request to the corresponding queue in the task pool or the cache pool according to the request type and the state of the task pool.
[0022] In some embodiments, after a new IO request enters the IO stack, the entry monitor serves as the first processing node to complete type determination by analyzing the identification information and business attributes carried by the request. The determination basis and rules strictly match the business scenario definition of IO requests in the distributed storage system. After the entry monitor completes type identification, it adds a unique type label to the IO request and synchronously records the request key information, and then packages the type label and request information and sends them to the distributor to provide basic data support for subsequent scheduling and distribution. After receiving the type and information of the IO request, the distributor needs to first interact with the entry monitor and the exit monitor in real time to obtain the current load state and resource occupation of the task pool, including: total capacity and remaining capacity of the task pool, occupation of each type of request sub-queue, and worker thread load balancing. The distributor combines the IO request type and the task pool state to perform request distribution according to the principle of "prioritizing high-priority request processing and considering resource utilization".
[0023] Step 103, check the state of the task pool and the cache pool at a preset time interval, and schedule the input / output requests in the cache pool to the task pool according to the priority order.
[0024] In some embodiments, the distributor sets a fixed checking period through the timer module, and the setting of the period needs to balance the "request response timeliness" and "system resource overhead". The core is based on the business delay demand of the distributed storage system, the average processing time of IO request, and the hardware performance. The distributor starts the "task pool-cache pool" state joint checking once the timer triggers, and suspends the non-urgent scheduling in the period to ensure the atomicity of the checking and scheduling operations and avoid state conflicts.
[0025] After the distributor triggers the checking, the distributor acquires two types of core state information through the real-time data interaction with the entrance monitor, the exit monitor, and the cache pool: the distributor preferentially queries the current available resources of the task pool to ensure that the scheduled request can be accommodated by the task pool, and after confirming that the task pool has free space, the distributor further queries the request storage of each linked list of the cache pool to determine the number and type of requests to be scheduled. The distributor provides the basis for subsequent scheduling decisions.
[0026] The distributor combines the "task pool remaining capacity" and the "cache pool request situation of each linked list", strictly follows the priority order of the IO request, and performs the request scheduling.
[0027] The distributor needs to trigger the state synchronization among the modules after completing the request scheduling each time to ensure the accuracy of the subsequent scheduling decisions.
[0028] Step 104, when the high-priority input / output request arrives and the task pool is full, the low-priority input / output request in the task pool is transferred to the cache pool to limit the input / output request allocation of computing resources.
[0029] In some embodiments, the distributor needs to meet two core conditions of "arrival of high-priority request" and "full task pool" to trigger the low-priority request migration operation. The judgment basis relies on the initialization module parameters and the monitor feedback data. When the arrived new request is high-priority, the migration triggering qualification is met; when the arrived new request is low-priority, even if the task pool is full when the request arrives, the migration is not triggered. To avoid affecting the IO request being processed in the task pool, the distributor needs to select the "migratable low-priority request". After the distributor selects the migratable low-priority request, the distributor performs the directional migration. After the migration is completed, the distributor needs to trigger the state synchronization among the modules to ensure the accuracy of the subsequent scheduling decisions.
[0030] Compared with the related art, the embodiment firstly configures the concurrent processing parameter and the total capacity parameter of the task pool; identifies the request type of a newly-arrived input / output request, and distributes the input / output request to the corresponding queue in the task pool or the cache pool according to the request type and the state of the task pool; checks the states of the task pool and the cache pool at a preset time interval, and schedules the input / output request in the cache pool to the task pool according to the priority order; when a high-priority input / output request arrives and the task pool is full, the low-priority input / output request in the task pool is transferred to the cache pool, so as to limit the input / output request to allocate computing resources. Compared with the related art, the application effectively solves the problem of mutual interference of various IO requests in the distributed storage system by classifying and dynamically scheduling the IO requests. At the same time, through the cooperative work of the cache pool and the task pool, the processing efficiency and resource utilization of the system for the IO request are improved, and the stability and reliability of the distributed storage system are enhanced.
[0031] Figure 2 Further, a flowchart of an IO flow rate limiting control method provided by the embodiment of the disclosure is shown, which includes the following steps: Step 201, set the number of concurrent working threads according to the available computing resources of the system.
[0032] In some embodiments, the distributor needs to first acquire two types of core hardware data through the system interface and the hardware monitoring module: the total CPU core number of the distributed storage system and the CPU core number occupied by the core function of the distributed storage system, to provide a basis for subsequent calculations. The total number of CPU cores allocated to the distributed storage system by the server can be obtained through the native interface of the operating system or the hardware monitoring tool. The number of concurrent working threads is based on the "available CPU core number", and is adjusted in combination with auxiliary resources and business needs to ensure that the number of threads matches the hardware carrying capacity.
[0033] Optionally, by default, the worker parameter = available CPU core number, at this time, the idle CPU resources can be maximized, the core is avoided to be idle, and the thread switching overhead is reduced.
[0034] The system stress test tool can be used to simulate medium pressure IO requests to verify whether the configured number of threads meets the CPU utilization rate without idling or overloading, the IO processing delay is less than the business allowed threshold, and the CPU of the core function process is not preempted.
[0035] Through the above process, three-dimensional adaptation of hardware resources, core functions and business needs is realized, which ensures that the number of concurrent working threads not only meets the configuration rules of the technical disclosure, but also actually matches the system hardware carrying capacity, laying a foundation for subsequent task pool capacity configuration.
[0036] Step 202, set the number of requests that each working thread can handle at the same time, thereby determining the total capacity of the task pool.
[0037] In some embodiments, the processing time of different types of IO requests differs significantly, and the historical request data needs to be prioritized or the key indicators need to be obtained through stress testing; the performance of the storage medium (such as SSD, HDD) and the IO bus directly determines the number of requests that a single thread can bear, and the key parameters need to be obtained through hardware performance testing tools; the value of the depth parameter needs to be determined comprehensively in combination with the IO request characteristics, hardware processing capacity and business delay requirements.
[0038] Through the above process, the depth parameter is accurately adapted to the system hardware and business requirements, and the total capacity of the task pool is calculated based on the explicit formula, ensuring that the depth parameter avoids processing delay caused by overloading of a single thread, and maximizes thread utilization, and finally realizes accurate matching of the task pool capacity and the system carrying capacity.
[0039] Step 203, identifying the request type of the newly arrived input / output request, and distributing the input / output request to the corresponding queue in the task pool or the cache pool according to the request type and the task pool state.
[0040] Step 204, checking the state of the task pool and the cache pool at a preset time interval, and scheduling the input / output request in the cache pool to the task pool according to the priority order.
[0041] Step 205, when a high-priority input / output request arrives and the task pool is full, transferring the low-priority input / output request in the task pool to the cache pool, so as to limit the allocation of computing resources for input / output requests.
[0042] For the description of steps 203-205, please refer to the description of steps 102-104 in the above embodiments. This embodiment will not be described one by one.
[0043] Figure 3 Further, a flowchart of an IO flow rate limiting control method provided by the embodiments of the present disclosure is shown, which includes the following steps: Step 301, determining the number of concurrent working threads according to the total number of system computing cores minus the number of cores occupied by system core functions.
[0044] In some embodiments, the "total number of system computing cores" specifically refers to the total number of CPU cores allocated by the operating system to the distributed storage system, rather than the total number of physical CPU cores of the server.
[0045] The "occupied core" is a module that guarantees the basic operation of the distributed storage system and cannot be interrupted. The CPU core occupied by it needs to be deducted from the total number of computing cores. Specifically, it includes three categories: metadata management module: the core process responsible for data index maintenance, directory structure update, and data positioning mapping, usually needs to occupy 2-4 cores to avoid affecting the overall IO performance due to metadata processing delay; data storage underlying driver module: the driver program that directly interacts with the storage medium (SSD / HDD), needs to occupy 1-2 cores to ensure that IO instruction transmission is not blocked; inter-node communication module: the communication process that implements data synchronization and consistency protocol between distributed nodes, needs to occupy 1-2 cores to avoid communication congestion leading to data inconsistency.
[0046] According to the type of operating system, select the corresponding tool to ensure that the collected is the "number of cores allocated to the distributed storage system", not the total number of physical cores.
[0047] In the Linux system, the lscpu command can be used in combination with CPU affinity configuration query. The specific command is lscpu|grep "CPU(s):"|head -n1 (get the total number of schedulable cores), and then query the core list that the process can use through cat / proc / [distributed storage system main process PID] / status|grep Cpus_allowed_list. The number of cores in the list is the "total number of computing cores".
[0048] In the Windows system, the GetProcessAffinityMask API function can be used to get the CPU affinity mask of the distributed storage system main process. After converting the mask to binary, count the number of "1" bits, which is the total number of computing cores.
[0049] Use process monitoring tools to count the number of exclusive cores of core function processes. In the Linux system, you can use htop (enable "CPU binding display" function), taskset command; in the Windows system, you can use "Task Manager-Details-Right-click process-Set Affinity"; Based on the above collected parameters, the number of concurrent working threads is calculated through a fixed formula. The formula is: Number of concurrent working threads = total number of computing cores - number of cores occupied by system core functions The core logic of this formula is "use all idle CPU cores for concurrent processing of IO requests to avoid core idling while not affecting the stable operation of system core functions". Through the above process, "accurate thread configuration based on CPU core number" is realized, ensuring that the number of concurrent working threads can maximize the use of idle resources while not affecting the stable operation of system core functions, providing a core basis for subsequent task pool capacity configuration.
[0050] Step 302, set the number of requests that each work thread can handle at the same time, thereby determining the total capacity of the task pool.
[0051] For the description of step 302, please refer to the description of step 202 in the above embodiment. This embodiment will not be repeated here.
[0052] Step 303, identify the request type of the newly arrived input / output request, and allocate the input / output request to the corresponding queue in the task pool or the cache pool according to the request type and the state of the task pool; Step 304, check the state of the task pool and the cache pool at a preset time interval, and schedule the input / output request in the cache pool to the task pool according to the priority order; Step 305, when a high-priority input / output request arrives and the task pool is full, transfer the low-priority input / output request in the task pool to the cache pool, so as to limit the input / output request to allocate computing resources.
[0053] For the description of steps 303-305, please refer to the description of steps 102-104 in the above embodiment. This embodiment will not be repeated here.
[0054] Figure 4 Further, a flowchart of an IO flow rate limiting control method provided by the embodiment of the present disclosure is shown, which includes the following steps: Step 401, configure the concurrent processing parameters and total capacity parameters of the task pool.
[0055] For the description of step 401, please refer to the description of step 101 in the above embodiment. This embodiment will not be repeated here.
[0056] Step 402, identify the request type of the newly arrived input / output request, including: query class, normal service class, management class and data recovery class, and allocate the input / output request to the corresponding queue in the task pool or the cache pool according to the request type and the state of the task pool.
[0057] In some embodiments, after a new IO request enters the IO stack, the entry monitor serves as the only identification node, and through analyzing the three-dimensional characteristics of the "identification field, initiation source, operation attribute" of the request, the accurate determination of the four types of requests is completed.
[0058] Identification of query class IO request: the core determination basis is that the request purpose is to "obtain data state information", and the specific identification characteristics include: The request header carries key fields such as "status_query", "data_check" and "node_load", or the request parameters contain state query keywords such as "state", "health" and "capacity"; Request origin is system monitoring module (such as storage node status monitoring process, user data query interface), not business application or management background; No data read / write, create / delete modification operation, only return the current state of data.
[0059] Identify the type of label "inquiry" after marking.
[0060] Identification of general business class IO request: the core basis for decision is that the request corresponds to "user actual business read / write operation", the specific identification features include: Request associated user business identification, such as business application ID, user database read / write port, user file path; Operation type is data read / write (such as "read", "write", "append"), no metadata management or fault recovery mark; Request origin is user business process, not system management tool.
[0061] Identify the type of label "normal" after marking.
[0062] Identification of management class IO request: the core basis for decision is that the request is used for "data storage management, such as metadata and data creation, deletion, etc.", the specific identification features include: Request contains "meta_create", "meta_delete", "config_update", "partition_init" and other metadata operation fields; Request origin is system management background, operation object is metadata; No user business data read / write, only modify the management attributes of storage system.
[0063] Identify the type of label "manage" after marking.
[0064] Identification of data recovery class IO request: the core basis for decision is that the request is used for "data recovery from other copies when data copy is lost due to fault", the specific identification features include: Request carries "replica_recover", "fault_repair", "copy_restore" and other fault recovery identification, and the parameters contain fault node ID and lost copy storage address; Request trigger time is after the system detects copy loss, and the origin is system fault recovery module; Operation type is "data replication", no user-initiated operation.
[0065] Identify the type of label "recovery" after marking, record the associated fault node information.
[0066] After the type identification is completed, the entrance monitor packs and synchronizes the type label and the request core information to the distributor, to provide basic data for subsequent allocation decisions, and there is no need for secondary analysis of the request content throughout, ensuring identification efficiency.
[0067] After receiving the request information, the distributor obtains three types of core state information, including the overall capacity and the remaining capacity of the task pool, the occupation of each type of sub-queue of the task pool, and the load balancing of the worker thread, through real-time interaction with the entrance monitor and the exit monitor, to ensure that the allocation decision is not deviated from the actual resource situation of the system, and the query logic completely relies on the parameters configured by the initialization module.
[0068] The distributor combines the "IO request type priority" and the "task pool state" to perform allocation according to the principle of "prioritizing high-priority requests, corresponding queue for similar requests, and caching when full".
[0069] Through the above process, a closed loop of "four types of IO request accurate identification-task pool state dynamic adaptation-queue accurate allocation" is realized, which ensures the accurate matching of requests, task pools and cache pools.
[0070] Step 403, check the state of the task pool and the cache pool at a preset time interval, and schedule the input / output requests in the cache pool to the task pool according to the priority order.
[0071] Step 404, when a high-priority input / output request arrives and the task pool is full, transfer the low-priority input / output requests in the task pool to the cache pool, in order to limit the allocation of input / output requests to computing resources.
[0072] For the description of steps 402-404, please refer to the description of steps 103-104 in the above embodiment. This embodiment will not be repeated here.
[0073] Figure 5 Further, a flowchart of an IO flow rate limiting control method provided by the embodiment of the present disclosure is shown, which includes the following steps: Step 501, configure the concurrent processing parameters and total capacity parameters of the task pool.
[0074] Step 502, identify the request type of the newly arrived input / output request, and allocate the input / output request to the corresponding queue in the task pool or the cache pool according to the request type and the task pool state.
[0075] For the description of steps 501-502, please refer to the description of steps 101-102 in the above embodiment. This embodiment will not be repeated here.
[0076] Step 503, check the task pool and the cache pool state at a preset time interval, and schedule the input and output requests in the cache pool to the task pool according to the priority order of the inquiry class, the normal service class, the management class, and the data recovery class.
[0077] In some embodiments, the distributor sets a fixed checking period through a built-in timer module. The period needs to balance the "IO request response timeliness" and "system resource overhead", and the core is completely consistent with the hardware performance and business demand of the distributed storage system. The timer automatically sends a "checking trigger signal" to the distributor every time it reaches the preset interval. After the distributor receives the signal, it suspends non-urgent scheduling and starts the joint checking of the "task pool-cache pool" state to ensure the atomicity of the checking and scheduling operations and avoid scheduling errors caused by state conflicts.
[0078] In the embodiments of the present disclosure, the cache pool includes a plurality of linked lists, each linked list corresponding to a request type and managing requests in a first-in-first-out order. The cache pool serves as a "request temporary storage carrier when the task pool is full", and maintains four independent FIFO linked lists inside, each linked list corresponding to a type of IO request.
[0079] In the embodiments of the present disclosure, each linked list corresponds to a request type, including an inquiry linked list, a normal service linked list, a management linked list, and a data recovery linked list.
[0080] The cache pool serves as a "request temporary storage carrier when the task pool is full", and maintains four independent FIFO linked lists inside, each linked list corresponding to a type of IO request.
[0081] The inquiry linked list corresponds to query class IO requests. When a new query class request arrives and the task pool is full, or the inquiry sub-queue of the task pool has reached the upper limit, the distributor temporarily stores the request in the inquiry linked list. The normal linked list corresponds to normal service class IO requests. When a new normal service class request arrives and the task pool is full, or the normal sub-queue of the task pool has reached the upper limit, the distributor temporarily stores the request in the normal linked list. The manage linked list corresponds to management class IO requests. When a new management class request arrives and the task pool is full, or the manage sub-queue of the task pool has reached the upper limit, the distributor temporarily stores the request in the manage linked list. The recovery linked list corresponds to data recovery class IO requests. When a new data recovery class request arrives and the task pool is full, or the recovery sub-queue of the task pool has reached the upper limit, the distributor temporarily stores the request in the manage linked list. After the distributor triggers the check, the two types of core state information are obtained through real-time data interaction with the entrance monitor, exit monitor, and cache pool management module, providing accurate basis for subsequent scheduling decisions.
[0082] The task pool can be preferentially confirmed whether it has enough space to accommodate the cache pool request, and the check dimensions include: Overall remaining capacity calculation: based on the worker parameters and depth parameters configured by the initialization module, the total capacity is calculated according to the formula "total capacity = number of workers x depth"; then the number of requests currently occupied by each worker thread is counted by the exit monitor, and the idle space is calculated according to the formula "remaining capacity = total capacity - occupied requests". If the remaining capacity = 0, it is determined that the task pool has no free space, and the current scheduling is terminated directly.
[0083] Idle condition of each type of sub-queue: the task pool maintains sub-queues corresponding to four types of requests (inquiry sub-queue, normal sub-queue, manage sub-queue, and recovery sub-queue), and the maximum capacity of each sub-queue = number of workers x depth. The distributor queries the current number of requests in each sub-queue to determine whether there is a "sub-queue full" condition. If the target sub-queue is full, even if the task pool has remaining capacity, the scheduling of this type of request is temporarily suspended to avoid processing delay caused by sub-queue overload.
[0084] Worker thread load balancing: the exit monitor provides real-time feedback on the current load of each worker thread, and the distributor selects low-load threads to which requests are preferentially assigned in subsequent scheduling, avoiding IO jam caused by excessive concentration of requests on a certain thread.
[0085] After confirming that the task pool has free space, the request storage status of each linked list in the cache pool is further queried to determine the number and priority of requests to be scheduled, and the check content includes: Request count of each type of linked list: the cache pool maintains four FIFO linked lists corresponding to each type of request, and the distributor obtains the current number of requests in each linked list through the cache pool management module to determine whether there is a "non-empty linked list".
[0086] Request waiting time statistics: each linked list manages requests according to the "first-in, first-out" rule, and the distributor records the time stamp of the earliest request in each linked list. In subsequent scheduling, the request with the longest waiting time is preferentially processed to ensure the fairness of processing requests of the same type.
[0087] Request resource matching verification: for large-size requests, the IO bus bandwidth utilization rate is additionally queried. If the bandwidth is insufficient, even if this type of request is accumulated in the cache pool, it is temporarily not scheduled to avoid IO bus congestion affecting the processing of other high-priority requests.
[0088] The distributor combines the "task pool remaining capacity" and the "cache pool each linked list request condition", and strictly follows the priority order of the query class, the general service class, the management class and the data recovery class to execute the request scheduling.
[0089] Through the above process, the "priority ordered flow transfer" of the IO requests between the cache pool and the task pool is realized, which strictly follows the priority definition and the FIFO rule, and ensures the system stability through load balancing and resource verification, effectively solving the problem of "mutual interference of various IO requests" in the prior art.
[0090] In step 504, when a high-priority input / output request arrives and the task pool is full, the low-priority input / output requests in the task pool are transferred to the cache pool, so as to limit the input / output request allocation of computing resources.
[0091] For the description of step 504, please refer to the description of step 104 in the above embodiment. This embodiment will not be repeated here.
[0092] Figure 6 One of the embodiments of the present disclosure shows a flow chart of an IO flow rate limiting control method, which includes the following steps: In step 601, the concurrent processing parameters and the total capacity parameters of the task pool are configured.
[0093] In step 602, the request type of the newly arrived input / output request is identified, and the input / output request is allocated to the corresponding queue in the task pool or the cache pool according to the request type and the task pool state.
[0094] In step 603, the state of the task pool and the cache pool is checked at a preset time interval, and the input / output request in the cache pool is scheduled to the task pool according to the priority order.
[0095] For the description of steps 601-603, please refer to the description of steps 101-103 in the above embodiment. This embodiment will not be repeated here.
[0096] In step 604, when a high-priority input / output request arrives and the task pool is full, the input / output requests that have not started processing in the task pool are sorted according to the priority.
[0097] In some embodiments, when the newly arrived request is a query class or a general service class, and the task pool is full, the sorting is triggered; the management class and the data recovery class are low-priority requests, and even if the task pool is full when they arrive, the sorting is not triggered. If the task pool is full but all requests are "processing" without "unprocessed" requests, the capacity cannot be released by migration, and this step is directly terminated (to avoid meaningless sorting); only when the "unprocessed request number ≥ 1", the subsequent screening and sorting link is entered.
[0098] To avoid misclassification of "processed requests" into the ranking, the "sortable unprocessed requests" are selected from all requests in the task pool by the state tag of the export monitor, and the selection process is as follows: The export monitor binds a "state tag" to each request in the task pool, which is updated in real time with the progress of the request processing: Processing: The worker thread has started IO read / write, data verification and other operations, and the associated hardware resources of the request have been locked. Such requests cannot be filtered; Unprocessed: The request has entered the task pool subqueue, but the worker thread has not called the processing interface, and it is only in the queuing state. Such requests are "filterable, sortable, and migratable" objects.
[0099] The distributor classifies and counts the selected unprocessed requests by "request type". The selected unprocessed requests are divided into four levels according to type priority, and the "high priority level is overall in the front" principle is strictly followed between levels, and cross-level queuing is not allowed: First level: inquiry unprocessed requests (INQUIRY), highest priority, overall first in the ranking result; Second level: normal business unprocessed requests (NORMAL), lower priority, after the first level; Third level: management unprocessed requests (MANAGE), lower priority, after the second level; Fourth level: data recovery unprocessed requests (RECOVERY), lowest priority, overall last in the ranking result.
[0100] Requests within the same priority level strictly follow the "first-in, first-out (FIFO)" principle and are sorted in ascending order of "entry time stamp" to ensure fairness in processing similar requests.
[0101] After sorting, the distributor needs to generate a "sorting result list" and synchronize it to the export monitor and the import monitor.
[0102] Through the above process, "accurate filtering and ordered sorting of unprocessed requests" are achieved, which strictly follows the priority definition and state constraints, and provides clear and executable basis for subsequent migration of low-priority requests, ensuring that the entire "high-priority request resource preemption" process is compliant and efficient.
[0103] Step 605, according to the priority sorting result, move the low-priority input / output request to the cache pool to limit the allocation of computing resources by the input / output request.
[0104] In some embodiments, the number of migrations needs to be dynamically determined according to the "space requirement of new high-priority input-output request" and the "current idle gap of task pool", which can ensure that the new high-priority request can be accommodated, and avoid resource waste caused by meaningless migration. The calculation logic completely relies on the initialization module parameters and real-time state data. Based on the "sorting result list" generated in step 604, the migration object is selected according to the principle of "migration priority from high to low, and the same type of request according to the order of entering the queue", which ensures that the selection logic is fair and meets the needs of "low-priority migration first". After the migration object is determined, the request needs to be directed to the corresponding linked list of the cache pool, and the FIFO rule of the cache pool needs to be strictly followed to avoid request classification confusion. After the migration is completed, the states of the task pool, the cache pool, the entrance monitor and the exit monitor need to be synchronized to ensure that the data of each module is consistent.
[0105] Through the above-mentioned "on-demand, directional and safe" migration of low-priority requests, the priority rules and module interaction logic are strictly followed, and the task pool can release enough space to accommodate high-priority requests, finally achieving the technical effect of "limiting the occupation of resources by low-priority requests and ensuring the priority processing of high-priority requests".
[0106] Figure 7 A flowchart of an IO flow rate limiting control method provided by the embodiments of the present disclosure is shown, which includes the following steps: Step 701, configure the concurrent processing parameters and total capacity parameters of the task pool.
[0107] Step 702, identify the request type of the newly arrived input-output request, and distribute the input-output request to the corresponding queue in the task pool or the cache pool according to the request type and the state of the task pool.
[0108] For the description of steps 701-702, please refer to the description of steps 101-102 in the above-mentioned embodiments. This embodiment will not be described one by one.
[0109] Step 703, record the load state of each worker thread in the task pool in real time through the entrance monitor and the exit monitor.
[0110] In some embodiments, the entrance monitor and the exit monitor cover the load recording of the whole life cycle of IO request "entry-processing-exit" through "division of labor, data intercommunication", and the responsibility boundary and interaction logic of the two completely fit the positioning of the monitor function in the technical disclosure: In some embodiments, the entry monitor increases the count of the corresponding worker thread when an input / output request enters the task pool, and the exit monitor decreases the count of the corresponding worker thread when the input / output request processing is completed. Specifically, when the allocator allocates an input / output request to the sub-queue of the task pool corresponding to the worker thread, the entry monitor immediately performs the count increasing operation; when the worker thread completes the processing of the IO request and moves the request out of the task pool, the exit monitor synchronously performs the count decreasing operation.
[0111] The embodiment accurately and real-timely records the load state of each worker thread through the entry monitor and the exit monitor, thereby providing data support for the dynamic scheduling of the allocator and ensuring efficient utilization and load balancing of the task pool resources.
[0112] Step 704: checking the states of the task pool and the cache pool at preset time intervals, and scheduling the input / output requests in the cache pool to the task pool according to the priority order.
[0113] Step 705: when a high-priority input / output request arrives and the task pool is full, transferring the low-priority input / output requests in the task pool to the cache pool, so as to limit the allocation of computing resources by the input / output requests.
[0114] For the description of steps 704-705, refer to the description of steps 103-104 in the above embodiment. The embodiment will not be repeated here.
[0115] Figure 8 One embodiment of the IO flow limiting control method provided by the present disclosure is shown in the flow chart, which includes the following steps: Step 801: configuring the concurrent processing parameters and the total capacity parameters of the task pool.
[0116] Step 802: identifying the request type of a newly arrived input / output request, and allocating the input / output request to the corresponding queue in the task pool or the cache pool according to the request type and the state of the task pool.
[0117] Step 803: checking the states of the task pool and the cache pool at preset time intervals, and scheduling the input / output requests in the cache pool to the task pool according to the priority order.
[0118] Step 804: when a high-priority input / output request arrives and the task pool is full, transferring the low-priority input / output requests in the task pool to the cache pool, so as to limit the allocation of computing resources by the input / output requests.
[0119] For the description of steps 801-804, refer to the description of steps 101-104 in the above embodiment. The embodiment will not be repeated here.
[0120] Step 805, when there is an idle worker thread in the task pool, the input / output request with the longest waiting time in the cache pool is preferentially scheduled into the task pool according to the waiting time of each linked list in the cache pool.
[0121] In some embodiments, the load status of all worker threads in the task pool can be obtained in real time by the exit monitor; the cache pool management module is called by the allocator to obtain the waiting time of all unscheduled requests in each type of IO request linked list (inquiry linked list-query type, normal linked list-ordinary service type, manage linked list-management type, recovery linked list-data recovery type); the allocator combines the "IO request priority rule" (query type> ordinary service type> management type> data recovery type) with the "waiting time" to screen the candidate requests to be scheduled; the allocator performs scheduling and allocation according to the available capacity of the idle worker thread and the resource demand of the candidate request; after the scheduling is completed, the allocator triggers global state synchronization to ensure the data consistency of each module. This step is triggered only when there is an idle worker thread in the task pool and there is a request to be processed in the cache pool, and can be combined with the "periodic check mechanism" of the allocator to avoid system resource waste caused by real-time polling.
[0122] Figure 9 A structural schematic diagram of an IO flow rate limiting control device provided by an embodiment of the present disclosure is shown in FIG. 1, which includes a configuration module 901, an allocation module 902, a scheduling module 903, and a transfer module 904. Figure 9
[0123] The configuration module 901 is configured to configure the concurrent processing parameters and total capacity parameters of the task pool.
[0124] The allocation module 902 is configured to identify the request type of a newly arrived input / output request, and allocate the input / output request to the corresponding queue in the task pool or the cache pool according to the request type and the state of the task pool.
[0125] The scheduling module 903 is configured to check the states of the task pool and the cache pool at a preset time interval, and schedule the input / output requests in the cache pool to the task pool according to the priority order.
[0126] The transfer module 904 is configured to, when a high-priority input / output request arrives and the task pool is full, transfer the low-priority input / output requests in the task pool to the cache pool, so as to limit the allocation of computing resources by the input / output requests.
[0127] In some examples of the embodiment, the configuration module 901 is specifically configured to set the number of concurrent work threads according to the available computing resources of the system; set the number of requests that can be processed simultaneously by each work thread, thereby determining the total capacity of the task pool; and determine the number of concurrent work threads according to the number of total computing cores of the system minus the number of cores occupied by the core functions of the system.
[0128] In some examples of the embodiment, the scheduling module 903 is specifically configured to schedule the input / output requests in the cache pool to the task pool in the order of priority of the query class, the normal service class, the management class, and the data recovery class.
[0129] In some examples of the embodiment, the transfer module 904 is specifically configured to sort the input / output requests that have not started processing in the task pool according to the priority; and move the input / output requests with low priority to the cache pool according to the sorting result.
[0130] It should be noted that other corresponding descriptions of the functions of the IO flow rate limiting control device provided in the embodiment can be referred to the corresponding descriptions in Figure 1 、 Figure 2 、 Figure 3 、 Figure 4 、 Figure 5 、 Figure 6 、 Figure 7 and Figure 8 , which will not be repeated here.
[0131] Based on the above-mentioned IO flow rate limiting control method as shown in Figure 1 、 Figure 2 、 Figure 3 、 Figure 4 、 Figure 5 、 Figure 6 、 Figure 7 and Figure 8 , correspondingly, the embodiment also provides a computer readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-mentioned IO flow rate limiting control method as shown in Figure 1 、 Figure 2 、 Figure 3 、 Figure 4 and Figure 7 .
[0132] Based on the above-mentioned IO flow rate limiting control method as shown in Figure 1 、 Figure 2 、 Figure 3 、 Figure 4 、 Figure 5 、 Figure 6 、 Figure 7 and Figure 8The embodiment illustrates an I / O stream rate limiting control method. Correspondingly, this embodiment also provides a computer program product on which a computer program is stored. When executed by a processor, this computer program implements the above-described method. Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 , Figure 6 , Figure 7 and Figure 8 This illustrates an I / O flow rate limiting control method.
[0133] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.
[0134] Based on the above, Figure 9 , Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 , Figure 6 and Figure 7 An I / O stream rate limiting control method is shown, and Figure 8 To achieve the above objectives, the present application also provides an electronic device, such as a personal computer or a server, in the illustrated virtual device embodiment. This device includes a storage medium and a processor; the storage medium stores a computer program; the processor executes the computer program to implement the above-described virtual device. Figure 9 , Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 , Figure 6 and Figure 7 Figure 8 This illustrates an I / O flow rate limiting control method.
[0135] In some embodiments, the aforementioned physical device may further include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, an input unit such as a keyboard, etc., and optionally, a USB interface, a card reader interface, etc. In some embodiments, the network interface may include a standard wired interface, a wireless interface (such as a Wi-Fi interface), etc.
[0136] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.
[0137] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.
[0138] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms, or it can be implemented by hardware. By applying the solution of this embodiment, compared with the existing technology, this embodiment can perform intelligent data processing and analysis functions to deeply mine and predictively analyze the collected data, provide cross-level I / O tracing means, perform root cause analysis of blocking, thereby accurately distinguishing VFS lock contention, block device queue congestion or physical disk response latency, and based on the historical pattern I / O anomaly prediction mechanism, can systematically locate timeout requests to specific levels and implement targeted optimization measures.
[0139] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.
[0140] The above are merely specific embodiments of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to these embodiments, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.
Claims
1. A method for I / O stream rate limiting control, characterized in that, include: Configure the concurrent processing parameters and total capacity parameters of the task pool; Identify the request type of newly arrived input / output requests, and allocate the input / output requests to the corresponding queues in the task pool or cache pool according to the request type and the task pool status; The status of the task pool and the cache pool is checked at preset time intervals, and input / output requests in the cache pool are scheduled to the task pool according to priority. When a high-priority input / output request arrives and the task pool is full, low-priority input / output requests in the task pool are transferred to the cache pool in order to limit the allocation of computing resources for input / output requests.
2. The IO stream rate limiting control method according to claim 1, characterized in that, The concurrent processing parameters and total capacity parameters of the configured task pool include: Set the number of concurrent worker threads based on the available computing resources in the system; The total capacity of the task pool is determined by setting the number of requests that each worker thread can handle simultaneously.
3. The IO stream rate limiting control method according to claim 2, characterized in that, The step of setting the number of concurrent worker threads based on the available computing resources of the system includes: The number of concurrent worker threads is determined by subtracting the number of cores occupied by the system's core functions from the total number of system computing cores.
4. The IO stream rate limiting control method according to claim 1, characterized in that, The request types include: query, general business, management, and data recovery.
5. The IO stream rate limiting control method according to claim 4, characterized in that, The step of scheduling input / output requests from the cache pool to the task pool according to priority includes: Input and output requests in the cache pool are scheduled to the task pool according to the priority order of query, general business, management, and data recovery.
6. The IO stream rate limiting control method according to claim 1, characterized in that, The cache pool includes multiple linked lists, each corresponding to a request type, and requests are managed in a first-in, first-out order.
7. The IO stream rate limiting control method according to claim 6, characterized in that, Each linked list corresponds to a request type, including query linked lists, ordinary business linked lists, management linked lists, and data recovery linked lists.
8. The IO stream rate limiting control method according to claim 1, characterized in that, The step of transferring low-priority input / output requests from the task pool to the cache pool includes: Sort the input / output requests that have not yet started processing in the task pool according to priority; Low-priority input / output requests are moved to the cache pool based on the priority sorting results.
9. The IO stream rate limiting control method according to claim 1, characterized in that, Also includes: The load status of each worker thread in the task pool is recorded in real time by the ingress and egress monitors.
10. The IO stream rate limiting control method according to claim 9, characterized in that, The entry monitor increments the count of the corresponding worker thread when an input or output request enters the task pool, and the exit monitor decrements the count of the corresponding worker thread after the input or output request has been processed.
11. The IO stream rate limiting control method according to claim 1, characterized in that, Also includes: When there are idle worker threads in the task pool, the input / output request with the longest waiting time is prioritized and scheduled into the task pool according to the waiting time of each linked list in the cache pool.
12. An IO flow rate limiting control device, characterized in that, include: The configuration module is used to configure the concurrent processing parameters and total capacity parameters of the task pool; The allocation module is used to identify the request type of newly arrived input / output requests and allocate the input / output requests to the corresponding queues in the task pool or cache pool according to the request type and the task pool status. The scheduling module is used to check the status of the task pool and the cache pool at preset time intervals, and schedule the input and output requests in the cache pool to the task pool according to priority order. The transfer module is used to transfer low-priority input / output requests from the task pool to the cache pool when a high-priority input / output request arrives and the task pool is full, so as to limit the allocation of computing resources for input / output requests.
13. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the I / O flow rate limiting control method according to any one of claims 1-11.
14. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to execute the IO flow rate limiting control method according to any one of claims 1-11.
15. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the I / O flow rate limiting control method according to any one of claims 1-11.
Citation Information
Patent Citations
Multiprocessor with stress responsive buffer
CA1147824A
An input / output cache for caching direct (virtual) memory access data
CA2036372A1
Assigning and scheduling threads for multiple prioritized queues
CN105474175A
Storage controller and IO (input / output) request processing method
CN106775493A
Method and device for ensuring request priority and computer device
CN108984121A