Second-level cold start batch test execution method and system based on resource prediction
By combining machine learning prediction and container snapshot technology with CPU/GPU heterogeneous scheduling and fault self-healing mechanisms, the problems of low efficiency and poor robustness in batch testing of data tools are solved, and efficient and stable batch test execution is achieved.
Patent Information
- Application Number
- CN202511512480.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-22
- Publication Date
- 2026-02-27
AI Technical Summary
In existing technologies, batch testing of data tools relies on manual processes, which leads to low efficiency, waste of resources, lack of flexibility and error-proneness, and cannot achieve high parallelism, low latency and robust operation.
By employing machine learning resource consumption prediction, container incremental snapshot second-level cold start, CPU/GPU heterogeneous computing scheduling, and fault injection-self-healing mechanisms, we achieve highly parallel, low-latency, and robust operation for large-scale data tool use cases.
It enables accurate prediction and real-time scheduling of task resource requirements, significantly shortens task startup time, improves resource utilization and system response speed, and enhances system robustness and automated analysis capabilities.
Smart Images
Figure CN121579332A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of software automated testing and computing resource management, more particularly to a second-level cold start batch test execution method and system based on resource prediction, and especially to a batch test execution method and system applied to "data tools" (such as interlocking data preparation tools, line table generation tools, simulation / verification scripts, etc.) in the field of rail transit. BACKGROUND
[0002] According to the industry standard requirements of EN50128, the batch test of the current data tools (interlocking table generation tools, line table verification scripts, simulation verification programs, etc.) is still mainly based on a full manual process, and the typical technical solution can be summarized as the following steps: 1. Manually preparing test data The test engineer manually edits or exports test cases in Excel or a database.
[0003] The data version and dependency relationship are recorded by file name or orally, and there is a lack of unified metadata management.
[0004] 2. Manually starting the program to be tested Double-clicking.exe / script to run one by one or in small batches on a single workstation or server; Concurrent running cannot be achieved, and there is a lack of reusable scheduling logic.
[0005] 3. Manually monitoring resources and fault handling If a deadlock or crash is found, the process needs to be manually ended, the intermediate files are cleaned up, and the execution is restarted; The GPU resources are basically idle, and heterogeneous scheduling cannot be done according to the task type.
[0006] 4. Result collection and comparison The engineer manually copies the output to a local folder and then compares the files one by one using Excel / Diff tools; The differences in logs or two-dimensional tables are mainly scanned by "naked eyes", which is low in efficiency and easy to miss.
[0007] 5. Test report arrangement The difference screenshots are pasted into Word, and a PDF is output; the entire cycle is usually measured in "days".
[0008] The main defects of the above existing technology are: Low efficiency: it takes hours to days for a complete regression; Waste of resources: CPU / GPU occupancy fluctuates greatly, and the machine is idle for a long time; Lack of flexibility: unable to dynamically adjust concurrency according to real-time load, and no cold start optimization; Error-prone: High error rate during manual reruns and result copying; Fault-free drills: Without fault injection and self-healing mechanisms, the robustness of the system cannot be verified. Summary of the Invention
[0009] To overcome the shortcomings of the existing technologies, this invention discloses a method and system for batch test execution with second-level cold start based on resource prediction. The purpose of this invention is to solve the bottlenecks in efficiency, stability, and scalability caused by complete reliance on manual processes in the existing technologies. This invention comprehensively utilizes machine learning resource occupancy prediction, second-level cold start of container incremental snapshots, CPU / GPU heterogeneous computing scheduling, and fault injection-self-healing mechanisms to achieve highly parallel, low-latency, and robust operation of large-scale data tool use cases, thereby replacing traditional manual processes.
[0010] To achieve the above objectives, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides a second-level cold start batch test execution method based on resource prediction, comprising the following steps: S1. Collect data to train the resource prediction model and update the weights of the resource prediction model; Preferably, step S1 includes: Collect historical resource usage data for tasks to be executed; wherein, the historical resource usage data includes CPU peak, memory peak, GPU peak, IO operations, and duration; Input the resource prediction model, and use historical resource usage data and the LightGBM algorithm to train the resource prediction model and update the weights of the resource prediction model.
[0011] S2. Receive the task batch queue, use the resource prediction model to predict the resource requirements of each task, calculate the target number of concurrent tasks using linear programming, and use PID filtering to adjust the number of concurrent tasks in batches. Preferably, step S2 includes: When the scheduler receives a new task batch queue, it predicts the resource requirements of each task using a resource prediction model; wherein, the resource requirements include CPU, memory, and GPU resource requirements; Based on the resource requirement prediction results of each task, and combined with the current hardware and software resources of the platform, the target number of concurrent tasks N is determined using the linear programming calculation interface. After determining the target number of concurrent tasks, the number of concurrent tasks is smoothly adjusted in batches through the PID filter control interface to keep the resource load within the set high and low water level range.
[0012] S3. Determine if there are any unexecuted tasks in the queue. If yes, proceed to step S4; otherwise, proceed to step S8. S4, select N unexecuted tasks in the queue based on the number of concurrent tasks, and determine whether a CRIU snapshot exists locally, if yes, load the incremental snapshot to start the task, if not, cold start for the first time and generate an incremental snapshot, and then load the incremental snapshot to start the task; Preferably, the S4 step comprises: Select an unexecuted task in the queue, and first check whether a CRIU snapshot exists locally; If no CRIU snapshot exists, it is the first time to start the task, cold start is performed, and an incremental snapshot is created, the incremental snapshot is loaded using the fast recovery interface to complete the fast start of the task; If a CRIU snapshot exists, it is not the first time to start the task, and the incremental snapshot is directly loaded using the fast recovery interface to complete the fast start of the task.
[0013] S5, determine whether the task label is a GPU-Able label, if yes, put the task into a GPU task pool for execution, if not, put the task into a CPU task pool for execution; Preferably, the S5 step comprises: After the task is started, the task is classified and determined through the task label interface GPU-Able label: For the task marked as GPU-Able, dynamically compile the GPU kernel and put it into the GPU task pool for execution; For the unmarked task, put it into the CPU task pool for execution.
[0014] Preferably, in the S5 step, the GPU task pool dynamically calls CUDA 12 Runtime or NVRTC to compile the kernel, and automatically allocates and utilizes GPU computing power; after the CPU and GPU tasks are completed, the results are uniformly recycled through ResultMerger to ensure that the task processing process is cooperative and efficient.
[0015] S6, during the execution, randomly inject faults through the ChaosAgent module; Preferably, the S6 step comprises: during the execution, randomly inject faults through the ChaosAgent module with a probability of 0.5%-2% for continuously verifying the robustness of the system; wherein the faults include SIGKILL, I / O delay, and memory overflow.
[0016] S7, poll the task running state, judge whether an exception is detected, if not, return to S2 step, if yes, automatically restart the task, if the restart is successful, return to S2 step, if the restart fails, start the CRIU hot migration self-healing mechanism, migrate the task to the standby node for continuous running, and record the failure event and the abnormal task, and then return to S2 step; wherein, when returning to S2 step, the task batch queue does not need to be performed again, and the task resource demand prediction, concurrent task quantity calculation and adjustment are directly performed; Preferably, the S7 step comprises: Poll the task running state by HealthMonitor every T milliseconds, if no abnormal task is monitored, return to S2 step; if an abnormal task is monitored, automatically restart the task, and the number of restart attempts is not more than M times; If the task is restarted successfully, return to S2 step; if M times of restarts all fail, start the CRIU hot migration self-healing mechanism, migrate the task to the standby node for continuous running, and record the failure event and the abnormal task for subsequent analysis and alarm notification, and then return to S2 step.
[0017] S8, the task execution is completed, and a comparison engine is started and a report is generated.
[0018] Preferably, the S8 step comprises: after the task execution is completed, a 1D / 2D comparison engine is started through a difference comparison interface, the task output result is automatically compared in detail, and a difference analysis report is generated, and the analysis report supports multiple formats.
[0019] In a second aspect, based on the above second-level cold start batch test execution method, another aspect of the present application also provides a second-level cold start batch test execution system based on resource prediction, comprising: An input module for inputting test data sets and software under test to the system; A resource prediction scheduling module in communication connection with the input module, for predicting the resource demand of each task by using a resource prediction model, linearly planning the number of concurrent tasks, and using PID filtering to adjust the number of concurrent tasks in batches; A cold start container management module in communication connection with the resource prediction scheduling module, for judging whether a CRIU snapshot exists locally, if yes, loading the incremental snapshot to start the task, if not, cold starting for the first time and generating an incremental snapshot, and then loading the incremental snapshot to start the task; A hybrid task pool module in communication connection with the cold start container management module, for judging whether the task label is a GPU-Able label, if yes, putting the task into the GPU task pool for execution, if not, putting the task into the CPU task pool for execution; The fault injection and self-recovery module is in communication connection with the mixed task pool module, and is used for randomly injecting faults and monitoring exceptions, automatically restarting tasks after monitoring exceptions, and starting a CRIU hot migration self-recovery mechanism to migrate tasks to a backup node for continuous operation when the task restart fails. The result normalization and difference comparison module is in communication connection with the mixed task pool module, and is used for normalizing and comparing differences of task data after execution is completed. The output module is in communication connection with the result normalization and difference comparison module, and is used for analyzing results of difference comparison, generating a difference analysis report and outputting.
[0020] The present application has the following advantages: 1. Self-designed resource prediction interface and dynamic scheduling control mechanism Based on the self-designed historical resource data acquisition interface, the resource prediction model is trained by inputting the LightGBM algorithm.
[0021] The self-designed linear programming calculation and PID filtering control interface accurately controls the number of concurrent tasks and ensures stable resource utilization.
[0022] 2. Self-designed interface and process design of incremental snapshot second-level recovery The self-designed first cold start and CRIU snapshot creation interface ensures the rapidity of subsequent task startup.
[0023] The self-designed rapid recovery interface realizes second-level recovery of task instances and greatly improves the task startup efficiency.
[0024] 3. Self-adaptive and control mechanism of CPU / GPU task heterogeneous resources The self-designed task classification tag interface (GPU-Able tag) realizes intelligent classification of CPU and GPU tasks.
[0025] The self-designed GPU task dynamic kernel compilation interface realizes efficient running of tasks in the GPU task pool.
[0026] 4. Self-designed fault injection and self-recovery mechanism The self-designed ChaosAgent fault injection module continuously verifies the robustness of task execution.
[0027] The self-designed HealthMonitor monitoring and CRIU hot migration self-recovery mechanism interface realizes automatic detection, recovery and alarm notification of task exceptions.
[0028] 5. Automatic result difference analysis and report generation mechanism The self-designed 1D / 2D comparison engine interface automatically compares and analyzes the task output results in detail.
[0029] Automatically generate multi-format difference reports to improve analysis efficiency and accuracy. BRIEF DESCRIPTION OF DRAWINGS
[0030] Figure 1 Flow chart of the method for executing the second-level cold start batch test based on resource prediction of the present application; Figure 2 Schematic diagram of the system for executing the second-level cold start batch test based on resource prediction of the present application. DETAILED DESCRIPTION
[0031] The concept, specific structure and resulting technical effects of the present application will be described clearly and completely below in combination with embodiments and drawings, so as to fully understand the purpose, features and effects of the present application.
[0032] Embodiment 1 A method for executing a second-level cold start batch test based on resource prediction, as shown in the following steps: Figure 1 1. First, collect the historical resource usage data (CPU peak value, memory peak value, GPU peak value, IO operation, duration) of the task to be executed, and input the machine learning model (LightGBM algorithm) through the self-designed interface for daily model training, and update the weight of the resource prediction model.
[0033] 2. When the scheduler receives a new task batch queue, the resource requirements (including CPU, memory, GPU resource requirements) of each task are predicted through the prediction model. After the prediction is completed, according to the resource requirement prediction results of each task, combined with the current platform hardware and software resource situation, the target concurrent task quantity N is determined by using the self-designed linear programming calculation interface. Then, through the designed PID filtering control interface, the concurrent task quantity is smoothly adjusted in batches, so that the resource load is kept within the set high and low water level interval.
[0034] 3. After entering the task execution link, the tasks in the task queue are selected in turn for starting. The system first checks whether there is a CRIU snapshot locally: * If it is the first time to start the task, cold start is performed, and an incremental snapshot is created for subsequent second-level start.
[0035] * If it is not the first time to start, the incremental snapshot is loaded secondly through the self-designed rapid recovery interface (runc restore) to complete the rapid start of the task.
[0036] 4. After the task is started, the task is classified and judged through the self-designed task tag interface (GPU-Able tag): * Tasks marked as GPU-Able are dynamically compiled with GPU kernels and executed in the self-designed GPU task pool.
[0037] * Unmarked tasks are executed in the self-designed CPU task pool.
[0038] 5. During execution, the system randomly injects faults such as SIGKILL, I / O delay, or memory overflow with a probability of 0.5%-2% through the self-designed ChaosAgent module to continuously verify the robustness of the system.
[0039] 6. The system simultaneously polls the task running state every 500 milliseconds through HealthMonitor. When an abnormal task is detected, the task is automatically restarted, and the number of restart attempts does not exceed three. If three automatic restarts fail, the system automatically starts the CRIU hot migration mechanism to migrate the task to a backup node for continuous execution, and records the failure event and abnormal task for subsequent analysis and alarm notification.
[0040] 7. After the task is completed, the 1D / 2D comparison engine is started through the self-designed difference comparison interface to automatically compare the task output results in detail and generate a difference analysis report in multiple formats (such as JSON / PDF).
[0041] The originality and innovation of the patent application are mainly concentrated in the task scheduling prediction, incremental snapshot second-level recovery, heterogeneous task resource self-adaptation, and fault injection-self-healing process control mechanism described in detail above. The interfaces and judgment processes involved in the flowchart are all self-designed innovative achievements of the invention.
[0042] Embodiment 2 A second-level cold start batch test execution system based on resource prediction, as shown in Figure 2 , comprising: an input module for inputting test data sets and software under test to the system; a resource prediction scheduling module in communication with the input module, configured to predict the resource requirements of each task using a resource prediction model, and to linearly plan and calculate the number of concurrent tasks, and to use PID filtering to adjust the number of concurrent tasks in batches; a cold start container management module in communication with the resource prediction scheduling module, configured to determine whether a CRIU snapshot exists locally, and if so, to load the incremental snapshot to start the task at the second level, and if not, to perform a first cold start and generate an incremental snapshot, and then load the incremental snapshot to start the task at the second level; a hybrid task pool module in communication with the cold start container management module, configured to determine whether the task label is a GPU-Able label, and if so, to execute the task in the GPU task pool, and if not, to execute the task in the CPU task pool. The fault injection and self-recovery module is in communication connection with the hybrid task pool module, and is used for randomly injecting faults and monitoring exceptions, automatically restarting tasks after monitoring exceptions, and starting a CRIU hot migration self-recovery mechanism to migrate tasks to a backup node for continuous operation when the task restart fails. The result normalization and difference comparison module is in communication connection with the hybrid task pool module, and is used for normalizing and comparing differences of task data after execution is completed. The output module is in communication connection with the result normalization and difference comparison module, and is used for analyzing results of difference comparison, generating a difference analysis report and outputting.
[0043] In the application, the technical problems to be solved and the technical means adopted are as follows: (1) Q1: Concurrent degree is difficult to dynamically match resources A machine learning model (gradient boosting decision tree, LightGBM algorithm is selected) is used to predict task resource demand, and a resource prediction model is established.
[0044] * Record key resource occupation indicators after each task execution: CPU peak (CPU_peak), memory peak (MEM_peak), IO operation (IO_ps), GPU peak (GPU_peak) and duration (Duration).
[0045] * Train the model offline every day and store it in the model library (Model Registry).
[0046] * After the scheduler receives the task queue, the task resource demand is predicted (cpu_i, mem_i, gpu_i) according to the prediction model, and then based on the real-time available resource margin, the number of concurrent tasks is calculated through a linear programming optimization algorithm to dynamically adjust the concurrency to prevent resource overload or idling.
[0047] (2) Q2: Long start-up time, affecting overall throughput Incremental snapshot technology is used to realize task second-level cold start.
[0048] * When starting the executable program to be tested for the first time, create a container image base layer that meets the OCI standard.
[0049] * After the first start is completed, use the CRIU tool to generate a process incremental memory snapshot (ΔS) containing only dirty page data and process register state.
[0050] * When starting the subsequent instance, load the snapshot ΔS through the restore --lazy-pages mode of the runc container runtime, and the start-up time is compressed to less than 1 second.
[0051] * Snapshot updates and distribution use OverlayFS and Copy-on-Write (COW) mechanisms, enabling rapid deployment without data copying.
[0052] (3) Q3: CPU and GPU resources cannot work together Build a unified CPU / GPU hybrid task scheduling mechanism.
[0053] * For specific tags in the task metadata (such as GPU-Able), route to the GPU task pool; otherwise, route to the CPU task pool.
[0054] * The GPU task pool dynamically calls CUDA 12 Runtime or NVRTC to compile kernels, enabling automatic allocation and utilization of GPU computing power.
[0055] * After CPU and GPU tasks are completed, the results are collected uniformly through ResultMerger to ensure efficient and coordinated task processing.
[0056] (4) Q4: Lack of robustness verification during execution A periodic fault injection and self-healing mechanism is introduced.
[0057] * ChaosAgent is used to randomly inject typical faults such as SIGKILL and network latency (tc delay) with a probability of 0.5%-2%.
[0058] The monitor checks the task status at 500-millisecond intervals. Once a container abnormality is detected (such as exit, memory overflow, or no response), the task is automatically restarted, with a maximum of 3 restarts.
[0059] * For tasks that fail to recover after more than 3 restarts, the CRIU tool will be used to perform hot container migration automatically, ensuring reliable task execution.
[0060] All abnormal events are logged to the EventStore for subsequent analysis and robustness assessment.
[0061] The innovativeness and scope of protection of this application are clearly focused on the interfaces and control mechanisms of the above-mentioned original design. The decision nodes and interface designs shown in the flowchart are all original achievements of this invention and constitute the core technical content protected by this application.
[0062] The inventive points of this invention are as follows: 1. Machine Learning-Driven Predictive Resource Scheduling Technical means: Collect CPU peak, memory peak, disk I / O peak, GPU peak, and execution duration, etc. "Resource signature" for each test task, and use gradient boosting decision tree (LightGBM) to train resource occupation prediction model offline; The scheduler calls this model when it goes online to predict the peak resource of the task to be scheduled and solve the linear programming to calculate the target concurrent instance number N(t) in real time. In order to prevent oscillation, PID-filtering method is used to increase and decrease the concurrency in batches. Technical advantages: The number of concurrent instances can dynamically converge with the system margin, and the average CPU utilization is stable at about 70%±5%, avoiding both idleness and overload.
[0063] 2. Second-level cold start of container incremental snapshot Technical means: First, make a read-only image layer of the program to be tested based on OCI, and then use CRIU to generate an incremental memory snapshot containing only dirty pages after the first run; When scheduling, directly execute runc restore --lazy-pages, relying on copy-on-write and on-demand paging to restore the snapshot to a new instance.
[0064] Technical advantages: The single-instance cold start time is shortened from the traditional 5-10 seconds to ≤1 second; When the concurrency reaches hundreds, the time-consuming of the entire startup phase can be shortened by about 8 times, greatly improving the overall throughput.
[0065] 3. CPU / GPU hybrid task pool scheduling Technical means: Add a "GPU-Able" tag to the task metadata. After the scheduler parses the tag, parallel matrix operations or simulation tasks are routed to the GPU pool, and the remaining tasks are still delivered to the CPU pool. GPU pool uses CUDA 12 runtime or NVRTC to dynamically compile kernels and uses GPUDirect to achieve zero-copy data path from storage to video memory.
[0066] Technical advantages: Make full use of idle GPU resources, get 10-25 times acceleration in floating-point intensive scenarios such as signal simulation, and reduce CPU load by about 40%.
[0067] 4. Fault injection and self-healing mechanism Technical means: ChaosAgent injects SIGKILL, I / O delay or memory fault into containers with a probability of 0.5%-2% during runtime. HealthMonitor polls container status every 500 milliseconds and automatically restarts once EXITED, OOM or unresponsive is detected; if it fails three times, it migrates and recovers instances on the same cluster node or other nodes with CRIU. All fault and recovery events are written to the event bus.
[0068] Technical advantages: The system can complete crash self-healing without manual intervention, the average repair time is shortened to about 3 seconds, and task zero loss is achieved in a 72-hour stress test.
[0069] In summary, the advantages of the present application are as follows: 1. Enhanced resource scheduling accuracy and real-time performance * The application realizes accurate prediction and real-time concurrent adjustment of task resource demand through self-designed resource prediction and scheduling interface, avoids resource waste or overload problem, and improves resource utilization efficiency and system response speed.
[0070] 2. Significant improvement in container startup efficiency * Through the self-designed second-level recovery interface, the application realizes the rapid startup of container instances, significantly shortens the overall execution period of batch tasks, and greatly reduces the time consumption in the task startup stage compared with the traditional startup method.
[0071] 3. Significant improvement in CPU / GPU resource utilization * Through the self-designed heterogeneous task classification and dynamic compilation interface, the application realizes the automatic adaptation and efficient utilization of CPU and GPU resources, fully releases the potential of GPU resources, and greatly improves the computing efficiency.
[0072] 4. Significant improvement in system robustness and stability * The self-designed fault injection and self-healing mechanism interface of the application ensures that the system can automatically identify and repair abnormal states, reduces the task failure rate, and significantly improves the robustness and reliability of the system.
[0073] 5. Improved accuracy of automatic result analysis * Through the self-designed automatic difference analysis and report generation interface, the application significantly improves the automation and accuracy of result analysis, avoids human errors, and improves the overall test execution and analysis efficiency.
[0074] The above describes the embodiments of the present application in detail, but the present application is not limited to the above-mentioned embodiments, and those skilled in the art can make various equivalent modifications or replacements without departing from the spirit of the present application, and these equivalent modifications or replacements are all included in the scope defined by the claims of the present application.
Claims
1. A second-level cold start batch test execution method based on resource prediction, characterized in that, Includes the following steps: S1. Collect data to train the resource prediction model and update the weights of the resource prediction model; S2. Receive the task batch queue, use the resource prediction model to predict the resource requirements of each task, calculate the target number of concurrent tasks using linear programming, and use PID filtering to adjust the number of concurrent tasks in batches. S3. Determine if there are any unexecuted tasks in the queue. If yes, proceed to step S4; otherwise, proceed to step S8. S4. Select N unexecuted tasks from the queue based on the number of concurrent tasks, and determine whether a CRIU snapshot exists locally. If it does, load the incremental snapshot in seconds to start the task. Otherwise, perform a cold start for the first time, generate an incremental snapshot, and then load the incremental snapshot in seconds to start the task. S5. Determine if the task label is GPU-Able. If it is, add the task to the GPU task pool for execution; otherwise, add the task to the CPU task pool for execution. S6. During execution, faults are randomly injected through the ChaosAgent module; S7. Poll the task running status to determine if any anomalies are detected. If not, return to step S2. If yes, automatically restart the task. If the restart is successful, return to step S2. If the restart fails, activate the CRIU hot migration self-healing mechanism to migrate the task to a backup node to continue running, and record the failure event and the abnormal task, then return to step S2. When returning to step S2, there is no need to queue the task batch again; directly perform task resource requirement prediction, concurrent task quantity calculation and adjustment. S8. Task completed, start the comparison engine and generate a report.
2. The second-level cold start batch test execution method based on resource prediction as described in claim 1, characterized in that, Step S1 includes: Collect historical resource usage data for tasks to be executed; wherein, the historical resource usage data includes CPU peak, memory peak, GPU peak, IO operations, and duration; Input the resource prediction model, and use historical resource usage data and the LightGBM algorithm to train the resource prediction model and update the weights of the resource prediction model.
3. The second-level cold start batch test execution method based on resource prediction as described in claim 1, characterized in that, Step S2 includes: When the scheduler receives a new task batch queue, it predicts the resource requirements of each task using a resource prediction model; wherein, the resource requirements include CPU, memory, and GPU resource requirements; Based on the resource requirement prediction results of each task, and combined with the current hardware and software resources of the platform, the target number of concurrent tasks N is determined using the linear programming calculation interface. After determining the target number of concurrent tasks, the number of concurrent tasks is smoothly adjusted in batches through the PID filter control interface to keep the resource load within the set high and low water level range.
4. The second-level cold start batch test execution method based on resource prediction as described in claim 1, characterized in that, Step S4 includes: Select an unexecuted task from the queue, and first check if a CRIU snapshot exists locally; If no CRIU snapshot exists, this is the first time the task is started. A cold start is performed, and an incremental snapshot is created. The incremental snapshot is loaded in seconds using the fast recovery interface to complete the task's fast start. If a CRIU snapshot exists, it indicates that this is not the first time the task has been started. In this case, the incremental snapshot is loaded directly through the fast recovery interface in seconds, thus completing the task's rapid startup.
5. The second-level cold start batch test execution method based on resource prediction as described in claim 1, characterized in that, The S5 steps include: After the task is started, the GPU-Able tag is used to classify and determine the task: For tasks marked as GPU-Able, dynamically compile the GPU kernel and execute it in the GPU task pool; Unmarked tasks are added to the CPU task pool for execution.
6. The second-level cold start batch test execution method based on resource prediction as described in claim 1, characterized in that, In step S5, the GPU task pool dynamically calls CUDA 12 Runtime or NVRTC to compile the kernel and automatically allocate and utilize GPU computing power; after the CPU and GPU tasks are completed, the results are collected in a unified manner through ResultMerger to ensure that the task processing process is coordinated and efficient.
7. The second-level cold start batch test execution method based on resource prediction as described in claim 1, characterized in that, Step S6 includes: during execution, the ChaosAgent module randomly injects faults with a probability of 0.5%-2% to continuously verify the robustness of the system; wherein, the faults include SIGKILL, I / O latency, and memory overflow.
8. The second-level cold start batch test execution method based on resource prediction as described in claim 1, characterized in that, Step S7 includes: The task running status is polled every T milliseconds using HealthMonitor. If no abnormal task is detected, the process returns to step S2. If an abnormal task is detected, the task is automatically restarted, with a maximum of M restart attempts. If the restart task is successful, return to step S2; if all M restarts fail, activate the CRIU hot migration self-healing mechanism to migrate the task to a standby node to continue running, and record failure events and abnormal tasks for subsequent analysis and alarm notification, then return to step S2.
9. The second-level cold start batch test execution method based on resource prediction as described in claim 1, characterized in that, The S8 steps include: after the task is completed, the 1D / 2D comparison engine is started through the difference comparison interface to perform a detailed automatic comparison of the task output results and generate a difference analysis report, which supports multiple formats.
10. A second-level cold start batch test execution system based on resource prediction, characterized in that, include: The input module is used to input the test dataset and the software under test into the system. The resource prediction and scheduling module is communicatively connected to the input module. It is used to predict the resource requirements of each task using a resource prediction model, calculate the target number of concurrent tasks using linear programming, and adjust the number of concurrent tasks in batches using PID filtering. The cold start container management module is connected to the resource prediction and scheduling module to determine whether a CRIU snapshot exists locally. If it does, the incremental snapshot is loaded and the startup task is started within seconds. Otherwise, the first cold start is performed and an incremental snapshot is generated, and then the incremental snapshot is loaded and the startup task is started within seconds. The hybrid task pool module is connected to the cold start container management module and is used to determine whether the task tag is a GPU-Able tag. If it is, the task is put into the GPU task pool for execution; otherwise, the task is put into the CPU task pool for execution. The fault injection and self-healing module is connected to the hybrid task pool module. It is used to randomly inject faults and monitor anomalies. After detecting an anomaly, it automatically restarts the task. If the restart fails, it starts the CRIU hot migration self-healing mechanism to migrate the task to the backup node to continue running. The result normalization and difference comparison module is connected in communication with the hybrid task pool module and is used to normalize and compare the differences of the task data after execution. The output module is communicatively connected to the result normalization and difference comparison module, and is used to analyze the difference comparison results, generate a difference analysis report, and output it.