Dynamic multi-queue scheduling method and device, equipment and medium
Through the dynamic multi-queue scheduling method, the problem that high-priority tasks cannot be called in time in large models is solved, and the full utilization of resources and efficient execution of tasks is achieved.
Patent Information
- Application Number
- CN202411737653.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-28
- Publication Date
- 2025-02-28
AI Technical Summary
When large models allocate resources, low-priority tasks occupy resources for a long time, resulting in high-priority tasks being unable to be called in time.
The dynamic multi-queue scheduling method is adopted to receive tasks, confirm the task type, distribute it to different queues, confirm the initial traffic weight and allocate the traffic weight, and finally call the target task in the queue based on the traffic weight.
It realizes full utilization of large-scale model resources, ensures that high-priority tasks can be called in time, and are universal and can be adapted to other scenarios.
Smart Images
Figure CN119536953A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of network resource management, and in particular to a dynamic multi-queue scheduling method, device, equipment and medium. Background Art
[0002] Big model technology is increasingly used in all business lines of the company. While big models empower businesses, they also cause resource allocation problems. Because big models consume a lot of GPU resources, if tasks for big models are requested in the existing queue in a first-in-first-out manner, low-priority tasks will always occupy resources and be called and executed first, while high-priority tasks will not be called. Summary of the invention
[0003] The present invention provides a dynamic multi-queue scheduling method, device, computer equipment and medium to solve the technical problem that high-priority tasks in a large model cannot be preferentially called.
[0004] In a first aspect, a dynamic multi-queue scheduling method is provided, comprising:
[0005] Receive the current task and confirm the task type;
[0006] Distribute current tasks to different queues according to task types;
[0007] Confirm the initial traffic weight of each queue and allocate the traffic weight of each queue according to the initial traffic weight;
[0008] According to the traffic weight, the target task of each queue is called for execution.
[0009] In a second aspect, a dynamic multi-queue scheduling device is provided, comprising:
[0010] The receiving module is used to receive the current task and confirm the task type;
[0011] The distribution module is used to distribute the current task to different queues according to the task type;
[0012] An allocation module, used to confirm the initial traffic weight of each queue and allocate the traffic weight of each queue according to the initial traffic weight;
[0013] The calling module is used to call the target task of each queue for execution according to the traffic weight.
[0014] In a third aspect, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned dynamic multi-queue scheduling method when executing the computer program.
[0015] In a fourth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned dynamic multi-queue scheduling method are implemented.
[0016] In the scheme implemented by the above-mentioned dynamic multi-queue scheduling method, device, computer equipment and storage medium, the task type can be confirmed by receiving the current task; the current task can be distributed to different queues according to the task type; the initial traffic weight of each queue can be confirmed, and the traffic weight of each queue can be allocated according to the initial traffic weight; according to the traffic weight, the target task of each queue can be called for execution.
[0017] It realizes full utilization of large model resources and is also versatile and can be adapted to other scenarios, such as AI outbound call matching outbound call resources, matching between Finebi and Impala resources, etc. By setting the priority of the queue to sort and access it, the present invention can be effectively used to solve practical problems. At the same time, by customizing the priority comparison logic, we can further expand its application scope to meet specific needs; the present invention also introduces a rule engine, and the task rules are separated from the system code to achieve centralized management of task rules; the task rules can be expanded and maintained at any time without restarting the service; the task rules can be dynamically modified to quickly respond to changes in requirements; the rule engine is relatively independent and only cares about the task rules, so that task analysts can also participate in editing and maintaining the system's task rules; the cost and risk of hard-coded task rules are reduced; the rule editing tool provided by the rule engine makes the implementation of complex task rules simple. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.
[0019] Figure 1 It is a schematic diagram of an application environment of a dynamic multi-queue scheduling method in one embodiment of the present invention;
[0020] Figure 2 is a flow chart of a dynamic multi-queue scheduling method according to an embodiment of the present invention;
[0021] Figure 3 is a structural diagram of a dynamic multi-queue scheduling device in one embodiment of the present invention;
[0022] Figure 4 is a schematic diagram of a structure of a computer device in one embodiment of the present invention;
[0023] Figure 5 It is another structural schematic diagram of a computer device in one embodiment of the present invention. DETAILED DESCRIPTION
[0024] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0025] The dynamic multi-queue scheduling method provided by the embodiment of the present invention can be applied in the following aspects: Figure 1 In the application environment, the client confirms the task type by receiving the current task; distributes the current task to different queues according to the task type; confirms the initial traffic weight of each queue, and allocates the traffic weight of each queue according to the initial traffic weight; calls the target task of each queue for execution according to the traffic weight. The large model resources are fully utilized, and it is also versatile and can be adapted to other scenarios, such as AI outbound call matching outbound call resources, matching between Finebi and Impala resources, etc. By setting the priority of the queue to sort and access it, the present invention can be effectively used to solve practical problems. At the same time, by customizing the priority comparison logic, we can further expand its application scope to meet specific needs; the present invention also introduces a rule engine, and the task rules are separated from the system code to realize the centralized management of task rules; the task rules can be expanded and maintained at any time without restarting the service; the task rules can be dynamically modified to quickly respond to changes in demand; the rule engine is relatively independent and only cares about the task rules, so that task analysts can also participate in editing and maintaining the system's task rules; the cost and risk of hard-coded task rules are reduced; the rule editing tool provided by the rule engine makes the implementation of complex task rules simple.
[0026] The present invention is described in detail below through specific embodiments.
[0027] See also Figure 2 As shown, Figure 2 A flow chart of a dynamic multi-queue scheduling method provided by an embodiment of the present invention includes the following steps:
[0028] S10: Receive the current task and confirm the task type;
[0029] Specifically, a target task is received, and the current task is compared with a preset condition range; if the current task is within the preset condition range, the task type of the current task is high priority; if the current task is outside the preset condition range, the task type of the current task is low priority. Therefore, in this embodiment, tasks can be divided into high priority tasks and low priority tasks. The preset condition range is set according to the calling requirements.
[0030] Of course, in another embodiment, the task type can also be a long task or a short task. If the queue length of the current task is within the preset length range, the task type of the current task is a short task; if the queue length of the current task is higher than the preset length range, the task type of the current task is a long task.
[0031] Of course, in another embodiment, the task type can also be a high-priority long task, a high-priority short task, a low-priority long task and a low-priority short task. If the queue length of the current task is within the preset length range and the preset condition range, the task type of the current task is a high-priority short task; if the queue length of the current task is within the preset length range and outside the preset condition range, the task type of the current task is a low-priority short task; if the queue length of the current task is higher than the preset length range and within the preset condition range, the task type of the current task is a high-priority long task; if the queue length of the current task is higher than the preset length range and outside the preset condition range, the task type of the current task is a low-priority long task.
[0032] S20: Distribute the current task to different queues according to the task type;
[0033] In this embodiment, the task types are high priority tasks and low priority tasks, and queues are set accordingly. The high priority task queue is set according to the high priority task, and the low priority task queue is set according to the low priority task. Therefore, the queue type includes a high priority task queue and a low priority task queue. After determining the task type of the current task, the queue corresponding to the task type is queried, and the current task is distributed to the corresponding queue (high priority task queue or low priority task queue).
[0034] Of course, in another embodiment, the task type can also be a long task and a short task, and queues are set accordingly, the long task queue is set according to the long task, and the short task queue is set according to the short task, so the queue type includes a long task queue and a short task queue. After determining the task type of the current task, the queue corresponding to the task type is queried, and the current task is distributed to the corresponding queue (long task queue or short task queue).
[0035] Of course, in another embodiment, the task type can also be a high priority long task, a high priority short task, a low priority long task and a low priority short task, and queues are set accordingly, and a high priority long task queue is set according to the high priority long task, a high priority short task queue is set according to the high priority short task, a low priority long task queue is set according to the low priority long task, and a low priority short task queue is set according to the low priority short task. Therefore, the queue type includes: a high priority long task queue, a high priority short task queue, a low priority long task queue and a low priority short task queue. After determining the task type of the current task, query the queue corresponding to the task type, and distribute the current task to the corresponding queue (one of the high priority long task queue, the high priority short task queue, the low priority long task queue and the low priority short task queue).
[0036] S30: confirming the initial traffic weight of each queue, and allocating the traffic weight of each queue according to the initial traffic weight;
[0037] The initial traffic weight of each queue is the initial state. After the queue type is set, the preset initial traffic weight is calculated based on the priority ratio of the queue type, and the preset initial traffic weight is introduced into the database stored in the large model. Therefore, when S20 determines the queue type of the current task, the initial weight corresponding to the queue type of the current task is extracted from the database, and the traffic weight of the queue type of the current task is allocated according to the initial traffic weight. The traffic weight determines the priority of the current task being called. The higher the traffic weight, the greater the chance of the current task being called. Conversely, the lower the traffic weight, the smaller the chance of the current task being called.
[0038] Of course, the initial traffic weight of a queue is not fixed and can be changed in the following ways:
[0039] Adjust the initial traffic weight through the real-time traffic weight of each queue: monitor the real-time traffic weight of each queue regularly; based on the monitoring of the real-time traffic weight of each queue, dynamically adjust the traffic weight allocated to each queue through the rule engine. It should be noted that due to the different number of tasks in each queue, the real-time traffic weight of the queue does not match the initial traffic weight of the queue during the execution of the call. Therefore, when the real-time traffic weight of the queue does not match the initial traffic weight of the queue, the initial traffic weight is adjusted to the real-time traffic weight, and the real-time traffic weight of each queue is monitored regularly; of course, when the real-time traffic weight of the queue does not match the initial traffic weight of the queue, confirm the number of real-time tasks in each queue, obtain the initial number of tasks of the queue when the initial traffic weight of the queue is obtained, adjust the number of real-time tasks of the queue based on the initial number of tasks of the queue, and when the number of real-time tasks of the queue is equal to the initial number of tasks of the queue, suspend the adjustment of the number of real-time tasks of the queue, and monitor the real-time traffic weight of each queue regularly.
[0040] The initial traffic weight is adjusted by the success rate of historical task execution of each queue: the success rate of historical task execution of each queue is monitored regularly; based on the success rate of historical task execution, the traffic weight allocated to each queue is dynamically adjusted through the rule engine. It should be noted that since the success rate of historical task execution of each queue is different, it is necessary to increase the traffic weight of the queue corresponding to the low success rate, and reduce the traffic weight of the queue with a high success rate. Therefore, the task execution success rate of the current queue is determined. When the task execution success rate of the current queue is lower than the preset success rate value, the real-time traffic weight of the current queue is increased; when the task execution success rate of the current queue is higher than the preset success rate value, and when the task execution success rate of another queue is higher than the preset success rate value, each queue maintains the initial traffic weight operation; when the task execution success rate of the current queue is higher than the preset success rate value, and when the task execution success rate of another queue is lower than the preset success rate value, the real-time traffic weight of the current queue is reduced.
[0041] The initial traffic weight is adjusted according to the real-time traffic weight of each queue and the success rate of historical task execution of each queue: when the real-time traffic weight of a queue does not match the initial traffic weight of the queue, the task execution success rate of the current queue is determined. When the task execution success rate of the current queue is lower than the preset success rate value, the real-time traffic weight of the current queue is increased, and the increased real-time traffic weight is set as the initial traffic weight; when the task execution success rate of the current queue is higher than the preset success rate value, and when the task execution success rate of another queue is higher than the preset success rate value, the real-time traffic weight of each queue is adjusted to the initial traffic weight, and each queue maintains the initial traffic weight operation; when the task execution success rate of the current queue is higher than the preset success rate value, and when the task execution success rate of another queue is lower than the preset success rate value, the real-time traffic weight of the current queue is reduced, and the reduced real-time traffic weight is set as the initial traffic weight.
[0042] The rule engine mainly separates the task decision part of the application and uses predefined semantic modules to write task decisions (task rules), which are configured and managed by users or developers when needed. It should be noted that the rule engine is not a specific technical framework, but refers to a type of system, namely the task rule management system. At present, the specific rule engine products on the market include: drools, VisualRules, iLog, etc. The rule engine realizes the separation of task decisions from application code, receives data input, interprets business rules, and makes task decisions based on task rules. The rule engine is actually an input and output platform. After the rule engine is introduced into the system, the task rules no longer reside in the system in the form of program code. Instead, the rule engine that processes the rules is replaced. The task rules are stored in the rule library and are completely independent of the program. Operators can manage task rules like managing data, such as querying, adding, updating, counting, submitting task rules, etc. Task rules are loaded into the rule engine for application system calls. The advantages of the rule engine are as follows: task rules are separated from system codes to achieve centralized management of task rules; task rules can be expanded and maintained at any time without restarting the service; task rules can be modified dynamically to quickly respond to changes in requirements; the rule engine is relatively independent and only cares about task rules, so that task analysts can also participate in editing and maintaining the system's task rules; the cost and risk of hard-coded task rules are reduced; using the rule editing tools provided by the rule engine makes the implementation of complex task rules simple.
[0043] Specifically, the setting process of the rule engine is as follows: by creating a new project, introducing dependencies, adding configuration categories of the rule engine, and creating corresponding entity class lists and list files according to the configuration categories. The execution process of the rule engine is as follows: the real-time traffic weight input value is put into the working memory, the rules set in the rule library and the initial traffic weight are proposed and compared with the real-time traffic weight, and the adjustment method after comparison is performed according to the above content, which is not listed here one by one; if there is a conflict in the execution of the rules, that is, multiple rules are activated at the same time, and the conflicting rules are placed in the conflict set, the conflicts in the conflict set are resolved, the activated rules are placed in the agenda in order, the rules in the agenda are executed, and the steps of proposing the rules set in the rule library and the initial traffic weight and comparing them with the real-time traffic weight are repeated.
[0044] S40: According to the traffic weight, the target task of each queue is called for execution.
[0045] Specifically, according to the traffic weight of each queue, determine the priority of traffic allocated to each queue; select the target task according to the priority of traffic allocated to each queue; call the target task and output it for execution. For example, when the traffic weight of the current queue is 50% of the entire call traffic, the corresponding priority of traffic allocated to the current queue is 50% of the call probability, and the target task is obtained by calling in the current queue based on the 50% call probability; of course, when the traffic weight of the current queue is 30% of the entire call traffic, the corresponding priority of traffic allocated to the current queue is 30% of the call probability, and the target task is obtained by calling in the current queue based on the 30% call probability. The traffic weight of the current queue can be a natural number traffic such as 30% or 50% or 20% or 10% of the entire call traffic.
[0046] After the step of calling the target task of each queue for execution according to the traffic weight, the present embodiment also includes: detecting whether the queue at the high priority is empty; if so, executing the step of receiving the current task and confirming the task type until a preset number of tasks are added to the high priority queue; if not, executing the step of calling the target task of each queue for execution according to the traffic weight. If the high-priority queue is empty, there is no task that can be called in the high-priority queue, and the real-time traffic weight of each queue does not match the initial traffic weight. In this case, it is necessary to accept new tasks and confirm the task type until the high-priority queue is filled with a preset number of tasks and the real-time traffic weight of each queue matches the initial traffic weight. If the high-priority queue is not empty, confirm whether the real-time traffic weight of each queue matches the initial traffic weight. When the real-time traffic weight of the queue does not match the initial traffic weight of the queue, adjust the initial traffic weight to the real-time traffic weight, and monitor the real-time traffic weight of each queue regularly. Of course, when the real-time traffic weight of the queue does not match the initial traffic weight of the queue, confirm the number of real-time tasks in each queue, obtain the initial number of tasks of the queue when obtaining the initial traffic weight of the queue, adjust the number of real-time tasks of the queue based on the initial number of tasks of the queue, and when the number of real-time tasks of the queue is equal to the initial number of tasks of the queue, suspend the adjustment of the number of real-time tasks of the queue, and monitor the real-time traffic weight of each queue regularly.
[0047] The present invention provides a dynamic multi-queue scheduling method, which first confirms the task type by receiving the current task; distributes the current task to different queues according to the task type; confirms the initial flow weight of each queue, and allocates the flow weight of each queue according to the initial flow weight; and calls the target task of each queue for execution according to the flow weight.
[0048] It realizes full utilization of large model resources and is also versatile and can be adapted to other scenarios, such as AI outbound call matching outbound call resources, matching between Finebi and Impala resources, etc. By setting the priority of the queue to sort and access it, the present invention can be effectively used to solve practical problems. At the same time, by customizing the priority comparison logic, we can further expand its application scope to meet specific needs; the present invention also introduces a rule engine, and the task rules are separated from the system code to achieve centralized management of task rules; the task rules can be expanded and maintained at any time without restarting the service; the task rules can be dynamically modified to quickly respond to changes in requirements; the rule engine is relatively independent and only cares about the task rules, so that task analysts can also participate in editing and maintaining the system's task rules; the cost and risk of hard-coded task rules are reduced; the rule editing tool provided by the rule engine makes the implementation of complex task rules simple.
[0049] It should be understood that the order of execution of the steps in the above embodiment does not necessarily mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present invention.
[0050] In one embodiment, a dynamic multi-queue scheduling device is provided, and the dynamic multi-queue scheduling device corresponds one-to-one to the dynamic multi-queue scheduling method in the above embodiment. Figure 3 As shown, the dynamic multi-queue scheduling device includes a receiving module 101, a distribution module 102, an allocation module 103, and a calling module 104. Each functional module is described in detail as follows:
[0051] Receiving module 101, used to receive the current task and confirm the task type;
[0052] A distribution module 102 is used to distribute the current task to different queues according to the task type;
[0053] The allocation module 103 is used to confirm the initial traffic weight of each queue and allocate the traffic weight of each queue according to the initial traffic weight;
[0054] The calling module 104 is used to call the target task of each queue for execution according to the traffic weight.
[0055] In one embodiment, the device is further configured to:
[0056] The real-time traffic weight monitoring module is used to regularly monitor the real-time traffic weight of each queue;
[0057] The first rule engine module is used to dynamically adjust the traffic weight allocated to each queue through the rule engine based on monitoring the real-time traffic weight of each queue.
[0058] In one embodiment, the device is further configured to:
[0059] The success rate monitoring module is used to periodically monitor the success rate of historical task execution in each queue;
[0060] The second rule engine module is used to dynamically adjust the traffic weight obtained by each queue allocation through the rule engine based on the success rate of historical task execution.
[0061] In one embodiment, the receiving module 101 is specifically configured to:
[0062] The priority setting submodule is used to receive the target task and compare the current task with the preset condition range; if the current task is within the preset condition range, the task type of the current task is high priority; if the current task is outside the preset condition range, the task type of the current task is low priority.
[0063] In one embodiment, the calling module 104 is specifically configured to:
[0064] The confirmation submodule is used to confirm the priority of traffic allocated to each queue according to the traffic weight of each queue;
[0065] The allocation submodule is used to select the target task according to the priority of allocating traffic to each queue;
[0066] The calling submodule is used to call the target task and output execution.
[0067] In one embodiment, the device is further configured to:
[0068] The traffic weight adjustment submodule is used to detect whether the queue at a high priority is empty; if so, execute the steps of receiving the current task and confirming the task type until a preset number of tasks are added to the high priority queue; if not, execute the steps of calling the target task of each queue for execution according to the traffic weight.
[0069] The present invention provides a dynamic multi-queue scheduling device, which first confirms the task type by receiving the current task; distributes the current task to different queues according to the task type; confirms the initial flow weight of each queue, and allocates the flow weight of each queue according to the initial flow weight; and calls the target task of each queue for execution according to the flow weight.
[0070] It realizes full utilization of large model resources and is also versatile and can be adapted to other scenarios, such as AI outbound call matching outbound call resources, matching between Finebi and Impala resources, etc. By setting the priority of the queue to sort and access it, the present invention can be effectively used to solve practical problems. At the same time, by customizing the priority comparison logic, we can further expand its application scope to meet specific needs; the present invention also introduces a rule engine, and the task rules are separated from the system code to achieve centralized management of task rules; the task rules can be expanded and maintained at any time without restarting the service; the task rules can be dynamically modified to quickly respond to changes in requirements; the rule engine is relatively independent and only cares about the task rules, so that task analysts can also participate in editing and maintaining the system's task rules; the cost and risk of hard-coded task rules are reduced; the rule editing tool provided by the rule engine makes the implementation of complex task rules simple.
[0071] For the specific definition of the dynamic multi-queue scheduling device, please refer to the definition of the dynamic multi-queue scheduling method above, which will not be repeated here. Each module in the above-mentioned dynamic multi-queue scheduling device can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.
[0072] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external client via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a dynamic multi-queue scheduling method service side.
[0073] In one embodiment, a computer device is provided. The computer device may be a client, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server through a network connection. When the computer program is executed by the processor, it realizes the functions or steps of the client side of a dynamic multi-queue scheduling method
[0074] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:
[0075] Receive the current task and confirm the task type;
[0076] Distribute current tasks to different queues according to task types;
[0077] Confirm the initial traffic weight of each queue and allocate the traffic weight of each queue according to the initial traffic weight;
[0078] According to the traffic weight, the target task of each queue is called for execution.
[0079] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the client side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.
[0080] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).
[0081] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.
[0082] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.
Claims
1. A dynamic multi-queue scheduling method, characterized in that: include: Receive the current task and confirm the task type; Distribute current tasks to different queues according to task types; Confirm the initial traffic weight of each queue and allocate the traffic weight of each queue according to the initial traffic weight; According to the traffic weight, the target task of each queue is called for execution.
2. The dynamic multi-queue scheduling method according to claim 1, characterized in that: Before the step of calling the target task of each queue for execution according to the traffic weight, the method further includes: Regularly monitor the real-time traffic weight of each queue; Based on monitoring the real-time traffic weight of each queue, the traffic weight allocated to each queue is dynamically adjusted through the rule engine.
3. The dynamic multi-queue scheduling method according to claim 2, characterized in that: Before the step of calling the target task of each queue for execution according to the traffic weight, the method further includes: Regularly monitor the success rate of historical task execution in each queue; Based on the success rate of historical task execution, the traffic weight allocated to each queue is dynamically adjusted through the rule engine.
4. The dynamic multi-queue scheduling method according to claim 1, characterized in that: The step of receiving the target task and confirming the task type includes: Receive the target task and compare the current task with the preset condition range; If the current task is within the preset condition range, the task type of the current task is high priority; If the current task is outside the preset condition range, the task type of the current task is low priority.
5. The dynamic multi-queue scheduling method according to claim 4, characterized in that: The different queues include at least: a high priority long task queue, a high priority short task queue, a low priority long task queue and a low priority short task queue.
6. The dynamic multi-queue scheduling method according to claim 1, characterized in that: The step of calling the target task of each queue for execution according to the traffic weight includes: According to the traffic weight of each queue, determine the priority of traffic allocated to each queue; Select the target task based on the priority of allocating traffic to each queue; Invokes the target task and outputs the execution.
7. The dynamic multi-queue scheduling method according to claim 2, characterized in that: After the step of calling the target task of each queue for execution according to the traffic weight, the method further includes: Check whether the queue at high priority is empty; If yes, execute the steps of receiving the current task and confirming the task type until the preset number of tasks are added to the high-priority queue; If not, execute the step of calling the target task of each queue for execution according to the traffic weight.
8. A dynamic multi-queue scheduling device, characterized in that: include: The receiving module is used to receive the current task and confirm the task type; The distribution module is used to distribute the current task to different queues according to the task type; An allocation module, used to confirm the initial traffic weight of each queue and allocate the traffic weight of each queue according to the initial traffic weight; The calling module is used to call the target task of each queue for execution according to the traffic weight.
9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the dynamic multi-queue scheduling method according to any one of claims 1 to 7 are implemented.
10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the dynamic multi-queue scheduling method according to any one of claims 1 to 7 are implemented.