Coroutine scheduling method and device based on distributed storage

Abstract

The invention relates to a coroutine scheduling method and device based on distributed storage. The method comprises the following steps that: a scheduler receives foreground and background silt, and adds the foreground and background silt into a foreground task queue and a background task queue respectively; calculating the CPU occupancy rate of the foreground and background default before executing the default every time, and judging which queue of the default is executed next time according to the CPU occupancy rate, so that the foreground and background services reach dynamic balance; the foreground service and the background service are alternately executed according to quota dynamic adjustment, the foreground service is preferentially scheduled under the condition that the background service execution quota is guaranteed, and time delay is reduced; a quota combined priority scheduling strategy is used in foreground and background services, so that high-priority services are ensured to be executed preferentially, and meanwhile, low-priority services are prevented from being starved. According to the method, the priority of the service can be dynamically adjusted according to the cluster state, the function consumption cpu resource index replaces the silt number to serve as the standard of the scheduling strategy, the distributed storage service is dynamically balanced, and therefore the problem that a single coroutine scheduling strategy cannot meet fine control of the distributed storage service is solved.

Description

Technical Field

[0001] This application belongs to the technical field of coroutine scheduling, and particularly relates to a coroutine scheduling method based on distributed storage. More precisely, it is a variable-priority coroutine scheduling method, device, computer-readable storage medium, and electronic device based on quotas. Background Art

[0002] Due to its small switching overhead, no need for system calls, reduction of the switching between user mode and kernel mode, utilization of the io multiplexing technology to achieve non-blocking io operations, and improvement of io efficiency, coroutines are widely used in io-intensive business scenarios.

[0003] Taking Argobots as an example, the implementation principle of coroutines uses user-level threads (ULTs) to achieve parallel computing.

[0004] Argobots encapsulates computing tasks into work units. A work unit is the smallest execution unit, which can be a function, a code block, or a task. Each work unit is assigned to a ult (User-Level Threads) for execution. Each ult is an independent execution unit and can independently execute computing tasks.

[0005] Each scheduler in Argobots maintains multiple task queues, including ults that need to be executed. When a ult completes the current task, the scheduler fetches a new ult from the task queue for execution. Typical coroutine scheduling strategies include the FIFO queue (scheduling according to the order of task submission) and the priority queue (scheduling according to the priority of the task queue). The priorities of each business are relatively fixed, using the number of ults as a judgment indicator and scheduling according to fixed rules.

[0006] However, in io-intensive business scenarios, according to different business types, the consumed resources are also different. As shown in the common distributed storage business model Figure 1 According to different businesses, the cpu resources consumed by a single ult (i.e., the length of the time slice occupied by the ult) vary greatly. The consumption of ults for a single business may differ by dozens of times. At this time, scheduling using the number of ults as a judgment indicator will cause the io ults not to be fully scheduled, resulting in foreground io timeouts and thus causing failures.

[0007] In addition, according to different cluster states, the priorities are also different. Taking the garbage collection task as an example, when the cluster capacity is low, its priority is low; when the cluster capacity is high, its priority is high. At this time, if scheduling is performed with a fixed priority, it will cause failures such as the capacity being filled up and the storage cluster becoming unavailable.

[0008] As can be seen from the above, the existing scheduling strategies cannot well meet the business scheduling requirements of distributed storage clusters. Summary of the Invention

[0009] To address the above problems, this application proposes a new coroutine scheduling method based on distributed storage. This method can dynamically change the priority of services according to the cluster status, use the CPU resource consumption index of functions instead of the number of ults as the standard of the scheduling strategy, and dynamically balance distributed storage services, thus solving the problem that a single coroutine scheduling strategy cannot meet the refined control requirements of distributed storage services.

[0010] To achieve the above object, this application provides the following technical solutions:

[0011] The first aspect of this application provides a coroutine scheduling method based on distributed storage, and the method includes:

[0012] When the scheduler receives a foreground ult, it adds it to the foreground task queue; when it receives a background ult, it adds it to the background task queue;

[0013] Before each execution of an ult, calculate the CPU occupancy rates of the foreground and background ults, and based on the CPU occupancy rates of the foreground and background ults, determine which queue's ult to execute next to achieve dynamic balance between the foreground and background services;

[0014] Dynamically adjust according to the quota to make the foreground and background services execute alternately, and give priority to scheduling the foreground service while ensuring the execution quota of the background service to reduce latency;

[0015] Use a quota combined with a priority scheduling strategy within the foreground and background services to ensure that high-priority services are executed first while preventing low-priority services from starving.

[0016] Optionally, in the method of this application, the foreground services include but are not limited to: replicas, EC, ROW; the background services include but are not limited to: compression, garbage collection, reconstruction, checkSum, snap, scrub.

[0017] Optionally, in the method of this application, the step of calculating the CPU occupancy rates of the foreground and background ults before each execution of an ult, and based on the CPU occupancy rates of the foreground and background ults, determining which queue's ult to execute next to achieve dynamic balance between the foreground and background services; includes:

[0018] Calculate the CPU occupancy rates of the foreground and background ults before each execution of an ult;

[0019] Judge whether the CPU occupancy rate of the foreground ult is less than the preset occupancy rate threshold. If so, execute the foreground ult and increase the execution time of the foreground ult; otherwise, execute the background ult and increase the execution time of the background ult;

[0020] Judge whether it is necessary to change the occupancy rate threshold according to the cluster capacity. If so, change the occupancy rate threshold and then return to execute the next ult task.

[0021] Optionally, the method of this application further includes:

[0022] Add a timestamp before and after each ult execution to obtain the time t when the ult occupies the time slice;

[0023] Calculate the CPU time occupied by the foreground ult as In the formula, T f represents the total time slice occupied by the foreground ult, and t i represents the time slice occupied by one ult, represents the sum of n foreground ult time slices; the CPU time occupied by the background ult is In the formula, T b represents the total time slice occupied by the background ult, and t j represents the time slice occupied by one ult, represents the sum of n background ult time slices; if then it means that the foreground service has an executable quota. At this time, execute the foreground ult, otherwise execute the background ult;

[0024] In the above formula, frontend_pct is the CPU occupancy rate of the foreground ult.

[0025] Optionally, the method of this application further includes: adding the following quota-based priority queues in the foreground ult and the background ult respectively:

[0026] Foreground service ult priority queue, f 1 , f 2 , f 3 …f n , whose priority is f 1 > f 2 > f 3 >…> f n , and the executable time quotas are pct f1 , pct f2 , pct f3 …pct fn , satisfying In the formula, fi represents the i-th priority queue of the foreground, and pct fi represents the time slice quota occupied by the i-th priority queue of the foreground, expressed as a percentage, It is indicated that there are n priority queues in the foreground, and the sum of the time - slice quotas of all foreground priority queues is 100%, which is used to allocate the foreground ult quota frontend_pct;

[0027] The background service ult priority queue, b 1 , b 2 , b 3 …b n , whose priority is b 1 >b 2 >b 3 >…>b n , and the executable time quotas are pct b1 , pct b2 , pct b3 …pct bn Satisfy In the formula, bi represents the i - th priority queue in the background, and pct bi represents the time - slice quota occupied by the i - th priority queue in the background, expressed as a percentage, It is indicated that there are n priority queues in the background, and the sum of the time - slice quotas of all background priority queues is 100%, which is used to allocate the background ult quota backend_pct.

[0028] Optionally, in the method of this application, the using quota combined with the priority scheduling strategy within the foreground and background services includes:

[0029] When executing the foreground ult, poll its priority queues in order from high to low according to the priority, and take out the ult queue that has a time quota and the highest priority;

[0030] Pop the ult from the head of the f i queue and execute it;

[0031] After satisfying the termination condition, execute f i+1 or execute the background service.

[0032] Optionally, in the method of this application, the termination condition includes:

[0033] (1) The foreground service quota is used up;

[0034] (2) The pct fi quota is used up;

[0035] (3) The f i queue is empty and there is no ult to execute;

[0036] (4) f 1 , f 2 , f 3…f n All are empty and there is no ult that can be executed.

[0037] Optionally, the method of the present application further includes: dynamically adjusting the cpu occupancy ratio of the foreground and background service ults and the priorities of the foreground and background services according to the cluster capacity;

[0038] When the cluster capacity is low, the foreground service has a high priority to ensure the stability of the foreground service;

[0039] When the cluster capacity is high, the background service has a high priority to ensure the data recovery rate;

[0040] Gradually increase the proportion of the background service as the cluster capacity increases. When the cluster capacity increases to the maximum value, the proportion of the foreground service is 0%, the foreground service is suspended, the proportion of the background service is 100%, and the background service is fully executed to reduce the cluster capacity.

[0041] The second aspect of the present application provides a coroutine scheduling device based on distributed storage, and the device includes:

[0042] Task receiving module: used to receive the foreground ult and add it to the foreground task queue; receive the background ult and add it to the background task queue;

[0043] Task scheduling module: used to calculate the cpu occupancy rate of the foreground and background ults before each execution of the ult, and determine which queue's ult to execute next according to the cpu occupancy rate of the foreground and background ults, so as to achieve dynamic balance between the foreground and background services;

[0044] Quota adjustment module: used to dynamically adjust according to the quota to make the foreground and background services execute alternately, and give priority to scheduling the foreground service while ensuring the execution quota of the background service to reduce latency;

[0045] Task execution module: used to use the quota combined with the priority scheduling strategy within the foreground and background services to ensure that high-priority services are executed first while preventing low-priority services from starving.

[0046] When the device is running, it implements the steps of the foregoing coroutine scheduling method based on distributed storage.

[0047] The third aspect of the present application provides an electronic device, including: a memory and a processor;

[0048] Memory: used to store computer programs;

[0049] Processor: used to execute the computer program to implement the steps of the foregoing coroutine scheduling method based on distributed storage.

[0050] The fourth aspect of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the foregoing coroutine scheduling method based on distributed storage are implemented.

[0051] In summary, the present application proposes a new coroutine scheduling method based on distributed storage. This method can dynamically adjust the priority of services according to the cluster status, use the function's CPU resource consumption index instead of the number of ults as the standard for the scheduling strategy, and dynamically balance the distributed storage services, thereby solving the problem that a single coroutine scheduling strategy cannot meet the refined control requirements of distributed storage services.

[0052] Other features and advantages of the present application will be described in the subsequent description, or can be understood by implementing the present application. The objectives and other advantages of the present application can be achieved and obtained by the technologies pointed out in the description, claims, and drawings. Brief Description of the Drawings

[0053] In order to more clearly illustrate the technical background and the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required for the description of the present application. Obviously, the drawings in the following description are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative efforts.

[0054] Figure 1 It is a schematic diagram of a common distributed storage service model.

[0055] Figure 2 It is the overall implementation flowchart of the coroutine scheduling method based on distributed storage of the present application.

[0056] Figure 3 It is the flowchart of the front-end and back-end service execution in the method of the embodiment of the present application.

[0057] Figure 4 It is a schematic diagram of the front-end and back-end service internal quota combined with the priority scheduling strategy in the method of the embodiment of the present application.

[0058] Figure 5 It is the composition structure diagram of the coroutine scheduling device based on distributed storage of the present application.

[0059] Figure 6 It is the schematic diagram of the structure of the electronic device provided by the embodiment of the present application. Detailed Embodiments

[0060] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the following will clearly and completely describe the technical solutions in the embodiments of this application with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part rather than all of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without creative efforts belong to the scope of protection of this application.

[0061] As used herein, the term "including" and its variations are open-ended, that is, "including but not limited to"; the term "based on" means "at least partially based on"; the term "an embodiment" means "at least one embodiment".

[0062] It should be noted that the modifications of "one" and "multiple" mentioned in this application are illustrative rather than restrictive. Those skilled in the art should understand that unless otherwise clearly specified in the context, it should be understood as "one or more".

[0063] Figure 2 The overall implementation process of the coroutine scheduling method based on distributed storage provided by this application is shown as follows, including the following steps:

[0064] When the scheduler receives the foreground ult, it adds it to the foreground task queue; when it receives the background ult, it adds it to the background task queue.

[0065] Before each execution of the ult, calculate the CPU occupancy rate of the foreground and background ults. According to the CPU occupancy rates of the foreground and background ults, determine which queue's ult to execute next to achieve dynamic balance between the foreground and background services.

[0066] Dynamically adjust according to the quota to make the foreground and background services execute alternately. While ensuring the execution quota of the background service, give priority to scheduling the foreground service to reduce latency.

[0067] Use the quota combined with the priority scheduling strategy within the foreground and background services to ensure that high-priority services are executed first while preventing low-priority services from starving.

[0068] Specifically, this embodiment provides a coroutine scheduling method based on distributed storage. Taking the foreground service and the background service as examples, it includes:

[0069] When the scheduler receives the foreground ult, it adds it to the foreground task queue; when the scheduler receives the background ult, it adds it to the background task queue.

[0070] Such as Figure 3As shown, based on the CPU utilization ratio of the executed ult, determine which queue's ult to execute next. Calculate the CPU utilization rates of the foreground and background ults before each ult execution to achieve dynamic balance between foreground and background services:

[0071] That is, if the CPU utilization ratio of the foreground ult is frontend_pct, then the CPU utilization ratio of the background ult is backend_pct = (100 - frontend_pct)%;

[0072] Optionally, add timestamps before and after each ult execution to obtain the time t that the ult occupies the time slice;

[0073] Calculate the CPU time occupied by the foreground ult as (where T f represents the total time slice occupied by the foreground ult, t i represents the time slice occupied by one ult, represents the sum of n foreground ult time slices), and the CPU time occupied by the background ult is (where T b represents the total time slice occupied by the background ult, t j represents the time slice occupied by one ult, represents the sum of n background ult time slices), if then it means there is an executable quota for the foreground service, execute the foreground ult, otherwise execute the background ult;

[0074] Optionally, if the number of ults in the task queue to be executed is determined to be 0, then the dynamic adjustment based on the quota ends this time, that is, one circle ends. At this time, execute the ults in other queues and clear the ult execution time record, and start recalculating.

[0075] Optionally, the foreground ult and the background ult can add a priority scheduling queue based on the quota;

[0076] That is, there is a foreground service ult priority queue, f 1 , f 2 , f 3 …f n , and its priority is f 1 > f 2 > f 3 >…> f n , and the executable time slice quota is pct f1 , pct f2 , pct f3 …pct fn , satisfying (where fi represents the i-th priority queue of the foreground, pctfi Indicates the time slice quota occupied by the i-th priority queue in the foreground, expressed as a percentage. Indicates that there are n priority queues in the foreground, and the sum of the time slice quotas of all foreground priority queues is 100% (used to allocate the foreground ult quota frontend_pct).

[0077] Background service ult priority queue, b 1 , b 2 , b 3 … b n , whose priority is b 1 > b 2 > b 3 > … > b n , and the executable time slice quota is pct b1 , pct b2 , pct b3 … pct bn Satisfy (where bi represents the i-th priority queue in the background, and pct bi Indicates the time slice quota occupied by the i-th priority queue in the background, expressed as a percentage. Indicates that there are n priority queues in the background, and the sum of the time slice quotas of all background priority queues is 100% (used to allocate the background ult quota backend_pct).

[0078] For example Figure 4 As shown, taking the foreground service as an example, when selecting the ult to be executed, poll its priority queues in order from high to low, and take out the ult queue with the time quota and the highest priority.

[0079] The calculation method is as follows: Let cnt1, cnt2, cnt3, … cntn be the number of currently executed ults in the priority queue f 1 , f 2 , f 3 … f n .

[0080] That is

[0081] Then pop the ult from the f i queue by head pop (an operation to remove and return an element from the head of the data structure) and execute it.

[0082] Its termination conditions are:

[0083] 1. The foreground service quota is used up.

[0084] 2. The pct fi quota is used up.

[0085] 3.f i The queue is empty and there is no ult to execute;

[0086] 4.f 1 , f 2 , f 3 …f n All are empty and there is no ult to execute.

[0087] After meeting the termination condition, the next operations are:

[0088] 1. Execute background services;

[0089] 2. Execute f i+1 .

[0090] Optionally, dynamically change the proportion of foreground and background services occupied according to the cluster capacity, and adjust the priorities of foreground and background services;

[0091] When the cluster capacity is lower than v1, the proportion of foreground services is frontend1_pct%, and the proportion of background services is (100 - frontend1_pct)%;

[0092] When the cluster capacity increases to v2, the proportion of foreground services is frontend2_pct%, and the proportion of background services is (100 - frontend2_pct)%;

[0093] When the cluster capacity increases to v3, the proportion of foreground services is frontend3_pct%, and the proportion of background services is (100 - frontend3_pct)%;

[0094] …

[0095] When the cluster capacity increases to max, the proportion of foreground services is 0%, the foreground services are suspended, the proportion of background services is 100%, and the background services are fully executed to reduce the cluster capacity.

[0096] Among them, the capacity and service proportion are adjusted according to the specific business;

[0097] Gradually increase the proportion of background services as the cluster capacity increases, speed up data recovery, and at the same time limit the iops of foreground services through scheduling to prevent the storage pool from being filled up and causing failures;

[0098] If the capacity is low, the foreground io priority is high to ensure the stability of foreground io;

[0099] If the capacity is high, the background io priority is high to ensure the data recovery rate;

[0100] In the above embodiments, the front-end and back-end services can be refined, and a customized CPU ratio can be given to each front-end and back-end service to avoid a situation where a certain service cannot be scheduled for a long time due to queuing.

[0101] Moreover, according to the characteristics of the storage service, the more garbage (recyclable data) there is in the cluster, the more data the back-end service can recycle per unit time, that is, the higher the back-end recycling efficiency.

[0102] To better understand the technical solution of the present application, the following embodiments of scenarios are further described.

[0103] Taking the simple storage service as an example:

[0104] The front-end service types are divided into two queues: read and write.

[0105] Assuming ideal conditions, the respective CPU time slices are read: 5us, write: 20us (in actual situations, the time slice occupied by each ult is different each time. For the convenience of calculation and understanding, fixed values are taken here).

[0106] Its priority is read > write.

[0107] pct r = 30%, pct w = 70%.

[0108] The back-end service types are aggregation compression (agg), garbage collection (gc), and reconstruction (rebuild, abbreviated as re).

[0109] Assuming ideal conditions, the respective CPU time slices are agg: 50us, gc: 100us, rebuild: 200us.

[0110] Its priority is agg > gc > rebuild.

[0111] pct agg = 20%, pct gc = 30%, pct re = 50%.

[0112] Let frontend_pct = 60%,

[0113] backend_pct = (100 - frontend_pct)% = 40%.

[0114] According to the above settings:

[0115] When Circle starts,

[0116] Select the first op:

[0117] Front Desk:

[0118] Backstage:

[0119] Where t represents the time slice occupied by each module, and the subscript is the module name, represents the total time slice occupied by the n ults that have been executed by this module;

[0120] Among them, all the time slices of the front desk are

[0121] All the time slices of the backstage are

[0122] Then the proportion of the front desk at this time (When calculating, take 0 when the denominator is defined as 0);

[0123] Execute the front desk op according to the priority;

[0124] The highest priority is read:

[0125] Execute read

[0126] Judge the next ult:

[0127] Front Desk:

[0128] Backstage:

[0129] Among them, all the time slices of the front desk are

[0130] All the time slices of the backstage are

[0131] Then the proportion of the front desk at this time

[0132] Execute the backstage op according to the priority;

[0133] The highest priority is read: Execute Judge the next ult:

[0134] Front Desk: Backstage: Among them, all the time slices of the front desk are All the time slices of the backstage are Then the proportion of the front desk at this time Execute the front desk op according to the priority;

[0135] The highest priority is read: Execute write Judge the next ult:

[0136] Foreground: Background: Among them, all time slices of the foreground are All time slices of the background are Then the foreground occupancy ratio at this time Execute foreground ops according to priority;

[0137] The highest priority is read: Execute read And so on, continue to execute 2 read ops and 2 write ops...

[0138] Judge the next ult:

[0139] Foreground: Background:

[0140] Among them, all time slices of the foreground are

[0141] All time slices of the background are

[0142] Then the foreground occupancy ratio at this time

[0143] Execute background ops according to priority;

[0144] The highest priority is agg:

[0145] The next priority is gc:

[0146] Execute

[0147] And so on, continue to execute 10 read ops and 6 write ops...

[0148] Judge the next ult:

[0149] Foreground:

[0150] Background:

[0151] Among them, all time slices of the foreground are

[0152] All time slices of the background are

[0153] Then the foreground occupancy ratio at this time

[0154] Execute background operations in order of priority;

[0155] The highest priority is agg:

[0156] The next priority is gc:

[0157] Execute

[0158] And so on until the foreground ult queue is empty (the executable ults have been executed).

[0159] During the execution, if the capacity increase reaches the threshold, the frontend_pct, the time slice quotas, and the priorities of each module can be flexibly changed according to the specific situation, and all the recorded time slices are cleared. For example:

[0160] When the capacity reaches v2, the settings are changed to:

[0161] frontend_pct = 40%,

[0162] The foreground priority is read > write,

[0163] pct r = 30%, pct w = 70%,

[0164] The background priority is gc > agg > rebuild,

[0165] pct agg = 10%, pct gc = 50%, pct re = 40%;

[0166] Foreground:

[0167] Background:

[0168] Start a new Circle.

[0169] Figure 5 The following shows a coroutine scheduling device based on distributed storage proposed by this application, including:

[0170] Task receiving module: used to receive foreground ults, add them to the foreground task queue; receive background ults, add them to the background task queue;

[0171] Task scheduling module: It is used to calculate the CPU occupancy rates of foreground and background ults before each execution of ult, and determine which queue's ult to execute next based on the CPU occupancy rates of foreground and background ults, so as to achieve dynamic balance between foreground and background services;

[0172] Quota adjustment module: It is used to dynamically adjust according to the quota to make the foreground and background services execute alternately, and give priority to scheduling the foreground service while ensuring the execution quota of the background service, so as to reduce the latency;

[0173] Task execution module: It is used to use the quota combined with the priority scheduling strategy within the foreground and background services to ensure that high-priority services are executed first while preventing low-priority services from starving.

[0174] When the above device runs, it implements the steps of the coroutine scheduling method based on distributed storage disclosed in this application.

[0175] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code that contains one or more executable instructions for implementing the specified logical function. It should also be noted that each block in the block diagram and / or flowchart, as well as the combination of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0176] As Figure 6 shown, an embodiment of this application also discloses an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing computer programs executable by the processor, and a communication bus 340. Among them, the processor 310, the communication interface 320, and the memory 330 complete communication with each other through the communication bus 340. The processor 310 runs the executable computer program to implement the steps of the above-mentioned coroutine scheduling method based on distributed storage.

[0177] It can be understood that in addition to the memory and the processor, this electronic device may also include an input device such as a keyboard, an output device such as a display, and other communication modules. The input device, the output device, and other communication modules communicate with the processor through an I / O interface (i.e., an input / output interface).

[0178] Computer program code for performing the operations of this application can be written in one or more programming languages or combinations thereof. The above-mentioned programming languages include, but are not limited to, object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any kind of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (for example, by using an Internet service provider to connect through the Internet).

[0179] Furthermore, this application also discloses a computer-readable storage medium. When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device can execute each step of the coroutine scheduling method based on distributed storage disclosed in this application.

[0180] In the context of this application, a computer-readable storage medium can be a tangible medium. More specific examples would include a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0181] In particular, according to an embodiment of this application, the process described in the flowchart can be implemented as a computer software program. For example, an embodiment of this application includes a computer program product that includes a computer program carried on a non-transitory computer-readable medium. The computer program contains program code for performing the coroutine scheduling method based on distributed storage disclosed in this application. When the computer program is executed by a processing device, the above-mentioned functions defined in the method of the embodiment of this application are executed.

[0182] Although several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of this application. The above description is only a preferred embodiment of this application and an explanation of the technical principles applied. Those skilled in the art should understand that the scope of disclosure involved in this application is not limited to the technical solution formed by the specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosure concept.

[0183] Those skilled in the art should also understand that they can still modify the technical solutions described in the foregoing embodiments, or equivalently replace some of the technical features therein; and such modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A coroutine scheduling method based on distributed storage, characterized in that: The method comprises: The scheduler receives the foreground ult and adds it to the foreground task queue; it receives the background ult and adds it to the background task queue; Before executing each ult, the CPU occupancy rate of the front-end and back-end ults is calculated. According to the CPU occupancy rate of the front-end and back-end ults, the ult of which queue will be executed next is determined, so that the front-end and back-end services can achieve a dynamic balance. Dynamically adjust the quota to allow foreground and backend services to be executed alternately, giving priority to foreground services while ensuring the backend service execution quota, thus reducing latency. Quotas are used in combination with priority scheduling strategies within the front-end and back-end businesses to ensure that high-priority businesses are executed first while preventing low-priority businesses from starving.

2. The method according to claim 1, characterized in that The foreground services include: copy, EC, ROW; the background services include: compression, garbage collection, reconstruction, checkSum, snap, scrub.

3. The method according to claim 1, characterized in that Before executing each ult, the CPU occupancy rates of the front-end and back-end ults are calculated, and according to the CPU occupancy rates of the front-end and back-end ults, the ult of which queue is to be executed next is determined, so that the front-end and back-end services are dynamically balanced; include: Calculate the CPU usage of the front and back end ults before executing each ult; Determine whether the CPU occupancy rate of the foreground ult is less than the preset occupancy rate threshold. If so, execute the foreground ult, and the execution time of the foreground ult is increased; if not, execute the background ult, and the execution time of the background ult is increased; Determine whether the occupancy threshold needs to be changed based on the cluster capacity. If so, change the occupancy threshold and then return to execute the next ult task.

4. The method according to claim 3, characterized in that The method also includes: Add a timestamp before and after each ult is executed to get the time t that the ult occupies in the time slice; Calculate the CPU time occupied by the foreground ult Where, T f Indicates the total time slice occupied by the foreground ult, t i Indicates the time slice occupied by an ult. It means the sum of n foreground ult time slices; the background ult occupies the CPU time Where, T b Indicates the total time slice occupied by the background ult, t j Indicates the time slice occupied by an ult. It means the sum of n background ult time slices; if It means that the foreground business has an executable quota, and the foreground ult is executed at this time, otherwise the background ult is executed; In the above formula, frontend_pct is the CPU occupancy rate of the foreground ult.

5. The method according to claim 1, characterized in that The method further includes: adding the following quota-based priority queues in the foreground ult and the background ult respectively: Foreground service ult priority queue, f1, f2, f3…f n , its priority is f1>f2>f3>…>f n , the executable time quotas are pct f1 , pct f2 , pct f3 …pct fn ,satisfy In the formula, fi represents the foreground i-th priority queue, pct fi Indicates the time slice quota occupied by the foreground i-th priority queue, expressed as a percentage. Indicates that there are n priority queues in the foreground, and the sum of the time slice quotas of all foreground priority queues is 100%, which is used to allocate the foreground ult quota frontend_pct; Background business ult priority queue, b1, b2, b3...b n , its priority is b1>b2>b3>…>b n , the executable time quotas are pct b1 , pct b2 , pct b3 …pct bn satisfy Where bi represents the background i-th priority queue, pct bi Indicates the time slice quota occupied by the background i-th priority queue, expressed as a percentage. It means there are n priority queues in the background, and the time slice quotas of all background priority queues add up to 100%, which is used to allocate the background ult quota backend_pct.

6. The method according to claim 5, characterized in that The quota combined with the priority scheduling strategy used within the front-end and back-end services includes: When executing the foreground ult, poll its priority queues in order from high to low priority, and take out the ult queue with the time quota and the highest priority; The ult from f i The head of the queue is popped out and executed; After the termination condition is met, execute f i+1 or perform back-office operations.

7. The method according to claim 6, characterized in that The termination conditions include: (1) The front desk service quota is fully used; (2)pct fi The quota is full; (3)f i The queue is empty and no ult can be executed; (4)f1,f2,f3…f n All are empty, no ult can be executed.

8. The method according to claim 1, characterized in that: The method further includes: dynamically adjusting the CPU occupancy ratio of the front-end and back-end services ult and the priority of the front-end and back-end services according to the cluster capacity; If the cluster capacity is low, the foreground business has a high priority to ensure the stability of the foreground business; If the cluster capacity is high, the background business priority is high to ensure the data recovery rate; As the cluster capacity increases, the proportion of backend business gradually increases. When the cluster capacity increases to the maximum value, the proportion of foreground business is 0%, and the foreground business is suspended. The proportion of backend business is 100%, and the backend business is fully executed to reduce the cluster capacity.

9. A coroutine scheduling device based on distributed storage, characterized in that: The device comprises: Task receiving module: used to receive the foreground ult and add it to the foreground task queue; receive the background ult and add it to the background task queue; Task scheduling module: used to calculate the CPU occupancy rate of the front-end and back-end ults before each ult is executed. According to the CPU occupancy rate of the front-end and back-end ults, it determines which queue's ult will be executed next, so that the front-end and back-end services can achieve a dynamic balance. Quota adjustment module: used to dynamically adjust the quota so that the front-end and back-end services are executed alternately. While ensuring the back-end service execution quota, the front-end service is scheduled first to reduce latency. Task execution module: used to use quotas and priority scheduling strategies within the front-end and back-end businesses to ensure that high-priority businesses are executed first while preventing low-priority businesses from starving.

10. An electronic device, characterized in that: include: Memory and processor; Memory: used to store computer programs; Processor: used to execute the computer program to implement the steps of the distributed storage-based coroutine scheduling method as described in any one of claims 1-8.

Images