A task scheduling method and related apparatus

Abstract

The application discloses a task scheduling method and related device, a first performance parameter of a node is used to identify the amount of processor resource used when the performance index of the node meets the time limit condition of the first type task, and a second performance parameter of the node is used to identify the amount of processor resource used when the performance index of the node meets the time limit condition of the second type task. Both can reflect the utilization of processor resource when the node runs which type of task. Correspondingly, the node performance type of the node can be determined based on the two, and the node performance type includes the first type suitable for processing the first type task. When scheduling tasks, the first node with higher performance is allocated to the target first type task with high time limit requirement. Avoid scheduling the task with high time limit requirement to the node whose performance cannot guarantee such task, so as to avoid the problem that the utilization of processor resource is still low due to the failure of the task to be executed because of the failure of performance to guarantee.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a task scheduling method and related apparatus. Background Technology

[0002] A hybrid deployment system refers to a system architecture that can support the simultaneous running of data processing tasks with different timeliness requirements on the same computer cluster or server.

[0003] To fully utilize the processor resources of hybrid deployment systems, related technologies have proposed a multi-task processor resource sharing scheme, which allows processor resources that have been allocated to task A but are now idle to be used for task B processing, thereby improving the utilization rate of processor resources.

[0004] However, even in solutions that support shared processor resources using relevant technologies, the problem of low processor resource utilization still exists. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a task scheduling method and related apparatus, which can avoid the problem of low processor resource utilization caused by the inability to execute tasks due to performance issues after scheduling.

[0006] The embodiments of this application disclose the following technical solutions:

[0007] On one hand, embodiments of this application provide a task scheduling method, the method comprising:

[0008] For N nodes in a hybrid deployment system, obtain a first performance parameter and a second performance parameter corresponding to each of the N nodes. The hybrid deployment system is configured with processor resources for executing data processing tasks. The data processing tasks include a first type of task and a second type of task. The first type of task has higher timeliness requirements than the second type of task. The first performance parameter is used to identify the amount of processor resources used by the node when the node's performance index meets the timeliness requirements of the first type of task. The second performance parameter is used to identify the amount of processor resources used by the node when the node's performance index meets the timeliness requirements of the second type of task.

[0009] Based on the first and second performance parameters of the nodes, determine the node performance types corresponding to the N nodes respectively, wherein the node performance types include a first type suitable for processing the first type of tasks;

[0010] For a target first type of task to be assigned for processing, a first node is determined from the nodes of the first type, and the target first type of task is scheduled to the first node.

[0011] In another aspect, embodiments of this application provide a task scheduling apparatus, the apparatus comprising an acquisition unit, a determination unit, and a scheduling unit:

[0012] The acquisition unit is used to acquire, for N nodes in the hybrid deployment system, first performance parameters and second performance parameters corresponding to each of the N nodes. The hybrid deployment system is configured with processor resources for executing data processing tasks. The data processing tasks include a first type of task and a second type of task. The first type of task has higher timeliness requirements than the second type of task. The first performance parameter is used to identify the amount of processor resources used by the node when the node's performance index meets the timeliness requirements of the first type of task. The second performance parameter is used to identify the amount of processor resources used by the node when the node's performance index meets the timeliness requirements of the second type of task.

[0013] The determining unit is configured to determine the node performance type corresponding to each of the N nodes based on the first performance parameter and the second performance parameter of the node, wherein the node performance type includes a first type suitable for processing the first type of task;

[0014] The scheduling unit is used to determine a first node from the nodes of the first type for a target first type of task to be assigned for processing, and to schedule the target first type of task to the first node.

[0015] On the other hand, embodiments of this application provide a computer device, the computer device including a processor and a memory:

[0016] The memory is used to store computer programs and to transfer the computer programs to the processor;

[0017] The processor is configured to execute the method described in any of the foregoing aspects according to instructions in the computer program.

[0018] On the other hand, embodiments of this application provide a computer-readable storage medium for storing a computer program, which, when run by a computer device, causes the computer device to perform the methods described in any of the foregoing aspects.

[0019] On the other hand, embodiments of this application provide a computer program product, including a computer program that, when run on a computer device, causes the computer device to perform the methods described in any of the foregoing aspects.

[0020] As can be seen from the above technical solution, the hybrid deployment system is configured with processor resources for executing data processing tasks. These tasks include a first type of task and a second type of task, where the first type of task has higher timeliness requirements than the second type. Nodes in the hybrid deployment system are used to execute tasks. A node's first performance parameter indicates the amount of processor resources it uses when its performance meets the timeliness requirements for the first type of task, and a second node performance parameter indicates the amount of processor resources it uses when its performance meets the timeliness requirements for the second type of task. In other words, both parameters reflect the achievable amount of processor resource utilization by a node when handling tasks with different timeliness requirements, thus indicating which type of task a node is running with higher processor resource utilization. Accordingly, the node's performance type can be determined based on these parameters to assess which type of task the node is more suitable for. Specifically, the node performance type includes a first type suitable for handling the first type of task; that is, nodes of the first type are more likely to generate higher processor resource utilization when handling the first type of task. Accordingly, for the target first-type task to be assigned, a first node is determined from the nodes of the first type, and the target first-type task is scheduled to the first node. It can be seen that the processor resource usage of each node in handling tasks with different timeliness requirements is evaluated, along with the node's own performance, to select nodes more suitable for the first-type tasks with high timeliness requirements. This allows task scheduling to consider both the task category and the node's performance, allocating higher-performance first nodes to target first-type tasks with high timeliness requirements. Compared to related technologies that only consider processor resource capacity, this avoids scheduling tasks with high timeliness requirements to nodes with poor performance that cannot guarantee such tasks, thus avoiding the problem of low processor resource utilization caused by tasks failing to execute due to unreliable performance after scheduling. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying 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.

[0022] Figure 1 A schematic diagram of a hybrid deployment system provided in an embodiment of this application;

[0023] Figure 2 This is a schematic diagram illustrating an application scenario of a task scheduling method provided in an embodiment of this application;

[0024] Figure 3A flowchart illustrating a task scheduling method provided in an embodiment of this application;

[0025] Figure 4 This application provides a schematic diagram of a task scheduling method that uses a low-level task as a high-level task in an embodiment of the present application.

[0026] Figure 5 A schematic diagram of a statistical histogram of CPU resources provided in an embodiment of this application;

[0027] Figure 6 A test schematic diagram provided for an embodiment of this application;

[0028] Figure 7 A schematic diagram illustrating a node performance-aware task scheduling strategy provided in an embodiment of this application;

[0029] Figure 8 A schematic diagram illustrating an expulsion strategy provided in an embodiment of this application;

[0030] Figure 9 This application provides a schematic diagram of a resource platform corresponding to an offline submachine.

[0031] Figure 10 A schematic diagram of an architecture for task scheduling provided in an embodiment of this application;

[0032] Figure 11 A structural diagram of a task scheduling device provided in an embodiment of this application;

[0033] Figure 12 A structural diagram of a terminal provided in an embodiment of this application;

[0034] Figure 13 This is a structural diagram of a server provided in an embodiment of this application. Detailed Implementation

[0035] The embodiments of this application will now be described with reference to the accompanying drawings.

[0036] A hybrid deployment system refers to a system architecture that can support the simultaneous execution of data processing tasks with different time-sensitive requirements on the same computer cluster or server. For example, it can support the simultaneous execution of online tasks and offline tasks (such as offline tasks and near-online tasks). Furthermore, in practical applications, even among offline tasks, the time-sensitive requirements of different tasks may vary.

[0037] Online tasks refer to computational tasks that require real-time execution, with high requirements for latency and response time. They typically involve user interaction or time-sensitive data processing tasks, demanding the highest level of timeliness. For example, applications such as online games, real-time video conferencing, and trading systems all require stable and efficient computing resources; tasks submitted in these scenarios are generally considered online tasks.

[0038] Offline tasks refer to computational tasks with lower real-time requirements than online tasks, and can be executed when system resources are idle. Similarly, offline tasks are computational tasks that do not require real-time execution, typically used for batch processing, data analysis, or background tasks, and can run when processor resources are idle to optimize overall resource utilization. Near-line tasks are data processing tasks with lower real-time requirements than online tasks but more urgent than offline tasks. They typically need to be completed within a certain timeframe but do not require immediate response. The timeliness requirements of near-line tasks fall between those of online and offline tasks; their latency tolerance can also be considered to be between that of online and offline tasks. They are typically used in scenarios requiring fast processing but not immediate response.

[0039] Furthermore, hybrid deployment systems are typically configured with processor resources for performing data processing tasks. For example, processor resources may include central processing unit (CPU) resources, graphics processing unit (GPU) resources, etc.

[0040] To fully utilize processor resources, related technologies have proposed a multi-task processor resource sharing scheme, allowing processor resources already allocated to task A (e.g., online task) but idle to be used for task B (e.g., offline task). Compared to fixed allocation technologies, this avoids the problem of wasted resources and low resource utilization caused by processor resources allocated to online tasks being unusable for offline tasks even when idle.

[0041] However, in solutions that support shared processor resources, task scheduling only considers processor capacity, which can lead to some time-sensitive data processing tasks being scheduled to nodes with lower performance. These lower-performance nodes may then struggle to utilize available processor resources, preventing the timely data processing tasks assigned to them from being executed. As a result, processor resource utilization remains low.

[0042] In this context, a node is a logical unit used to execute data processing tasks. It runs on a host machine (or physical machine) and is capable of carrying out specific data processing tasks. Typically, a node can be a virtual sub-machine created on the host machine, and containers or processes can be created on nodes to carry out corresponding data processing tasks. In practical applications, the execution of data processing tasks also requires memory resources. However, the memory resources of a node are fixed and not shared. This means that some nodes may already have relatively full memory utilization, resulting in poor performance, and even if there are idle processor resources, they may be difficult to utilize.

[0043] For ease of understanding, the embodiments of this application provide, as follows: Figure 1 The diagram shown is a schematic of a hybrid deployment system. Figure 1 In this example, taking online and offline tasks sharing processor resources, the specific details are as follows:

[0044] The host machine is a hybrid deployment system.

[0045] A scheduler is used to schedule processor resources, data processing tasks to be allocated, and so on. For example, a scheduler can be a VM First Scheduler (VMF) scheduler.

[0046] Online virtual machines (VMs) are virtual machines created on a host machine using virtualization technology. The VMF scheduler guarantees their highest priority, and they are generally used to run online tasks. Examples include online cloud virtual machines (CVMs). Typically, multiple online VMs can be created on a single host machine as needed. Figure 1 This is merely an example and is not intended to be limiting.

[0047] Offline virtual machines (VMs) are virtual machines created on a host machine using virtualization technology. The VMF scheduler ensures that offline VMs have lower priority than online VMs and are generally used to run offline tasks, such as offline and near-online tasks. For example, CVMs can be run offline. Typically, their processor resources utilize portions of the host machine that are not fully utilized by online VMs. Furthermore, multiple offline VMs can be created on a single host machine as needed. Figure 1 This is merely an example and is not intended to be limiting.

[0048] exist Figure 1 In the example hybrid deployment system, online tasks and offline tasks (including both inline and near-line tasks) share the host machine's processor resources, such as CPU resources. This allows CPU resources allocated to online tasks to be scheduled to offline virtual machines to run offline tasks, near-line tasks, etc., when idle.

[0049] It should also be noted that the aforementioned nodes can be Figure 1 In the example, a sub-machine (such as an offline virtual sub-machine or an online virtual sub-machine) is created on the host machine.

[0050] To address the issue of low processor resource utilization in the aforementioned related technologies, this application provides a task scheduling method and related apparatus. Data processing tasks are categorized into a first category of tasks with high timeliness requirements and a second category of tasks with low timeliness requirements, based on the processor resource usage achievable by a node while handling tasks with different timeliness requirements. The method assesses which type of task a node is more suitable for, i.e., which type of task it utilizes more efficiently, by utilizing the processor resource usage achievable by a node. Accordingly, a first type of node suitable for handling the first type of tasks is identified, and during task scheduling, the target first type of task with high timeliness requirements is scheduled to the first node suitable for handling this type of task.

[0051] Compared to related technologies that only consider processor resource capacity, this application embodiment considers the performance of the node itself, avoiding scheduling tasks with high timeliness requirements to nodes with poor performance that cannot guarantee such tasks. This avoids the problem of low processor resource utilization caused by tasks failing to execute due to unreliable performance after scheduling.

[0052] The task scheduling method provided in this application can be implemented using a computer device, which can be a terminal or a server. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Terminals include, but are not limited to, smartphones, computers, smart voice interaction devices, smart home appliances, and in-vehicle terminals. Terminals and servers can be directly or indirectly connected via wired or wireless communication, and this application does not impose any limitations on this connection.

[0053] The embodiments of this application can be specifically applied to task scheduling scenarios in various hybrid deployment systems. For example, they can support task scheduling scenarios where multiple types of tasks with different timeliness requirements share processor resources. Specifically, they can support task scheduling scenarios where online tasks and offline tasks (including offline tasks and near-online tasks) share CPU resources, as described above. Figure 1 Example.

[0054] It should be noted that in the specific embodiments of this application, the process of task scheduling may involve user information and other related data. When the above embodiments of this application are applied to specific products or technologies, it is necessary to obtain separate consent or permission from the user, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0055] Figure 2 This illustration shows an application scenario of the task scheduling method provided in the embodiments of this application. Figure 2 In the scenario shown, server 200 is used as an example of the aforementioned computer equipment for illustration:

[0056] exist Figure 2 In the example, taking N=3 (including nodes 1, 2, and 3) and CPU resources as the processor resource, the data processing tasks to be executed can include two types of tasks. The first type of task has higher timeliness requirements than the second type. Specifically:

[0057] First, server 200 can obtain the first performance parameter a1 and the second performance parameter b1 corresponding to node 1, the first performance parameter a2 and the second performance parameter b2 corresponding to node 2, and the first performance parameter a3 and the second performance parameter b3 corresponding to node 1.

[0058] Taking node 1 as an example, a1 is used to identify the amount of CPU resources used when the performance index of node 1 meets the timeliness requirements of the first type of task, and b1 is used to identify the amount of CPU resources used when the performance index of node 1 meets the timeliness requirements of the second type of task.

[0059] Among these, node performance metrics reflect node performance, while task timeliness requirements identify the timeliness requirements for processing. Typically, the timeliness requirements for Category I tasks are higher than those for Category II tasks, and the timeliness requirements for Category I tasks are more stringent. When a node's performance metrics meet the task timeliness requirements, it can be considered that the node can guarantee that the performance of the tasks running on it meets the timeliness requirements for processing.

[0060] Therefore, a1 reflects the CPU resource usage of node 1 when ensuring the timeliness requirements of the tasks running on it are of the first type, and b1 reflects the CPU resource usage of node 1 when ensuring the timeliness requirements of the tasks running on it are of the second type. Thus, both reflect the achievable CPU resource usage of node 1 when handling tasks with different timeliness requirements, thereby indicating which type of task node 1 utilizes more CPU resources, i.e., achieving higher CPU resource utilization.

[0061] Therefore, based on a1 and b1, the performance of node 1 can be evaluated to determine whether node 1 is more suitable for running the first type of task or the second type of task. Similarly, the explanation for nodes 2 and 3 is similar to that for node 1.

[0062] Accordingly, server 200 can determine the node performance type corresponding to each node. For example, it can determine that the node performance type of node 2 is type 1, and the node performance type of node 3 is also type 1. Nodes of type 1 are suitable for processing type 1 tasks.

[0063] Next, for the first type of task to be assigned and processed, server 200 can determine the first node from node 2 and node 3, such as in Figure 1 In the example, the first node is node 3, and the target type 1 task is scheduled to node 3 so that the target type 1 task can be run through node 3.

[0064] As can be seen, by evaluating the processor resource usage of nodes when handling tasks with different time-sensitive requirements, and by selecting nodes of the first type that are more suitable for the first type of tasks with high time-sensitive requirements, the scheduling process can allocate higher-performance nodes to the first type of tasks with high time-sensitive requirements.

[0065] Compared to related technologies that only consider processor resource capacity, this approach avoids scheduling time-sensitive tasks to nodes with poor performance that cannot guarantee such tasks. This prevents the problem of low CPU resource utilization resulting from task failure due to unreliable performance after scheduling. Therefore, it helps improve CPU resource utilization in hybrid deployment systems and avoids wasting idle CPU resources.

[0066] Figure 3 A flowchart of a task scheduling method provided in this application embodiment, using a server as an example of the aforementioned computer device, is used for illustration. The method includes S301-S303:

[0067] S301: For N nodes in a hybrid deployment system, obtain the first performance parameter and the second performance parameter corresponding to each of the N nodes.

[0068] The hybrid deployment system is configured with processor resources for performing data processing tasks, such as CPU resources and GPU resources. The hybrid deployment system can be a system architecture deployed on a host machine (or physical machine), the same computing cluster, or a server. In a hybrid deployment system, multiple types of tasks with different timeliness requirements can share processor resources.

[0069] Data processing tasks refer to computational tasks that need to be performed. In practical applications, different tasks have different requirements for processing timeliness. Data processing tasks can be divided into two categories, with the first category having higher requirements for processing timeliness than the second category.

[0070] It should be noted that this application does not impose any limitations on data processing tasks, or specifically on the first and second types of tasks. In practical applications, configuration can be performed as needed. For example, in one instance, both the first and second types of tasks can be the aforementioned offline tasks, but the timeliness requirements for the first type of task are higher than those for the second type.

[0071] Furthermore, this application does not impose any limitations on the timeliness requirements. For ease of understanding, the following examples are provided in the embodiments of this application:

[0072] Understandably, compared to a solution that exclusively uses processor resources, a shared processor resource approach may require tasks to wait for processor resources to become available, which could lead to a decrease in task execution speed.

[0073] Therefore, as an example, the timeliness requirements of a task can be determined by the lower limit of the speed reduction it incurs, which can also be called the performance guarantee target for the task's execution performance. In specific implementation, the first and second types of tasks can be distinguished by the maximum tolerable speed reduction factor when sharing processor resources versus exclusively using the same amount of processor resources. For example, the first type of task corresponds to a 2x speed reduction, and the second type of task corresponds to a 4x speed reduction.

[0074] In practical implementation, the degree of speed degradation can be reflected by the total time spent by the nodes (i.e., the virtualization cores) bound to the task waiting for processor resources, and the proportion of this time relative to the total non-idle time of processor resources. This proportion can be called Pod Stealtime. For example, the upper limit of Pod Stealtime for the first type of task is set to 45%, such as data generation tasks for parallel model training, near-line video image transcoding tasks, etc. And the upper limit of Pod Stealtime for the second type of task is set to 65%, such as log processing, data backup, batch file conversion, etc.

[0075] In practical applications, the first type of task has higher requirements for processing timeliness and can be called a task with a high-performance guarantee objective, or simply a "high-task". Correspondingly, the second type of task has lower requirements for processing timeliness and can be called a task with a low-performance guarantee objective, or simply a "low-task". Relatively speaking, the lower limit requirements for the operating performance of high-tasks are higher than those of low-tasks, and it can also be considered that low-tasks have a higher tolerance and compatibility with node performance fluctuations.

[0076] A node can be used to perform tasks; for example, it can be a virtual sub-machine created on a host machine. N is a positive integer used to represent the number of nodes.

[0077] It should also be noted that this application does not impose any restrictions on the node settings. In one example, the value of N can be determined based on the actual number of virtual submachines created.

[0078] In another example, the specific virtual submachines of the nodes can be set according to the characteristics of the first and second types of tasks to be scheduled. For instance, in a scenario where online and offline tasks share processor resources, online tasks typically run in online virtual submachines, while offline tasks run in offline virtual submachines. Since the scheduler guarantees the highest priority for online virtual submachines, the performance of offline tasks is less guaranteed compared to online tasks. Therefore, this application can be primarily applied to the scheduling of offline tasks. In this case, N nodes can represent N offline virtual submachines. The aforementioned first and second types of tasks can also both be offline tasks.

[0079] For a node, the first performance parameter identifies the amount of processor resources used by the node when its performance metrics meet the timeliness requirements for the first type of task. The second performance parameter identifies the amount of processor resources used by the node when its performance metrics meet the timeliness requirements for the second type of task. The node's performance metrics reflect its overall performance.

[0080] The timeliness requirements for a task are used to identify the timeliness requirements for processing that task. That is, the timeliness requirements for the first type of task can be used to identify the timeliness requirements for processing that type of task, and the same applies to the timeliness requirements for the second type of task. In practical applications, if the performance indicators of a node can meet the timeliness requirements for the task when it runs, it indicates that the node can guarantee the timeliness requirements for processing that task, meaning that the running performance of the task meets the timeliness requirements.

[0081] Therefore, the first performance parameter reflects the amount of processor resources a node uses to ensure that the tasks running on it meet the timeliness requirements of the first type of tasks, and the second performance parameter reflects the amount of processor resources a node uses to ensure that the tasks running on it meet the timeliness requirements of the second type of tasks. Accordingly, both parameters reflect the amount of processor resources that the node can utilize to ensure tasks with different timeliness requirements. Based on these parameters, it is possible to assess which type of task the node can handle with greater processor resource utilization, i.e., which results in greater processor resource utilization.

[0082] S302: Determine the node performance type corresponding to each of the N nodes based on the first and second performance parameters of the nodes.

[0083] The node performance type indicates which type of task the node is suitable for handling. Specifically, the node performance type can include a first type suitable for handling the first type of tasks. That is, nodes of the first type are suitable for handling the first type of tasks with higher timeliness requirements.

[0084] S303: For the target first type of task to be assigned and processed, determine the first node from the first type of nodes and schedule the target first type of task to the first node.

[0085] Here, the target first-category task refers to a data processing task that is yet to be assigned for processing. For example, it could be a newly submitted first-category task from the business side, or a first-category task that was originally running on a certain node but was evicted for some reason. And, the first node refers to the node used to carry the target first-category task.

[0086] Because the target type I task has high timeliness requirements, and type I nodes are suitable for handling such tasks, the server can determine the first node from the type I nodes and schedule the target type I task to the first node. After scheduling, the target type I task can be run through the first node.

[0087] As can be seen from the above technical solution, the hybrid deployment system is configured with processor resources for executing data processing tasks. These tasks include a first type of task and a second type of task, where the first type of task has higher timeliness requirements than the second type. Nodes in the hybrid deployment system are used to execute tasks. A node's first performance parameter indicates the amount of processor resources it uses when its performance meets the timeliness requirements for the first type of task, and a second node performance parameter indicates the amount of processor resources it uses when its performance meets the timeliness requirements for the second type of task. In other words, both parameters reflect the achievable amount of processor resource utilization by a node when handling tasks with different timeliness requirements, thus indicating which type of task a node is running with higher processor resource utilization. Accordingly, the node's performance type can be determined based on these parameters to assess which type of task the node is more suitable for. Specifically, the node performance type includes a first type suitable for handling the first type of task; that is, nodes of the first type are more likely to generate higher processor resource utilization when handling the first type of task. Accordingly, for the target first-type task to be assigned, a first node is determined from the nodes of the first type, and the target first-type task is scheduled to the first node. It can be seen that the processor resource usage of each node in handling tasks with different timeliness requirements is evaluated, along with the node's own performance, to select nodes more suitable for the first-type tasks with high timeliness requirements. This allows task scheduling to consider both the task category and the node's performance, allocating higher-performance first nodes to target first-type tasks with high timeliness requirements. Compared to related technologies that only consider processor resource capacity, this avoids scheduling tasks with high timeliness requirements to nodes with poor performance that cannot guarantee such tasks, thus avoiding the problem of low processor resource utilization caused by tasks failing to execute due to unreliable performance after scheduling.

[0088] The above embodiments have provided illustrative examples of the task scheduling method provided in this application. For a more comprehensive understanding, this application will be further described through the following embodiments.

[0089] I. This application does not limit the method for determining the node performance type, i.e., the implementation method of S302 mentioned above. For ease of understanding, the following examples are provided in this application:

[0090] For ease of understanding, the first performance parameter is denoted as X1, and the second performance parameter as X2. X1 / X2 represents the processor resource utilization a node can achieve by setting a performance guarantee floor for Type II tasks (such as the aforementioned 65%) compared to setting a performance guarantee floor for Type I tasks (such as the aforementioned 45%), which is X2 / X1 times higher. Therefore, the smaller X1 / X2 is, the greater the increase in processor resource utilization when setting a performance guarantee floor for Type II tasks, and the lower the cost of running Type II tasks (i.e., the low-performance guarantee target low-level tasks mentioned above), making it more suitable for running Type II tasks. Conversely, the larger X1 / X2 is, the smaller the increase in processor resource utilization when setting a performance guarantee floor for Type II tasks. Since the cost of running Type II tasks is not significantly different from that of running Type I tasks, such nodes are more suitable for running Type I tasks.

[0091] Therefore, as in Example 1-1: the node performance type can be determined directly based on X1 and X2. Specifically:

[0092] In one implementation, for nodes whose X1 / X2 ratio is less than a certain threshold, their node performance type can be determined as the second type, suitable for processing the second type of task. And for nodes whose X1 / X2 ratio is greater than or equal to the threshold, their node performance type is determined as the first type, suitable for processing the first type of task. Based on this, the node performance type of each node can be quickly determined in a simple and convenient way.

[0093] In another implementation, the ratio of X1 / X2 can be determined as the performance ratio parameter of the node, and the N nodes are sorted according to the size of X1 / X2 to obtain the first ordered set. The performance ratio parameter of the i-th node in the first ordered set is less than the performance ratio parameter of the (i+1)-th node, where 1≤i≤N.

[0094] Next, node performance types are assigned to these N nodes. For example, the first preset number of nodes in the first ordered set are of type 2, and the next preset number of nodes are of type 1. For example, the preset number can be 1 / 2N, or if N is an odd number, it can be 1 / 2(N-1) of type 1 (or type 2) or 1 / 2(N-1)+1 of type 2 (or type 1). This application does not impose any limitations on this.

[0095] As examples 1-2: Based on X1 and X2, the node performance type can also be determined by considering the load conditions of the hybrid deployment system. Specifically:

[0096] The server can obtain the first resource allocation corresponding to the first type of task running in the hybrid deployment system, and the second resource allocation corresponding to the second type of task running in the hybrid deployment system. Then, based on the first and second performance parameters, as well as the first and second resource allocations corresponding to the N nodes, the server can determine the first type of nodes with the first performance type and the second type of nodes with the second performance type from the N nodes. The second type of nodes are suitable for processing the second type of task.

[0097] The first resource allocation can refer to the amount of processor resources allocated to the first type of tasks running in the hybrid deployment system, such as now_t_h. The second resource allocation can refer to the amount of processor resources allocated to the second type of tasks running in the hybrid deployment system, such as now_t_l. Since both are tasks running in the hybrid deployment system, they can represent the current load situation in the hybrid deployment system.

[0098] Furthermore, the first type of node refers to a node with a performance type of the first category. It is suitable for handling the first type of tasks (i.e., high tasks), and therefore can be called a node suitable for high-performance assurance tasks, or simply a "high node". The second type of node refers to a node with a performance type of the second category. It is suitable for handling the second type of tasks (i.e., low tasks), and therefore can also be called a node suitable for low-performance assurance tasks, or simply a "low node".

[0099] As can be seen, based on X1 and X2, considering the first and second resource allocations, i.e., the current load situation in the comprehensive hybrid deployment system, the first and second types are determined. This ensures that the identified first-type nodes can meet the load conditions of the running first-type tasks, and the second-type nodes can meet the load conditions of the running second-type tasks, thus balancing the needs of both types of currently running tasks.

[0100] Regarding Examples 1-2, it should also be noted that this application does not impose any limitations on the specific method for determining the first type of node and the second type of node based on X1, X2, and the first and second resource allocation amounts. For ease of understanding, the embodiments of this application provide the following examples:

[0101] To meet the needs of the two types of tasks currently in operation, as an example, specific implementations could include A11-A14:

[0102] A11: The ratio of the node's first performance parameter to its second performance parameter is determined as the node's performance ratio parameter.

[0103] A12: Sort the N nodes according to the magnitude of their respective performance ratio parameters to obtain a first ordered set. In this first ordered set, the performance ratio parameter of the i-th node is less than that of the (i+1)-th node, where 1 ≤ i ≤ N.

[0104] A13: Obtain the third and fourth performance parameters corresponding to N nodes respectively. The third performance parameter can be used to identify the amount of processor resources allocated to the node when the node's performance index meets the timeliness requirements of the first type of task. The fourth performance parameter can be used to identify the amount of processor resources allocated to the node when the node's performance index meets the timeliness requirements of the second type of task.

[0105] A14: For the first ordered set, starting from the Nth node, sum the third performance parameters of the nodes sequentially backward. When the sum of the third performance parameters of the last k nodes satisfies the first resource allocation, the node performance type of the last k nodes is determined as the first type. Similarly, starting from the 1st node, sum the fourth performance parameters of the nodes sequentially backward. When the sum of the fourth performance parameters of the first t nodes satisfies the second resource allocation, the node performance type of the first t nodes is determined as the second type. Here, t and k are both positive integers less than or equal to N.

[0106] Specifically, steps A11-A12 sort the N nodes using the ratio of X1 / X2. A node ranked higher in the sorting is more suitable as a low-level node, and a node ranked lower is more suitable as a high-level node. Next, considering that task scheduling in practical applications is based on the remaining, allocable resources, the aforementioned third and fourth performance parameters are also obtained when determining how many low-level and high-level nodes to allocate. Then, for the first ordered set, allocation begins from both ends:

[0107] When the sum of the third performance parameters of the last k nodes satisfies the first resource allocation, it indicates that the total amount of processor resources allocated to these last k nodes is sufficient to meet the needs of the currently running first-type task. Therefore, these last k nodes are considered sufficient to meet the requirements of the currently running first-type task. Accordingly, the node performance type of these last k nodes is determined to be the first type.

[0108] Similarly, when the sum of the fourth performance parameters of the first t nodes satisfies the second resource allocation amount, it indicates that the total amount of processor resources allocated to these first t nodes is sufficient to meet the amount of processor resources allocated to the currently running second type of task. Therefore, it is considered that these first t nodes are sufficient to meet the needs of the currently running second type of task. Accordingly, the node performance type of these first t nodes is determined to be the second type.

[0109] In this way, the allocated first and second type nodes are sufficient to meet the needs of the two types of tasks currently running, making the evaluation of node performance more accurate without affecting current requirements. Furthermore, this method allows the simultaneous allocation of high and low performance nodes from both ends after obtaining the first ordered set, thereby improving the efficiency of determining the node performance type.

[0110] In practical applications, offline tasks typically have lower priority and are therefore not overloaded, resulting in remaining nodes after the allocation in step A14. This application does not impose any limitations on how to determine the node performance type of these remaining nodes (i.e., nodes whose performance type was not determined in step A14). For ease of understanding, the following examples are provided in this application's embodiments:

[0111] If t < Nk, it indicates that there are still remaining nodes, and the remaining nodes are the (t+1)th node to the Nkth node. Accordingly, for the (t+1)th node to the Nkth node, their node performance type can also be determined in the following way.

[0112] To avoid situations where certain types of nodes are excessively idle or too few, leading to a lack of suitable nodes for available tasks, one possible implementation involves combining historical load data from the hybrid deployment system to determine the performance type of the remaining nodes. This ensures a more balanced and reasonable distribution of the total number of first-type and second-type nodes, thus balancing the allocation of tasks to be processed. In specific implementations, this can include A21-A23:

[0113] A21: Obtain the first historical resource allocation corresponding to the first type of task running in the hybrid deployment system within the historical period, and the second historical resource allocation corresponding to the second type of task running in the hybrid deployment system within the historical period.

[0114] It should be noted that this application does not impose any restrictions on the historical time period settings. For example, it could be a period of time prior to the current performance evaluation cycle, such as statistical analysis of load conditions over the past 24 hours.

[0115] The first historical resource allocation refers to the amount of processor resources allocated to the first type of tasks running within a historical period, and the second historical resource allocation refers to the amount of processor resources allocated to the second type of tasks running within the same historical period. Both reflect the historical load of processor resources in a hybrid deployment system, specifically the historical load on each type of task. Typically, the task allocation of a hybrid deployment system does not change significantly in the short term. Therefore, historical load data can be used to predict the processor resource requirements of the two types of tasks that may need to be allocated in the future. Based on this, the remaining nodes can be allocated to accommodate future task scheduling.

[0116] A22: Determine the first idle degree of the first type of node based on the first total allocation and the first historical resource allocation corresponding to the first type of node, and determine the second idle degree of the second type of node based on the second total allocation and the second historical resource allocation corresponding to the second type of node.

[0117] Wherein, the first total allocation is the sum of the third performance parameters corresponding to the first type of nodes, and the second total allocation is the sum of the fourth performance parameters corresponding to the second type of nodes. Furthermore, the first idle degree can be used to represent the idle level of the processor resources corresponding to the currently identified first type of nodes compared to the historical load of the first type of tasks, and the second idle degree can be used to represent the idle level of the processor resources corresponding to the current second type of nodes compared to the historical load of the second type of tasks.

[0118] A23: The node allocation target is the difference between the first idle degree and the second idle degree being less than a preset threshold. Starting from the Nkth node, the node performance type of the node is determined to be the first type, and starting from the t+1th node, the node performance type of the node is determined to be the second type.

[0119] For the remaining nodes, they are assigned to the first type of nodes forward and the second type of nodes backward. The node allocation target and constraints for this allocation are designed to ensure that the idle time of the two types of nodes obtained after allocation is approximately the same, specifically, the difference is less than a preset threshold. It should be noted that this application does not impose any restrictions on the setting of the preset threshold, which can be set according to the actual situation, such as 0.1, 0.2, etc.

[0120] Based on this, when determining the node performance type for the remaining nodes, historical load conditions were comprehensively considered, and the idle degree of the two types of nodes was roughly the same as a constraint condition. This can avoid problems such as excessive idle resources of one type of node and lack of resources of another type of node, which may lead to problems such as no suitable node for a certain type of task to be assigned for processing later.

[0121] In summary, for N nodes, the allocation process for determining the first type of nodes (i.e., high-level nodes) and the second type of nodes (i.e., low-level nodes) involves two rounds. Specifically: In the first round, allocation proceeds sequentially from both ends until the current load of the hybrid deployment system is met, thus ensuring currently running tasks are covered. In the second round, a constraint is used to ensure that the idle levels of the two types of nodes are roughly equal, guaranteeing a balanced allocation. Accordingly, in the second round of allocation, i.e., the specific implementation of A23, if the first idle level is lower, then first-type nodes are allocated; if the second idle level is lower, then second-type nodes are allocated, until finally the idle levels of both types are roughly equal and all nodes have been allocated.

[0122] It should also be noted that this application does not impose any limitations on the method for determining idle time. For ease of understanding, the following examples are provided in the embodiments of this application:

[0123] In one possible implementation, the ratio of the first total allocation to the first historical resource allocation can be determined as the first idle level, and the ratio of the second total allocation to the second historical resource allocation can be determined as the second idle level. Based on this, the idle level of processor resources can be simply and intuitively represented.

[0124] In practical applications, task execution requires not only processor resources but also memory resources. Therefore, another possible implementation approach is to comprehensively consider memory resource availability to determine idle time, thereby improving the accuracy of idle time determination. In specific implementation:

[0125] The memory resources of the first type of nodes can be summed to obtain the first total memory, and the memory resources of the second type of nodes can be summed to obtain the second total memory. Correspondingly, the first historical total memory corresponding to the first type of tasks running in the historical period, and the second historical total memory corresponding to the second type of tasks running in the historical period, can also be calculated.

[0126] Accordingly, the first idle level can be min(cap_t_h / his_t_h, cap_m_h / his_m_h), and the second idle level can be min(cap_t_l / his_t_l, cap_m_l / his_m_l). Here, cap_t_h represents the first total allocation, his_t_h represents the first historical resource allocation, cap_m_h represents the first total memory, and his_m_h represents the first historical total memory. Similarly, cap_t_l represents the second total allocation, his_t_l represents the second historical resource allocation, cap_m_l represents the second total memory, and his_m_l represents the second historical total memory.

[0127] In addition, the system idleness corresponding to the hybrid deployment system can be recorded as min(first idleness, second idleness) to evaluate the idleness of the hybrid deployment system as a whole.

[0128] II. This application does not impose any limitations on the scheduling method for the second type of task (i.e., the aforementioned low-level tasks). For ease of understanding, the embodiments of this application provide the following examples:

[0129] As an example 2-1: Low-level tasks can be directly scheduled to low-level nodes. Specifically:

[0130] The second type of task has lower timeliness requirements and can be directly scheduled to a suitable second-type node for processing. In practice, for the target second-type task to be assigned, a second node is determined from the second-type nodes, and the target second-type task is scheduled to the second node. The target second-type task can be a newly submitted second-type task or a second-type task that was originally running on a node but was evicted and needs rescheduling. The second node is the node used to host the target second-type task.

[0131] Based on this, low-level tasks can be directly scheduled to low-level nodes, which is simple and convenient. Since low-level nodes are designed to handle low-level tasks, task performance targets can be guaranteed and resource idleness on low-level nodes can be avoided, thereby improving overall resource utilization.

[0132] As an example 2-2: Lower-level tasks can be scheduled as higher-level tasks and assigned to higher-level nodes. Specifically:

[0133] In practical applications, some high-performance tasks exhibit low processor resource requests and high memory resource requests, which may result in high-performance nodes having more remaining processor resources than memory resources. Conversely, some low-performance tasks exhibit high processor resource requests and low memory resource requests. Therefore, in another possible implementation, for the target second-type task to be allocated processing, if the ratio of the processor resource request amount to the memory resource request amount corresponding to the target second-type task is greater than the mixing ratio threshold, a third node is determined from the first-type nodes, and the target second-type task is scheduled to the third node.

[0134] The processor resource request amount for the second type of target task refers to the amount of processor resources requested by the task. Taking CPU resources as an example, it can be denoted as request_cpu. The memory resource request amount for the second type of target task refers to the amount of memory resources requested by the task, which can be denoted as request_mem. The mixing ratio threshold can be a condition used to determine whether a task can be considered a high-performing task, such as denoted as mix_threshold. If request_cpu / request_mem > mix_threshold, then the task can be considered a high-performing task, and thus a third node can be determined from the high-performing nodes to carry the second type of target task.

[0135] Understandably, since high-performance nodes are suited for handling high-performance tasks, they can also ensure the performance of low-performance tasks with lower timeliness requirements. Therefore, by using low-performance nodes as high-performance nodes, we can not only ensure the performance of tasks, but also make full use of the idle processor resources on high-performance nodes (such as third-party nodes), so that the use of processor and memory resources on high-performance nodes is more balanced, thereby improving the overall resource utilization.

[0136] Regarding Example 2-2, it should also be noted that this application does not impose any limitations on how to determine the method of using low values ​​as high values, nor on the mixing ratio threshold. For ease of understanding, this application provides examples and illustrations below.

[0137] Example 2-2-1:

[0138] To avoid high-level nodes being overloaded by low-level tasks, leading to excessive idleness (low resource utilization) on low-level nodes and a lack of suitable nodes for high-level tasks awaiting processing (making time-sensitive tasks unable to execute), another possible implementation method is to set a mixed limit. In practical implementation:

[0139] If the ratio of the processor resource request amount corresponding to the target second-type task to the memory resource request amount corresponding to the target second-type task is greater than the mixing ratio threshold, and the mixing limit of processor resources is greater than the sum of the allocated mixed resources and the processor resource request amount of the target second-type task, then a third node is determined from the first-type nodes. Furthermore, after scheduling the target second-type task to the third node, the processor resource request amount of the target second-type task is accumulated into the allocated mixed resources to obtain an updated allocated mixed resources amount.

[0140] Among them, the processor resource mixing limit is used to represent the upper limit of processor resources that can be allocated to mixed tasks, such as denoted as mix_x. The amount of allocated mixed resources refers to the amount of processor resources that have been allocated to mixed tasks, such as denoted as allocated_mix_x. A mixed task is a task that uses low resources as high resources.

[0141] Therefore, when request_cpu / request_mem > mix_threshold, it indicates that the task can be considered a high-level task. Furthermore, when mix_x > allocated_mix_x + request_cpu, it means that scheduling this task to a high-level node will not exceed the mixing limit. Only when both conditions are met will the lower-level task be considered the higher-level task, and the target second-type task will be scheduled to the third node.

[0142] Furthermore, allocated_mix_x is updated after scheduling, so that if a new low task that can be considered a high task is subsequently added, it will no longer be treated as a high task if the second condition is not met. For example, in practical implementation, whenever a low task with a proportion exceeding mix_threshold is sent to a high node, the count is incremented to update allocated_mix_x.

[0143] Based on this, we can achieve balanced resource utilization of high nodes by using low-level tasks as high-level tasks, while limiting the amount of low-level tasks used as high-level tasks to avoid problems such as high nodes being over-occupied by low-level tasks.

[0144] Understandably, for better scheduling, a set of mixed tasks can be maintained. When a task in this set finishes running, it is removed from the set, and its count is reduced to deduct its processor resource request from allocated_mix_x. This ensures the accuracy of allocated_mix_x.

[0145] To better understand, embodiments of this application also provide, as follows: Figure 4 The diagram illustrates a task scheduling approach where a lower-level task is used as a higher-level task. Specifically:

[0146] With N=6, after evaluating node performance, nodes 1, 2, and 3 are identified as the second type of nodes (low-level nodes), and nodes 4, 5, and 6 are identified as the first type of nodes (high-level nodes). After task scheduling, node 1 runs low-level tasks 1 and 2, node 2 runs low-level task 3, and node 3 runs low-level task 4. Additionally, node 4 runs high-level task 3 and low-level task 5, node 5 runs high-level task 2, and node 6 runs high-level task 1.

[0147] That is, node 4 is a high-level node that carries low-level tasks. To facilitate understanding, this example illustrates task scheduling where low-level tasks are used as high-level tasks:

[0148] exist Figure 4In the example, when only high-level task 3 is running on node 4, its CPU and memory resource usage is shown in ①. For low-level task 5, which has a large ratio of CPU resource request to memory resource request, it is a task with high CPU demand and low memory demand. After determining that the low-level task should be prioritized over the high-level task, low-level task 5 is scheduled to node 3. After scheduling, the CPU and memory resource usage on node 4 is shown in ②.

[0149] Clearly, by adopting a scheduling approach that prioritizes lower-level tasks, the CPU and memory resources of node 4 are used more evenly. Furthermore, because node 4 is a higher-level node, it can guarantee the timeliness requirements of lower-level task 5.

[0150] Example 2-2-2:

[0151] The mixing threshold is a condition used to determine whether a task can be considered a high-performing task. Specifically, the mixing threshold can be the ratio between the mixing limit of processor resources and the mixing limit of memory resources corresponding to the hybrid deployment system. The mixing limit of processor resources is the aforementioned `mix_x`. The mixing limit of memory resources can refer to the upper limit of memory that can be allocated to hybrid tasks, such as denoted as `mix_m`. That is, `mix_threshold = mix_x / mix_m`.

[0152] The mixed limit for processor resources is determined based on the amount of processor resources requested by data processing tasks running in the mixed deployment system during a historical period, and the mixed limit for memory resources is determined based on the amount of memory resources requested by data processing tasks running in the mixed deployment system during a historical period.

[0153] Based on this, considering historical load conditions, we can flexibly set hybrid limits so that hybrid deployment systems with different historical loads can determine the appropriate hybrid limits, which is conducive to achieving optimal overall resource utilization by adopting a hybrid approach.

[0154] It should also be noted that this application does not impose any limitations on how to determine the mixed limits for processor resources and memory resources. For ease of understanding, embodiments of this application refer to data processing tasks running in the hybrid deployment system during historical periods as historical tasks, and provide the following examples:

[0155] For historical tasks running within a historical time period in a hybrid deployment system, statistics are compiled based on the ratio of processor resource requests to memory resource requests for each historical task, resulting in a statistical histogram. For ease of understanding, using CPU resources as an example, the following is obtained: Figure 5The diagram shows a statistical histogram of CPU resources. Specifically, the horizontal axis represents the ratio of CPU resource requests to memory resource requests, and the vertical axis represents the CPU resource requests. In this histogram, each bar represents the sum of CPU resource requests for historical tasks that fall within that ratio.

[0156] Accordingly, when determining the mixing limit, the low-performance guaranteed tasks (i.e., low tasks) with a mix% ratio can be selected as the mixing tasks. When selecting, you can select from the maximum side to the minimum side of the histogram until the total CPU resource request amount (such as the number of CPU core requests) of the selected historical tasks reaches mix%*his_t_h. Then, record the total CPU resource request amount of these historical tasks as mix_x, and you can also record the total memory resource request amount of these historical tasks as mix_m.

[0157] It is understood that the above example is merely one possible implementation and is not intended to be limiting. For instance, one could also analyze the histogram of memory resources and then determine mix_x and mix_m. Alternatively, one could directly set mixing limits based on historical load data.

[0158] It should also be noted that in the method that supports low-to-high scheduling (i.e., supports mixed scheduling), mixed tasks (i.e., low tasks scheduled to high nodes) are treated as high tasks, i.e., as Category I tasks. Consequently, the aforementioned first historical resource allocation amount, second historical resource allocation amount, etc., are updated compared to the method that does not support mixed scheduling. Specifically:

[0159] Regarding historical load conditions, the historical load considered as a high task is the sum of the historical load of high tasks and the historical load of low tasks (which are considered high when they are low), and the historical load considered as a low task is the difference between the historical load of low tasks and the historical load of low tasks (which are considered high when they are low). Accordingly, the historical loads considered as high tasks (his_t_h', his_m_h') and the historical loads considered as low tasks ((his_t_l', his_m_l')) are derived. The corresponding current loads (now_t_h', now_m_h') and (now_t_l', now_m_l') are also derived. The updated load conditions are then used in the aforementioned calculations. For example, when calculating the first idle time, it is min(cap_t_h / his_t_h', cap_m_h / his_m_h'), and other similar calculations follow the same logic.

[0160] It is understandable that the aforementioned statistical histogram can be used more conveniently and quickly to determine the first resource allocation, the second resource allocation, the first historical resource allocation, and the second historical resource allocation. The same principle applies to the allocation of memory resources.

[0161] It should also be noted that this application does not impose any limitations on how to determine methods such as statistical histograms. For ease of understanding, the embodiments of this application provide the following examples:

[0162] As an example, a historical load feature array can be stored, representing the moving average of the histogram for each hour over 24 hours. A current load feature can also be stored. By dynamically updating this array, the historical and current load conditions can be quickly determined. For instance, two historical load feature updates are triggered every hour, and the statistical histogram of the corresponding historical load feature is updated using the formula: old x_i = lambda * old x_i + (1-lambda) * present x_i.

[0163] Where i represents the i-th bar in the statistical histogram, old x_i represents the updated y-axis value corresponding to the i-th bar, present x_i represents the current y-axis value, and lambda represents the weighting coefficient (usually a value between 0 and 1, with a smaller value). Based on this, the update considers both the current situation and the previous situation, especially at high update frequencies, and can take into account changes caused by noise (such as faults), making the updated histogram more accurate.

[0164] Third, this application does not impose any limitations on how to determine the first node, the second node, or the third node. For ease of understanding, the following examples are provided in the embodiments of this application:

[0165] Example 3-1:

[0166] Regarding the determination of the first node, as an example, in specific implementation, it can include B11-B14:

[0167] B11: Obtain the processor resource request amount and memory resource request amount corresponding to the target first-type task. These two values ​​represent the requirements of the target first-type task, such as request_cpu and request_mem respectively.

[0168] B12: From the nodes of the first type, the nodes whose remaining processor resources are greater than or equal to the processor resource request amount corresponding to the target first type of task, and whose remaining memory resources are greater than or equal to the memory resource request amount corresponding to the target first type of task, are determined as the first available nodes.

[0169] Among these, the remaining processor resources can be used to identify the amount of processor resources that the node can still allocate, and the remaining memory resources can be used to represent the amount of memory resources that the node can allocate. Furthermore, the first available node refers to a node capable of accommodating the target type-one task.

[0170] B13: If there are K first-available nodes, determine the first score for each of the K first-available nodes. The first score of a first-available node is positively correlated with its ranking in the first ordered set, where K > 1. That is, the higher the ranking of the first-available node, the better its performance, and the higher its corresponding first score.

[0171] B14: Determine the first node from the K first available nodes based on the first scores corresponding to the K first available nodes.

[0172] As can be seen, considering the demands of high-performing tasks and the remaining resources of high-performing nodes, the first available node capable of accommodating the task is selected. Multiple first-available nodes are then scored to select the primary node for carrying the target first type of task. Based on this, by scoring nodes, a more suitable node can be determined from the available nodes for scheduling, thereby facilitating optimal overall resource utilization.

[0173] Example 3-2:

[0174] For identifying a second node for the second type of target task to be assigned for processing, as an example, in specific implementation, it may include B21-B24:

[0175] B21: Obtain the processor resource request amount and memory resource request amount corresponding to the target second-type task. These two values ​​represent the requirements of the target second-type task, such as request_cpu and request_mem respectively.

[0176] B22: From the nodes of the second type, the nodes whose remaining processor resources are greater than or equal to the processor resource request amount corresponding to the target second type of task, and whose remaining memory resources are greater than or equal to the memory resource request amount corresponding to the target second type of task, are determined as the second available nodes.

[0177] Specifically, the remaining processor resources indicate the amount of processor resources that the node can still allocate, and the remaining memory resources indicate the amount of memory resources that the node can allocate. Furthermore, a second available node refers to a node capable of accommodating the target type II task.

[0178] B23: If there are R second available nodes, for each of the R second available nodes, determine the first score corresponding to the second available node. The first score of the second available node is negatively correlated with its ranking in the first ordered set, where R > 1. That is, the smaller the ranking of the first available node, the lower its performance, and the higher its corresponding first score.

[0179] B24: Determine the second node from the R second available nodes based on the first scores corresponding to the R second available nodes.

[0180] As can be seen, considering the requirements of low-level tasks and the remaining resources of low-level nodes, a second available node capable of accommodating the task is first selected. Multiple second available nodes are then scored to select the second node suitable for carrying the target second type of task. Based on this, by scoring nodes, a more suitable node can be determined from the available nodes for scheduling, thereby facilitating optimal overall resource utilization.

[0181] Regarding Examples 3-1 and 3-2, it should also be noted that this application does not impose any limitations on the method used to determine the remaining processor resources and memory resources. For ease of understanding, the embodiments of this application provide the following examples:

[0182] Taking any node out of N nodes as an example, its remaining memory resources can be expressed as (memory_capacity – memory_allocated), where memory_capacity represents the total amount of memory resources corresponding to the node, and memory_allocated represents the total amount of memory resources already allocated to the node. The difference between the two represents the amount of memory resources that have not yet been allocated, which is the remaining memory resources of the node. Similarly, the remaining processor resources of the node (taking CPU resources as an example) can be expressed as (OFFLINE – cpu_allocated), where cpu_allocated represents the total amount of CPU resources already allocated, and OFFLINE represents the total amount of CPU resources that can be used. For example, in a scenario where online and offline tasks share the CPU, OFFLINE can refer to the total number of CPU cores that offline tasks on a single physical machine can use, as reported by the kernel scheduler.

[0183] It should also be noted that this application does not impose any limitations on how the first node and the second node are determined based on the first score. For ease of understanding, the following examples are provided in the embodiments of this application:

[0184] As an example, the first available node with the highest score can be directly selected as the first node. Based on this, the target first type of task can be scheduled to the node with the best performance among the available nodes, which is conducive to better ensuring the operation of the task.

[0185] Similarly, the second node with the highest first score can be directly selected as the second node. Based on this, the target second type of task can be scheduled to the node with the worst performance among the available nodes. This can ensure the task runs while retaining nodes with better performance to better accommodate the tasks that need to be allocated and processed later.

[0186] Based on this, high-performance tasks will be scheduled to nodes with higher performance as much as possible, and low-performance tasks will be scheduled to nodes with lower performance as much as possible, which is conducive to achieving the separation of high-performance and low-performance tasks.

[0187] To further optimize scheduling, in addition to considering the first score, other factors can be taken into account, such as resource balancing and minimizing the number of potential evictions. Therefore, as another example:

[0188] For a target available node, which may be a first available node or a second available node, a second score can also be determined. The second score includes at least one of a resource balancing score and a duration score. Then, based on the first score and the second score corresponding to the target available node, a comprehensive score for the target available node is determined.

[0189] Accordingly, if the target available node is the first available node, then in the specific implementation of B14, the first available node with the highest comprehensive score can be determined as the first node based on the comprehensive scores corresponding to the K first available nodes. And, if the target available node is the second available node, then in the specific implementation of B24, the second available node with the highest comprehensive score can be determined as the second node based on the comprehensive scores corresponding to the R second available nodes.

[0190] The resource balancing score identifies the difference between the remaining memory resources and processor resources of the target available node, reflecting the degree of resource balancing. The resource balancing score is positively correlated with the difference; a larger difference indicates greater imbalance, and a higher resource balancing score. The duration score identifies the duration for which the available processor resources of the target available node exceed the processor resource request of the target task. The duration score is positively correlated with the duration; the longer the resources of the target available node can guarantee task execution, the better the node can ensure task operation, resulting in a higher duration score. Specifically, if the target available node is a first-class available node, the target task is a first-class target task; if the target available node is a second-class available node, the target task is a second-class target task.

[0191] Based on this, in addition to considering the ranking, other aspects (such as resource balancing and guarantee duration) are also taken into account to comprehensively score the nodes, so as to select the best node for task scheduling, which is conducive to achieving global scheduling optimization.

[0192] Regarding the above embodiments for scoring nodes, it should be noted that this application does not impose any limitations on how to determine the first score, the resource balancing score, the duration score, or the comprehensive score. For ease of understanding, this application provides examples through the following embodiments.

[0193] (1) The following example is provided for determining the first score:

[0194] As mentioned above, for high-level nodes, the first score is positively correlated with ranking, while for low-level nodes, the first score is negatively correlated with ranking. Therefore, low-level tasks are scheduled to lower-level nodes, and high-level tasks are scheduled to higher-level nodes. Furthermore, since low-level tasks have lower timeliness requirements, it is desirable for them to be clustered as densely as possible on low-level nodes, while high-level tasks have higher timeliness requirements, so it is desirable for them to be clustered as evenly as possible on high-level nodes. Based on this, resource utilization is optimized to ensure the timeliness requirements of all types of tasks.

[0195] Correspondingly, for high-level tasks (i.e., the first type of objective task), the first score corresponding to the first available node can be:

[0196] q_score = (node ​​quality ranking score)^(1 / 2) + 0.125 * (cpu_allocated / OFFLINE + memory_allocated / memory_capacity)

[0197] Furthermore, for low-level tasks (i.e., the second type of objective task), the first score corresponding to the second available node can be:

[0198] q_score = (1 - node quality ranking score)^2

[0199] Here, q_score represents the first score, and the node quality ranking score represents the score corresponding to the node's ranking in the first ordered set. Typically, after obtaining the first ordered set, the "node quality ranking score" (0-1) can be obtained based on its ranking position.

[0200] (2) The following example is provided for determining the resource balance score:

[0201] As an example, the resource balance score can be determined by assessing the resource balance of nodes after assuming that tasks to be assigned are scheduled to a particular node. This can be calculated using the following formula:

[0202] b_score=|(memory_allocated+request_memory) / memory_capcacity-(cpu_allocated+request_cpu) / T|

[0203] Where b_score is used to represent the resource balancing score, and if the node is the first available node (high node), then T is the third performance parameter corresponding to the first available node (i.e., T = T1), and if the node is the second available node (low node), then T is the fourth performance parameter corresponding to the second available node (i.e., T = T2).

[0204] Therefore, assuming that after scheduling a task to be processed onto this node, there is a significant difference between the node's CPU and memory resources, a higher score will be awarded, and vice versa. It's understandable that the goal is to avoid creating a large difference in resources after scheduling; therefore, in this example, a higher resource balancing score corresponds to a lower overall score, meaning a lower probability of being scheduled onto that node.

[0205] (3) For scores based on a given duration, the following example is provided:

[0206] Understandably, the estimated execution time of different tasks will vary. Therefore, in another possible implementation, to optimize scheduling, the estimated execution time of the tasks to be assigned can be considered comprehensively to select nodes for scheduling.

[0207] As an example, the duration score can be calculated using the following formula:

[0208] e_score=(available_time / expected_remaining_duration)^2

[0209] Here, e_score represents the duration score, expected_remaining_duration represents the estimated execution time of the task to be assigned, and available_time represents the duration during which the available processor resources of the target node exceed the processor resource request of the target task. The target task refers to the task to be assigned.

[0210] If the node is the first available node (high node), available_time is the number of hours in which T1 - alllocated_cpu ≥ request_cpu can be true. If the node is the second available node (low node), available_time is the number of hours in which T2 - alllocated_cpu ≥ request_cpu can be true.

[0211] (4) The following example is provided for determining the overall score:

[0212] Taking the second score, which includes resource balance score and duration score, as an example, when determining the comprehensive score, we can set the score weights for these three parts, and then perform a weighted sum to obtain the comprehensive score.

[0213] As an example, the overall score can be determined using the following formula:

[0214] score=q_score+0.5*(1-b_score)+0.25*e_score

[0215] In the above formula, "score" represents the overall score. The weights of the three scores are 1, 0.5, and 0.25, respectively, but this is only an example and is not intended to be limiting. In practical applications, these weights can be set as needed.

[0216] In summary, for the above-described node scoring implementation, for tasks to be assigned, available nodes with sufficient resources are first selected. Then, from the selected available nodes, three factors are considered: first priority, which considers the separation of high and low tasks, corresponding to the first score; second priority, which considers the balanced use of CPU and memory resources of the nodes, corresponding to the resource balance score; and third priority, which considers minimizing the number of potential evictions, corresponding to the duration score. Based on the third priority, nodes that can guarantee the completion of tasks are allocated as much as possible, thus reducing the number of evictions and saving on the cost of continuous performance assurance.

[0217] Example 3-3:

[0218] In scenarios supporting hybrid scheduling where lower-level tasks are prioritized over higher-level tasks, a third node may need to be identified for the target second-type task (lower-level task) awaiting processing. This is because the purpose of hybrid scheduling is to improve the balanced utilization of node resources. Therefore, as an example, when identifying the third node, a third available node capable of accommodating the target second-type task can be determined from the first-type nodes.

[0219] Next, from the available third nodes, the node with the largest ratio of remaining processor resources (such as CPU resources) to memory resources, i.e., the most unbalanced use of processor and memory resources, can be selected as the third node. Based on this, scheduling the target second type of task to the third node helps to improve the balanced use of processor and memory resources on the third node.

[0220] IV. This application does not impose any limitations on how the first, second, third, and fourth performance parameters are determined. For ease of understanding, the following examples are provided in the embodiments of this application:

[0221] For ease of understanding, the first performance parameter will be denoted as X1, the second performance parameter as X2, the third performance parameter as T1, and the fourth performance parameter as T2.

[0222] As an example 4-1: In specific implementations, the aforementioned S301 may include C11-C15:

[0223] C11: In the i-th performance evaluation cycle, determine the total idle time of the processor resources based on the total usage time of the processor resources involved in the node.

[0224] Where i is a positive integer, this application does not impose any restrictions on the setting of the performance evaluation period. For example, taking 24 hours as an example, the times 0, 4, 8, 12, 16, and 20 can all be used as a performance evaluation period to re-evaluate the node performance of N nodes in the hybrid deployment system.

[0225] Furthermore, the performance evaluation period may include at least M test iterations, where M is a positive integer. Thus, within a performance evaluation period, tests are performed sequentially through M test iterations to determine the aforementioned X1 and X2, and T1 and T2. This application does not impose any limitation on the number of test iterations. For example, some nodes may be idle at the start of the current performance evaluation period, requiring multiple test iterations to determine the required parameters. Conversely, some nodes may already be running many tasks at the start of the current performance evaluation period, resulting in generally lower node performance, thus requiring only a few test iterations to determine the required parameters.

[0226] The total usage time of processor resources involved in a node can refer to the total usage time corresponding to the processor resources bound to the node. The total usage time is also the total non-idle time, representing the amount of non-idle processor resources. Its unit can be the same as the unit of processor resources, such as the unit of cores, specifically, 2.8 CPU cores.

[0227] In addition, the total idle time of processor resources can represent the amount of currently idle processor resources, that is, the amount of processor resources that can be used for testing.

[0228] Typically, the relationship between total usage time and total idle time can be expressed as: Total idle time = PHYCPU - Exist, where PHYCPU can be used to represent the total number of host cores, and Exist is used to represent the total usage time.

[0229] C12: In the j-th test iteration, determine the test time from the total idle time based on the j-th resource ratio, and create a number of test threads on the node that match the test time.

[0230] Where j is a positive integer, 1≤j≤M. The j-th resource ratio is obtained by increasing the resource ratio of the (j-1)-th test iteration by a certain percentage to increase the step size. It is used to determine the test time in the j-th test iteration, thereby determining how many test threads need to be established in the j-th test iteration. The test threads are used to simulate data processing tasks.

[0231] Therefore, in each test iteration, test threads are created to simulate the node running data processing tasks, thereby detecting the node's performance when running these tasks. Furthermore, as the test iterations progress, the step size is gradually increased to simulate an increasing load on the data processing tasks running on the node, thus further evaluating node performance.

[0232] It should be noted that this application does not impose any limitations on the setting of the incremental step size. For example, the incremental step size could be 5%, with the first resource percentage being 0%, the second resource percentage being 5%, and so on. Correspondingly, the aforementioned total idle time (PHYCPU-exist) can also be considered as the maximum test time, which also corresponds to the maximum number of test threads that can be established.

[0233] C13: Determine the performance metrics of the node in the j-th test iteration based on the processor resources allocated to the data processing tasks by the processors used by the data processing tasks running in the node.

[0234] The data processing task running in a node refers to the data processing task running in that node during the j-th test iteration. This application does not impose any limitations on this. For example, if there are no tasks running in a node initially, but a test thread is created to simulate the data processing task for testing purposes, then the data processing task running in the node is the created test thread. Alternatively, typically, at the start of a test, there are already tasks running in the node; in this case, the data processing task running in the node can include both the existing tasks and the test thread.

[0235] C14: When the performance indicators of a node meet the timeliness requirements of the first type of task, the node's usage of processor resources is determined as the first performance parameter.

[0236] Next, when the performance indicators of a node reach the timeliness target of the first type of task, it means that the node's performance indicators have reached the limit of ensuring the timeliness target of the first type of task (high task) in the current test iteration. Therefore, the amount of processor resources used at this time can be used as the first performance parameter (X1), which is the upper limit of the amount of processor resources that the node can use when ensuring the performance target of the high task.

[0237] Correspondingly, the amount of processor resources allocated to the node at this time can also be determined as the third performance parameter (T1), which is the upper limit of the amount of processor resources that the node can allocate while ensuring the performance target of high tasks.

[0238] For example, in the 8th test iteration, X1 and T1 can be determined by satisfying the condition C14.

[0239] C15: When the performance indicators of a node meet the timeliness requirements of the second type of task, the node's usage of processor resources is determined as the second performance parameter.

[0240] Similarly, when the performance indicators of a node reach the timeliness requirements of the second type of task, it means that the node's performance indicators have reached the limit of ensuring the timeliness requirements of the second type of task (low task) in the current test iteration. Therefore, the amount of processor resources used at this time can be used as the second performance parameter (X2), which is the upper limit of the amount of processor resources that the node can use to ensure the performance target of the low task.

[0241] Correspondingly, the amount of processor resources allocated to the node at this time can be determined as the fourth performance parameter (T2), which is the upper limit of the amount of processor resources that the node can allocate while ensuring the performance target of low-task tasks.

[0242] For example, in the 12th test iteration, X2 and T2 can be determined by finding that the condition C15 is met.

[0243] Based on this, through M test iterations and by establishing test threads, the achievable amount of processor resources and allocation of the node when ensuring tasks with different timeliness requirements are tested step by step, so as to facilitate subsequent use.

[0244] It should also be noted that this application does not impose any limitations on the timing of the performance evaluation cycle or on the method for determining the total amount of idle time. For ease of understanding, the embodiments of this application provide the following examples.

[0245] Example 4-2: The following example illustrates the timing of execution in a performance evaluation cycle:

[0246] As one example, performance evaluation cycles can be performed periodically. As yet another example, performance evaluation cycles can be performed based on the allocation requirements of data processing tasks.

[0247] Based on this, node performance can be evaluated periodically, such as at times 0, 4, and 8 as mentioned above. Alternatively, it can be performed only when there is a need to allocate data processing tasks. In this way, the evaluated node performance type is up-to-date, which helps ensure the accuracy of data processing task scheduling. Furthermore, when there is no data processing task to allocate, the above steps do not need to be performed, saving computer resources and also helping to meet the needs of different allocation scenarios.

[0248] Example 4-3: The following example is provided for determining the total amount of free time:

[0249] As an example, at the beginning of the i-th performance evaluation cycle, the total idle time of the processor resources involved in the detection node can be determined by detecting the total usage time of the processor resources within the evaluation duration.

[0250] The evaluation duration can be used to identify a period of time for determining the total usage time. For example, it can start at the beginning of the i-th performance evaluation cycle, accumulate the evaluation duration, and average the total usage time within this period to obtain the corresponding total usage time for subsequent use. For instance, the evaluation duration could be 10 seconds, and the total usage time can be determined by scanning the average total non-idle time within 10 seconds.

[0251] As another example, at the start of the j-th test iteration, the total idle time of the processor resources involved in the node during the evaluation period can be determined by detecting the total usage time of the processor resources within that node. Accordingly, the total idle time of the processor resources corresponds one-to-one with each test iteration.

[0252] In practical applications, a suitable approach can be flexibly chosen. The first approach, where the total usage time only needs to be determined once per performance evaluation cycle, is simpler and more convenient. The second approach, where the total usage time is redefined for each test iteration within the same performance evaluation cycle, is more compatible with data processing tasks running on nodes and changes during the test process, resulting in different total idle time at different times. This helps determine a more suitable total idle time for the current test iteration, guiding the creation of appropriate test threads.

[0253] Example 4-4: It also provides a fault tolerance mechanism, specifically:

[0254] In practical applications, since there are often running tasks on the nodes at the beginning of the performance evaluation cycle, there may be nodes that have already exceeded the conditions required to determine X1 and T1 at the start of the performance evaluation cycle. Since the accurate X1 and T1 cannot be determined, it is impossible to determine the node performance type based on X1 and X2.

[0255] To avoid errors in the entire test due to the inability to determine the node performance type, this application embodiment also provides another detection mechanism to improve fault tolerance.

[0256] In practical implementation, for the first target node among N nodes (which can be any of the N nodes), if in the first test iteration of the i-th performance evaluation cycle, it is determined that the node's performance indicators can no longer meet the timeliness requirements of the first type of task, it indicates that the corresponding X1 and T1 cannot be determined for that node, and therefore its node performance type cannot be determined. Accordingly, the first target node can be determined as a node without a node performance type, and the identification of the node performance type of the first target node can be temporarily suspended for a specified period of time.

[0257] Furthermore, if, after a specified period of time, a node without a node performance type still fails to meet the timeliness requirements of the first type of task in the first test iteration of the current performance evaluation cycle, it indicates that the node has been in a poor performance level for a long time. In this case, the first task to be evicted running on the node without a node performance type can be removed, and the running performance of the first task to be evicted does not meet the timeliness requirements of the first type of task.

[0258] It is evident that for nodes that cannot meet the requirements for determining X1 and T1 at the beginning of the current performance evaluation cycle, identification is temporarily suspended for a specified period of time. This avoids errors caused by the inability to determine the node's performance type, thus improving fault tolerance.

[0259] Furthermore, for nodes that fail to meet test conditions after a specified time period, a task eviction scheme is provided. By evicting tasks running on the node whose performance cannot be guaranteed, the performance pressure on the node is alleviated, making it possible for the node to recover to a state where X1 and T1 can be determined. In this way, the node performance type can be determined, and after the node performance type is determined, appropriate data processing tasks can be assigned to it, thus balancing task allocation efficiency.

[0260] For example, at the start of the first test iteration of the i-th performance evaluation cycle, if the PodStealtime corresponding to node W exceeds 45%, node W is identified as a node with no node performance type, and identification is suspended for a specified period (e.g., 10 days). After 10 days, at the start of the first performance evaluation cycle, if the PodStealtime corresponding to node W still exceeds 45%, and X1 and T1 of node W are not measured within 10 days, identification continues to be suspended, and data processing tasks on node W with Pod Stealtime exceeding 45% are evicted. After eviction, the Pod Stealtime can be waited for to update until it is less than 45%.

[0261] For ease of understanding, embodiments of this application also provide, as follows: Figure 6 The diagram shown illustrates a test scenario. Figure 6 In the example, taking CPU resources as the primary resource, the horizontal axis of graph ① represents CPU allocation rate, and the vertical axis represents preemption time (Stealtime). Similarly, in graph ②, the horizontal axis represents CPU allocation rate, and the vertical axis represents CPU utilization.

[0262] CPU utilization refers to the proportion of a CPU that is in a computing state over a period of time. CPU allocation rate refers to the proportion of CPU cores allocated to a specific task in a hybrid deployment system out of the total number of physical CPU cores in the system. Based on Figure 6 The graph shown can determine the CPU utilization when X1 is defined, and thus the corresponding usage, X1, can be calculated. The same applies to T1. Furthermore, X2 is calculated in a similar way to T2.

[0263] Understandably, similar graphs can be determined during testing for memory resources. This involves memory utilization and memory allocation rate. Memory utilization can refer to the proportion of currently used memory to available memory. Memory allocation rate can refer to the proportion of memory resources allocated to a specific task in a hybrid deployment system relative to the total available memory.

[0264] To better understand the above embodiments, this application also provides embodiments that... Figure 7This diagram illustrates a task scheduling strategy based on node performance awareness. (For...) Figure 7 For example, it should be noted that the sequence numbers are only for easy reference and do not restrict the execution order. For instance, S702 and S703 can be executed simultaneously, as in the scenario described in Example 1-1 above. Alternatively, S703 can be executed first, and then the historical load data and current load data can be used to determine the node performance type, as in the scenario described in Example 1-2 above.

[0265] V. In order to ensure the operational performance of the task and the balanced use of node resources, this application also provides an eviction policy, which will be illustrated in the following embodiments.

[0266] Example 5-1: Proactive eviction strategy to improve resource balance

[0267] For the second target node among N nodes, which can be any of the N nodes, if the difference between the remaining processor resources and the remaining memory resources of the second target node indicates that the second target node has excess processor resources, then a second task to be evicted is determined from the data processing tasks running on the second target node. Specifically, the processor resource request of the second task to be evicted is less than the memory resource request exceeding a first preset value. That is, the second target node has excess processor resources, and the second task to be evicted is a task running on the second target node with low processor resource requirements and high memory resource requirements. Evicting the second task to be evicted helps improve the balanced use of processor and memory resources on the second target node.

[0268] Next, for the second eviction task, a third target node is determined from the N nodes excluding the second target node, and the second eviction task is scheduled from the second target node to the third target node. Specifically, the third target node has remaining processor resources greater than or equal to the processor resource request of the second eviction task, and remaining memory resources greater than or equal to the memory resource request of the second eviction task. In other words, the third target node is a node capable of accommodating the second eviction task and is chosen as the node to carry it.

[0269] Correspondingly, if the difference between the remaining processor resources and the remaining memory resources of the second target node indicates that the second target node has excess memory resources, a third task to be evicted is determined from the data processing tasks running on the second target node. Specifically, the processor resource request of the third task to be evicted exceeds the memory resource request of the second task to be evicted by a second preset value. That is, the second target node has excess memory resources, and the third task to be evicted is a task running on the second target node with high processor resource requirements and low memory resource requirements. Evicting the third task to be evicted helps improve the balanced use of processor and memory resources on the second target node.

[0270] Next, for the third eviction task, a fourth target node is determined from the N nodes excluding the second target node, and the third eviction task is scheduled from the second target node to the fourth target node. Specifically, the fourth target node has remaining processor resources greater than or equal to the processor resource request of the third eviction task, and its remaining memory resources are also greater than or equal to the memory resource request of the third eviction task. In other words, the fourth target node is a node capable of accommodating the third eviction task and is specifically used to host it.

[0271] Based on this, by detecting the processor and memory resources of a node, it can be determined whether there is an excess of any one of these resources. If so, tasks currently running on the node that would cause the excess problem are evicted, thereby improving the balanced use of processor and memory resources. Furthermore, new nodes are reassigned to the evicted tasks, ensuring their continued operation.

[0272] Regarding Example 5-1, it should also be noted that this application does not impose any limitations on how to determine if a node has excess resources, how to identify tasks to be evicted, or how to determine new nodes for tasks to be evicted. For ease of understanding, this application provides examples one by one through the following embodiments.

[0273] (1) For cases where resources are determined to be excessive, the following example is provided:

[0274] As an example, the ratio of the remaining processor resources to the remaining memory resources of the second target node can be used to reflect the difference between the two. If the ratio is greater than threshold 'a' (e.g., greater than 2), the processor resources are considered excessive; if the ratio is less than threshold 'b' (e.g., less than 0.5), the memory resources are considered excessive. Based on this, it is possible to quickly determine whether a certain type of resource excess exists.

[0275] As another example, the ratio of a node's remaining processor resources to its remaining memory resources can be determined as the node's resource ratio parameter. Then, based on the magnitude of the resource ratio parameters corresponding to the N nodes, the N nodes are sorted to obtain a second ordered set. In this second ordered set, the resource ratio parameter of the i-th node is smaller than that of the (i+1)-th node, where 1 ≤ i ≤ N. It is evident that in the second ordered set, a larger ranking indicates more surplus processor resources, while a smaller ranking indicates more surplus memory resources. For example, the N-th node in the second ordered set can be identified as the node with surplus processor resources.

[0276] (2) For tasks identified as slated for deportation, the following example is provided:

[0277] As an example, if the second target node has excess processor resources, the data processing task A1 running on the second target node with the smallest ratio of processor resource request to memory resource request can be identified as the second task to be evicted.

[0278] Correspondingly, if the second target node has excess memory resources, then the data processing task A2 running on the second target node with the largest ratio of processor resource request to memory resource request can be identified as the third task to be evicted.

[0279] It should be noted that the above is merely an example and is not intended to be limiting. For instance, the second-to-last data processing task could also be designated as the second task to be evicted.

[0280] (3) Determine a new node for the expelled task, as shown in the following example:

[0281] To facilitate understanding, let's take the aforementioned data processing task A1 as the second task to be expedited and the aforementioned data processing task A2 as the third task to be expedited as examples:

[0282] For A1, the ratio of processor resource request to memory resource request is the smallest. Therefore, we can start from the first node in the second ordered set and find a node that can accommodate A1 as the third target node. Based on this, we can reschedule it to one of the nodes that can accommodate it, the node with the most memory surplus, which is beneficial for achieving balanced resource utilization across N nodes.

[0283] For A2, the ratio of processor resource request to memory resource request is the highest. Therefore, we can start from the Nth node in the second ordered set and find a node that can accommodate A2 as the fourth target node. Based on this, we can reschedule it to one of the nodes that can accommodate it, the node with the most surplus processor resources, which is beneficial for achieving balanced resource utilization across all N nodes.

[0284] In this context, "capable of accommodating" means that the node is a usable node for the task to be evicted. That is, the node's remaining processor resources are greater than or equal to the processor resource request of the task to be evicted, and the node's corresponding remaining memory resources are greater than or equal to the memory resource request of the task to be evicted.

[0285] As another example, in addition to considering whether a node can accommodate more resources, the relationship between the ratio of a node's processor resources to its memory resources and the ratio of the number of requests from the node to be evicted can also be taken into account. Correspondingly, the ratio between the third performance parameter of the aforementioned third target node and the memory resource setting of the third target node should be greater than the ratio between the processor resource request and memory resource request of the second task to be evicted. The determination of the fourth target node is similar.

[0286] For example, if it is determined that node B can accommodate the task to be evicted, and T_B / memory_capacity_B > lambda, then node B can be designated as the new node to host the task to be evicted. Here, if node B is a higher-order node, T_B represents T1 corresponding to node B; if node B is a lower-order node, T_B represents T2 corresponding to node B. And lambda represents the ratio of the processor resource request to the memory resource request of the task to be evicted.

[0287] It should also be noted that this application does not impose any restrictions on the timing of the proactive eviction strategy. For example, it can be implemented in real time, so that once a node is detected to have excessive resources, it can be evicted in a timely manner to achieve balanced resource utilization, thus accommodating scenarios where the processor resources of a node may change at any time. Alternatively, proactive eviction can also be triggered at the six times mentioned above: 0, 4, 8, 12, 16, and 20.

[0288] To better understand the aforementioned proactive expulsion strategy, the embodiments of this application also provide the following examples:

[0289] As an example, in practical implementation, a first proactive eviction thread and a second proactive eviction thread can be configured. The first proactive eviction thread is used to identify a third target node for the second eviction task and schedule it to the third target node. The second proactive eviction thread is used to identify a fourth target node for the third eviction task and schedule it to the fourth target node.

[0290] Based on this, once the proactive eviction strategy is implemented, the N nodes can be sorted to obtain a second ordered set. Then, the two threads mentioned above are started to scan from both ends of the second ordered set and proactively evict nodes, improving eviction efficiency and achieving overall resource balance more quickly.

[0291] In this way, by proactively evicting and rescheduling tasks to balance resource usage, the high resource utilization of the entire cluster is maintained continuously. For example, when the number of online tasks decreases at night and the available CPU resources for a node increase, leading to a surplus of CPU resources, offline tasks with smaller CPU resource requests (total memory resource requests) will be proactively evicted to make full use of the increased nighttime CPU resources.

[0292] Correspondingly, this application embodiment also provides two thread termination conditions, specifically:

[0293] As an example, the termination condition for the first proactive eviction thread could be: there is no node on which (T1-cpu_allocated) / (memory_capacity-memory_allocated) is greater than 2 and there is a task running on it that meets the migration criteria. Similarly, the termination condition for the second proactive eviction thread is similar: there is no node on which (T1-cpu_allocated) / (memory_capacity-memory_allocated) is less than 0.5 and there is a task running on it that meets the migration criteria. Meeting the migration criteria means that the ratio of the task's processor resource request to its memory resource request is either too small or too large.

[0294] As another example, the termination condition could be that the total number of proactive expulsions exceeds a set limit.

[0295] The above embodiments have provided a detailed description of the proactive eviction strategy provided in this application. Based on the proactive eviction strategy, it is possible to avoid the situation where processor resources (such as CPU resources) of a node are subject to timing changes, leaving only single processor or memory resources remaining. This promotes a balanced use of both types of resources, thereby improving the overall resource utilization of the hybrid deployment system.

[0296] Example 5-2: Passive eviction strategy to ensure task performance

[0297] For the fifth target node among N nodes, the fifth target node can be any of the N nodes. If it is determined that there is a target processing task among the data processing tasks running on the fifth target node, then the fourth task to be evicted is determined from the data processing tasks running on the fifth target node.

[0298] Specifically, the performance of the target processing task cannot meet its timeliness requirements. In other words, the target processing task is running on the fifth target node, but its current performance is insufficient to meet the timeliness requirements. For example, if the target processing task is a high-performance task, the current performance cannot meet the requirement of Pod Stealtime < 45%; if the target processing task is a low-performance task, the current performance cannot meet the requirement of Pod Stealtime < 65%.

[0299] Furthermore, the fourth task to be deported falls under the category of target processing tasks. That is, the fourth task to be deported is also a task whose operational performance cannot be guaranteed, and it is the task to be deported this time.

[0300] Next, the fourth task to be evicted is removed from the fifth target node, and after the removal, the fourth task to be evicted is added to the data processing tasks to be assigned.

[0301] As can be seen, when a node contains tasks whose performance does not meet the timeliness requirements of the task, i.e., whose performance violates the task's performance guarantee label, a passive eviction policy is implemented. A fourth task to be eviction is identified and evictioned from the fifth target node. Furthermore, after eviction, the fourth task to be eviction is added to the data processing tasks awaiting allocation. This allows for the allocation of a suitable new node for the fourth task to be eviction, ensuring that the task's performance meets its requirements. Therefore, even when the priority of an offline task is lower than that of an online task, continuous and reliable performance guarantees can still be provided.

[0302] In this regard, it should be noted that this application does not impose any limitations on how the fourth deportation task is determined. For ease of understanding, the following examples are provided in the embodiments of this application:

[0303] If there are multiple target processing tasks, one of them can be designated as the fourth task to be evicted during the first expulsion. If no target processing tasks remain after expulsion, the expulsion process ends. If target processing tasks still exist after expulsion, another target processing task can be designated as the fourth task to be evicted for a second round of expulsion.

[0304] Based on this, a single expulsion only expels one target processing task, ensuring that the performance violation problem can be resolved with one expulsion, while also guaranteeing the performance of other tasks without waiting for rescheduling.

[0305] As an example, since low-level tasks have lower timeliness requirements, when there are multiple target processing tasks, including both low-level and high-level tasks (such as in a hybrid scheduling scenario), the low-level tasks can be prioritized as the fourth task to be evicted. That is, low-level tasks are evicted first, and if performance violations occur after eviction, they can be evicted in turn, one high-level task followed by one low-level task.

[0306] In practice, you can first check the total remaining available resources (T1 total - total_allocated) of nodes that are ranked higher than the current node (nodes that are more suitable for scheduling low-performance guaranteed tasks). If the remaining available resources account for more than 15%, it indicates that the performance violation problem of the node is not very urgent, so the low-performance task with the performance violation should be evicted first. If the performance violation still exists after eviction, then the high-performance task should be evicted in turn, followed by the low-performance task.

[0307] As another example, if the remaining available resources are less than 15%, it indicates a serious performance violation by the node. In this case, the high-performance task that violates the performance metrics can be evicted first, making the high-performing task in the target processing task the fourth task to be evicted. If the performance violation still exists after eviction, then the low-performing task that violates the performance metrics can be evicted next.

[0308] Based on this, the fourth task to be removed can be determined according to the urgency of the performance violation problem of the node, which is more flexible and also facilitates the rapid adjustment of the node to a level that can guarantee the performance of the task.

[0309] In practical applications, a passive eviction thread can be configured. For example, the eviction decision module can continuously scan all nodes in a loop. When a task that violates performance rules is found on a certain node, the eviction decision module triggers the passive eviction thread for that node to execute the aforementioned steps of determining the fourth task to be eviction and eviction.

[0310] Typically, the entire passive eviction process is a single-threaded sequential process, with a 3-minute interval between each two evictions to allow time for the Pod Stealthtime to be updated after the previous eviction. Furthermore, adopting the above-mentioned priority eviction order for low-level tasks helps ensure that low-level tasks make full use of low-level node resources, thus reserving high-level node resources for high-level tasks.

[0311] It is understandable that the tasks that were expelled were all target processing tasks mentioned above, which were tasks running on the node that had performance violations.

[0312] The above embodiments have provided a detailed description of the active and passive expulsion strategies provided in this application. For further details, please refer to... Figure 8 The diagram illustrates a possible expulsion strategy. Figure 8For example, it should be noted that the sequence numbers are only for easy reference and do not impose any restrictions on the execution order. For instance, S803 and S804 can be performed simultaneously, or one of them can be executed at a time. Furthermore, S803 and S804 may be executed multiple times until there are no longer any related performance violations or resource balancing issues, at which point the final step of S805 will be executed.

[0313] In summary, proactive eviction strategies occur on nodes where processor and memory resources change significantly. By promoting balanced use of processor and memory resources, they maintain a high overall processor resource allocation and utilization rate in the hybrid deployment system. Passive eviction strategies occur on nodes where task performance deviates from guaranteed performance metrics. By allocating suitable new nodes to evictiond tasks, they can ensure continued performance. In practical applications, eviction and rescheduling decisions can be made for appropriate tasks on appropriate nodes at appropriate times.

[0314] The task scheduling method provided in this application has been described in detail through the above embodiments. For better understanding, this application uses the aforementioned hybrid deployment system supporting shared CPU resources for online and offline tasks as an example. In this example, both the first type of task and the second type of task can be offline tasks, and correspondingly, it also provides... Figure 9 The diagram illustrates a resource platform corresponding to an offline submachine. Offline tasks can include both offline and near-line tasks, specifically data processing tasks such as model training, big data computation, offline encoding / decoding, and off / near-line transcoding. The computing platform connects the task layer and the computing resource layer, scheduling tasks. For example, the computing platform uses the aforementioned VMF scheduler as its underlying infrastructure to provide a computing service platform that supports sharing CPU cores (i.e., CPU resources) among offline tasks.

[0315] In practical applications, the host machine's kernel scheduler can employ the VMF scheduler, running several online virtual submachines corresponding to online tasks and one offline virtual submachine corresponding to offline tasks on the host machine. Each online virtual submachine is bound to a different host machine core and allocated a certain amount of memory resources. The creation and destruction of online virtual submachines, as well as the online tasks they run, are entirely determined by the needs of the online business department. Offline virtual submachines on the host machine are bound to all CPU cores on the host node and allocated a certain amount of memory resources. Instances of offline tasks can be packaged as containers, with the offline application specifying the required number of CPU cores and total memory, i.e., the CPU and memory resource requests corresponding to the task. The containers can then be deployed to offline virtual submachines by the computing platform's scheduler and bound to the cores (i.e., virtualized cores) of the offline virtual submachines. The number of bound cores is equal to the number of CPU cores requested, and the cores bound to different offline task instance containers are different. Furthermore, the offline virtual submachines also allocate the requested memory resources to the containers of offline tasks; the memory resources of containers of different offline tasks are not shared.

[0316] In this context, the host kernel can refer to a CPU hyperthread on the host machine. The virtualization kernel, on the other hand, refers to the CPU core that the application is aware of within the container of offline tasks; this core is mapped by the host kernel scheduler to a process on a specific physical core. Task scheduling is then implemented based on this process.

[0317] In addition, it also provides, such as Figure 10 The diagram illustrates an architecture for task scheduling, primarily comprising a node performance-aware task scheduler and a task performance-aware task eviction mechanism. Specifically:

[0318] Part 1: A Node Performance-Aware Task Scheduler

[0319] It mainly consists of three parts: accurate resource estimation methods, task load statistics methods, and performance-aware scheduling algorithms. Specifically, it can be implemented as a task scheduler with node performance awareness, consisting of four modules: resource prediction module, task load management module, scheduling decision planning module, and task scheduling module.

[0320] ①Resource Prediction Module

[0321] This module implements the aforementioned resource estimation method, specifically for estimating the instantaneous resource capacity and performance characteristics of each node in a hybrid deployment system (or hybrid deployment cluster), and estimating the temporal characteristics of these features, thus forming a resource prediction module. The resource prediction module consists of a centralized resource prediction manager and resource prediction agents distributed across each node.

[0322] The instantaneous features may include the aforementioned X1, X2, T1, and T2. For details, please refer to the detailed description in the foregoing embodiments. The temporal features are expressed as the values ​​of the above four features at the six time points of 0, 4, 8, 12, 16, and 20.

[0323] A resource prediction agent distributed across nodes executes a node performance prediction script. This script takes the current node's OFFLINE and PHYCPU as input and outputs X1, X2, T1, and T2. First, it scans / proc / stat to determine the average total non-empty time over 10 seconds (the aforementioned evaluation duration), denoted as `exist`, and then derives `PHYCPU - exist` as the maximum number of threads used for measurement. Here, `PHYCPU` represents the total number of host cores. Each test thread performs a prime number factorization operation.

[0324] Then, X1, X2, T1, and T2 are initialized to 0, and the first test iteration of the i-th performance evaluation cycle is entered, and so on for the M test iterations corresponding to this performance evaluation cycle. For example, the first sub-test iteration uses 0%*(PHYCPU-exist) test threads, the second sub-test uses 5%*(PHYCPU-exist) test threads, and so on. That is, in this example, the aforementioned scaling step size is 5%.

[0325] In practical applications, each test iteration can run for approximately 6 seconds. Simultaneously, the prediction script checks ` / proc / stat` to obtain the Stealtime of the offline virtual machine and the sum of the non-idle times of all cores. Since there are often running offline tasks on the offline virtual machine during the prediction script's execution, the Pod Stealtime is defined as the ratio of the offline virtual machine's Stealtime to the sum of the non-idle times of all its cores. Here, Stealtime can refer to the time spent by tasks within the offline virtual machine waiting for CPU resources in a virtualized environment, i.e., the preemption time caused by tasks on the online virtual machine on the same host machine occupying the offline virtual machine's CPU. The virtual machine's Stealtime is equal to the sum of the Stealtimes of all its bound CPU cores.

[0326] If the ratio is less than 45%, the node's performance metrics are considered to have met the timeliness requirements for the first type of task. In this case, X1 is updated to the sum of the execution times of all cores, and T1 is updated to the sum of the non-idle times of all cores. If the ratio is less than 65% or greater than 45%, X2 and T2 are updated in the same manner.

[0327] Additionally, the resource prediction manager notifies 1 / 10 of the resource prediction agents in the hybrid deployment system (or hybrid deployment cluster) to run prediction scripts at fixed intervals (e.g., every 10 days). Each run executes the prediction script at six times: 0, 4, 8, 12, 16, and 20. Specifically, for nodes with Pod Stealtime exceeding 45% (i.e., nodes with the aforementioned no-node performance type), the prediction script will be temporarily suspended, as this means accurate X1 and T1 measurements are no longer possible. Furthermore, if this value is not measured for more than 40 days (i.e., the aforementioned specified duration), the script will be suspended again, and the resource prediction module will first notify the scheduler to mark it as a temporary "high node," thereby evicting offline tasks on that node with Pod Stealtime exceeding 45% (i.e., the aforementioned first eviction task), until the Pod Stealtime of all offline tasks on the node falls below 45%, at which point the prediction script will be immediately triggered again. Finally, after completing the data collection required for one performance evaluation cycle, the resource prediction manager will first notify the scheduler to restore the node's original label. In addition, the Resource Prediction Manager can also be used to maintain data with time-series characteristics.

[0328] Based on this, by running a lightweight prediction script on a regular basis, the CPU resource usage and allocation of nodes under different performance guarantee targets can be measured, thereby more accurately predicting the capacity of each node and scheduling an appropriate amount of offline tasks.

[0329] ②Task Load Management Module

[0330] This module is responsible for statistically analyzing load characteristics, such as historical load and current load as described in the aforementioned embodiments. In specific implementations, statistics can be used to determine the characteristics mentioned above. Figure 5 The statistical histogram shown.

[0331] In addition, the task load management module is responsible for calculating the estimated execution time of each task, specifically the average execution time of containers for all completed tasks in history. Tasks with an execution time exceeding 24 hours are considered to have a 24-hour execution time. Furthermore, the task load management module also records the submission time of currently running tasks on the platform, internally calculates the execution time when a task's container ends, and provides this information to the task scheduling module.

[0332] ③ Scheduling Decision Planning Module

[0333] This module is mainly used to generate scheduling decision planning schemes at fixed intervals based on the prediction results of the resource prediction module and the load statistics results of the task load management module.

[0334] In practice, the main steps include the aforementioned sorting of nodes to obtain the first ordered set, decision-making on the proportion of mixed tasks, and node allocation. For details on each step, please refer to the foregoing embodiments.

[0335] ④ Task scheduling module

[0336] This module is primarily used to schedule tasks to suitable nodes. Tasks can include newly submitted tasks awaiting assignment and tasks that have been evicted and need to be rescheduled. Specifically, it may include filtering available nodes, comprehensively scoring available nodes based on three priorities, and then selecting nodes for scheduling. For details, please refer to the foregoing embodiments.

[0337] Based on this, low-performance and high-performance guarantee tasks can be prioritized and scheduled to more suitable nodes, which helps to improve the overall resource utilization of the hybrid deployment cluster.

[0338] In addition, the task scheduling module also provides feedback on the remaining schedulable capacity of the hybrid deployment system (or hybrid deployment cluster), such as the remaining capacity for schedulable offline tasks, facilitating users on the business side to submit new tasks. Specifically, the capacity feedback includes `avail_t_h`, `avail_m_h`, `avail_t_l`, and `avail_m_l`. This means that if a new high-performance guarantee task is submitted, a high-performance task with `avail_t_h` core CPU and `avail_m_h` memory resources can be submitted; conversely, if a low-performance guarantee task is submitted, a low-performance task with `avail_t_l` core CPU and `avail_m_l` memory resources can be submitted. Furthermore, the calculation method for high-task available capacity is as follows: Perform a binary search on extra_t_h. For each extra_t_h, try_t_h = now_t_h + extra_t_h, try_m_h = now_m_h + extra_t_h * his_m_h / his_t_h. Call the task mixing ratio decision process using (try_t_h, try_m_h, now_t_l, now_m_l). If the obtained system idle degree is greater than 1.1, it is considered to be able to accommodate, and avail_t_h = try_t_h, avail_m_h = try_m_h is updated; otherwise, it is considered not to be able to accommodate. The calculation method for low-task available capacity is similar.

[0339] Part Two: Task Destroyers with Task Performance Awareness

[0340] It primarily relies on task performance monitoring and cluster-aware eviction and rescheduling algorithms. This performance guarantee method is implemented as a task eviction mechanism with task performance awareness, consisting of two modules: a centralized eviction decision module and a task monitoring module distributed across each node.

[0341] ①Task Detection Module

[0342] This module is primarily used to detect whether the performance of running tasks on each node violates the timeliness requirements of the tasks. Specifically, it can detect whether the instantaneous performance guarantee requirements of the tasks are violated. The instantaneous performance guarantee requirement refers to the average performance of offline tasks within a specified short time window (e.g., 5 minutes, 10 minutes) in a hybrid deployment system, ensuring that the task's performance guarantee objective is met. For example, the instantaneous performance guarantee requirement for high-performance tasks is <45% Pod Stealtime.

[0343] Typically, Pod Stealtime is used as an equivalent value for task performance metrics, providing a lower bound guarantee for task performance. Pod Stealtime is defined as the proportion of the total time that the virtualization cores bound to a task wait for computing resources to be used, relative to the total non-idle time. This can be implemented by a task detection agent distributed across each node. The detection agent runs every 5 minutes, obtaining the container process IDs of tasks running on the node via Docker command lines, and then using the `taskset` tool to determine the virtualization cores bound to them. Subsequently, by scanning the non-idle time and Stealtime data of each core in ` / proc / stat`, the agent calculates the 5-minute average Pod Stealtime and reports it to the metrics detection and management plane of the hybrid deployment system.

[0344] ②Expulsion Decision Module

[0345] This module is the centralized component of the hybrid deployment system (or hybrid deployment cluster). The eviction decision module cyclically scans all nodes, combining the performance data from the task detection module and the load and capacity characteristics of the hybrid deployment system provided by the task scheduling module. The former is used to determine whether to execute a passive eviction policy, and the latter is used to determine whether to execute an active eviction policy. For details, please refer to the foregoing embodiments.

[0346] Based on the eviction strategy, continuous performance guarantee is provided for the task. In this case, continuous performance guarantee means that in a hybrid deployment system (or hybrid deployment cluster), the task can achieve the aforementioned instantaneous performance guarantee within each shorter time window over a longer life cycle (such as 8 hours, 2 days, etc.).

[0347] The task scheduling method provided in this application is described in detail through the above embodiments. Experiments have shown that in a hybrid deployment system deployed in a production environment, after adopting this application, an offline task CPU allocation rate of 85.9% and a CPU utilization rate of 45.6% can be achieved, both being 24-hour averages. Compared with related technologies, this significantly improves resource utilization and enables resource optimization. Furthermore, after determining the node performance type for a node in this application, nodes are divided into high-performance nodes and low-performance nodes. However, this is only a sorting, not an absolute separation; the sorting may change in the next performance evaluation cycle, thus enabling more accurate task scheduling. Additionally, a hybrid scheduling strategy of using low-performance nodes as high-performance nodes is also provided, which can fully utilize the processor resources on high-performance nodes and avoid their memory bottlenecks. Based on this, it can cope with situations such as time-series changes in node performance caused by day-night load variations.

[0348] Furthermore, because low-level tasks are prioritized for scheduling to low-level nodes and high-level tasks to high-level nodes, it is beneficial to achieve continuous performance assurance for offline tasks at a lower cost, unaffected by changes in online task load. Experiments have shown that, after adopting this application, the number of eviction and rescheduling events per day is only a few, indicating that the task scheduling scheme achieves overall optimization, and the cost incurred by eviction is negligible.

[0349] Especially in scenarios where online and offline tasks are deployed in a mixed manner, on the one hand, online tasks fluctuate over time, which can easily lead to online virtual machines over-subscribing to CPU resources, resulting in low actual CPU resource utilization. On the other hand, the types of online tasks running within online virtual machines are diverse, handling different business processes, with varying CPU usage and CPU usage cycles. This results in differences in the quality of resources provided by different offline virtual machines, and even the same offline virtual machine can provide different resource quality at different times. Consequently, the performance of offline tasks running on offline virtual machines is difficult to guarantee. To address this, this application enables reasonable scheduling of offline tasks, thereby providing continuous performance guarantees for them. Based on this, it can quickly and dynamically adjust the offline tasks within offline virtual machines when the CPU resource usage of online tasks within online virtual machines changes over time, thus ensuring their operational performance.

[0350] In summary, by employing the task scheduling strategies described above, cloud computing platforms can utilize computing resources more effectively while meeting the performance requirements of different tasks, thus facilitating cost-effectiveness optimization.

[0351] It should also be noted that, based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods.

[0352] based on Figure 3 Corresponding to the task scheduling method provided in the embodiments, this application also provides a task scheduling device 1100, which includes an acquisition unit 1101, a determination unit 1102, and a scheduling unit 1103:

[0353] The acquisition unit 1101 is used to acquire first performance parameters and second performance parameters corresponding to N nodes in a hybrid deployment system. The hybrid deployment system is configured with processor resources for executing data processing tasks. The data processing tasks include a first type of task and a second type of task. The first type of task has higher timeliness requirements than the second type of task. The first performance parameter is used to identify the amount of processor resources used by the node when the node's performance index meets the timeliness requirements of the first type of task. The second performance parameter is used to identify the amount of processor resources used by the node when the node's performance index meets the timeliness requirements of the second type of task.

[0354] The determining unit 1102 is used to determine the node performance type corresponding to each of the N nodes according to the first performance parameter and the second performance parameter of the node, wherein the node performance type includes a first type suitable for processing the first type of task;

[0355] The scheduling unit 1103 is used to determine a first node from the nodes of the first type for a target first type of task to be assigned for processing, and to schedule the target first type of task to the first node.

[0356] In one possible implementation, the determining unit is further configured to:

[0357] Obtain the first resource allocation amount corresponding to the first type of task currently running in the hybrid deployment system, and the second resource allocation amount corresponding to the second type of task currently running in the hybrid deployment system;

[0358] Based on the first performance parameter and the second performance parameter corresponding to the N nodes respectively, as well as the first resource allocation amount and the second resource allocation amount, a first type of node with the first type of node performance and a second type of node with the second type of node performance are determined from the N nodes. The second type of node is suitable for processing the second type of task.

[0359] In one possible implementation, the determining unit is further configured to:

[0360] The ratio of the first performance parameter to the second performance parameter of the node is determined as the performance ratio parameter of the node;

[0361] Based on the magnitude of the performance ratio parameters corresponding to the N nodes, the N nodes are sorted to obtain a first ordered set. The performance ratio parameter of the i-th node in the first ordered set is less than the performance ratio parameter of the (i+1)-th node, where 1≤i≤N.

[0362] Obtain the third performance parameter and the fourth performance parameter corresponding to each of the N nodes. The third performance parameter is used to identify the amount of processor resources allocated to the node when the node's performance index meets the timeliness requirement of the first type of task. The fourth performance parameter is used to identify the amount of processor resources allocated to the node when the node's performance index meets the timeliness requirement of the second type of task.

[0363] For the first ordered set, starting from the Nth node, the sum of the third performance parameters of the nodes is counted sequentially backward. When the sum of the third performance parameters corresponding to the last k nodes satisfies the first resource allocation amount, the node performance type of the last k nodes is determined as the first type. Starting from the 1st node, the sum of the fourth performance parameters of the nodes is counted sequentially backward. When the sum of the fourth performance parameters corresponding to the current t nodes satisfies the second resource allocation amount, the node performance type of the previous t nodes is determined as the second type.

[0364] In one possible implementation, if t < Nk, for nodes from the (t+1)th node to the Nkth node, the determining unit is further configured to:

[0365] Obtain the first historical resource allocation amount corresponding to the first type of task running by the hybrid deployment system within a historical period, and the second historical resource allocation amount corresponding to the second type of task running by the hybrid deployment system within the historical period;

[0366] Based on the first total allocation and the first historical resource allocation corresponding to the first type of node, the first idle degree corresponding to the first type of node is determined, and based on the second total allocation and the second historical resource allocation corresponding to the second type of node, the second idle degree corresponding to the second type of node is determined. The first total allocation is the sum of the third performance parameters corresponding to the first type of node respectively, and the second total allocation is the sum of the fourth performance parameters corresponding to the second type of node respectively.

[0367] The node allocation target is set based on the difference between the first idle degree and the second idle degree being less than a preset threshold. Starting from the Nkth node, the node performance type of the node is determined forward to be the first type, and starting from the t+1th node, the node performance type of the node is determined backward to be the second type.

[0368] In one possible implementation, the scheduling unit is further configured to:

[0369] For the target second type of task to be assigned, determine a second node from the second type of nodes and schedule the target second type of task to the second node; or...

[0370] For a target second type of task to be assigned for processing, if the ratio of the processor resource request amount corresponding to the target second type of task to the memory resource request amount corresponding to the target second type of task is greater than the mixing ratio threshold, a third node is determined from the first type of nodes, and the target second type of task is scheduled to the third node.

[0371] In one possible implementation, the scheduling unit is further configured to:

[0372] If the ratio of the processor resource request amount corresponding to the target second type of task to the memory resource request amount corresponding to the target second type of task is greater than the mixing ratio threshold, and the mixing limit of the processor resources is greater than the sum of the allocated mixed resources and the processor resource request amount of the target second type of task, then the third node is determined from the first type of node;

[0373] After scheduling the target second type of task to the third node, the processor resource request amount of the target second type of task is accumulated into the allocated mixed resource amount to obtain the updated allocated mixed resource amount.

[0374] In one possible implementation, the mixing ratio threshold is the ratio between the mixing limit of the processor resources and the mixing limit of the memory resources corresponding to the hybrid deployment system, wherein the mixing limit of the processor resources is determined based on the amount of requests for the processor resources by the data processing tasks running in the hybrid deployment system during a historical period, and the mixing limit of the memory resources is determined based on the amount of requests for the memory resources by the data processing tasks running in the hybrid deployment system during the historical period.

[0375] In one possible implementation, the scheduling unit is further configured to:

[0376] Obtain the processor resource request amount and the memory resource request amount corresponding to the target first type of task;

[0377] From the nodes of the first type, the nodes whose remaining processor resources are greater than or equal to the processor resource request amount corresponding to the target first type of task, and whose remaining memory resources are greater than or equal to the memory resource request amount corresponding to the target first type of task, are determined as the first available nodes;

[0378] If the number of first available nodes is K, for each of the K first available nodes, determine the first score corresponding to the first available node. The first score of the first available node is positively correlated with the ranking of the first available node in the first ordered set, and K > 1.

[0379] The first node is determined from the K first available nodes based on the first scores corresponding to the K first available nodes.

[0380] In one possible implementation, the scheduling unit is further configured to:

[0381] Obtain the processor resource request amount and the memory resource request amount corresponding to the target second type of task;

[0382] From the nodes of the second type, nodes whose remaining processor resources are greater than or equal to the processor resource request amount corresponding to the target second type of task, and whose remaining memory resources are greater than or equal to the memory resource request amount corresponding to the target second type of task, are determined as second available nodes;

[0383] If the number of second available nodes is R, for each of the R second available nodes, determine the first score corresponding to the second available node. The first score of the second available node is negatively correlated with the ranking of the second available node in the first ordered set, and R>1.

[0384] The second node is determined from the R second available nodes based on the first scores corresponding to the R second available nodes.

[0385] In one possible implementation, the target available node is either the first available node or the second available node, and the scheduling unit is further configured to:

[0386] A second score is determined corresponding to the target available node. The second score includes at least one of a resource balancing score and a duration score. The resource balancing score is used to identify the difference between the remaining memory resources and the remaining processor resources of the target available node, and the resource balancing score is positively correlated with the difference. The duration score is used to identify the duration for which the allocable processor resources of the target available node exceed the processor resource request of the target task, and the duration score is positively correlated with the duration. If the target available node is the first available node, the target task is the first type of target task. If the target available node is the second available node, the target task is the second type of target task.

[0387] Based on the first score corresponding to the target available node and the second score corresponding to the target available node, determine the comprehensive score corresponding to the target available node;

[0388] If the target available node is the first available node, then based on the comprehensive scores corresponding to the K first available nodes, the first available node with the highest comprehensive score is determined as the first node;

[0389] If the target available node is the second available node, the second available node with the highest comprehensive score is determined as the second node based on the comprehensive scores corresponding to the R second available nodes.

[0390] In one possible implementation, the acquisition unit is further configured to:

[0391] In the i-th performance evaluation cycle, the total idle time of the processor resources involved in the node is determined based on the total usage time of the processor resources involved in the node. The performance evaluation cycle includes at least M test iterations.

[0392] In the j-th test iteration, the test time is determined from the total idle time based on the j-th resource ratio, and a number of test threads matching the test time are established at the node. The test threads are used to simulate the data processing task. The j-th resource ratio is obtained by increasing the resource ratio of the (j-1)-th test iteration by a certain percentage and step size.

[0393] Based on the processor resources allocated to the data processing task by the processor used by the data processing task running in the node, determine the performance index of the node in the j-th test iteration;

[0394] When it is determined that the performance index of the node meets the timeliness requirements of the first type of task, the amount of processor resources used by the node is determined as the first performance parameter.

[0395] When it is determined that the performance index of the node meets the timeliness requirements of the second type of task, the amount of processor resources used by the node is determined as the second performance parameter.

[0396] In one possible implementation, the acquisition unit is further configured to:

[0397] At the start of the i-th performance evaluation cycle, the total idle time of the processor resources involved in the node is determined by detecting the total usage time of the processor resources within the evaluation duration; or,

[0398] At the start of the j-th test iteration, the total idle time of the processor resources involved in the node during the evaluation period is determined by detecting the total usage time of the processor resources during the j-th test iteration. The total idle time of the processor resources corresponds one-to-one with the test iteration.

[0399] In one possible implementation, for a first target node among the N nodes, the acquisition unit is further configured to:

[0400] When it is determined in the first test iteration of the i-th performance evaluation cycle that the performance index of the node can no longer meet the timeliness requirements of the first type of task, the first target node is identified as a node without node performance type, and the node performance type of the first target node is temporarily deferred for a specified period of time.

[0401] If, after the specified time period has elapsed, the performance indicators of the node without node performance type still fail to meet the timeliness requirements of the first type of task in the first test iteration of the current performance evaluation cycle, the first task to be evicted running on the node without node performance type will be removed, and the running performance of the first task to be evicted will not meet the timeliness requirements of the first type of task.

[0402] In one possible implementation, for the second target node among the N nodes, the scheduling unit is further configured to:

[0403] If the difference between the remaining processor resources of the second target node and the remaining memory resources of the second target node indicates that the second target node has excess processor resources, a second task to be evicted is determined from the data processing tasks running on the second target node. The processor resource request of the second task to be evicted is less than the memory resource request of the second task to be evicted exceeding a first preset value.

[0404] For the second task to be evicted, a third target node is determined from the N nodes excluding the second target node, and the second task to be evicted is scheduled from the second target node to the third target node. The remaining processor resources of the third target node are greater than or equal to the processor resource request of the second task to be evicted, and the remaining memory resources of the third target node are greater than or equal to the memory resource request of the second task to be evicted.

[0405] If the difference between the remaining processor resources of the second target node and the remaining memory resources of the second target node indicates that the second target node has excess memory resources, a third task to be evicted is determined from the data processing tasks running on the second target node. The processor resource request of the third task to be evicted exceeds the memory resource request of the second task to be evicted by a second preset value.

[0406] For the third task to be evicted, a fourth target node is determined from the N nodes excluding the second target node, and the third task to be evicted is scheduled from the second target node to the fourth target node. The remaining processor resources of the fourth target node are greater than or equal to the processor resource request of the third task to be evicted, and the remaining memory resources of the fourth target node are greater than or equal to the memory resource request of the third task to be evicted.

[0407] In one possible implementation, for the fifth target node among the N nodes, the scheduling unit is further configured to:

[0408] If it is determined that there is a target processing task among the data processing tasks running on the fifth target node, a fourth task to be expelled is determined from the data processing tasks running on the fifth target node. The running performance of the target processing task cannot meet the timeliness requirements of the target processing task, and the fourth task to be expelled belongs to the target processing task.

[0409] The fourth task to be expelled is expelled from the fifth target node, and after expulsion, the fourth task to be expelled is added to the data processing tasks to be assigned.

[0410] As can be seen from the above technical solution, the hybrid deployment system is configured with processor resources for executing data processing tasks. These tasks include a first type of task and a second type of task, where the first type of task has higher timeliness requirements than the second type. Nodes in the hybrid deployment system are used to execute tasks. A node's first performance parameter indicates the amount of processor resources it uses when its performance meets the timeliness requirements for the first type of task, and a second node performance parameter indicates the amount of processor resources it uses when its performance meets the timeliness requirements for the second type of task. In other words, both parameters reflect the achievable amount of processor resource utilization by a node when handling tasks with different timeliness requirements, thus indicating which type of task a node is running with higher processor resource utilization. Accordingly, the node's performance type can be determined based on these parameters to assess which type of task the node is more suitable for. Specifically, the node performance type includes a first type suitable for handling the first type of task; that is, nodes of the first type are more likely to generate higher processor resource utilization when handling the first type of task. Accordingly, for the target first-type task to be assigned, a first node is determined from the nodes of the first type, and the target first-type task is scheduled to the first node. It can be seen that the processor resource usage of each node in handling tasks with different timeliness requirements is evaluated, along with the node's own performance, to select nodes more suitable for the first-type tasks with high timeliness requirements. This allows task scheduling to consider both the task category and the node's performance, allocating higher-performance first nodes to target first-type tasks with high timeliness requirements. Compared to related technologies that only consider processor resource capacity, this avoids scheduling tasks with high timeliness requirements to nodes with poor performance that cannot guarantee such tasks, thus avoiding the problem of low processor resource utilization caused by tasks failing to execute due to unreliable performance after scheduling.

[0411] This application also provides a computer device, which can be a terminal, taking a smartphone as an example:

[0412] Figure 12 The diagram shown is a block diagram of a portion of the structure of a smartphone provided in an embodiment of this application. (Reference) Figure 12The smartphone includes components such as a radio frequency (RF) circuit 1110, a memory 1120, an input unit 1130, a display unit 1140, a sensor 1150, an audio circuit 1160, a Wi-Fi module 1170, a processor 1180, and a power supply 1190. The input unit 1130 may include a touch panel 1131 and other input devices 1132, the display unit 1140 may include a display panel 1141, and the audio circuit 1160 may include a speaker 1161 and a microphone 1162. Those skilled in the art will understand that... Figure 12 The smartphone structure shown does not constitute a limitation on smartphones and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0413] The memory 1120 can be used to store software programs and modules. The processor 1180 executes various functions and data processing of the smartphone by running the software programs and modules stored in the memory 1120. The memory 1120 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the smartphone (such as audio data, phonebook, etc.). In addition, the memory 1120 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0414] The processor 1180 is the control center of the smartphone, connecting various parts of the smartphone via various interfaces and lines. It performs various functions and processes data by running or executing software programs and / or modules stored in the memory 1120 and calling data stored in the memory 1120. Optionally, the processor 1180 may include one or more processing units; preferably, the processor 1180 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1180.

[0415] In this embodiment, the steps performed by the processor 1180 in the smartphone can be based on Figure 12 The structure shown is implemented.

[0416] The computer device provided in this application embodiment can also be a server. Please refer to [link / reference]. Figure 13 As shown, Figure 13This is a structural diagram of the server 1200 provided in this application embodiment. The server 1200 can vary significantly due to different configurations or performance. It may include one or more processors, such as a central processing unit (CPU) 1222, and a memory 1232, and one or more storage media 1230 (e.g., one or more mass storage devices) for storing application programs 1242 or data 1244. The memory 1232 and storage media 1230 can be temporary or persistent storage. The program stored in the storage media 1230 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 1222 may be configured to communicate with the storage media 1230 and execute the series of instruction operations in the storage media 1230 on the server 1200.

[0417] Server 1200 may also include one or more power supplies 1226, one or more wired or wireless network interfaces 1250, one or more input / output interfaces 1258, and / or one or more operating systems 1241, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0418] In this embodiment, the central processing unit 1222 in server 1200 can perform the following steps:

[0419] For N nodes in a hybrid deployment system, obtain a first performance parameter and a second performance parameter corresponding to each of the N nodes. The hybrid deployment system is configured with processor resources for executing data processing tasks. The data processing tasks include a first type of task and a second type of task. The first type of task has higher timeliness requirements than the second type of task. The first performance parameter is used to identify the amount of processor resources used by the node when the node's performance index meets the timeliness requirements of the first type of task. The second performance parameter is used to identify the amount of processor resources used by the node when the node's performance index meets the timeliness requirements of the second type of task.

[0420] Based on the first and second performance parameters of the nodes, determine the node performance types corresponding to the N nodes respectively, wherein the node performance types include a first type suitable for processing the first type of tasks;

[0421] For a target first type of task to be assigned for processing, a first node is determined from the nodes of the first type, and the target first type of task is scheduled to the first node.

[0422] According to one aspect of this application, a computer-readable storage medium is provided for storing a computer program that, when executed by a computer device, causes the computer device to perform the task scheduling method described in the foregoing embodiments.

[0423] According to one aspect of this application, a computer program product is provided, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the methods provided in various optional implementations of the above embodiments.

[0424] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0425] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0426] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of 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 between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

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

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

[0429] 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, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0430] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

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

Claims

1. A task scheduling method, characterized in that, The method includes: For N nodes in a hybrid deployment system, obtain a first performance parameter and a second performance parameter corresponding to each of the N nodes. The hybrid deployment system is configured with processor resources for executing data processing tasks. The data processing tasks include a first type of task and a second type of task. The first type of task has higher timeliness requirements than the second type of task. The first performance parameter is used to identify the amount of processor resources used by the node when the node's performance index meets the timeliness requirements of the first type of task. The second performance parameter is used to identify the amount of processor resources used by the node when the node's performance index meets the timeliness requirements of the second type of task. Based on the first and second performance parameters of the nodes, determine the node performance types corresponding to the N nodes respectively, wherein the node performance types include a first type suitable for processing the first type of tasks; For a target first type of task to be assigned for processing, a first node is determined from the nodes of the first type, and the target first type of task is scheduled to the first node.

2. The method according to claim 1, characterized in that, The step of determining the node performance type corresponding to each of the N nodes based on the first and second performance parameters of the node includes: Obtain the first resource allocation amount corresponding to the first type of task currently running in the hybrid deployment system, and the second resource allocation amount corresponding to the second type of task currently running in the hybrid deployment system; Based on the first performance parameter and the second performance parameter corresponding to the N nodes respectively, as well as the first resource allocation amount and the second resource allocation amount, a first type of node with the first type of node performance and a second type of node with the second type of node performance are determined from the N nodes. The second type of node is suitable for processing the second type of task.

3. The method according to claim 2, characterized in that, The step of dividing the N nodes into a first type of node with the first performance type and a second type of node with the second performance type based on the first performance parameter and the second performance parameter corresponding to the N nodes, and the first resource allocation amount and the second resource allocation amount respectively, includes: The ratio of the first performance parameter to the second performance parameter of the node is determined as the performance ratio parameter of the node; Based on the magnitude of the performance ratio parameters corresponding to the N nodes, the N nodes are sorted to obtain a first ordered set. The performance ratio parameter of the i-th node in the first ordered set is less than the performance ratio parameter of the (i+1)-th node, where 1≤i≤N. Obtain the third performance parameter and the fourth performance parameter corresponding to each of the N nodes. The third performance parameter is used to identify the amount of processor resources allocated to the node when the node's performance index meets the timeliness requirement of the first type of task. The fourth performance parameter is used to identify the amount of processor resources allocated to the node when the node's performance index meets the timeliness requirement of the second type of task. For the first ordered set, starting from the Nth node, the sum of the third performance parameters of the nodes is counted sequentially backward. When the sum of the third performance parameters corresponding to the last k nodes satisfies the first resource allocation amount, the node performance type of the last k nodes is determined as the first type. Starting from the 1st node, the sum of the fourth performance parameters of the nodes is counted sequentially backward. When the sum of the fourth performance parameters corresponding to the current t nodes satisfies the second resource allocation amount, the node performance type of the previous t nodes is determined as the second type.

4. The method according to claim 3, characterized in that, If t < Nk, for nodes from the (t+1)th node to the Nkth node, the method further includes: Obtain the first historical resource allocation amount corresponding to the first type of task running by the hybrid deployment system within a historical period, and the second historical resource allocation amount corresponding to the second type of task running by the hybrid deployment system within the historical period; Based on the first total allocation and the first historical resource allocation corresponding to the first type of node, the first idle degree corresponding to the first type of node is determined, and based on the second total allocation and the second historical resource allocation corresponding to the second type of node, the second idle degree corresponding to the second type of node is determined. The first total allocation is the sum of the third performance parameters corresponding to the first type of node respectively, and the second total allocation is the sum of the fourth performance parameters corresponding to the second type of node respectively. The node allocation target is set based on the difference between the first idle degree and the second idle degree being less than a preset threshold. Starting from the Nkth node, the node performance type of the node is determined forward to be the first type, and starting from the t+1th node, the node performance type of the node is determined backward to be the second type.

5. The method according to claim 3, characterized in that, The method further includes: For the target second type of task to be assigned, a second node is determined from the second type of nodes, and the target second type of task is scheduled to the second node; or... For a target second type of task to be assigned for processing, if the ratio of the processor resource request amount corresponding to the target second type of task to the memory resource request amount corresponding to the target second type of task is greater than the mixing ratio threshold, a third node is determined from the first type of nodes, and the target second type of task is scheduled to the third node.

6. The method according to claim 5, characterized in that, If the ratio of the processor resource request amount corresponding to the target second type of task to the memory resource request amount corresponding to the target second type of task is greater than the mixing ratio threshold, the third node is determined from the first type of nodes, including: If the ratio of the processor resource request amount corresponding to the target second type of task to the memory resource request amount corresponding to the target second type of task is greater than the mixing ratio threshold, and the mixing limit of the processor resources is greater than the sum of the allocated mixed resources and the processor resource request amount of the target second type of task, then the third node is determined from the first type of node; The method further includes: After scheduling the target second type of task to the third node, the processor resource request amount of the target second type of task is accumulated into the allocated mixed resource amount to obtain the updated allocated mixed resource amount.

7. The method according to claim 6, further wherein the mixing ratio threshold is the ratio between the mixing limit of the processor resources and the mixing limit of the memory resources corresponding to the hybrid deployment system, wherein, The mixed limit for processor resources is determined based on the amount of processor resources requested by data processing tasks running in the hybrid deployment system during a historical period, and the mixed limit for memory resources is determined based on the amount of memory resources requested by data processing tasks running in the hybrid deployment system during the historical period.

8. The method according to any one of claims 3-7, characterized in that, The step of determining a first node from the nodes of the first type for a target first category of tasks to be assigned for processing includes: Obtain the processor resource request amount and the memory resource request amount corresponding to the target first type of task; From the nodes of the first type, the nodes whose remaining processor resources are greater than or equal to the processor resource request amount corresponding to the target first type of task, and whose remaining memory resources are greater than or equal to the memory resource request amount corresponding to the target first type of task, are determined as the first available nodes; If the number of first available nodes is K, for each of the K first available nodes, determine the first score corresponding to the first available node. The first score of the first available node is positively correlated with the ranking of the first available node in the first ordered set, and K > 1. The first node is determined from the K first available nodes based on the first scores corresponding to the K first available nodes.

9. The method according to any one of claims 5-7, characterized in that, For the second type of target task to be assigned for processing, determining the second node from the second type of nodes includes: Obtain the processor resource request amount and the memory resource request amount corresponding to the target second type of task; From the nodes of the second type, nodes whose remaining processor resources are greater than or equal to the processor resource request amount corresponding to the target second type of task, and whose remaining memory resources are greater than or equal to the memory resource request amount corresponding to the target second type of task, are determined as second available nodes; If the number of second available nodes is R, for each of the R second available nodes, determine the first score corresponding to the second available node. The first score of the second available node is negatively correlated with the ranking of the second available node in the first ordered set, and R>1. The second node is determined from the R second available nodes based on the first scores corresponding to the R second available nodes.

10. The method according to any one of claims 8-9, characterized in that, For a target available node, which is either the first available node or the second available node, the method further includes: A second score is determined corresponding to the target available node. The second score includes at least one of a resource balancing score and a duration score. The resource balancing score is used to identify the difference between the remaining memory resources and the remaining processor resources of the target available node, and the resource balancing score is positively correlated with the difference. The duration score is used to identify the duration for which the allocable processor resources of the target available node exceed the processor resource request of the target task, and the duration score is positively correlated with the duration. If the target available node is the first available node, the target task is the first type of target task. If the target available node is the second available node, the target task is the second type of target task. Based on the first score corresponding to the target available node and the second score corresponding to the target available node, determine the comprehensive score corresponding to the target available node; If the target available node is the first available node, the step of determining the first node from the K first available nodes based on the first scores corresponding to the K first available nodes includes: Based on the comprehensive scores corresponding to the K first available nodes, the first available node with the highest comprehensive score is determined as the first node; If the target available node is the second available node, the step of determining the second node from the R second available nodes based on the first scores corresponding to the R second available nodes includes: Based on the comprehensive scores corresponding to the R second available nodes, the second available node with the highest comprehensive score is determined as the second node.

11. The method according to claim 1, characterized in that, The step of obtaining the first performance parameter and the second performance parameter corresponding to each of the N nodes includes: In the i-th performance evaluation cycle, the total idle time of the processor resources involved in the node is determined based on the total usage time of the processor resources involved in the node. The performance evaluation cycle includes at least M test iterations. In the j-th test iteration, the test time is determined from the total idle time based on the j-th resource ratio, and a number of test threads matching the test time are established at the node. The test threads are used to simulate the data processing task. The j-th resource ratio is obtained by increasing the resource ratio of the (j-1)-th test iteration by a certain percentage and step size. Based on the processor resources allocated to the data processing task by the processor used by the data processing task running in the node, determine the performance index of the node in the j-th test iteration; When it is determined that the performance index of the node meets the timeliness requirements of the first type of task, the amount of processor resources used by the node is determined as the first performance parameter. When it is determined that the performance index of the node meets the timeliness requirements of the second type of task, the amount of processor resources used by the node is determined as the second performance parameter.

12. The method according to claim 11, characterized in that, In the i-th performance evaluation cycle, the total idle time of the processor resources is determined based on the total usage time of the processor resources involved in the node, including: At the start of the i-th performance evaluation cycle, the total idle time of the processor resources involved in the node is determined by detecting the total usage time of the processor resources within the evaluation duration; or, At the start of the j-th test iteration, the total idle time of the processor resources involved in the node during the evaluation period is determined by detecting the total usage time of the processor resources during the j-th test iteration. The total idle time of the processor resources corresponds one-to-one with the test iteration.

13. The method according to claim 11, characterized in that, For the first target node among the N nodes, the method further includes: When it is determined in the first test iteration of the i-th performance evaluation cycle that the performance index of the node can no longer meet the timeliness requirements of the first type of task, the first target node is identified as a node without node performance type, and the node performance type of the first target node is temporarily deferred for a specified period of time. If, after the specified time period has elapsed, the performance indicators of the node without node performance type still fail to meet the timeliness requirements of the first type of task in the first test iteration of the current performance evaluation cycle, the first task to be evicted running on the node without node performance type will be removed, and the running performance of the first task to be evicted will not meet the timeliness requirements of the first type of task.

14. The method according to any one of claims 1-7 or any one of claims 11-13, characterized in that, For the second target node among the N nodes, the method further includes: If the difference between the remaining processor resources of the second target node and the remaining memory resources of the second target node indicates that the second target node has excess processor resources, a second task to be evicted is determined from the data processing tasks running on the second target node. The processor resource request of the second task to be evicted is less than the memory resource request of the second task to be evicted exceeding a first preset value. For the second task to be evicted, a third target node is determined from the N nodes excluding the second target node, and the second task to be evicted is scheduled from the second target node to the third target node. The remaining processor resources of the third target node are greater than or equal to the processor resource request of the second task to be evicted, and the remaining memory resources of the third target node are greater than or equal to the memory resource request of the second task to be evicted. If the difference between the remaining processor resources of the second target node and the remaining memory resources of the second target node indicates that the second target node has excess memory resources, a third task to be evicted is determined from the data processing tasks running on the second target node. The processor resource request of the third task to be evicted exceeds the memory resource request of the second task to be evicted by a second preset value. For the third task to be evicted, a fourth target node is determined from the N nodes excluding the second target node, and the third task to be evicted is scheduled from the second target node to the fourth target node. The remaining processor resources of the fourth target node are greater than or equal to the processor resource request of the third task to be evicted, and the remaining memory resources of the fourth target node are greater than or equal to the memory resource request of the third task to be evicted.

15. The method according to any one of claims 1-7 or any one of claims 11-13, characterized in that, For the fifth target node among the N nodes, the method further includes: If it is determined that there is a target processing task among the data processing tasks running on the fifth target node, a fourth task to be expelled is determined from the data processing tasks running on the fifth target node. The running performance of the target processing task cannot meet the timeliness requirements of the target processing task, and the fourth task to be expelled belongs to the target processing task. The fourth task to be expelled is expelled from the fifth target node, and after expulsion, the fourth task to be expelled is added to the data processing tasks to be assigned.

16. A task scheduling device, characterized in that, The device includes an acquisition unit, a determination unit, and a scheduling unit: The acquisition unit is used to acquire, for N nodes in the hybrid deployment system, first performance parameters and second performance parameters corresponding to each of the N nodes. The hybrid deployment system is configured with processor resources for executing data processing tasks. The data processing tasks include a first type of task and a second type of task. The first type of task has higher timeliness requirements than the second type of task. The first performance parameter is used to identify the amount of processor resources used by the node when the node's performance index meets the timeliness requirements of the first type of task. The second performance parameter is used to identify the amount of processor resources used by the node when the node's performance index meets the timeliness requirements of the second type of task. The determining unit is configured to determine the node performance type corresponding to each of the N nodes based on the first performance parameter and the second performance parameter of the node, wherein the node performance type includes a first type suitable for processing the first type of task; The scheduling unit is used to determine a first node from the nodes of the first type for a target first type of task to be assigned for processing, and to schedule the target first type of task to the first node.

17. A computer device, characterized in that, The computer device includes a processor and memory: The memory is used to store computer programs and to transfer the computer programs to the processor; The processor is configured to execute the method according to any one of claims 1-15 according to instructions in the computer program.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program that, when executed by a computer device, causes the computer device to perform the method according to any one of claims 1-15.

19. A computer program product, comprising a computer program, characterized in that, When it is run on a computer device, it causes the computer device to perform the method according to any one of claims 1-15.

Images