Heterogeneous resource dynamic sensing and self-adaptive scheduling method

Abstract

The invention provides a heterogeneous resource dynamic sensing and self-adaptive scheduling method, which comprises the following steps of: dynamically acquiring basic attributes such as resource types, core configuration, memory capacity and bandwidth and real-time information such as load state and temperature through a heterogeneous resource feature extraction module by utilizing a hardware interface and software probe technology, and storing data in a feature table after processing, accurate scheduling decision basis is ensured; a self-adaptive scheduling algorithm is designed, matching with resource characteristics is carried out based on task calculation, memory and parallelism requirements, proper resources are preferentially allocated, competition is avoided by checking a load state, and the algorithm supports dynamic adjustment so as to optimize allocation efficiency; and finally, through a real-time monitoring and dynamic adjustment mechanism, regularly collecting resource and task state information, detecting a competition or low-efficiency condition, executing operations such as task migration, priority adjustment or resource reservation and the like, and ensuring efficient operation of the system. The heterogeneous resource scheduling efficiency and stability are improved, and the method is suitable for a modern computing environment.

Description

Technical Field

[0001] The present invention relates to the field of computer resource management, and in particular to a method for dynamic perception and adaptive scheduling of heterogeneous resources. Background Art

[0002] With the rapid development of cloud computing and distributed computing technologies, the integrated application of heterogeneous resources (such as CPU, GPU, FPGA, TPU, etc.) has become the key to improving system performance. Traditional schedulers are mostly based on the assumption of homogeneous resources, relying on static allocation or simple polling, and are difficult to adapt to the complexity of heterogeneous environments. For example, in mixed load scenarios, the scheduler may assign tasks that require high parallel computing to mismatched resources, resulting in low resource utilization (usually <60%) and increased task delays (average 20%-50%). In addition, when multiple tasks compete for the same resource, traditional methods lack dynamic identification capabilities, and the resource conflict rate can be as high as 40%. Existing improvement solutions such as priority scheduling or manual binding are difficult to cope with real-time changing loads. Therefore, there is an urgent need for an automated and accurate resource identification and scheduling method. Summary of the Invention

[0003] The purpose of the invention is to propose a method for dynamic perception and adaptive scheduling of heterogeneous resources to solve the resource competition problem caused by the inability of traditional schedulers to identify heterogeneous resources, thereby increasing resource utilization to more than 85%, reducing task delays by 30%-40%, and enhancing system stability.

[0004] The technical solution is a method for dynamic perception and adaptive scheduling of heterogeneous resources. The specific steps are as follows:

[0005] S1: Through the heterogeneous resource feature extraction module, hardware and software collaborative technology are used to dynamically collect feature information of heterogeneous resources and generate a resource feature table, providing accurate and reliable data support for subsequent task allocation and scheduling decisions;

[0006] S2: Based on the resource feature table and task demand characteristics, an adaptive scheduling algorithm is used to allocate tasks to the most suitable heterogeneous resources through task-resource matching analysis. At the same time, a contention avoidance mechanism is used to optimize the allocation process to avoid resource overuse or conflicts.

[0007] S3: By real-time monitoring of resource operation status and task execution, combined with dynamic adjustment of scheduling strategies, timely response to resource competition or inefficiency issues can be achieved to ensure efficient task execution and long-term system stability.

[0008] Furthermore, the heterogeneous resource feature extraction module in step S1 dynamically collects feature information of various heterogeneous resources by combining hardware interfaces and software probe technology. The collection process covers various resource types and operating environments, specifically including:

[0009] S1.1: For graphics processor resources, use dedicated programming interfaces to obtain information such as the number of cores, main frequency, video memory capacity, and current thread occupancy to fully characterize its computing and parallel processing capabilities;

[0010] S1.2: For CPU resources, extract operating parameters such as core frequency, cache size, and temperature through the interface provided by the operating system to evaluate its current status and available performance;

[0011] S1.3: For field-programmable gate arrays or dedicated accelerators, collect characteristic data such as the number of logic units and memory bandwidth through the driver interface provided by the manufacturer to reflect their dedicated computing capabilities;

[0012] S1.4: The characteristic information is divided into two categories: static parameters and dynamic status. Static parameters include resource type, number of cores, main frequency, memory capacity, bandwidth, and supported instruction sets, which are used to describe the basic capabilities of the resource. Dynamic status includes current load percentage, temperature, power consumption, and available computing power, which are used to reflect the real-time operating status of the resource.

[0013] S1.5: The collected data is optimized through smoothing technology to eliminate noise interference and stored in a resource feature table in memory to provide real-time data support for the scheduler.

[0014] Furthermore, the heterogeneous resource feature extraction module in step S1 also includes a fault-tolerant mechanism to ensure the continuity and reliability of feature information collection in a complex heterogeneous environment, specifically including:

[0015] S1.6: Set timeout retry logic to automatically trigger a retry operation when the interface response times out to avoid data interruption caused by temporary failures;

[0016] S1.7: When data is missing or abnormal, use the average value of historically collected data to fill in the gaps and maintain the integrity of the feature information;

[0017] S1.8: Support dynamic adjustment of collection frequency and data processing to adapt to the needs of different resource types and operating environments, ensuring that the generated resource feature table can still provide high-precision and low-latency data support in various abnormal scenarios.

[0018] Furthermore, the adaptive scheduling algorithm described in step S2 includes a complete process of task demand modeling and resource matching, aiming to achieve efficient matching of tasks with heterogeneous resources, specifically including:

[0019] S2.1: Generate a task requirement vector by parsing the task configuration file or analyzing historical operation data. The task requirement vector comprehensively represents the computing requirements, memory requirements, and parallelism requirements of the task, and fully reflects the resource usage characteristics of the task;

[0020] S2.2: Based on the task requirement vector and the data in the resource feature table, calculate the matching degree between the task and each heterogeneous resource. The matching degree is determined by a multi-dimensional weighted method, which comprehensively evaluates the matching degree of computing power, memory capacity, and parallel support.

[0021] S2.3: Before assigning tasks, avoid resource contention by checking the current load status and occupancy of the target resources. The avoidance mechanism includes marking high-load resources and adjusting the priority of multiple tasks competing for resources to ensure that the task allocation process balances efficiency and fairness.

[0022] Furthermore, the adaptive scheduling algorithm described in step S2 also supports online learning functions to further optimize the task allocation strategy and scheduling effect, specifically including:

[0023] S2.4: Based on historical task execution data and feedback, the algorithm dynamically adjusts the weighting parameters used in the matching calculation by analyzing the actual performance of tasks on different resources. For example, if the performance of a certain type of task on a specific resource falls short of expectations, the algorithm automatically increases the weighting of the relevant resource characteristics.

[0024] S2.5: Support dynamic updating of task demand vectors. By collecting performance data from the first run of the task, the initial demand model is revised to improve the matching degree and adaptability of the allocation strategy, ensuring that the scheduling process can continuously adapt to changes in task characteristics and resource status.

[0025] Furthermore, the real-time monitoring described in step S3 is implemented by a lightweight monitoring agent deployed on each computing node, which aims to dynamically track the running status of resources and tasks, specifically including:

[0026] S3.1: The monitoring agent regularly collects information such as resource load, task delay, network bandwidth usage, and task progress, and sends the data to the central scheduler via an efficient transmission protocol for real-time analysis and decision-making;

[0027] S3.2: The dynamic adjustment strategy includes a task migration method, which transfers tasks by evaluating the status of alternative resources to alleviate competition;

[0028] S3.3: The dynamic adjustment strategy includes a priority adjustment method to dynamically reduce the resource usage of competing tasks according to the importance of the tasks;

[0029] S3.4: The dynamic adjustment strategy includes a resource reservation method, which reserves part of the resource capacity for critical tasks to avoid sudden competition;

[0030] S3.5: When the monitoring agent detects a resource failure or abnormal status, such as excessive temperature or abnormal error rate, it immediately isolates the affected resources and triggers an alarm, while reallocating related tasks to healthy resources to ensure the continuity and stability of system operation.

[0031] Beneficial effects: The present invention solves the competition and inefficiency problems caused by the inability of traditional schedulers to accurately identify resource characteristics, improves resource utilization efficiency, reduces task execution time, and enhances system stability. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 It is a flow chart of the present invention. DETAILED DESCRIPTION

[0033] Example 1

[0034] like Figure 1 As shown in FIG, a method for dynamic perception and adaptive scheduling of heterogeneous resources is described, and the specific steps are as follows:

[0035] Step 1: Heterogeneous resource feature extraction

[0036] This module is the foundational component of this invention. It aims to comprehensively and dynamically collect feature information about heterogeneous resources through deep collaboration between hardware and software, ensuring that the scheduler can make decisions based on accurate data. The specific implementation of the module includes the following levels of technical details:

[0037] 1.1 Data Collection Methods: The module utilizes a variety of data collection methods, including hardware-level API calls and software-level probe technology. For GPU resources, the CUDA 11.0 or OpenCL 2.0 interface is used to obtain the core number, main frequency, video memory capacity, and current thread occupancy. For CPU resources, the Linux operating system's / proc / cpuinfo and / sys / class / thermal interfaces are used to extract core frequency, cache size, and temperature data. For specialized accelerators such as FPGAs, the manufacturer's driver interface (such as Xilinx SDAccel) is used to obtain the number of logic units and memory bandwidth.

[0038] 1.2 Collection Parameter Range: The collected features are categorized into two types: static parameters and dynamic states. Static parameters include resource type (e.g., CPU model Intel Xeon E5, GPU model NVIDIA A100), number of cores (e.g., 12-core CPU, 3584 CUDA cores), main frequency (e.g., 2.6GHz), memory capacity (e.g., 32GB DRAM, 12GB HBM3), bandwidth (e.g., 1GB / s), and supported instruction sets (e.g., AVX-512, FP16). Dynamic states include current load percentage (0-100%), temperature (°C), power consumption (watts), and available computing power (FLOPS). The dynamic state collection frequency is set to 1 time / second to balance real-time performance with system overhead (CPU utilization is kept below 2%).

[0039] 1.3 Data processing and storage: The collected raw data is smoothed by the sliding window averaging method with a window size of 5 seconds. The calculation formula is: where X t is the smoothed value at the current moment, X i The available computing power of the resource is calculated by the formula: r =C r ×F r ×(1-L r ), where A r : Available computing power of resource r (unit: FLOPS); C r : Number of resource cores; F r : Resource main frequency (unit: GHz); L r : The current load percentage of the resource (0-1);

[0040] The collection results are stored in the resource feature table in the memory, the table structure is {resource ID, type, A r , memory, bandwidth, temperature, timestamp}, using hash table to achieve fast query (average time complexity O(1)).

[0041] Fault-tolerance mechanism: To cope with hardware failures or interface anomalies, the module has built-in timeout retry logic (timeout threshold 500ms, 3 retries), and uses historical averages to fill in missing data to ensure the integrity of the feature table.

[0042] Through the above design, the module can provide high-precision (error <5%) and low-latency (<10ms) feature data for heterogeneous resources, providing a reliable basis for subsequent scheduling.

[0043] Step 2: Adaptive Scheduling Algorithm

[0044] This algorithm is the core optimization method of this invention, which aims to achieve efficient task-resource matching based on resource characteristics and task requirements while avoiding resource competition. Its design includes the following detailed steps and technical details:

[0045] 2.1 Task Demand Modeling: The demand vector of each task is generated by parsing the configuration file or analyzing the historical operation data, which is defined as: T d ={C d ,M d ,P d}, where C d : Computing requirements (FLOPS, such as 10^9FLOPS, which indicates the number of floating-point operations per second); M d : Memory requirement (GB, such as 8GB, indicating the memory space required for the task); P d : Parallelism requirement (number of threads, such as 16, indicating the number of threads or cores required).

[0046] To improve modeling accuracy, the algorithm supports dynamic updates, such as adjusting C by sampling the performance of the initial task run. d (The error is controlled within 10%).

[0047] 2.2 Matching Degree Calculation: The algorithm calculates the matching degree between tasks and resources through multi-dimensional weighted Euclidean distance. The formula is: Among them, S tr : The matching degree between task t and resource r; M r : Resource available memory (GB); P r : The degree of parallelism supported by the resource; w1, w2, w3: weight coefficients, the default values are 0.4, 0.3, 0.3, and are dynamically adjusted according to the task type. For example, computing-intensive tasks are set to {0.5, 0.3, 0.2}, and memory-intensive tasks are set to {0.2, 0.6, 0.2}; matching degree S tr The range is 0 to 1, with higher scores indicating a better match.

[0048] 2.3 Contention Avoidance Mechanism: Before allocating resources, the algorithm checks the current load L of the target resource r ; If L r If the value is >0.85, the resource is considered to be in a high-load state, marked as unavailable, and the suboptimal matching resource is selected from the resource pool; to further reduce competition, the algorithm introduces a pre-allocation check: if a resource is already occupied by multiple tasks (>2), its matching weight is reduced (by 20%).

[0049] 2.4 Scheduling Optimization Strategy: The goal of the algorithm is to maximize the overall matching degree and minimize resource competition, using a greedy strategy to prioritize S trThe highest resource is used, while also combining global load balancing. If no qualified resource is available in the resource pool, the task enters the waiting queue and is sorted by priority (high-priority tasks have a waiting time of less than 1 second). The algorithm has a time complexity of O(n × m), where n is the number of tasks and m is the number of resources.

[0050] 2.5 Adaptive Adjustment: The algorithm supports online learning and adjusts weight parameters by recording historical scheduling results. For example, if a task's execution time on the GPU exceeds expectations by 20%, the w1 value will be increased next time to prioritize the computing power. This algorithm ensures efficient and fair task allocation through meticulous matching calculations and contention avoidance.

[0051] Step 3: Real-time monitoring and dynamic adjustment of resource status

[0052] This mechanism aims to solve resource contention and inefficiency issues during runtime by monitoring resource status and task execution in real time, dynamically optimizing scheduling strategies, and implementing it. Its implementation includes the following technical details:

[0053] 3.1 Monitoring data collection: Deploy a lightweight monitoring agent, run it on each computing node, and collect data every 200 milliseconds. The collected indicators include resource load L r , Task Delay D t , network bandwidth usage (MB / s), error rate (number of exceptions per minute), and task progress (percentage of completion). Data is transmitted to the central scheduler via the UDP protocol with a transmission delay of <5ms.

[0054] 3.2 Competition detection: Define the triggering conditions of the competition state as: C c =(L r >0.9)∧(D t >D0×1.2), where C c :Competition state (Boolean value); D t : Current task delay (seconds); D0: Task baseline delay (seconds, obtained by initial run or user specified);

[0055] The detection algorithm is based on time series analysis, sets a 5-second sliding window, calculates the mean and variance of load and latency, and ensures a false alarm rate of <3%.

[0056] 3.3 Dynamic Adjustment Strategy: The adjustment mechanism includes the following three methods:

[0057] (1) Task migration

[0058] Find alternative resources with load < 50% and calculate the migration cost: O m =T d / B r +R t , where Om : Migration cost (seconds); T d : Task data volume (GB); B r : Inter-resource bandwidth (GB / s); R t : Task restart time (seconds, default 0.2 seconds).

[0059] If O m <D t -D0 uses container migration technology (such as Docker checkpoint / restore) to transfer tasks, and the migration process ensures data consistency (checksum verification).

[0060] (2) Priority Adjustment

[0061] If there are no suitable alternative resources, the priority of the competing task is lowered, reducing its resource utilization (e.g., from 100% to 70%), freeing up resources for the higher-priority task. The adjustment is based on the task's importance score (user-specified, ranging from 0-10).

[0062] (3) Resource reservation

[0063] Reserve resources for critical tasks (such as 20% of GPU memory). Set a resource cap to avoid sudden competition. The reserved amount can be adjusted dynamically (based on the task queue length).

[0064] 3.4 Adjustment Optimization: To reduce the overhead caused by frequent migration, a cooldown period (default 10 seconds) is set. The same task can be adjusted at most once during the cooldown period. The adjusted resource status is synchronized to all nodes via broadcast to ensure scheduling consistency.

[0065] 3.5 Exception handling: If the monitoring agent detects a resource failure (e.g., temperature > 90°C or error rate > 5 times / minute), the resource is immediately isolated and an alarm is triggered, and the task is reallocated to a healthy resource.

[0066] Through real-time monitoring and multi-strategy adjustment, this mechanism can quickly respond to resource competition and maintain efficient system operation.

[0067] Example 2

[0068] Hybrid task scheduling on cloud computing platforms

[0069] In a cloud computing platform containing 48 nodes, the node resource configuration is as follows: 24 CPU nodes (model Intel Xeon E5-2620 v4, main frequency 2.6GHz, 12 cores, memory 32GB, bandwidth 1GB / s), 12 GPU nodes (model NVIDIA Tesla V100, main frequency 1.8GHz, CUDA core 5120, video memory 12GB, bandwidth 900MB / s), 12 FPGA nodes (model Xilinx VU9P, main frequency 600MHz, number of logic units 2.5 million, memory 8GB, bandwidth 600MB / s). The platform is used to process mixed task loads submitted by users, including multiple computing requirements such as image processing, data analysis and real-time reasoning. This embodiment takes the scheduling of three typical tasks as an example to demonstrate in detail the execution process and technical effects of the method of the present invention, including:

[0070] Task Description

[0071] The user submits the following three tasks at the same time:

[0072] Task A (image processing): requires high parallel computing capabilities, and the demand vector is T d ={6×10 9 FLOPS,8GB,32} indicates that 600 million floating-point operations per second are required, 8GB of memory is used, and 32 parallel threads are required. The task profile specifies a priority of 8 (range 0-10).

[0073] Task B (data analysis): memory-intensive task with a demand vector of T d ={2×10 9 FLOPS, 16GB, 8}, the computational complexity is low but requires large memory, and the priority is 6.

[0074] Task C (real-time reasoning): a balanced task with a demand vector of T d ={4×10 9 FLOPS, 4GB, 16}, requiring medium computing power and parallelism, with a priority of 7.

[0075] Step 1: Resource feature collection and initialization

[0076] When the system starts, the heterogeneous resource feature extraction module collects the current status of each node through API and probe technology:

[0077] GPU1 (Tesla V100): 5120 cores, 1.8 GHz clock speed, 25% load, 12 GB video memory, 900 MB / s bandwidth, 45°C temperature. Computing available capacity: A r =5120×1.8×(1-0.25)=6.912×10 9FLOPS;

[0078] CPU1 (Xeon E5-2620): 12 cores, 2.6 GHz clock speed, 40% load, 32 GB memory, 1 GB / s bandwidth, 50°C temperature. Computing capacity available: A r =12×2.6×(1-0.4)=18.72×10 9 FLOPS;

[0079] FPGA1 (VU9P): 2.5 million logic units, 600 MHz main frequency (equivalent to 8 cores), current load 10%, 8 GB memory, 600 MB / s bandwidth, temperature 40°C. Computing available capacity: A r =8×0.6×(1-0.1)=4.32×10 9 FLOPS;

[0080] The collected data is stored in the resource feature table in the format of {resource ID, type, r , memory, bandwidth, temperature, timestamp}. To ensure data accuracy, the module updates at a frequency of 1 time / second, with a 5-second sliding window for smoothing, and the system overhead is controlled at 1.8% CPU usage.

[0081] Step 2: Task requirement modeling and resource matching

[0082] The scheduler parses the task requirements and generates T d vector and calculate the matching degree between each task and resource:

[0083] Task A matching calculation:

[0084] With GPU1: (The upper limit of parallelism is the maximum value of resources);

[0085] With CPU1: GPU1 has the highest score and its load is <85%, so task A is assigned to GPU1.

[0086] Task B matching calculation:

[0087] With CPU1: (memory-intensive weight adjustment);

[0088] With FPGA1: CPU1 has the highest score, so task B is assigned to CPU1.

[0089] Task C matching calculation:

[0090] With FPGA1: FPGA1 has the highest score, so task C is assigned to FPGA1.

[0091] Step 3: Real-time monitoring and dynamic adjustment

[0092] After the task runs, the monitoring agent collects status every 200 milliseconds:

[0093] Initial run: Task A runs on GPU1 for 5 seconds, load rises to 90%, delay D t =0.23 seconds, benchmark delay D0 =0.19 seconds; tasks B and C run normally, with loads of CPU1 55% and FPGA1 30% respectively.

[0094] Competition detection: GPU1 meets C c =(0.9>0.9)∧(0.23>0.19×1.2)=true, triggering adjustment.

[0095] Adjustment decision: Find alternative resource GPU2 (load 30%, A r =6.912×10 9 FLOPS), calculate the migration overhead: O m =8 / 0.9+0.2=9.09 seconds delay increment D t -D0=0.04 seconds, O m >D t -D0: Migration is not cost-effective. Instead, we lower the priority of task A to 6, freeing up 20% of GPU resources and restoring latency to 0.20 seconds.

[0096] Subsequent optimization: After 10 seconds of execution, Task A was completed, and the GPU1 load dropped to 10%. Tasks B and C were completed in 12 and 15 seconds, respectively, for a total execution time of 15 seconds.

[0097] Result Analysis

[0098] Effects of the present invention: total completion time is 15 seconds, resource utilization rate is 85% on average, and contention rate is <5%.

[0099] Comparison with traditional scheduling: Without recognition capabilities, tasks A and B might be assigned to CPU1, and task C to GPU1, resulting in an overload on CPU1 (>95%), a total execution time of 22 seconds, and a 46% increase in latency.

[0100] This method shortens execution time by 31%, significantly improving efficiency.

[0101] The preferred embodiments of the present invention are described in detail above. However, the present invention is not limited to the specific details in the above embodiments. Within the technical concept of the present invention, various equivalent transformations can be made to the technical solutions of the present invention, and these equivalent transformations all fall within the scope of protection of the present invention.

Claims

1. A method for dynamic perception and adaptive scheduling of heterogeneous resources, characterized in that: The following steps are involved: S1: Through the heterogeneous resource feature extraction module, hardware and software collaborative technology are used to dynamically collect feature information of heterogeneous resources and generate a resource feature table, providing accurate and reliable data support for subsequent task allocation and scheduling decisions; S2: Based on the resource feature table and task demand characteristics, an adaptive scheduling algorithm is used to allocate tasks to the most suitable heterogeneous resources through task-resource matching analysis. At the same time, a contention avoidance mechanism is used to optimize the allocation process to avoid resource overuse or conflicts. S3: By real-time monitoring of resource operation status and task execution, combined with dynamic adjustment of scheduling strategies, timely response to resource competition or inefficiency issues can be achieved to ensure efficient task execution and long-term system stability.

2. The method according to claim 1, characterized in that The heterogeneous resource feature extraction module in step S1 dynamically collects feature information of various heterogeneous resources by combining hardware interfaces and software probe technology. The collection process covers various resource types and operating environments, specifically including: S1.1: For graphics processor resources, use dedicated programming interfaces to obtain information such as the number of cores, main frequency, video memory capacity, and current thread occupancy to fully characterize its computing and parallel processing capabilities; S1.2: For CPU resources, extract operating parameters such as core frequency, cache size, and temperature through the interface provided by the operating system to evaluate its current status and available performance; S1.3: For field-programmable gate arrays or dedicated accelerators, collect characteristic data such as the number of logic units and memory bandwidth through the driver interface provided by the manufacturer to reflect their dedicated computing capabilities; S1.4: The characteristic information is divided into two categories: static parameters and dynamic status. Static parameters include resource type, number of cores, main frequency, memory capacity, bandwidth, and supported instruction sets, which are used to describe the basic capabilities of the resource. Dynamic status includes current load percentage, temperature, power consumption, and available computing power, which are used to reflect the real-time operating status of the resource. S1.5: The collected data is optimized through smoothing technology to eliminate noise interference and stored in a resource feature table in memory to provide real-time data support for the scheduler.

3. The method according to claim 2, characterized in that The heterogeneous resource feature extraction module in step S1 also includes a fault-tolerant mechanism to ensure the continuity and reliability of feature information collection in a complex heterogeneous environment, specifically including: S1.6: Set timeout retry logic to automatically trigger a retry operation when the interface response times out to avoid data interruption caused by temporary failures; S1.7: When data is missing or abnormal, use the average value of historically collected data to fill in the gaps and maintain the integrity of the feature information; S1.8: Support dynamic adjustment of collection frequency and data processing to adapt to the needs of different resource types and operating environments, ensuring that the generated resource feature table can still provide high-precision and low-latency data support in various abnormal scenarios.

4. The method according to claim 1, wherein The adaptive scheduling algorithm described in step S2 includes the complete process of task demand modeling and resource matching, aiming to achieve efficient matching of tasks with heterogeneous resources, specifically including: S2.1: Generate a task requirement vector by parsing the task configuration file or analyzing historical operation data. The task requirement vector comprehensively represents the computing requirements, memory requirements, and parallelism requirements of the task, and fully reflects the resource usage characteristics of the task; S2.2: Based on the task requirement vector and the data in the resource feature table, calculate the matching degree between the task and each heterogeneous resource. The matching degree is determined by a multi-dimensional weighted method, which comprehensively evaluates the matching degree of computing power, memory capacity, and parallel support. S2.3: Before assigning tasks, avoid resource contention by checking the current load status and occupancy of the target resources. The avoidance mechanism includes marking high-load resources and adjusting the priority of multiple tasks competing for resources to ensure that the task allocation process balances efficiency and fairness.

5. The method according to claim 4, characterized in that The adaptive scheduling algorithm described in step S2 also supports online learning to further optimize the task allocation strategy and scheduling effect, including: S2.4: Based on historical task execution data and feedback, the algorithm dynamically adjusts the weighting parameters used in the matching calculation by analyzing the actual performance of tasks on different resources. For example, if the performance of a certain type of task on a specific resource falls short of expectations, the algorithm automatically increases the weighting of the relevant resource characteristics. S2.5: Support dynamic updating of task demand vectors. By collecting performance data from the first run of the task, the initial demand model is revised to improve the matching degree and adaptability of the allocation strategy, ensuring that the scheduling process can continuously adapt to changes in task characteristics and resource status.

6. The method according to claim 1, characterized in that The real-time monitoring described in step S3 is implemented by a lightweight monitoring agent deployed on each computing node, which aims to dynamically track the running status of resources and tasks, including: S3.1: The monitoring agent regularly collects information such as resource load, task delay, network bandwidth usage, and task progress, and sends the data to the central scheduler via an efficient transmission protocol for real-time analysis and decision-making; S3.2: The dynamic adjustment strategy includes a task migration method, which transfers tasks by evaluating the status of alternative resources to alleviate competition; S3.3: The dynamic adjustment strategy includes a priority adjustment method to dynamically reduce the resource usage of competing tasks according to the importance of the tasks; S3.4: The dynamic adjustment strategy includes a resource reservation method, which reserves part of the resource capacity for critical tasks to avoid sudden competition; S3.5: When the monitoring agent detects a resource failure or abnormal status, such as excessive temperature or abnormal error rate, it immediately isolates the affected resources and triggers an alarm, while reallocating related tasks to healthy resources to ensure the continuity and stability of system operation.

Images