Io flow rate limiting control method and device, electronic equipment and storage medium

Abstract

The application discloses an IO flow rate limiting control method and device, electronic equipment and a storage medium, relates to the technical field of computer data storage, and comprises the following steps: configuring concurrent processing parameters and total capacity parameters of a task pool; identifying the request type of a newly arrived input / output request, and distributing the input / output request to a 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 a priority order; when a high-priority input / output request arrives and the task pool is full, transferring low-priority input / output requests in the task pool to the cache pool, and limiting the allocation of computing resources to IO requests. The technical problems that related technologies lack flexible and dynamic regulation and control mechanisms can be solved, the processing efficiency of the system for IO requests and the resource utilization rate are improved, and the stability and reliability of the distributed storage system are enhanced.

Description

Technical Field

[0001] This application relates to the field of computer data storage technology, and in particular to an I / O stream rate limiting control method and apparatus, electronic device and storage medium. Background Technology

[0002] In the field of distributed storage, the IO stack needs to process four types of core IO requests in parallel, including: ordinary business IO that directly corresponds to the actual read and write operations of users' business; management IO that serves data storage management needs and covers metadata and data creation, deletion and other operations; query IO that is used to obtain data status information; and data recovery IO that recovers data from other normal copies when a failure causes the data copy to be lost.

[0003] In related technologies, most distributed storage systems primarily employ two scheduling methods when handling I / O requests: FIFO scheduling, which queues I / O requests according to their arrival order and has simple logic; and weighted static allocation, which pre-assigns fixed weights to different types of I / O requests and statically allocates I / O processing resources based on these weights.

[0004] However, the aforementioned technologies lack flexible and dynamic control mechanisms, resulting in a situation where, after a failure occurs, a large amount of data recovery I / O coexists with other types of I / O, making it difficult to ensure the priority processing of critical I / O and affecting the overall performance and stability of the system. Summary of the Invention

[0005] This application provides an IO flow rate limiting control method, device, electronic device, and storage medium, relating to the field of computer data storage technology. By prioritizing and dynamically scheduling IO requests, it effectively solves the problem of mutual interference between various IO requests in a distributed storage system. At the same time, through the collaborative work of the cache pool and task pool, it improves the system's processing efficiency and resource utilization for IO requests, and enhances the stability and reliability of the distributed storage system.

[0006] Firstly, this application provides an I / O stream rate limiting control method, including:

[0007] Configure the concurrent processing parameters and total capacity parameters of the task pool;

[0008] 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 based on the request type and task pool status;

[0009] The status of the task pool and 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.

[0010] 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.

[0011] Secondly, this application provides an IO stream rate limiting control device, comprising:

[0012] The configuration module is used to configure the concurrent processing parameters and total capacity parameters of the task pool;

[0013] 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 task pool status.

[0014] The scheduling module is used to check the status of the task pool and the cache pool at preset time intervals, and schedule input and output requests in the cache pool to the task pool according to priority.

[0015] The transfer module is used to transfer low-priority input / output requests from the task pool to the cache pool when high-priority input / output requests arrive and the task pool is full, so as to limit the allocation of computing resources for input / output requests.

[0016] Thirdly, this application provides an electronic device, including at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the IO flow rate limiting control method implementing the first aspect.

[0017] Fourthly, this application provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the I / O flow rate limiting control method of the first aspect.

[0018] Fifthly, this application provides a computer program product on which a computer program is stored, and when the computer program is executed by a processor, it implements the I / O flow rate limiting control method of the first aspect.

[0019] The IO flow rate limiting control method, apparatus, electronic device, and storage medium provided in this application include: configuring concurrent processing parameters and total capacity parameters of a task pool; identifying the request type of newly arriving input / output requests and allocating the input / output requests to the corresponding queues in the task pool or cache pool according to the request type and task pool status; checking the status of the task pool and cache pool at preset time intervals and scheduling input / output requests in the cache pool to the task pool according to priority; when a high-priority input / output request arrives and the task pool is full, transferring low-priority input / output requests in the task pool to the cache pool to limit the allocation of computing resources by input / output requests. Therefore, this method addresses the problem of related technologies lacking flexible and dynamic control mechanisms, where, after a failure, a large amount of data recovery IO coexists with other types of IO, making it difficult to guarantee the priority processing of critical IO, thus affecting the overall performance and stability of the system. 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 stability and reliability of distributed storage systems. Attached Figure Description

[0020] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating an IO flow rate limiting control method provided in this application embodiment;

[0022] Figure 2 A flowchart illustrating another IO flow rate limiting control method provided in this application embodiment;

[0023] Figure 3 A flowchart illustrating another IO flow rate limiting control method provided in this application embodiment;

[0024] Figure 4 A flowchart illustrating another IO flow rate limiting control method provided in this application embodiment;

[0025] Figure 5 A flowchart illustrating another IO flow rate limiting control method provided in this application embodiment;

[0026] Figure 6 A flowchart illustrating another IO flow rate limiting control method provided in this application embodiment;

[0027] Figure 7 A flowchart illustrating another IO flow rate limiting control method provided in this application embodiment;

[0028] Figure 8 A flowchart illustrating another IO flow rate limiting control method provided in this application embodiment;

[0029] Figure 9 This is a schematic diagram of the structure of an IO flow rate limiting control device provided in an embodiment of this application. Detailed Implementation

[0030] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0031] It should be noted that, in the description of this application, 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. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0032] In the field of distributed storage, the IO stack needs to process four types of core IO requests in parallel: ordinary business IO that directly corresponds to the user's actual business read and write operations; management IO that serves data storage management needs, covering metadata and data creation, deletion, and other operations; query IO for obtaining data status information; and data recovery IO that recovers data from other normal copies when a failure causes the loss of data copies. In related technologies, most distributed storage systems mainly use two scheduling methods when processing IO requests: First-In-First-Out (FIFO) scheduling: IO requests are queued and processed in the order they arrive, which is logically simple. Weighted static allocation: Fixed weights are pre-set for different types of IO requests, and the system statically allocates IO processing resources according to the weight ratio. However, the above-mentioned technologies lack flexible and dynamic control mechanisms. When a failure occurs, a large number of data recovery IOs coexist with other types of IOs, making it difficult to guarantee the priority processing of critical IOs, thus affecting the overall performance and stability of the system.

[0033] In this context, a new solution is needed to address the I / O request scheduling problem. This solution should be able to prioritize and dynamically schedule I / O requests, enabling cache pools and task pools to work together to improve the system's efficiency in handling I / O requests and resource utilization, thereby enhancing the stability and reliability of the distributed storage system.

[0034] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0035] Figure 1 A flowchart of an IO stream rate limiting control method provided in an embodiment of this disclosure is shown below. Figure 1 As shown, the method includes the following steps:

[0036] Step 101: Configure the concurrent processing parameters and total capacity parameters of the task pool.

[0037] In some embodiments, during the initialization of the distributed storage system's IO flow rate limiting module, the `worker` and `depth` parameters of the IO stack are configured. The `worker` parameter represents the maximum number of concurrently executing worker threads in the IO stack. It determines the system's parallel processing capability for IO requests. Properly setting this parameter can fully utilize the system's hardware resources, such as CPU cores. It is recommended to set it to the total number of CPUs allocated to the distributed storage system by the operating system, minus the number of CPUs for the core functions of the distributed storage system, and the number of available CPU cores. The `depth` parameter represents the maximum number of IO requests that each worker thread can handle simultaneously. This parameter, together with the `worker` parameter, determines the overall capacity of the task pool, i.e., the total number of IO requests the system can handle at a given time.

[0038] Step 102: 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 cache pool according to the request type and task pool status.

[0039] In some embodiments, after a new IO request enters the IO stack, the ingress monitor acts as the first processing node. It parses the request's built-in identifier and business attributes to determine the request type. The determination criteria and rules strictly match the business scenario definition of the IO request in the distributed storage system. After type identification, the ingress monitor adds a unique type tag to the IO request and simultaneously records key request information. It then packages the type tag and request information and sends it to the allocator, providing basic data support for subsequent scheduling and allocation. Upon receiving the IO request type and information, the allocator first obtains the current load status and resource usage of the task pool through real-time interaction with the ingress and egress monitors. This includes the total and remaining capacity of the task pool, the usage of sub-queues for each type of request, and the worker thread load balancing. The allocator, combining the IO request type and task pool status, performs request allocation according to the principle of "prioritizing high-priority request processing while considering resource utilization."

[0040] Step 103: Check the status of the task pool and cache pool at preset time intervals, and schedule the input and output requests in the cache pool to the task pool according to priority.

[0041] In some embodiments, the allocator sets a fixed check period through a timer module. The setting of this period needs to balance "request response timeliness" and "system resource overhead," and the core basis includes the business latency requirements of the distributed storage system, the average processing time of IO requests, and hardware performance. Each time the timer is triggered, the allocator starts a joint check of the "task pool-cache pool" status, and at the same time suspends non-urgent scheduling within that period to ensure the atomicity of the check and scheduling operations and avoid state conflicts.

[0042] After the allocator triggers the check, it obtains two types of core status information through real-time data interaction with the ingress monitor, egress monitor, and cache pool: The allocator first queries the available resources in the task pool to ensure that the scheduled requests can be accommodated by the task pool. After confirming that there is free space in the task pool, the allocator further queries the request storage status of each linked list in the cache pool to determine the number and type of requests to be scheduled. This provides a basis for subsequent scheduling decisions.

[0043] The allocator combines the "remaining capacity of the task pool" and the "request status of each linked list in the cache pool" to strictly follow the priority order of IO requests and perform request scheduling.

[0044] After each request scheduling is completed, the allocator needs to trigger state synchronization between multiple modules to ensure the accuracy of subsequent scheduling decisions.

[0045] Step 104: 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 computing resources for input / output requests.

[0046] In some embodiments, the allocator must simultaneously meet two core conditions—"high-priority request arrival" and "task pool full"—before triggering a low-priority request migration operation. This determination is based on initialization module parameters and monitor feedback data. Only high-priority new requests qualify for migration; low-priority new requests, even if the task pool is full upon arrival, will not trigger migration. To avoid impacting ongoing I / O requests within the task pool, the allocator must first filter out "migratable low-priority requests." After filtering out migratable low-priority requests, the allocator performs targeted migration. After migration, the allocator triggers multi-module state synchronization to ensure the accuracy of subsequent scheduling decisions.

[0047] Compared with related technologies, this embodiment first configures the concurrent processing parameters and total capacity parameters of the task pool; identifies the request type of newly arriving input / output requests, and allocates the input / output requests to the corresponding queues in the task pool or cache pool according to the request type and task pool status; checks the status of the task pool and cache pool at preset time intervals, and schedules the input / output requests in the cache pool to the task pool according to priority; 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 to limit the allocation of computing resources by input / output requests. Compared with related technologies, this invention effectively solves the problem of mutual interference between various IO requests in a distributed storage system by prioritizing and dynamically scheduling IO requests. At the same time, through the collaborative work of the cache pool and task pool, it improves the system's processing efficiency and resource utilization for IO requests, and enhances the stability and reliability of the distributed storage system.

[0048] Figure 2 A flowchart of an IO stream rate limiting control method provided for embodiments of this disclosure is further shown, including the following steps:

[0049] Step 201: Set the number of concurrent worker threads based on the available computing resources of the system.

[0050] In some embodiments, the allocator first needs to obtain two types of core hardware data through the system interface and hardware monitoring module: the total number of CPU cores in the distributed storage system and the number of CPU cores used by the core functions 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 and the number of concurrent worker threads can be obtained through the operating system's native interface or hardware monitoring tools. Based on the "available CPU cores," the number of threads can be fine-tuned in conjunction with auxiliary resources and business requirements to ensure that the number of threads matches the hardware capacity.

[0051] Optionally, by default, the worker parameter is equal to the number of available CPU cores. This maximizes the utilization of idle CPU resources, avoids core idleness, and reduces thread switching overhead.

[0052] The system stress testing tool can be used to simulate medium-pressure I / O requests to verify whether the configured number of threads meets the requirements of no idle or overloaded CPU utilization, I / O processing latency less than the business allowable threshold, and no CPU preemption of core function processes.

[0053] Through the above process, a three-dimensional adaptation of hardware resources, core functions, and business requirements was achieved, ensuring that the number of concurrent worker threads not only complies with the configuration rules in the technical disclosure document but also matches the actual system hardware carrying capacity, laying the foundation for subsequent task pool capacity configuration.

[0054] Step 202: Set the number of requests that each worker thread can handle simultaneously, thereby determining the total capacity of the task pool.

[0055] In some embodiments, the processing time for different types of IO requests varies significantly, so it is necessary to prioritize the collection of historical request data or obtain key indicators through stress testing; the performance of storage media (such as SSD, HDD) and IO bus directly determines the number of requests that a single thread can handle, so it is necessary to obtain key parameters through hardware performance testing tools; the value of the depth parameter needs to be determined comprehensively in combination with IO request characteristics, hardware processing capabilities and business latency requirements.

[0056] Through the above process, the depth parameter is precisely matched with the system hardware and business requirements. At the same time, the total capacity of the task pool is calculated based on a clear formula to ensure that the depth parameter avoids processing delays caused by overload of a single thread and maximizes thread utilization, ultimately achieving a precise match between the task pool capacity and the system's carrying capacity.

[0057] Step 203: 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 cache pool according to the request type and task pool status.

[0058] Step 204: Check the status of the task pool and cache pool at preset time intervals, and schedule the input and output requests in the cache pool to the task pool according to priority.

[0059] Step 205: 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 in order to limit the allocation of computing resources for input / output requests.

[0060] For a description of steps 203-205, please refer to the description of steps 102-104 in the above embodiment. This embodiment will not repeat these steps in detail.

[0061] Figure 3 A flowchart of an IO stream rate limiting control method provided for embodiments of this disclosure is further shown, including the following steps:

[0062] Step 301: Determine the number of concurrent worker threads based on the total number of computing cores of the system minus the number of cores occupied by the system's core functions.

[0063] In some embodiments, "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.

[0064] "Occupied cores" refers to modules that ensure the basic, uninterrupted operation of the distributed storage system. The CPU cores they occupy must be deducted from the total number of computing cores. Specifically, they include three categories: Metadata management module: the core process responsible for data index maintenance, directory structure updates, and data location mapping, which typically requires 2-4 cores to avoid impacting overall IO performance due to metadata processing delays; Data storage underlying driver module: the driver program that directly interacts with the storage medium (SSD / HDD), which requires 1-2 cores to ensure unblocked IO instruction transmission; Inter-node communication module: the communication process that implements data synchronization and consistency protocols between distributed nodes, which requires 1-2 cores to avoid data inconsistency caused by communication congestion.

[0065] Select the appropriate tool based on the operating system type, and ensure that the data collected is the "number of cores allocated to the distributed storage system", rather than the total number of physical cores.

[0066] In Linux systems, the `lscpu` command can be used in conjunction with CPU affinity configuration to query the total number of schedulable cores in the system. The specific command is `lscpu|grep"CPU(s):"|head-n1` (to get the total number of schedulable cores in the system). Then, you can use `cat / proc / [Distributed storage system main process PID] / status|grepCpus_allowed_list` to query the list of cores that the process can use. The number of cores in the list is the "total number of computing cores in the system".

[0067] In Windows systems, the CPU affinity mask of the main process of a distributed storage system can be obtained through the GetProcessAffinityMaskAPI function. After converting the mask to binary, the number of "1"s is counted, which is the total number of computing cores.

[0068] Use process monitoring tools to count the number of core processes exclusively used by core functionalities. In Linux systems, you can use `htop` (with "CPU binding display" enabled) or the `taskset` command; in Windows systems, you can use "Task Manager - Details - Right-click the process - Set affinity";

[0069] Based on the parameters collected above, the number of concurrent worker threads is calculated using a fixed formula. The formula is:

[0070] Number of concurrent worker threads = Total number of system computing cores - Number of cores used for core system functions

[0071] The core logic of this formula is to "use all idle CPU cores for concurrent processing of I / O requests, avoiding core idleness, and ensuring that they do not compete with core system functions for resources." Through the above process, "precise thread configuration based on the number of CPU cores" is achieved, ensuring that the number of concurrent worker threads maximizes the use of idle resources without affecting the stable operation of core system functions, providing a core basis for subsequent task pool capacity configuration.

[0072] Step 302: Set the number of requests that each worker thread can handle simultaneously, thereby determining the total capacity of the task pool.

[0073] For a description of step 302, please refer to the description of step 202 in the above embodiment. This embodiment will not repeat the details further.

[0074] 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 cache pool according to the request type and task pool status.

[0075] Step 304: Check the status of the task pool and 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.

[0076] Step 305: 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 in order to limit the allocation of computing resources for input / output requests.

[0077] For a description of steps 303-305, please refer to the description of steps 102-104 in the above embodiment. This embodiment will not repeat these steps in detail.

[0078] Figure 4 A flowchart of an IO stream rate limiting control method provided for embodiments of this disclosure is further shown, including the following steps:

[0079] Step 401: Configure the concurrent processing parameters and total capacity parameters of the task pool.

[0080] For a description of step 401, please refer to the description of step 101 in the above embodiment. This embodiment will not repeat the details further.

[0081] Step 402: Identify the request type of the newly arrived input / output requests, including: query type, general business type, management type and data recovery type, and allocate the input / output requests to the corresponding queues in the task pool or cache pool according to the request type and task pool status.

[0082] In some embodiments, after a new IO request enters the IO stack, the entry monitor acts as the unique identification node, and accurately determines the four types of requests by parsing the three-dimensional features of the request: "identification field, origin, and operation attribute".

[0083] Identification of query-type I / O requests: The core criterion is that the request purpose is "to obtain data status information," and specific identification characteristics include:

[0084] The request header carries key fields such as "status_query", "data_check", and "node_load", or the request parameters contain status query keywords such as "state", "health", and "capacity".

[0085] The request originated from a system monitoring module (such as a storage node status monitoring process or a user-end data query interface), rather than a business application or management backend.

[0086] No data read / write, creation / deletion, or other modification operations are performed; only the current state of the data is returned.

[0087] After identification, the type label "inquiry" is marked.

[0088] Identification of ordinary business-related I / O requests: The core criterion is the "read and write operation of the user's actual business" corresponding to the request. Specific identification features include:

[0089] Request the associated user business identifier, such as business application ID, user database read / write port, and user file path;

[0090] The operation type is data read / write (such as "read", "write", "append"), without metadata management or fault recovery markers;

[0091] The request originated from the user's business process, not from the system management tool.

[0092] After identification, the type label "normal" is assigned.

[0093] Identification of Management I / O Requests: The core criterion is that the request is for "data storage management, such as metadata and data creation, deletion, etc." Specific identification characteristics include:

[0094] The request includes metadata operation fields such as "meta_create", "meta_delete", "config_update", and "partition_init";

[0095] The request originated from the system management backend, and the object of the operation is metadata;

[0096] No user business data read / write is performed; only the management attributes of the storage system are modified.

[0097] After identification, the type label "manage" is marked.

[0098] Identification of data recovery I / O requests: The core criterion is that the request is used to "recover data from other copies when a data copy is lost due to a failure". Specific identification characteristics include:

[0099] The request should include fault recovery identifiers such as "replica_recover", "fault_repair", and "copy_restore", and the parameters should include the fault node ID and the storage address of the lost replica.

[0100] The request is triggered when the system detects a copy loss, and its origin is the system fault recovery module.

[0101] The operation type is "data replication", and there is no user-initiated operation.

[0102] After identification, the type label "recovery" is marked, and the associated fault node information is recorded.

[0103] After the entry monitor completes type identification, it packages the type label and request core information and synchronizes them to the allocator, providing basic data for subsequent allocation decisions. Moreover, the entire process does not require secondary parsing of the request content, ensuring identification efficiency.

[0104] After receiving the request information, the allocator obtains three core status information through real-time interaction with the ingress and egress monitors: the overall and remaining capacity of the task pool, the occupancy status of various types of sub-queues in the task pool, and the load balancing of worker threads. This ensures that the allocation decision does not deviate from the actual resource situation of the system, and the query logic relies entirely on the parameters configured in the initialization module.

[0105] The allocator combines "IO request type priority" and "task pool status" to perform allocation according to the principle of "prioritizing high-priority requests, putting similar requests into the corresponding queue, and caching when the pool is full".

[0106] Through the above process, a closed loop of "accurate identification of four types of IO requests - dynamic adaptation of task pool status - accurate allocation of queues" is achieved, which at the same time ensures that the requests are accurately matched with the queues of the task pool and the cache pool.

[0107] Step 403: Check the status of the task pool and cache pool at preset time intervals, and schedule the input and output requests in the cache pool to the task pool according to priority.

[0108] Step 404: 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 in order to limit the allocation of computing resources for input / output requests.

[0109] For a description of steps 402-404, please refer to the description of steps 103-104 in the above embodiment. This embodiment will not repeat these steps in detail.

[0110] Figure 5 A flowchart of an IO stream rate limiting control method provided for embodiments of this disclosure is further shown, including the following steps:

[0111] Step 501: Configure the concurrent processing parameters and total capacity parameters of the task pool.

[0112] 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 cache pool according to the request type and task pool status.

[0113] For a description of steps 501-502, please refer to the description of steps 101-102 in the above embodiment. This embodiment will not repeat the details further.

[0114] Step 503: Check the status of the task pool and cache pool at preset time intervals, and schedule the input and output requests in the cache pool to the task pool according to the priority order of query type, ordinary business type, management type and data recovery type.

[0115] In some embodiments, the allocator sets a fixed check cycle through a built-in timer module. The cycle setting needs to balance "timeliness of IO request response" and "system resource overhead," and its core basis is fully aligned with the hardware performance and business requirements of the distributed storage system. Every time the timer reaches the preset interval, it automatically sends a "check trigger signal" to the allocator. Upon receiving the signal, the allocator pauses non-urgent scheduling and initiates a joint check of the "task pool-cache pool" status to ensure the atomicity of the check and scheduling operations and avoid scheduling errors caused by status conflicts.

[0116] In this embodiment, the cache pool includes multiple linked lists, each corresponding to a request type, and manages requests in a first-in, first-out (FIFO) order. The cache pool serves as a temporary storage medium for requests when the task pool is full, and internally maintains four independent FIFO linked lists, each specifically corresponding to a type of I / O request. Each linked list in the cache pool strictly adheres to the FIFO rule to manage requests, ensuring fairness in the processing order of similar requests throughout the entire process of "request enqueueing - queue maintenance - request dequeueing," with no priority queue jumping.

[0117] In this embodiment of the disclosure, each linked list corresponds to a request type, including a query linked list, a normal business linked list, a management linked list, and a data recovery linked list.

[0118] The cache pool serves as a temporary storage medium for requests when the task pool is full. Internally, it maintains four independent FIFO linked lists, each corresponding to a specific type of IO request.

[0119] The inquiry list corresponds to query-type IO requests. When a new query-type request arrives and the task pool is full, or the task pool's inquiry sub-queue has reached its limit, the allocator temporarily stores the request in the inquiry list.

[0120] The normal linked list corresponds to ordinary business I / O requests. When a new ordinary business request arrives and the task pool is full, or the normal sub-queue of the task pool has reached its limit, the allocator temporarily stores the request in the normal linked list.

[0121] The manage list corresponds to managed IO requests. When a new managed request arrives and the task pool is full, or the task pool's manage sub-queue has reached its limit, the allocator temporarily stores the request in the manage list.

[0122] The recovery list corresponds to data recovery IO requests. When a new data recovery request arrives and the task pool is full, or the task pool's recovery sub-queue has reached its limit, the allocator temporarily stores the request in the manage list.

[0123] After the allocator triggers the check, it obtains two types of core status information through real-time data interaction with the ingress monitor, egress monitor, and buffer pool management module, providing accurate basis for subsequent scheduling decisions.

[0124] First, check if the task pool has enough space to accommodate cache pool requests. This can be done by checking the following dimensions:

[0125] Overall remaining capacity calculation: Based on the worker and depth parameters configured in the initialization module, the total capacity is calculated using the formula "Total task pool capacity = Number of workers × Depth". Then, the number of requests currently occupied by each worker thread is counted by the exit monitor, and the free space is calculated using the formula "Remaining capacity = Total capacity - Number of occupied requests". If the remaining capacity = 0, it is determined that the task pool has no free space, and the current scheduling is terminated.

[0126] Idle status of sub-queues: The task pool maintains sub-queues corresponding to the four types of requests (inquiry sub-queue, normal sub-queue, manage sub-queue, recovery sub-queue). The maximum capacity of each sub-queue = number of workers × depth. The allocator queries the current number of requests in each sub-queue to determine if there is a "sub-queue full" situation. If the target sub-queue is full, even if the task pool as a whole has remaining capacity, this type of request will not be scheduled temporarily to avoid sub-queue overload and processing delays.

[0127] Worker thread load balancing: The egress monitor provides real-time feedback on the current load of each worker thread, and the allocator filters out low-load threads. During subsequent scheduling, requests are prioritized to these threads to avoid IO lag caused by excessive concentration of requests on a particular thread.

[0128] After confirming that there is free space in the task pool, further query the request storage status of each linked list in the cache pool to clarify the number and priority of requests to be scheduled. The check includes:

[0129] Request count for each type of linked list: The cache pool maintains four FIFO linked lists that correspond one-to-one with the request type. The allocator obtains the current request count for each linked list through the cache pool management module and determines whether there is a "non-empty linked list".

[0130] Request waiting time statistics: Each linked list manages requests according to the "first-in, first-out" rule. The allocator records the timestamp of the earliest request entering each linked list. During subsequent scheduling, the request with the longest waiting time is processed first to ensure the fairness of processing similar requests.

[0131] Request resource matching and verification: For large requests, additionally check the I / O bus bandwidth utilization. If the bandwidth is insufficient, even if such requests are backed up in the cache pool, they will not be scheduled for the time being to avoid I / O bus congestion affecting the processing of other high-priority requests.

[0132] The allocator combines the "remaining capacity of the task pool" and the "request status of each linked list in the cache pool" to strictly follow the priority order of query, general business, management, and data recovery tasks when scheduling requests.

[0133] Through the above process, the "priority-ordered flow" of IO requests between the cache pool and the task pool is realized. It strictly follows the priority definition and FIFO rules, and ensures system stability through load balancing and resource verification, effectively solving the problem of "mutual interference of various IO requests" in the existing technology.

[0134] 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 in order to limit the allocation of computing resources for input / output requests.

[0135] For a description of step 504, please refer to the description of step 104 in the above embodiment. This embodiment will not repeat the details further.

[0136] Figure 6 A flowchart illustrating an I / O stream rate limiting control method provided for embodiments of this disclosure is shown in one step, including the following steps:

[0137] Step 601: Configure the concurrent processing parameters and total capacity parameters of the task pool.

[0138] Step 602: 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 cache pool according to the request type and task pool status.

[0139] Step 603: Check the status of the task pool and cache pool at preset time intervals, and schedule the input and output requests in the cache pool to the task pool according to priority.

[0140] For a description of steps 601-603, please refer to the description of steps 101-103 in the above embodiment. This embodiment will not repeat these steps in detail.

[0141] Step 604: When a high-priority input / output request arrives and the task pool is full, sort the input / output requests that have not yet started processing in the task pool according to their priority.

[0142] In some embodiments, sorting is triggered only when a new request is a query or a regular business request and the task pool is full; management and data recovery requests are considered low-priority requests and are not sorted even if the task pool is full when they arrive. If the task pool is full but all requests are "processing" and there are no "unprocessed" requests, capacity cannot be released through migration, and this step is terminated directly (to avoid meaningless sorting); subsequent filtering and sorting stages are only entered when "the number of unprocessed requests is ≥1".

[0143] To avoid mistakenly including "processed requests" in the sorting, it is necessary to filter out "sortable unprocessed requests" from all requests in the task pool using the status flags of the exit monitor. The filtering process is as follows:

[0144] The exit monitor assigns a "status tag" to each request in the task pool, and this tag updates in real time as the request processing progresses:

[0145] In progress: The worker thread has started IO read / write, data verification and other operations. The hardware resources associated with the request have been locked. Such requests cannot be filtered.

[0146] Unprocessed: The request has entered the task pool queue, but the worker thread has not yet called the processing interface and is only in a queued state. Such requests are "filterable, sortable, and transferable" objects.

[0147] The allocator categorizes and counts the filtered unprocessed requests by "request type," and divides them into four levels based on type priority. The principle of "higher priority levels appear first" is strictly followed between levels, and skipping levels is not allowed.

[0148] First level: Unprocessed query requests (INQUIRY), with the highest priority, appearing at the top of the sorted results;

[0149] Second level: Unprocessed requests in the normal business category, with the next highest priority, following the first level;

[0150] The third level: unprocessed requests managed by the MANAGE class, with lower priority, and located after the second level;

[0151] The fourth level: Unprocessed data recovery requests (RECOVERY), with the lowest priority, are located last in the overall sorting results.

[0152] Requests within the same priority level are strictly processed according to the "first-in, first-out (FIFO)" principle, sorted by "enqueue timestamp in ascending order" to ensure fairness in processing similar requests.

[0153] After sorting is complete, the allocator needs to generate a "sorting result list" and synchronize it to the exit monitor and the entrance monitor.

[0154] Through the above process, "precise filtering and orderly sorting of unprocessed requests" is achieved, which not only strictly follows the priority definition and state constraints, but also provides a clear and executable basis for the migration of subsequent low-priority requests, ensuring that the entire process of "high-priority requests preempting resources" is compliant and efficient.

[0155] Step 605: Move low-priority input / output requests to the cache pool according to the priority sorting results in order to limit the allocation of computing resources for input / output requests.

[0156] In some embodiments, the number of requests to be migrated needs to be dynamically determined based on the "space requirements of new high-priority input / output requests" and the "current free space gap in the task pool." This ensures that the new high-priority requests can be accommodated while avoiding meaningless migrations that would waste resources. The calculation logic relies entirely on the initialization module parameters and real-time status data. Based on the "sorting result list" generated in step 604, migration objects are selected according to the principle of "migration priority from high to low, and requests of the same type according to their enqueue order," ensuring that the selection logic is fair and meets the requirement of "low-priority requests being migrated out first." After the migration objects are determined, the requests need to be directed to the linked list corresponding to the cache pool, strictly following the FIFO rule of the cache pool to avoid confusion in request classification. After the migration is completed, the status of the task pool, cache pool, entry monitor, and exit monitor needs to be synchronized to ensure data consistency across modules.

[0157] By migrating low-priority requests in an "on-demand, targeted, and secure" manner, we can strictly follow the priority rules and module interaction logic while ensuring that the task pool can release enough space to accommodate high-priority requests. Ultimately, this achieves the technical effect of "limiting the resource consumption of low-priority requests and ensuring that high-priority requests are processed first".

[0158] Figure 7 A flowchart illustrating an I / O stream rate limiting control method provided for embodiments of this disclosure is shown in one step, including the following steps:

[0159] Step 701: Configure the concurrent processing parameters and total capacity parameters of the task pool.

[0160] Step 702: 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 cache pool according to the request type and task pool status.

[0161] For a description of steps 701-702, please refer to the description of steps 101-102 in the above embodiment. This embodiment will not repeat the details further.

[0162] Step 703: Record the load status of each worker thread in the task pool in real time through the ingress monitor and the egress monitor.

[0163] In some embodiments, the ingress monitor and the egress monitor work together through a "division of labor and data exchange" approach to jointly cover the load recording of the entire lifecycle of IO requests from "entry to processing to exit." The boundaries of their responsibilities and their interaction logic are completely consistent with the technical disclosure document's definition of the monitor's function.

[0164] In some embodiments, the ingress monitor increments the count of the corresponding worker thread when an input / output request enters the task pool, and the egress monitor decrements the count of the corresponding worker thread after the input / output request has been processed. Specifically, when the allocator assigns an input / output request to the sub-queue of the corresponding worker thread in the task pool, the ingress monitor immediately performs a count increment operation; when the worker thread completes the processing of the IO request and removes the request from the task pool, the egress monitor synchronously performs a count decrement operation.

[0165] This embodiment uses ingress and egress monitors to accurately and in real-time record the load status of each worker thread, providing data support for the dynamic scheduling of the allocator and ensuring efficient utilization and load balancing of task pool resources.

[0166] Step 704: Check the status of the task pool and cache pool at preset time intervals, and schedule the input and output requests in the cache pool to the task pool according to priority.

[0167] Step 705: 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 in order to limit the allocation of computing resources for input / output requests.

[0168] For a description of steps 704-705, please refer to the description of steps 103-104 in the above embodiment. This embodiment will not repeat these steps in detail.

[0169] Figure 8 A flowchart illustrating an I / O stream rate limiting control method provided for embodiments of this disclosure is shown in one step, including the following steps:

[0170] Step 801: Configure the concurrent processing parameters and total capacity parameters of the task pool.

[0171] Step 802: 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 cache pool according to the request type and task pool status.

[0172] Step 803: Check the status of the task pool and cache pool at preset time intervals, and schedule the input and output requests in the cache pool to the task pool according to priority.

[0173] Step 804: 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 in order to limit the allocation of computing resources for input / output requests.

[0174] For a description of steps 801-804, please refer to the description of steps 101-104 in the above embodiment. This embodiment will not repeat the details further.

[0175] Step 805: When there are idle worker threads in the task pool, according to the waiting time of each linked list in the cache pool, prioritize scheduling the input / output request with the longest waiting time into the task pool.

[0176] In some embodiments, the load status of all worker threads in the task pool can be obtained in real time through the exit monitor; the allocator calls the cache pool management module to obtain the "waiting time" of all unscheduled requests in each type of IO request chain (inquiry chain - query type, normal chain - normal business type, manage chain - management type, recovery chain - data recovery type); the allocator combines the "IO request priority rule" (query type > normal business type > management type > data recovery type) with the "waiting time" to filter candidate requests to be scheduled; the allocator performs scheduling allocation based on the available capacity of idle worker threads and the resource requirements of candidate requests; after scheduling is completed, the allocator triggers global state synchronization to ensure data consistency among modules. This step is triggered only when "there are idle worker threads in the task pool" and "there are pending requests in the cache pool", and can be combined with the allocator's "periodic check mechanism" to avoid system resource waste caused by real-time polling.

[0177] Figure 9 This is a schematic diagram of the structure of an IO flow rate limiting control device provided in an embodiment of this disclosure, as shown below. Figure 9 As shown, it includes: configuration module 901, allocation module 902, scheduling module 903, and transfer module 904.

[0178] Configuration module 901 is configured to configure the concurrent processing parameters and total capacity parameters of the task pool.

[0179] The allocation module 902 is configured to identify the request type of newly arriving input / output requests and allocate the input / output requests to the corresponding queues in the task pool or cache pool based on the request type and task pool status.

[0180] The scheduling module 903 is configured to check the status of the task pool and the cache pool at preset time intervals, and schedule input and output requests in the cache pool to the task pool according to priority.

[0181] The transfer module 904 is configured 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.

[0182] In some examples of this embodiment, the configuration module 901 is specifically configured to set the number of concurrent worker threads according to the available computing resources of the system; set the number of requests that each worker thread can process at the same time, thereby determining the total capacity of the task pool; and determine the number of concurrent worker threads based on the value obtained by subtracting the number of cores occupied by the system's core functions from the total number of computing cores of the system.

[0183] In some examples of this embodiment, the scheduling module 903 is specifically configured to schedule input and output requests in the cache pool to the task pool according to the priority order of query type, ordinary business type, management type, and data recovery type.

[0184] In some examples of this embodiment, the transfer module 904 is specifically configured to sort the input / output requests that have not yet started processing in the task pool according to their priority; and to move the low-priority input / output requests to the cache pool according to the priority sorting result.

[0185] It should be noted that other corresponding descriptions of the functional units involved in the IO flow rate limiting control device provided in this embodiment can be found in [reference needed]. Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 , Figure 6 , Figure 7 and Figure 8 The corresponding description in [the document] will not be repeated here.

[0186] Based on the above, Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 , Figure 6 , Figure 7 and Figure 8 The embodiment illustrates an I / O stream rate limiting control method. Correspondingly, this embodiment also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described method. Figure 1 , Figure 2 , Figure 3 , Figure 4 and Figure 7 This illustrates an I / O flow rate limiting control method.

[0187] Based on the above, 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.

[0188] 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.

[0189] Based on the above, Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 , Figure 6 , Figure 7 and Figure 8 An I / O stream rate limiting control method is shown, and Figure 9 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 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.

[0190] 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.

[0191] 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.

[0192] 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.

[0193] 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.

[0194] 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.

[0195] 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, the 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. 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; Set the number of requests that each worker thread can handle simultaneously, thereby determining the total capacity of the task pool; 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 core functions of the system from the total number of computing cores of the system; the total number of computing cores of the system 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. 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; Based on the priority sorting results, low-priority input / output requests are moved to the cache pool; The request types include: query type, general business type, management type, and data recovery type; The cache pool includes multiple linked lists, each corresponding to a request type, and requests are managed in a first-in-first-out order.

2. The IO stream rate limiting control method according to claim 1, 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.

3. The IO stream rate limiting control method according to claim 1, 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.

4. 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 monitor and the egress monitor.

5. The IO stream rate limiting control method according to claim 4, 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.

6. 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.

7. 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 high-priority input / output requests arrive and the task pool is full, so as to limit the allocation of computing resources for input / output requests. 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; Set the number of requests that each worker thread can handle simultaneously, thereby determining the total capacity of the task pool; 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 core functions of the system from the total number of computing cores of the system; the total number of computing cores of the system 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. 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; Based on the priority sorting results, low-priority input / output requests are moved to the cache pool; The request types include: query type, general business type, management type, and data recovery type; The cache pool includes multiple linked lists, each corresponding to a request type, and requests are managed in a first-in-first-out order.

8. 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-6.

9. 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-6.

10. 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-6.

Images