Resource scheduling method, terminal equipment and storage medium

Abstract

The invention is suitable for the technical field of resource allocation, and provides a resource scheduling method, terminal equipment and a storage medium, and the method comprises the steps: obtaining a current system parameter when a triggering moment of a resource scheduling period is reached, the current system parameters comprise a task queue, a resource allocation state, task characteristics of each task in the task queue and a stored system operation scene; generating a plurality of candidate resource scheduling strategies according to the priority of the to-be-executed task and the current system parameter; resource allocation constraint conditions are determined according to the system operation scenes, different system operation scenes correspond to different resource allocation constraint conditions, the multiple candidate resource scheduling strategies are verified according to the resource allocation constraint conditions, and the optimal resource scheduling strategy is obtained. Dynamic resource allocation is carried out according to the current system scene instead of depending on a fixed strategy, so that changes of task load and resource availability are adapted, and strategy scheduling flexibility is improved.

Description

Technical Field

[0001] This application belongs to the field of resource allocation technology, and in particular relates to a resource scheduling method, terminal equipment and storage medium. Background Technology

[0002] With the rapid development of cloud computing, distributed computing, and big data processing technologies, the scale and complexity of tasks undertaken by various business systems continue to rise, placing stringent demands on the efficiency, accuracy, and adaptability of system resource scheduling. As a core component ensuring stable system operation, improving resource utilization, and enhancing task execution efficiency, the rationality of resource scheduling strategies directly determines the overall performance of the system.

[0003] Currently, conventional resource scheduling methods generally employ fixed-rule scheduling strategies for resource allocation. However, in real-world applications, business systems often face diverse operational scenarios, and fixed-rule scheduling strategies cannot meet the current system requirements, resulting in inaccurate resource scheduling strategies. Summary of the Invention

[0004] This application provides a resource scheduling method, terminal device, and storage medium, which can solve the problem of inaccurate resource scheduling strategies.

[0005] In a first aspect, embodiments of this application provide a resource scheduling method, including: In response to the triggering time of the resource scheduling cycle, the current system parameters are obtained, including the task queue, resource allocation status, task characteristics of each task in the task queue, and stored system operation scenario; If there are tasks to be executed in the task queue, resource configuration is planned for the tasks to be executed according to their priority and the current system parameters, and multiple candidate resource scheduling strategies are generated. Query the resource allocation constraints corresponding to the system operation scenario, where different system operation scenarios correspond to different resource allocation constraints; Based on the resource allocation constraints, the candidate resource scheduling strategies are verified to obtain the optimal resource scheduling strategy. The task to be executed will be performed according to the optimal resource scheduling strategy.

[0006] In this application, upon reaching the trigger time of the resource scheduling cycle, current system parameters are obtained. These parameters include the task queue, resource allocation status, task characteristics of each task in the task queue, and the stored system operating scenario. Based on the priority of the tasks to be executed and the current system parameters, multiple candidate resource scheduling strategies are generated. This application dynamically allocates resources according to the current system scenario, rather than relying on a fixed strategy, thereby adapting to changes in task load and resource availability and improving the flexibility of strategy scheduling. The task characteristics of each task are also considered when generating candidate resource scheduling strategies, making resource allocation more targeted, avoiding resource mismatch, and thus improving the task execution success rate. Then, resource allocation constraints are determined based on the system operating scenario. Different system operating scenarios correspond to different resource allocation constraints, realizing the customization and compliance of resource scheduling strategies and enhancing scenario adaptability. Multiple candidate resource scheduling strategies are validated based on the resource allocation constraints to obtain the optimal resource scheduling strategy, ensuring that the scheduling strategy conforms to the system's constraints, avoiding system instability due to over-allocation or conflicts, and enhancing robustness.

[0007] Secondly, embodiments of this application provide a resource scheduling apparatus, including: The parameter acquisition module is used to acquire the current system parameters in response to the triggering time of the resource scheduling cycle. The current system parameters include the task queue, resource allocation status, task characteristics of each task in the task queue, and stored system operation scenario. The resource planning module is used to plan resource configuration for the tasks to be executed based on the priority of the tasks to be executed and the current system parameters, and generate multiple candidate resource scheduling strategies if there are tasks to be executed in the task queue. The condition query module is used to query the resource allocation constraints corresponding to the system operation scenario, wherein different system operation scenarios correspond to different resource allocation constraints. The strategy verification module is used to verify multiple candidate resource scheduling strategies based on the resource allocation constraints to obtain the optimal resource scheduling strategy. The task execution module is used to execute the task to be executed according to the optimal resource scheduling strategy.

[0008] Thirdly, embodiments of this application provide a terminal device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the resource scheduling method described in any one of the first aspects above.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the resource scheduling method described in any one of the first aspects above.

[0010] Fifthly, embodiments of this application provide a computer program product that, when run on a terminal device, causes the terminal device to execute the resource scheduling method described in any one of the first aspects. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art 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.

[0012] Figure 1 This is a flowchart illustrating a resource scheduling method provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a method for generating candidate resource scheduling strategies for high-priority tasks according to an embodiment of this application; Figure 3 This is a flowchart illustrating a method for resource scheduling from the same resource cluster according to an embodiment of this application; Figure 4 This is a flowchart illustrating a method for generating candidate resource scheduling strategies for low-priority tasks according to an embodiment of this application. Figure 5 This is a flowchart illustrating a method for determining the optimal resource scheduling strategy according to an embodiment of this application; Figure 6 This is a flowchart illustrating a system automatic learning method provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a resource scheduling device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. Detailed Implementation

[0013] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0014] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0015] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0016] The system's hardware and software resources are limited, such as the computing power of the Central Processing Unit (CPU), memory space, disk I / O, network bandwidth, and graphics processing unit (GPU) resources. However, multiple tasks often run simultaneously. To avoid resource conflicts and waste and to ensure that various tasks are carried out in an orderly manner, resources need to be allocated.

[0017] Existing resource scheduling systems, especially in scenarios involving mixed training / inference, mixed data preparation and training, and multiple projects sharing a GPU, typically have the following shortcomings: Using a fixed resource allocation strategy leads to resource waste and inconsistent overall resource utilization. For example, if fixed resources are allocated to projects A and B respectively, project A's tasks may be piling up in the queue, waiting for resources, while project B's quota may be idle.

[0018] High-priority tasks directly force low-priority tasks to stop running, increasing the cost of interruption. This not only wastes previously invested computing power, but may also lead to incomplete data, duplicate calculations, and even affect the user experience due to task interruption.

[0019] Resource scheduling strategies need to be manually set and cannot be dynamically adjusted based on the current system operating status, leading to inaccurate resource scheduling. For example, when the business switches from "daytime online inference" to "nighttime mass training," the resource scheduling rules cannot switch automatically.

[0020] Resource scheduling strategies cannot be dynamically updated based on historical results.

[0021] Based on the above problems, this application proposes a resource scheduling method. This application can generate multiple candidate resource scheduling strategies based on the current system operation scenario, resource allocation status and task characteristics, and then verify each candidate resource scheduling strategy according to the resource allocation constraints corresponding to the current system operation scenario to obtain the optimal resource scheduling strategy.

[0022] This application can also dynamically update the system operation scenario and resource allocation constraints based on the resource scheduling strategy within the historical resource scheduling cycle, so that a resource scheduling strategy can be generated based on the accurate system status each time resource scheduling is performed.

[0023] In addition, this application sets resource scheduling strategies for high-priority tasks and low-priority tasks respectively, so that tasks of different priorities correspond to different resource scheduling strategies, making the generated resource survey strategy more targeted and accurate.

[0024] The following combination Figure 1 The resource scheduling method of the embodiments of this application will be described in detail.

[0025] Figure 1 A schematic flowchart of the resource scheduling method provided in this application is shown, with reference to... Figure 1 The method is described in detail below: S101, in response to the triggering time of the resource scheduling cycle, obtain the current system parameters, which include the task queue, resource allocation status, task characteristics of each task in the task queue, and stored system operation scenario.

[0026] In this embodiment, resource scheduling is performed according to a preset cycle (fast cycle). For example, the resource scheduling cycle can be set to every 30 seconds, every minute, etc., and there is no limitation here.

[0027] In this embodiment, the task queue may include a high-priority queue and a low-priority queue. The high-priority queue stores high-priority tasks, and the low-priority queue stores low-priority tasks. The priority of a task can be determined based on the task queue in which it belongs. Specifically, if the task to be executed is in the high-priority queue, then the task to be executed is a high-priority task; if the task to be executed is in the low-priority queue, then the task to be executed is a low-priority task.

[0028] Resource allocation status includes the amount of resources used for ongoing projects, the resource quota for projects, the remaining resources for ongoing projects, the remaining resources for each resource cluster, the resources used for each resource cluster, the topology of the resource cluster, quota burst limits, and preemptive budgets. For example, projects can be facial recognition projects, map projects, etc.

[0029] Among them, a Virtual Cluster (VC) is a logical resource domain that is divided into labels, queues or security domains on a shared physical cluster. For example, a first type of processor is divided into one resource cluster and a second type of processor is divided into another resource cluster. The first type and the second type are different types.

[0030] Each project is assigned a corresponding resource quota (Project×VC quota). For example, the resource quota for the face recognition project is 20 processors, and the resource quota for the map project is 30 processors.

[0031] By using two consumable quotas, namely "budget grabbing" and "sudden quota allocation", the questions of "how many to kill" and "whether more can be run in a short period of time" are made controllable parameters.

[0032] Among them, the quota emergency limit represents the upper limit that allows a task to temporarily seize additional resources (over-quota) on the basis of the basic resource quota, ensuring the execution of emergency tasks.

[0033] Preemption budget represents the upper limit of the number of tasks that can be reclaimed / stopped within a resource scheduling cycle. It is used to limit scheduling disturbances and wasted computations. Preemption budget can be used to limit the high frequency of task stopping.

[0034] In this embodiment, the task characteristics may include interruptibility, cooldown time, resource consumption, number of startup attempts, waiting time, number of pauses, etc.

[0035] Interruptibility characterizes the degree to which a task can be forcibly paused. It is a comprehensive indicator describing whether a task can be safely interrupted, the time of the most recent checkpoint, and the cost of interruption. Setting interruptibility provides a basis for interrupting tasks, reducing the cost of task interruption.

[0036] The waiting time represents the duration of an unexecuted task from when the task was received to the current time.

[0037] "Budget grabbing", "sudden quota allocation", and "cooling-off time" are all related to disturbance costs.

[0038] In this embodiment, the system operation scenario represents the current state of the system. For example, the system operation scenario can be a resource-rich scenario, a resource-insufficient scenario, a high-fragmentation scenario, a high-priority task influx scenario, a nighttime training scenario, etc. Among them, the high-fragmentation scenario indicates that the resources occupied by tasks in the resource cluster are relatively dispersed.

[0039] In this embodiment, the system operation scenario can be determined based on the resource scheduling situation within the historical resource scheduling cycle.

[0040] Specifically, a system learning cycle (slow cycle) is set. The system learns itself according to this cycle to obtain the system's operating scenario and updates the previously stored scenarios. Upon reaching the trigger point of the resource scheduling cycle, the system can directly retrieve the currently stored operating scenario, eliminating the need to determine the operating scenario for each resource scheduling cycle. The specific implementation of the slow cycle is described below and will not be elaborated upon here.

[0041] For example, the system learning cycle can be 10 minutes, 20 minutes, or 30 minutes, etc., without any restrictions. The system learning cycle is longer than the resource scheduling cycle.

[0042] As an example, the storage system operates in scenario A. When resource scheduling is performed, the system operates in scenario A. After N resource scheduling operations, system learning is initiated. Through system learning, the system operating scenario is determined to be scenario B. The storage system operating scenario is then changed from scenario A to scenario B. When performing the N+1th resource scheduling operation, scenario B is used, and resource scheduling is performed based on scenario B.

[0043] S102, if there are tasks to be executed in the task queue, resource configuration is planned for the tasks to be executed according to the priority of the tasks to be executed and the current system parameters, and multiple candidate resource scheduling strategies are generated.

[0044] In this embodiment, different resource planning methods are used for high-priority and low-priority tasks. For high-priority tasks, resource allocation is mainly based on resource reclamation / resource preemption when resources are insufficient. For low-priority tasks, resource allocation is mainly based on task time-sharing / task resumption.

[0045] In this embodiment, when generating multiple candidate resource scheduling strategies, strategy planning can be performed for different recycling purposes.

[0046] As an example, if the task to be executed is a high-priority task: Option 1: Reclaim the resources of low-priority tasks according to their interruptibility, cooldown time, etc., to obtain a candidate resource scheduling strategy; Option 2: Generate a candidate resource scheduling strategy with the aim of interrupting as few tasks as possible.

[0047] In another implementation, if there are no tasks to be executed, it means that all tasks are currently being executed and resource scheduling has already been performed on the tasks that are currently being executed. Therefore, no resources will be reallocated at this moment, and the execution will continue according to the current resource scheduling strategy.

[0048] S103, query the resource allocation constraints corresponding to the system operation scenario, wherein different system operation scenarios correspond to different resource allocation constraints.

[0049] In this embodiment, resource allocation constraints may include quota burst limits, resource capacity, resource topology within the resource cluster, task cooldown time, low-priority task release intensity, and preemption budget, etc.

[0050] The low-priority task release strength represents the upper limit of low-priority tasks that can be released each time.

[0051] Resource capacity is the upper limit / boundary of the resources available for scheduling within the resource cluster.

[0052] In this embodiment, the resource allocation constraints can be determined based on the resource scheduling situation within the historical resource scheduling cycle.

[0053] Specifically, the system learns according to a slow cycle to obtain the system's operating scenario and the corresponding resource allocation constraints; it then updates the previously stored operating scenarios and resource allocation constraints. Upon reaching the resource scheduling time, it directly retrieves the currently stored operating scenario and corresponding resource allocation constraints. The specific implementation of the slow cycle is described below and will not be elaborated upon here.

[0054] S104, Based on the resource allocation constraints, the multiple candidate resource scheduling strategies are verified to obtain the optimal resource scheduling strategy.

[0055] In this embodiment, candidate resource scheduling strategies are validated to determine whether they meet resource allocation constraints. If a candidate resource scheduling strategy does not meet the resource allocation constraints, it is not executable and cannot be retained. If a candidate resource scheduling strategy meets the resource allocation constraints, it is executable and can be retained. The optimal candidate resource scheduling strategy is then selected from the finally determined executable candidate resource scheduling strategies.

[0056] For example, the optimal resource scheduling strategy can be selected from among the executable candidate resource scheduling strategies, choosing the one with the fastest task execution speed; or, the optimal resource scheduling strategy can be selected from among the executable candidate resource scheduling strategies, choosing the one with the lowest equipment consumption; or, the optimal resource scheduling strategy can be selected from among the executable candidate resource scheduling strategies, choosing the one with the least task disturbance.

[0057] S105, execute the task to be executed according to the optimal resource scheduling strategy.

[0058] The overall process of resource scheduling has been explained above. The implementation of specific steps in resource scheduling will be explained below.

[0059] In one feasible approach, when a task to be executed is of high priority and resources are insufficient, a two-stage resource reclamation method can be used. Specifically, the two-stage resource reclamation method is as follows: first, reclaim resources from low-priority tasks currently running in the same project as the high-priority task; if, after reclaiming resources in the same project, the available resources still cannot meet the needs of the high-priority task to be executed, then reclaim resources from low-priority tasks currently running in other projects belonging to the same VC as the high-priority task.

[0060] Specifically, such as Figure 2 As shown, the implementation of step S102 above may include: S1021, if the task to be executed is a high-priority task, obtain the estimated resource occupancy required by the task to be executed, wherein the project type of the high-priority task is the first project.

[0061] In this embodiment, the resource requirements corresponding to projects of different task types are stored in advance. The resource requirements of a high-priority task are found according to its task type to obtain the estimated resource occupancy required for the task to be executed.

[0062] S1022, if the sum of the estimated resource occupancy and the used resource amount of the first project exceeds the resource quota of the first project, based on the task characteristics of the first task and the estimated resource occupancy, a strategy for resource recovery from the first task is planned to obtain multiple first resource scheduling strategies and an estimated first recovery resource amount for each of the first resource scheduling strategies, wherein the first task is a low-priority task currently being executed in the first project.

[0063] In this embodiment, the task characteristics of the first task include at least one of interruptibility, cooldown time, and resource consumption. After the first task is recycled, the total number of times the first task has been recycled and the cooldown time are recorded.

[0064] In this embodiment, the estimated resource occupancy and the used resources of the first project are added together to obtain the total resources. If the total resources are greater than the resource quota of the first project, it indicates that the current resources are insufficient and resource recovery is required.

[0065] For high-priority tasks, resources are reclaimed from the same project first. For example, if the task to be executed belongs to the face recognition project, resources are reclaimed from low-priority tasks currently being executed within the face recognition project.

[0066] Specifically, based on the characteristics of the low-priority tasks (first tasks) currently being executed within the same project, tasks that can be reclaimed for resources are assessed, i.e., low-priority tasks that can be paused are identified. The amount of resources to be reclaimed is determined based on the difference between the estimated resource occupancy and the remaining resources of the first project. Based on the amount of resources to be reclaimed and the identified low-priority tasks that can be paused, multiple resource reclamation strategies are determined; in this application, the determined resource reclamation strategy is denoted as the first resource scheduling strategy. Alternatively, multiple first resource scheduling strategies can be determined based on the amount of resources to be reclaimed, the identified low-priority tasks that can be paused, and the reclamation objective. The reclamation objective is explained in step S102 above and will not be repeated here.

[0067] In one approach, if the task characteristics include interruptibility, cooldown time, and resource consumption, and if the interruptibility is greater than a first preset threshold, the cooldown time is greater than a second preset threshold, and the resource consumption is within a preset range, then the first task is determined to be a low-priority task that can be paused.

[0068] The resource amount that can be recovered by the first resource scheduling strategy is determined by summing the resource occupancy of all suspended first tasks in the first resource scheduling strategy. In this application, the resource amount that can be recovered by the first resource scheduling strategy is recorded as the first recovered resource amount.

[0069] Alternatively, the task features can be weighted and summed to obtain the scores for each first task. First tasks with scores greater than the preset scores can be filtered out, and resources with scores greater than the first tasks can be recycled.

[0070] In another implementation, if the sum of the estimated resource occupancy and the used resources of the first project does not exceed the resource quota of the first project, it means that the remaining resources in the resource pool of the first project are sufficient to run the high-priority task. There is no need to reclaim resources from the low-priority tasks that are being executed. Resources can be directly configured for the high-priority task and run according to the resource configuration.

[0071] S1023, for each of the first recovered resource quantities, calculate the current remaining resource quantity of the resource pool matched by the first project based on the first recovered resource quantity.

[0072] In this embodiment, the remaining available resources before resource recycling are obtained by subtracting the used resources of the first project from the resource quota of the first project. The current remaining resources are obtained by adding the first recycled resources to the remaining available resources.

[0073] S1024, if the current remaining resource amount is less than the estimated resource occupancy, based on the difference between the estimated resource occupancy and the current remaining resource amount, a strategy for recovering resources from the resource pool matched by other projects is planned to obtain multiple second resource scheduling strategies, wherein the other projects are projects that belong to the same resource cluster as the first project.

[0074] In this embodiment, if it is determined that the current remaining resource amount is less than the estimated resource occupancy, it indicates that even after resource reclamation from the low-priority tasks of the first project, the tasks to be executed are still in a state of insufficient resources. In this case, resources can be reclaimed from projects belonging to the same resource cluster (VC) as the first project.

[0075] Specifically, such as Figure 3 As shown, the method for determining the second resource scheduling strategy may include: S11, the resource difference of the high-priority task is obtained by subtracting the current remaining resource amount from the estimated resource occupancy.

[0076] S12, query the remaining resource quantity in the resource pool matching the other projects from the resource allocation status.

[0077] S13, if the remaining resources of the other projects are less than the resource difference, a strategy for resource recovery from the second task is planned based on the task characteristics of the second task and the resource difference, resulting in multiple second resource scheduling strategies, wherein the second task is a low-priority task being executed in the other projects.

[0078] In this embodiment, the task characteristics of the second task include at least one of interruptibility, cooldown time, and resource consumption.

[0079] The method for determining the second resource scheduling strategy is similar to the method for determining the first resource scheduling strategy in step S1022 above. Please refer to the description of step S1022, which will not be repeated here.

[0080] S14. If the remaining resources of other projects are greater than or equal to the resource difference, generate a second resource scheduling strategy based on the remaining resources of other projects.

[0081] In this embodiment, if the remaining resources of other projects are greater than or equal to the resource difference, it means that the remaining resources of other projects are sufficient to meet the needs of high-priority tasks, and the remaining resources of other projects can be directly allocated to the high-priority tasks to be executed.

[0082] S1025, generate multiple candidate resource scheduling strategies based on multiple first resource scheduling strategies and multiple second resource scheduling strategies.

[0083] In this embodiment, the first resource scheduling strategy and the corresponding second resource scheduling strategy are combined to obtain a candidate resource scheduling strategy. Specifically, if the current remaining resource amount A is obtained using the first resource scheduling strategy A, and the second resource scheduling strategy A is determined using the current remaining resource amount A, then the first resource scheduling strategy A and the second resource scheduling strategy A correspond to each other, and the first resource scheduling strategy A and the second resource scheduling strategy A can be combined into a single candidate resource scheduling strategy.

[0084] S1026, if the current remaining resource amount is greater than or equal to the estimated resource occupancy, the multiple first resource scheduling strategies are determined as multiple candidate resource scheduling strategies.

[0085] In this embodiment, if the current remaining resource amount is greater than or equal to the estimated resource occupancy, it means that after resource reclamation from the low-priority tasks of the first project, the remaining resources corresponding to the first project are sufficient for the high-priority task to use, and no further resource reclamation is needed. The first resource scheduling strategy can be directly determined as the candidate resource scheduling strategy.

[0086] In this application, for high-priority tasks to be executed, an internal loop-first resource reclamation strategy is adopted. Resources are first reclaimed from low-priority tasks in the same project, and then from projects in the same resource cluster. This approach reduces conflicts of cross-project resource contention by prioritizing internal digestion, reduces the impact on other projects, and ensures the execution timeliness and delivery quality of high-priority tasks.

[0087] The above describes the method for configuring resources for high-priority tasks. Below is the method for configuring resources for low-priority tasks.

[0088] Specifically, refer to Figure 4 As shown, the implementation of step S102 above may also include: S201, if the task to be executed is a low-priority task and the system running scenario is a preset scenario, obtain the required resource amount of the low-priority task, wherein the preset scenario is a scenario that satisfies the requirement to start the low-priority task, and the project type of the low-priority task is the second project. In this embodiment, the preset scenario can be a scenario with sufficient resources and / or a scenario with high fragmentation, etc., and the preset scenario can be preset.

[0089] S202, if the remaining resources of the resource cluster where the second project is located are greater than or equal to the required resources of the low-priority task, the release order of the low-priority task is planned according to the task characteristics and release intensity of the low-priority task.

[0090] The low-priority task features include at least one of the following: number of attempts to start, cooldown time, waiting time, and number of times it has been paused.

[0091] In this embodiment, if the task features include multiple features, the multiple task features are weighted and summed to obtain the score of each low-priority task. The release order of the low-priority tasks is determined according to the scores of each low-priority task. For example, the lower-priority task with the higher score is released earlier.

[0092] If the task characteristics only include the number of launch attempts, then the greater the number of launch attempts, the earlier the low-priority task will be released. If the task characteristics only include the number of pauses, then the greater the number of pauses, the earlier the low-priority task will be released. If the task characteristics only include the waiting time, then the greater the waiting time, the earlier the low-priority task will be released.

[0093] S203, Based on the release order, plan resource allocation for low-priority tasks and generate multiple candidate resource scheduling strategies.

[0094] In this embodiment, a time-sharing release strategy is adopted for low-priority tasks. Low-priority tasks are released in a time-sharing manner according to a determined release order, so that the number of low-priority tasks released each time does not exceed the release intensity of low-priority tasks.

[0095] S204, if the remaining resources of the resource cluster where the second project is located are less than the resources required by the low-priority task, control the low-priority task to continue waiting.

[0096] In this embodiment, if the remaining resources of the resource cluster (VC) where the second project is located are less than the resources required by the low-priority task, it means that the current remaining resources are not suitable for executing the low-priority task to be executed, and the low-priority task to be executed needs to continue to wait.

[0097] In this application, blindly retrying low-priority tasks will consume system resources such as CPU, memory, and network, and may also cause problems such as task queue congestion and excessive load on scheduling nodes. When the preset scenario is reached, it means that resources are relatively abundant. Resuming the execution of low-priority tasks when resources are sufficient or business is idle reduces the ineffective resource contention and task scheduling overhead. This allows limited resources to be concentrated on core business during peak periods of high-priority tasks and allocated to low-priority tasks when resources are sufficient, thus achieving efficient time-sharing utilization of resources.

[0098] After introducing the method for determining multiple candidate resource scheduling strategies in step S102 above, the following section refers to... Figure 5 As shown, the implementation process of step S104 above will now be introduced.

[0099] S1041, the current system parameters, the system operation scenario, and multiple candidate resource scheduling strategies are input into the trained large language model to obtain a recommendation ranking of the multiple candidate resource scheduling strategies, wherein the recommendation ranking is sorted from high to low according to the degree of recommendation.

[0100] In this embodiment, the large language model evaluates the candidate resource scheduling strategies based on evaluation metrics, obtains a score for each candidate resource scheduling strategy, and recommends and ranks each candidate resource scheduling strategy based on the score. The higher the score, the better the candidate resource scheduling strategy.

[0101] The evaluation metrics may include at least one of the following: high-priority task guarantee metrics, disturbance / waste cost, resource utilization improvement, and cooldown time / repeated recycling risk. High-priority task guarantee metrics may include at least one of the following: high-priority task waiting time, estimated start time, and whether resource / topology requirements are met. Disturbance / waste cost may include the estimated number of tasks that will be stopped and the interruptibility of the tasks that are expected to be stopped. Resource utilization improvement refers to the expected increase in resource utilization after execution. Cooldown time / repeated recycling risk indicates whether the same low-priority task has just been recycled or whether the cooldown limit has been hit.

[0102] In this embodiment, in addition to outputting the recommended ranking of multiple candidate resource scheduling strategies, the large language model can also output explanatory text to facilitate subsequent system learning.

[0103] S1042, starting from the first candidate resource scheduling strategy in the recommended order, the verification is performed. For the i-th candidate resource scheduling strategy, the verification is performed based on the resource allocation constraints to obtain the i-th verification result of the i-th candidate resource scheduling strategy, where i≥1.

[0104] In this embodiment, if a candidate resource scheduling strategy meets the resource allocation constraints, the verification result of the candidate resource scheduling strategy is determined to be qualified.

[0105] If a candidate resource scheduling strategy does not meet the resource allocation constraints, then the verification result of the candidate resource scheduling strategy is determined to be unqualified.

[0106] S1043, if the i-th verification result indicates that the verification is qualified, then the i-th candidate resource scheduling strategy is determined as the optimal resource scheduling strategy.

[0107] S1044, if the i-th verification result indicates that the verification is unqualified, the i-th candidate resource scheduling strategy is repaired based on the reason for the verification failure, and the repaired i-th candidate resource scheduling strategy is obtained.

[0108] In this embodiment, repairing the i-th candidate resource scheduling strategy may include adjusting the resource reclamation object, reducing the number of resource reclamation objects in a single operation, etc.

[0109] S1045, Based on the resource allocation constraints, the i-th candidate resource scheduling strategy after repair is verified, and the i-th repair verification result is obtained.

[0110] S1046, if the i-th repair verification result indicates that the verification is unqualified, the (i+1)-th candidate resource scheduling strategy is verified based on the resource allocation constraints to obtain the (i+1)-th verification result of the (i+1)-th candidate resource scheduling strategy. This process is repeated to obtain the optimal resource scheduling strategy.

[0111] For example, if there are multiple candidate resource scheduling strategies, namely E, F and G, and the recommended order is E > F > G.

[0112] First, E is validated based on the resource allocation constraints to obtain the validation result of E. If the validation result of E is satisfactory, then E is determined as the optimal resource scheduling strategy.

[0113] If the verification result of E fails, E is repaired, and the process proceeds to the repaired E. The repaired E is then verified according to the resource allocation constraints to obtain its verification result. If the verification result of the repaired E passes, then the repaired E is determined as the optimal resource scheduling strategy.

[0114] If the verification result of the repaired E fails, then F is verified according to the resource allocation constraints to obtain the verification result of F. If the verification result of F passes, then F is determined as the optimal resource scheduling strategy.

[0115] If the verification result of F fails, F is repaired, and the repaired F is obtained. The repaired F is then verified according to the resource allocation constraints to obtain the verification result of the repaired F. If the verification result of the repaired F passes, the repaired F is determined as the optimal resource scheduling strategy.

[0116] If the verification result of the repaired F fails, then G is verified according to the resource allocation constraints to obtain the verification result of G. If the verification result of G passes, then G is determined as the optimal resource scheduling strategy.

[0117] In another implementation, if the last candidate resource scheduling strategy is checked and it still does not meet the resource allocation conditions, then no resource scheduling will be performed in the current resource scheduling cycle, and the process will wait for the next resource scheduling cycle.

[0118] The above describes resource scheduling within the resource scheduling cycle (fast cycle). The following describes the method for system learning within the system learning cycle (slow cycle). During the system learning cycle, the execution effects of different historical resource scheduling strategies are compared. Based on the execution effects, the large language model, resource allocation constraints, and system operating scenarios are updated so that the resource scheduling cycle can use a more accurate large language model, resource allocation constraints, and system operating scenarios to generate more accurate resource scheduling strategies. Therefore, as... Figure 6 As shown, the method of this application may also include: S301, in response to the triggering time of the system learning cycle, obtain historical resource scheduling logs for multiple resource scheduling cycles within a historical time period, wherein the system learning cycle is longer than the resource scheduling cycle.

[0119] In this embodiment, the number of multiple resource scheduling cycles can be set as needed, such as 5 or 10.

[0120] Within each resource scheduling cycle, the resource scheduling status of each task is recorded, generating corresponding resource scheduling logs. The historical time period is a period of time preceding the current moment. For example, if 20 resource scheduling cycles occurred before the current moment, the historical resource scheduling logs for the last 5 resource scheduling cycles are obtained. The historical resource scheduling logs record all actions within the resource scheduling cycle. Specifically, the historical resource scheduling logs include system parameters within the resource scheduling cycle, generated candidate resource scheduling strategies, the recommended ranking of multiple candidate resource scheduling strategies output by the large language model, repairs to candidate resource scheduling strategies, and the execution results of the optimal resource scheduling strategy.

[0121] S302, based on the historical resource scheduling log, update the system operation scenario and the resource allocation constraints corresponding to the system operation scenario.

[0122] In this embodiment, if the system operation scenario is a resource-abundant scenario, the low-priority task release intensity is set to a first value, and the quota burst limit is set to a second value; if the system operation scenario is a resource-insufficient scenario, the low-priority task release intensity is set to a third value, and the quota burst limit is set to a fourth value, wherein the third value is less than the first value, and the fourth value is less than the second value.

[0123] In this embodiment, historical resource scheduling logs are analyzed to determine the current system operating scenario. For example, the data analysis may include analysis of resource usage, resource reclamation counts, task completion rates, and resource fragmentation.

[0124] Of course, in addition to updating the quota burst limit and priority task release intensity, parameters such as preemptive budget can also be updated, without any restrictions.

[0125] S303, update the model information in the large language model based on the system operating scenario, wherein different system operating scenarios correspond to different model information, and the model information includes prompt words and / or weight parameters.

[0126] In this embodiment, the prompt words are used to guide the large language model to generate a recommended ranking of multiple candidate resource scheduling strategies.

[0127] In this application, the system can correct the large language model and the current system operation scenario through self-learning, so that the system operation scenario determined at different times is accurate. At the same time, it ensures that the large language model outputs more accurate data in the process of continuous correction, so that the resource scheduling strategy obtained in each cycle is more accurate.

[0128] In this application, resource scheduling is modified using a resource scheduling cycle, and resource scheduling parameters are updated through a system learning cycle. This ensures both the real-time performance of online resource scheduling and the accuracy of the parameters used in each calculation of the resource scheduling strategy.

[0129] It should be understood that the sequence number of each step in the above embodiments does not imply 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 embodiments of this application.

[0130] Corresponding to the resource scheduling method described in the above embodiments, Figure 7 A structural block diagram of the resource scheduling device provided in the embodiments of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0131] Reference Figure 7 The device 400 may include: a parameter acquisition module 410, a resource planning module 420, a condition query module 430, a strategy verification module 440, and a task execution module 450.

[0132] The parameter acquisition module 410 is used to acquire current system parameters in response to the triggering time of the resource scheduling cycle. The current system parameters include the task queue, resource allocation status, task characteristics of each task in the task queue, and stored system operation scenario. The resource planning module 420 is used to plan resource configuration for the tasks to be executed according to the priority of the tasks to be executed and the current system parameters, and generate multiple candidate resource scheduling strategies if there are tasks to be executed in the task queue. The condition query module 430 is used to query the resource allocation constraints corresponding to the system operation scenario, wherein different system operation scenarios correspond to different resource allocation constraints. The strategy verification module 440 is used to verify multiple candidate resource scheduling strategies based on the resource allocation constraints to obtain the optimal resource scheduling strategy. The task execution module 450 is used to execute the task to be executed according to the optimal resource scheduling strategy.

[0133] In one possible implementation, the device 400 further includes: The log acquisition module is used to acquire historical resource scheduling logs for multiple resource scheduling cycles within a historical time period in response to the triggering time of the system learning cycle, wherein the system learning cycle is longer than the resource scheduling cycle. The data confirmation module is used to update the system operation scenario and the resource allocation constraints corresponding to the system operation scenario based on the historical resource scheduling log. The information update module is used to update the model information in the large language model based on the system operating scenario. Different system operating scenarios correspond to different model information, and the model information includes prompt words and / or weight parameters.

[0134] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0135] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to 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. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0136] This application also provides a terminal device, see [link to relevant documentation] Figure 8The terminal device 500 may include: at least one processor 510, a memory 520, and a computer program stored in the memory 520 and executable on the at least one processor 510. When the processor 510 executes the computer program, it implements the steps in any of the above method embodiments, for example... Figure 1 Steps S101 to S105 in the illustrated embodiment. Alternatively, when the processor 510 executes the computer program, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 7 The functions of the parameter acquisition module 410 to the task execution module 450 are shown.

[0137] For example, a computer program may be divided into one or more modules / units, one or more of which are stored in memory 520 and executed by processor 510 to complete this application. The one or more modules / units may be a series of computer program segments capable of performing specific functions, which describe the execution process of the computer program in terminal device 500.

[0138] Those skilled in the art will understand that Figure 8 This is merely an example of a terminal device and does not constitute a limitation on the terminal device. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, buses, etc.

[0139] The processor 510 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0140] The memory 520 can be an internal storage unit of the terminal device or an external storage device, such as a plug-in hard drive, a smart media card (SMC), a secure digital (SD) card, or a flash card. The memory 520 is used to store the computer program and other programs and data required by the terminal device. The memory 520 can also be used to temporarily store data that has been output or will be output.

[0141] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0142] The resource scheduling method provided in this application can be applied to terminal devices such as computers, tablets, laptops, netbooks, and personal digital assistants (PDAs). This application does not impose any restrictions on the specific type of terminal device.

[0143] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0144] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0145] In the embodiments provided in this application, it should be understood that the disclosed terminal devices, apparatuses, and methods can be implemented in other ways. For example, the terminal device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, apparatuses, or units, and may be electrical, mechanical, or other forms.

[0146] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0147] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0148] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by one or more processors, it can implement the steps of the various method embodiments described above.

[0149] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by one or more processors, it can implement the steps of the various method embodiments described above.

[0150] Similarly, as a computer program product, when the computer program product is run on a terminal device, it enables the terminal device to implement the steps in the above-described method embodiments.

[0151] The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0152] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions 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 this application, and should all be included within the protection scope of this application.

Claims

1. A resource scheduling method, characterized in that, include: In response to the triggering time of the resource scheduling cycle, the current system parameters are obtained, including the task queue, resource allocation status, task characteristics of each task in the task queue, and stored system operation scenario; If there are tasks to be executed in the task queue, resource configuration is planned for the tasks to be executed based on their priority and the current system parameters, and multiple candidate resource scheduling strategies are generated. Query the resource allocation constraints corresponding to the system operation scenario, where different system operation scenarios correspond to different resource allocation constraints; Based on the resource allocation constraints, the candidate resource scheduling strategies are verified to obtain the optimal resource scheduling strategy. The task to be executed will be performed according to the optimal resource scheduling strategy.

2. The resource scheduling method as described in claim 1, characterized in that, The task queue contains the priority of the tasks to be executed, and the resource allocation status includes the amount of resources used by the currently executing project and the resource quota of the project; The step involves planning resource allocation for the task to be executed based on its priority and the current system parameters, generating multiple candidate resource scheduling strategies, including: If the task to be executed is a high-priority task, obtain the estimated resource consumption required by the task to be executed, wherein the project type of the high-priority task is the first project; If the sum of the estimated resource occupancy and the used resource amount of the first project exceeds the resource quota of the first project, based on the task characteristics of the first task and the estimated resource occupancy, a strategy for resource recovery from the first task is planned to obtain multiple first resource scheduling strategies and an estimated first recovery resource amount for each of the first resource scheduling strategies. The first task is a low-priority task currently being executed in the first project, and the task characteristics of the first task include at least one of interruptibility, cooldown time, and resource occupancy. For each of the first recovered resource quantities, calculate the current remaining resource quantity of the resource pool matched by the first project based on the first recovered resource quantity; If the current remaining resource amount is less than the estimated resource occupancy, a strategy to reclaim resources from the resource pool matched by other projects is planned based on the difference between the estimated resource occupancy and the current remaining resource amount, resulting in multiple second resource scheduling strategies. The other projects are projects that belong to the same resource cluster as the first project. Multiple candidate resource scheduling strategies are generated based on multiple first resource scheduling strategies and multiple second resource scheduling strategies.

3. The resource scheduling method as described in claim 2, characterized in that, The strategy of planning resource recovery from resource pools matched with other projects based on the difference between the estimated resource occupancy and the current remaining resource amount yields multiple second resource scheduling strategies, including: The resource difference for the high-priority task is obtained by subtracting the current remaining resource amount from the estimated resource occupancy. From the resource allocation status, query the remaining resource amount in the resource pool matching the other projects; If the remaining resources of the other projects are less than the resource difference, a strategy for resource reclamation from the second task is planned based on the task characteristics of the second task and the resource difference, resulting in multiple second resource scheduling strategies. The second task is a low-priority task currently being executed in the other projects, and the task characteristics of the second task include at least one of interruptibility, cooldown time, and resource consumption.

4. The resource scheduling method as described in claim 1, characterized in that, The task queue contains the priorities of the tasks to be executed, and the resource allocation status includes the remaining resources of the currently executing project; the resource allocation constraints include the allowance strength for low-priority tasks corresponding to the system operation scenario. The step involves planning resource allocation for the task to be executed based on its priority and the current system parameters, generating multiple candidate resource scheduling strategies, including: If the task to be executed is a low-priority task and the system running scenario is a preset scenario, obtain the required amount of resources for the low-priority task, wherein the preset scenario is a scenario that satisfies the requirement to start the low-priority task, and the project type of the low-priority task is the second project. If the remaining resources of the resource cluster where the second project is located are greater than or equal to the resources required by the low-priority task, the release order of the low-priority task is planned according to the task characteristics and release strength of the low-priority task. The task characteristics of the low-priority task include at least one of the following: number of attempts to start, cooldown time, waiting time, and number of times it has been paused. Based on the release order, resource allocation is planned for the low-priority tasks, and multiple candidate resource scheduling strategies are generated.

5. The resource scheduling method according to any one of claims 1 to 4, characterized in that, The step of verifying multiple candidate resource scheduling strategies based on the resource allocation constraints to obtain the optimal resource scheduling strategy includes: The current system parameters, the system operation scenario, and multiple candidate resource scheduling strategies are input into the trained large language model to obtain a recommendation ranking of the multiple candidate resource scheduling strategies, wherein the recommendation ranking is sorted from high to low according to the degree of recommendation; The verification process begins with the first candidate resource scheduling strategy in the recommended order. For the i-th candidate resource scheduling strategy, the verification is performed based on the resource allocation constraints to obtain the i-th verification result of the i-th candidate resource scheduling strategy, where i ≥ 1. The resource allocation constraints include at least one of quota burst limit, resource capacity, cluster resource topology, and capacity. The quota burst limit represents the upper limit on which tasks are allowed to temporarily preempt additional resources based on the basic resource quota. If the i-th verification result indicates that the verification is successful, then the i-th candidate resource scheduling strategy is determined as the optimal resource scheduling strategy.

6. The resource scheduling method as described in claim 5, characterized in that, After verifying the i-th candidate resource scheduling strategy based on the resource allocation constraints and obtaining the i-th verification result of the i-th candidate resource scheduling strategy, the method further includes: If the i-th verification result indicates that the verification is unqualified, the i-th candidate resource scheduling strategy is repaired based on the reason for the verification failure, and the repaired i-th candidate resource scheduling strategy is obtained. Based on the resource allocation constraints, the i-th candidate resource scheduling strategy after repair is verified, and the i-th repair verification result is obtained. If the i-th repair verification result indicates that the verification is unqualified, the (i+1)-th candidate resource scheduling strategy is verified based on the resource allocation constraints to obtain the (i+1)-th verification result of the (i+1)-th candidate resource scheduling strategy. This process is repeated to obtain the optimal resource scheduling strategy.

7. The resource scheduling method as described in claim 5, characterized in that, The method further includes: In response to the triggering time of the system learning cycle, historical resource scheduling logs for multiple resource scheduling cycles within a historical time period are obtained, wherein the system learning cycle is longer than the resource scheduling cycle. Based on the historical resource scheduling logs, update the system operation scenario and the resource allocation constraints corresponding to the system operation scenario; The model information in the large language model is updated based on the system operating scenario, wherein different system operating scenarios correspond to different model information, and the model information includes prompt words and / or weight parameters.

8. The resource scheduling method as described in claim 7, characterized in that, The resource allocation constraints include the release strength of low-priority tasks and the burst quota limit. The burst quota limit represents the upper limit on which a task is allowed to temporarily preempt additional resources on the basis of the basic resource quota. If the system is operating in a resource-rich scenario, the low-priority task release strength is set to a first value, and the quota burst limit is set to a second value. If the system is operating in a resource-scarce scenario, the low-priority task release strength is set to a third value, and the quota burst limit is set to a fourth value, wherein the third value is less than the first value, and the fourth value is less than the second value.

9. A terminal 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, it implements the resource scheduling method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the resource scheduling method as described in any one of claims 1 to 8.

Images