A method, system and apparatus for detecting dynamic scheduling of software processes
By separating the detection task into a material acquisition process and a detection process, and by utilizing independent buffers and self-healing strategies, the problem of resource contention between image acquisition and defect detection in the same process is solved, achieving efficient detection task recovery and improved system stability.
Patent Information
- Application Number
- CN202511164405.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-20
- Publication Date
- 2025-11-21
- Estimated Expiration
- 2045-08-20
AI Technical Summary
In existing technologies, image acquisition and defect detection are performed in the same process, which leads to competition for CPU resources. Under high load scenarios, the system response is slow, tasks are delayed, it is difficult to take advantage of multi-core processors, and stability and maintainability are poor.
The detection task is separated into a material acquisition process and a detection process. Dynamic resource allocation is carried out through an independent cache and real-time resource monitoring. When the detection process is abnormal, the detection task is automatically restarted and restored. Combined with a self-healing strategy, the system stability is improved.
It improves the parallel processing capability and operating efficiency of the detection system, adapts to high-frequency and high-load detection needs, and ensures task continuity and system performance.
Smart Images

Figure CN120653407B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of data processing, in particular to a method, system and device for detecting dynamic scheduling of software processes. BACKGROUND
[0002] Automatic optical inspection systems are widely used in electronic manufacturing, industrial quality inspection and other fields. The core task of the system is to capture images through a camera and detect product defects using image processing algorithms.
[0003] In the prior art, image acquisition and defect detection are usually integrated in the same software process. When the detection task is triggered, the process controls the camera to capture images and directly executes the defect recognition algorithm on the image data.
[0004] Because the photographing and algorithm processing share the same process resources, especially in a multi-threaded or multi-task environment, they may compete for CPU and memory, causing processing bottlenecks. In particular, in a high-load scenario, CPU usage is prone to be too high, resulting in slow system response, task delay, and even freezing or crashing. Moreover, because all tasks are concentrated in a single process, this architecture cannot effectively utilize the advantages of multi-core processors, limiting the system's performance expansion space and resulting in poor system stability and maintainability. SUMMARY
[0005] To solve the above technical problems, the present application provides a method, system and device for detecting dynamic scheduling of software processes, which separates the processes of different functions of the detection software and improves the stability of the detection task through dynamic scheduling.
[0006] The technical solutions provided in the present application are described as follows:
[0007] The first aspect of the present application provides a method for detecting dynamic scheduling of software processes, comprising:
[0008] According to the detection requirements, a material acquisition process and a detection process are established, the number of detection processes is not unique, and the detection process is provided with an independent cache area;
[0009] The detection material is acquired through the material acquisition process, and the detection material is input into the detection process for detection according to a preset rule;
[0010] The detection process is monitored in real time by a monitoring module to obtain resource occupation data of the detection process;
[0011] The detection process is dynamically allocated resources according to the resource occupation data;
[0012] When the detection process is abnormal, the detection process is automatically restarted, and the working state of the material acquisition process is suspended;
[0013] When the detection process completes restart, the restarted detection process obtains intermediate state data of a detection task through the independent cache area, and continues to execute the detection task according to the intermediate state data.
[0014] Optionally, after the detection process is automatically restarted when the detection process is abnormal, and the working state of the material obtaining process is suspended, the method further comprises:
[0015] When the detection process enters a restart state, a self-recovery strategy is started;
[0016] If the detection process cannot be recovered by the self-recovery strategy, a detection task of the detection process is allocated to other detection processes according to the resource occupation data.
[0017] Optionally, the dynamic resource allocation to the detection process according to the resource occupation data comprises:
[0018] An algorithm for prediction is obtained;
[0019] The resource occupation state of the detection process is predicted according to the algorithm for prediction and the resource occupation data;
[0020] The detection process is dynamically allocated resources according to the resource occupation state.
[0021] Optionally, after the detection material is input into the detection process for detection according to a preset rule, the method further comprises:
[0022] Intermediate state data generated by the detection process in executing a detection task is stored in the independent cache area.
[0023] Optionally, after the detection process is dynamically allocated resources according to the resource occupation data, the method further comprises:
[0024] Resources allocated to the detection process are preheated through a memory preheating technology.
[0025] Optionally, after the detection process is automatically restarted when the detection process is abnormal, the method further comprises:
[0026] An error log is generated according to the abnormality of the detection process, and the error log records an abnormal type and a running state of the detection process when the detection process is abnormal.
[0027] Optionally, the method further comprises:
[0028] The self-recovery strategy of the detection process is tested by simulating the detection process into an abnormal state through program code, the abnormal state including a memory leakage state, thread blocking, file I / O failure, and model loading delay.
[0029] The second aspect of the present application provides a system for detecting dynamic scheduling of software processes, the system comprising:
[0030] A first obtaining unit is configured to establish a material obtaining process and a detection process according to detection requirements, the number of the detection processes is not unique, and the detection processes are provided with independent cache areas.
[0031] A second obtaining unit is configured to obtain detection materials through the material obtaining process and input the detection materials into the detection processes for detection according to preset rules.
[0032] A monitoring unit is configured to monitor the detection processes in real time through a monitoring module to obtain resource occupation data of the detection processes.
[0033] A first allocation unit is configured to perform dynamic resource allocation on the detection processes according to the resource occupation data.
[0034] An abnormality control unit is configured to automatically restart the detection processes when the detection processes are abnormal, and suspend a working state of the material obtaining process.
[0035] A restart unit is configured to control the restarted detection processes to obtain intermediate state data of a detection task through the independent cache areas when the detection processes are restarted, and continue to execute the detection task according to the intermediate state data.
[0036] Optionally, the system further comprises:
[0037] A self-recovery unit is configured to start a self-recovery strategy when the detection processes enter a restart state.
[0038] A second allocation unit is configured to allocate a detection task of the detection process to other detection processes according to the resource occupation data if the self-recovery strategy fails to recover the detection process.
[0039] Optionally, the first allocation unit is specifically configured to:
[0040] Obtain a prediction algorithm.
[0041] Predict a resource occupation state of the detection process according to the prediction algorithm and the resource occupation data.
[0042] Perform dynamic resource allocation on the detection process according to the resource occupation state.
[0043] Optionally, the system further comprises:
[0044] The storage unit is configured to store the intermediate state data generated by the detection process in performing the detection task into the independent cache area.
[0045] Optionally, the system further comprises:
[0046] The preheating unit is configured to preheat the resources allocated to the detection process by using a memory preheating technique.
[0047] Optionally, the system further comprises:
[0048] The generation unit is configured to generate an error log according to the exception of the detection process, the error log recording the type of the exception and the running state of the detection process when the exception occurs.
[0049] Optionally, the system further comprises:
[0050] The test unit is configured to test the self-recovery strategy of the detection process by simulating the detection process to enter an abnormal state through program code, the abnormal state including a memory leakage state, a thread blocking, a file I / O failure, and a model loading delay.
[0051] The third aspect of the present application provides a device for detecting dynamic scheduling of a software process, the device comprising:
[0052] a processor, a memory, an input / output unit, and a bus;
[0053] The processor is connected to the memory, the input / output unit, and the bus;
[0054] The memory stores a program, and the processor invokes the program to execute the method of the first aspect and any optional method of the first aspect.
[0055] The fourth aspect of the present application provides a computer readable storage medium, the computer readable storage medium storing a program, the program being executed on a computer to execute the method of the first aspect and any optional method of the first aspect.
[0056] As can be seen from the above technical solutions, the present application has the following advantages:
[0057] The present method separates the material acquisition process from the plurality of detection processes, and dynamically allocates resources such as CPU and memory through an independent cache area and real-time resource monitoring, thereby preventing resource waste or overload. The detection process is automatically restarted when an exception occurs, and the material collection is suspended. After the restart, the detection task can be resumed based on the cache, thereby ensuring the continuity of the task. In combination with the dynamic scheduling and the exception self-recovery mechanism, the parallel processing capability and the running efficiency of the detection system are improved, and the high-frequency and high-load detection requirements are met. Attached Figure Description
[0058] To more clearly illustrate the technical solutions in this application, the accompanying drawings used in the description of the embodiments 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.
[0059] Figure 1 This is a schematic flowchart of an embodiment of the method for detecting dynamic scheduling of software processes in this application;
[0060] Figure 2 This is a flowchart illustrating another embodiment of the method for detecting dynamic scheduling of software processes in this application;
[0061] Figure 3 This is a schematic diagram of an embodiment of the system for detecting dynamic scheduling of software processes in this application;
[0062] Figure 4 This is a schematic diagram of another embodiment of the system for detecting dynamic scheduling of software processes in this application;
[0063] Figure 5 This is a schematic diagram of an embodiment of the device for detecting dynamic scheduling of software processes in this application. Detailed Implementation
[0064] It should be noted that the dynamic scheduling method for the detection software process provided in this application can be applied to terminals, systems, and servers. For example, a terminal can be a smartphone, computer, tablet, smart TV, smartwatch, portable computer, or a desktop computer, etc. For ease of explanation, this application uses a detection terminal as the execution subject for illustration.
[0065] To adapt to diversified execution terminals, a hardware abstraction layer (HAL) design is introduced in the embodiments of the present application, and different platform system resource management mechanisms are adapted through modular interfaces. For example, on an embedded Linux platform, a scheduling strategy is limited in resources and priority through a cgroups (a resource control mechanism provided by a Linux kernel) and a sched_setscheduler() (a system call of Linux, used for setting a scheduling strategy and priority of a process) system call; on an Android platform, a process life cycle management is detected through a task scheduling framework component, such as a JobScheduler and a WorkManager. On hardware supporting GPU inference acceleration, a detection process calls a resource detection interface before starting a task, and preferentially uses a GPU for image preprocessing and model inference, so as to improve overall detection efficiency.
[0066] The technical solutions in the present application will be described clearly and completely in the embodiments of the present application in combination with the accompanying drawings. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative labor fall within the protection scope of the present application.
[0067] Please refer to Figure 1 The present application first provides an embodiment of a method for detecting dynamic scheduling of software processes, which comprises the following steps:
[0068] S101, a material acquisition process and a detection process are established according to detection requirements, the number of the detection processes is not unique, and the detection processes are provided with independent cache areas;
[0069] Taking defect detection of a shooting content through a picture as an example, a detection terminal needs to control a camera to shoot defect detection materials and to detect defects of a shot content of the shot materials.
[0070] Specifically, when a detection task is triggered, camera shooting and detection algorithm execution are started in independent processes. The material acquisition process is responsible for controlling the camera to shoot to acquire image materials, and ensures real-time acquisition of image material data; the detection process is responsible for detection material processing and analysis, and acquires image data from the shooting process and performs detection.
[0071] The detection terminal creates a material acquisition process, the material acquisition process is used to control a camera or a material acquisition tool, the material acquisition tool can be an external module or a wireless connection module, or can be directly built-in in an actual device of the detection terminal, and the material acquisition process is allocated with independent memory space and thread resources when the material acquisition process is created.
[0072] The detection terminal creates a detection process, the number of detection processes is preset according to actual needs, the detection process is used for executing a detection algorithm, different detection algorithms correspond to different detection tasks, and the detection process is used for executing a corresponding detection algorithm according to a detection task. In actual cases, different detection processes can execute the same or different detection tasks, which are specifically set according to actual detection needs. After the detection terminal completes the establishment of the detection process, the detection terminal allocates independent memory space and thread resources for each detection process. The detection process sets an independent cache area, and the independent cache area is used for caching intermediate resources generated during the running of the detection process.
[0073] Each detection process is allocated an independent cache area, the independent cache area is used for storing temporary data and state information of a task, and all independent cache areas adopt an efficient memory management algorithm to ensure fast reading, writing and storage of data.
[0074] S102, obtaining detection materials through the material acquisition process, and inputting the detection materials into the detection process according to a preset rule for detection;
[0075] The actual working process of the detection terminal is to obtain detection materials through the material acquisition process. After the detection terminal obtains the detection materials through the material acquisition process, the detection terminal inputs the detection materials into the detection process for detection.
[0076] It should be noted that the detection terminal is a carrier capable of simultaneously running the material acquisition process and the detection process. The detection terminal can obtain detection materials from the material acquisition process through a logical algorithm of information interaction, and input the detection materials into the detection process to complete the overall process of the detection task.
[0077] Specifically, the detection process is used for loading a detection algorithm, each detection process obtains material data from the material acquisition process for processing and analysis, and identifies different defects in the material data.
[0078] In the case that the detection terminal simultaneously runs multiple detection processes, the detection terminal needs to determine the input order of the detection materials input into different detection processes and the detection processes that need to be input through all detection algorithms currently actually executed by the detection process, that is, in actual cases, the output data of one detection process is the input data of another detection process. The detection process will process the detection materials during the detection of the detection materials, for example, the detection materials provided in the present application will perform noise reduction or gray value adjustment on image data during the material detection process, and will perform corresponding processing on the features of the defects to be detected.
[0079] It should be noted that the detection terminal supports a hot update mechanism for the detection algorithm to improve the dynamic adaptation capability of the system to the detection logic during operation. The hot update refers to replacing and upgrading the algorithm model or parameter configuration called by the detection process without restarting the detection process or the terminal, that is, the hot update mechanism refers to a mechanism for updating the detection algorithm model without restarting the detection process.
[0080] Specifically, when loading the detection algorithm, the detection process loads the algorithm by using a modular plug-in architecture (such as using a dynamic link library DLL or a shared object SO). The algorithm logic is decoupled from the process main body running environment, and the system manages the version of the algorithm module, dynamically mounts and unmounts the algorithm module through a hot update controller.
[0081] After the detection terminal receives an algorithm upgrade instruction, the hot update controller marks the currently used detection algorithm as a “waiting for unmounting” state, and automatically releases the resource occupied by the algorithm module after the detection process finishes processing the current task. Then, the new algorithm module is mounted to the corresponding position of the detection process, and the algorithm replacement is completed through an interface registration mechanism. The whole process is completed in milliseconds and does not affect subsequent task scheduling or intermediate cache state.
[0082] To ensure the correctness and compatibility of the algorithm replacement, the detection terminal performs integrity check and version compatibility verification before updating, and can optionally configure a “gray update” strategy, that is, only replacing the algorithm for part of the detection processes, and gradually expanding to all processes after stable operation.
[0083] The algorithm hot update mechanism described in this embodiment is not only suitable for algorithm version iteration, but also can quickly replace the algorithm when the detection task is switched (such as switching from surface defect detection to structure recognition detection), effectively improving the versatility and adaptability of the detection system.
[0084] S103, real-time monitoring of the detection process is performed through a monitoring module to obtain resource occupation data of the detection process;
[0085] In actual situations, there is more than one detection process. To ensure that the detection process is more stable during operation, the detection terminal enables a monitoring module to monitor the running state of the detection process when the detection process is running.
[0086] The resource occupation data monitored by the monitoring module includes but is not limited to terminal computing power resource occupation of the detection process, actual load generation of the detection process, and the like. After the monitoring module obtains the resource occupation data of the detection process, a prediction algorithm is used to analyze the current occupation trend of the detection process to predict the resource occupation state of the detection process in the future, so that the detection terminal can more accurately allocate the CPU resource occupation state of the detection terminal.
[0087] Specifically, after the detection task is started, the monitoring module starts to collect resource data such as CPU usage and memory occupation of each process at a preset frequency, and records the data into a log file.
[0088] S104, dynamically allocating resources to the detection process according to the resource occupation data;
[0089] After the detection terminal obtains the resource occupation data of the detection process, it will allocate resources to the detection process according to the current state of the resource occupation data through the feedback result of the prediction model, so that the detection process will not be unable to respond in time due to insufficient CPU allocation of computing resources during running.
[0090] According to the prediction result and real-time monitoring data, the detection terminal dynamically adjusts the resource allocation of each process. For example, according to historical running data, the detection terminal predicts that the detection process may have a memory bottleneck in the next few minutes, and the detection terminal will pre-allocate additional memory from the resource pool.
[0091] It should be noted that the independent cache area corresponding to the detection process is implemented through a shared memory mechanism or a ring buffer queue. The cache structure is divided into a metadata area and a content data area, wherein the metadata area records the ID of the current detection task, the processing progress (such as the number of processed pictures), the detection algorithm version information, etc.; the content data area is used to store the intermediate results of image processing generated during the detection process, such as the tensor matrix after feature extraction, the mask image, etc. The independent cache area adopts a lightweight concurrent access control strategy, such as atomic lock or read-write lock, to ensure the consistency and safety of multi-threaded access to data.
[0092] In order to realize the dynamic allocation of detection process resources, the detection terminal scores all running detection processes based on a resource occupation priority scoring model. The scoring model considers multiple indicators such as detection task urgency (such as real-time detection demand priority), historical resource utilization rate, current occupation rate trend, and predicted volatility, and dynamically allocates resources according to weighted scoring and dynamic sorting. When resources are insufficient, some low-priority detection processes are frozen or their memory occupation space is compressed to free up available resources. In addition, in combination with the NUMA (Non-Uniform Memory Access) architecture optimization strategy, the resource allocation can be bound to the CPU node where the current thread of the detection process is located as much as possible, reducing the cross-node access overhead.
[0093] S105, when the detection process is abnormal, automatically restarting the detection process and suspending the working state of the material acquisition process;
[0094] When the detection process inevitably enters an abnormal state, the detection terminal will release the resources occupied by the current detection process by restarting the detection process and reallocating resources to the detection process. When the detection process is restarted due to an abnormality, the working state of the detection process will be suspended, causing the processing of the detection task to stop. To prevent loss of materials, when the detection process enters a restart state due to an abnormality, the detection terminal will notify the control material acquisition process to acquire detection materials to ensure the integrity of the actual detection process.
[0095] Specifically, detection process abnormalities usually trigger automatic restarts, but may also be restarted due to external control instructions.
[0096] S106, when the detection process completes the restart, the restarted detection process controls the detection process to acquire the intermediate state data of the detection task through the independent cache area, and continues to execute the detection task according to the intermediate state data.
[0097] When generating a detection process, the detection terminal will allocate a different independent cache area to each detection process. The independent cache area is used to store the intermediate nodes of the unfinished detection task, so that after the detection process is restarted due to an abnormality, the restarted detection process can directly acquire the intermediate data through the independent cache area. The detection process determines the detection task node corresponding to the intermediate data from the task node and continues to execute the detection task.
[0098] When the detection process is restarted, the detection terminal will reallocate the CPU computing power resources required to execute the detection task to the detection process. If the detection process completes the restart, it means that the remaining computing power of the current detection terminal meets the requirements of the detection process to continue executing the detection task. Otherwise, the detection terminal will restart the cycle of entering the restart state again until the detection process completes the restart.
[0099] During the execution of the detection task, the task intermediate results and state information stored in the independent cache area include, but are not limited to, the number of processed images, the type and position of recognized defects, algorithm execution progress, and other key data.
[0100] The embodiment separates the material acquisition process from multiple detection processes and dynamically allocates CPU, memory, and other resources through independent cache areas and real-time resource monitoring to prevent resource waste or overload. The detection process automatically restarts when it is abnormal, suspends material collection, and resumes the detection task based on the cache after restarting to ensure task continuity. Combined with dynamic scheduling and abnormal self-healing mechanisms, the parallel processing capability and running efficiency of the detection terminal are improved to adapt to high-frequency and high-load detection requirements.
[0101] Please refer to Figure 2 Another embodiment of the detection software process dynamic scheduling method provided by the embodiment of the application is provided, which comprises:
[0102] S201, establish a material obtaining process and a detection process according to detection requirements, the number of detection processes is not unique, and the detection process sets an independent cache area;
[0103] The step S201 in the embodiment is similar to the step S101 in the foregoing embodiment, and details are not described herein again.
[0104] S202, simulate the detection process to enter an abnormal state through program code, test the self-recovery strategy of the detection process, and the abnormal state includes a memory leakage state, thread blocking, file I / O failure, and model loading delay;
[0105] This step is a test of the self-recovery strategy of the detection process, that is, the detection process is forced to enter an abnormal state, so that the detection terminal tests the self-recovery strategy of the detection process, to determine that the detection process can correctly pass through the abnormal state to enter the self-recovery strategy and actively repair the state of the detection process exception before the detection task is executed.
[0106] Specifically, the self-recovery strategy is mainly the self-learning prediction and correction ability of the detection terminal when executing the detection task, and the detection process of the self-recovery strategy is to simulate the detection process to enter the following abnormal states through program code, such as a memory leakage state, thread blocking, file I / O failure, and model loading delay. After the detection task is started and runs for 10 minutes, an abnormal code segment is artificially triggered, so that the detection process enters the corresponding abnormal state according to the abnormal code content.
[0107] After the monitoring module detects the exception of the detection process, a memory processing mechanism is triggered immediately. For example, when memory leakage occurs, the detection terminal attempts to release the excess memory of the detection process, and records detailed error logs, and when the memory occupation of the detection process exceeds the preset confidence interval boundary, the detection terminal triggers immediate resource scheduling intervention to ensure that the detection process can continue to run stably.
[0108] S203, obtain detection materials through the material obtaining process, and input the detection materials into the detection process according to a preset rule for detection;
[0109] The step S203 in the embodiment is similar to the step S102 in the foregoing embodiment, and details are not described herein again.
[0110] S204, store intermediate state data generated by the detection process in executing a detection task to the independent cache area;
[0111] The intermediate state data is non-result data generated during the detection process performs the detection task, and the intermediate state data is periodically written to the data in the independent cache area through the state snapshot mechanism. Specifically, if a detection process is restarted abnormally, the detection terminal will control the detection process to recover the task state of the detection task from the independent cache area and continue to perform the unfinished task. In addition to actively restarting due to an exception, the detection process may also be restarted unexpectedly due to a fault or human intervention. The detection process is restarted during the execution of the detection task, and the corresponding independent cache area will cache related data of the detection task. The restarted detection process will switch to a task recovery mode to recover the execution state of the detection task through the data state of the independent cache area and / or the detection task execution state of the detection terminal, so that the detection process recovers the task execution environment according to the cached data, reloads the algorithm model and parameters, and continues to perform the unfinished detection task.
[0112] S205, real-time monitoring of the detection process is obtained by monitoring the resource occupation data of the detection process;
[0113] The step S205 in the embodiment is similar to the step S103 in the foregoing embodiment, and details are not repeated here.
[0114] S206, obtaining a prediction algorithm;
[0115] To improve the accuracy of the prediction model, the detection terminal automatically counts and saves the resource usage data of each run during the execution of the detection task by the detection terminal. In this embodiment, the frequency of data collection is once per second, which ensures that the changes in resource usage can be captured in time. The key indicators collected include CPU usage, memory occupation, etc., and resource usage data reports are generated periodically (e.g., every hour), and the report content covers the resource usage trend, peak and valley, average usage rate, etc. of each process in different time periods. The report is displayed in the form of tables, column charts, line charts, etc. to intuitively display the data, which is convenient for users to view.
[0116] In this embodiment, the prediction algorithm is selected from time series analysis algorithm and long short-term memory network (LSTM) or Transformer model.
[0117] Specifically, the time series analysis algorithm (such as ARIMA, exponential smoothing method) is used to fit and predict the resource usage data. The detection terminal analyzes the historical data to identify the periodic and trend changes in resource usage, and generates a resource demand prediction curve for a future period of time.
[0118] Long Short-Term Memory (LSTM) or Transformer models are used to predict future resource demand. These models can capture long-term dependencies and short-term fluctuations in resource usage, providing more accurate prediction results. The detection terminal generates a confidence interval for each prediction result using a Long Short-Term Memory (LSTM) or Transformer model, which dynamically adjusts the interval range based on historical prediction errors and data volatility.
[0119] The upper and lower limits of the confidence interval are dynamically adjusted based on the volatility of historical data and prediction errors to ensure the reliability of the prediction results. If the actual resource consumption exceeds the upper limit of the confidence interval, indicating that resource usage is abnormally high, the detection terminal will trigger an immediate resource scheduling intervention mechanism to allocate more resources to high-load processes. If the actual resource consumption is lower than the lower limit of the confidence interval, indicating that resource usage is lower, the detection terminal will attempt to reallocate some resources to other processes to improve resource utilization.
[0120] In this embodiment, the detection terminal improves resource scheduling accuracy by fusing multiple prediction models during task execution. Specifically, the ARIMA model is used at the base layer to capture periodic changes, the LSTM network is used at the middle layer to capture long-term trends and sudden fluctuations, and the Transformer model with attention mechanism is used at the high layer to judge short-term load surge risks. The prediction results are weighted and averaged by multiple models and dynamically corrected by confidence intervals, and finally used by the scheduling module as the basis for resource allocation. Prediction errors are fed back to the model training system through each detection cycle to form a closed-loop optimization.
[0121] S207, predicting the resource occupation state of the detection process according to the prediction algorithm combined with the resource occupation data;
[0122] The resource occupation state is divided by a preset proportion of the confidence interval, and the resource occupation state of the current detection process is directly determined by the confidence interval. At the same time, the resource occupation state can reflect the demand of the current detection process for CPU computing power resources, so that the detection terminal can make feedback to the corresponding detection process according to the resource occupation state.
[0123] S208, dynamically allocating resources to the detection process according to the resource occupation state;
[0124] The detection terminal dynamically adjusts resource allocation of each process according to the prediction result and real-time monitoring data. When it is predicted that a resource bottleneck may occur in a process in the future, the detection terminal will allocate additional resources to the process in advance from the resource pool, and accelerate the first use of the newly allocated memory by the process through the memory warm-up technology, thereby reducing the delay. The detection terminal dynamically adjusts the resource allocation of each process according to the actual resource usage and the prediction result, to ensure the overall performance and stability of the detection terminal when the detection task is executed.
[0125] S209, preheating the resources allocated to the detection process through the memory preheating technology;
[0126] Memory preheating refers to loading data, models or resources required for using the allocated resources into memory in advance before the detection process uses the allocated resources, so as to reduce the waiting time in subsequent calls and improve the response speed and execution efficiency of the program. That is, by preloading critical resources, the purpose of reducing task delay, avoiding cold start lag, and improving continuity and response speed is achieved.
[0127] Specifically, the memory preheating technology is implemented in the following way: the detection terminal preloads the weight parameters required by the detection model, the shared library file called by the algorithm, and the basic image processing module (such as the filter function of the OpenCV library) into the RAM; and actively performs an empty inference task to activate the GPU cache. For a typical neural network model, an inference engine such as TensorRT is called in the detection terminal startup stage to generate an inference cache (such as a CUDA Graph or engine file), so as to reduce the first detection delay. This technology is particularly suitable for embedded detection terminals with limited hardware resources, and significantly improves the model loading and task response speed.
[0128] S210, when the detection process is abnormal, automatically restarting the detection process and suspending the working state of the material acquisition process;
[0129] Step S210 in the embodiment is similar to step S105 in the foregoing embodiment, and will not be described here.
[0130] S211, when the detection process enters the restart state, starting the self-healing strategy;
[0131] The self-healing strategy is generally triggered automatically by the detection terminal when the detection process is abnormal. In addition to process restart, the detection process exception triggered by the monitoring module when the current defect processed by the detection process exceeds the threshold, after the detection process triggers an exception, the detection terminal will control the detection process to restart and try to repair the process by reloading the algorithm library of the detection process, cleaning cache data and other operations.
[0132] It should be noted that the cause of the detection process restart includes: external operation failure and detection terminal active control detection process restart when detecting process exception. Therefore, the detection process restart will inevitably activate the self-healing strategy, so that the detection process obtains the execution progress of the detection task through the independent cache area.
[0133] The self-healing strategy process includes three-stage processing: diagnosis, repair attempt, and alternative execution. Among them, the diagnosis stage is triggered by the monitoring module through three mechanisms of stack backtracking, exception type identification (such as NullPointerException, OOM), and system resource state determination; the repair attempt stage includes releasing resources, resetting the detection module state, reloading the model, and other operations; if the repair fails, the alternative execution stage is entered, that is, the interrupted detection task in the abnormal detection process is redistributed to other detection processes with sufficient resources, and the task breakpoint information is read through the independent cache area and continues to execute, thereby realizing uninterrupted task.
[0134] In some cases, such as when the detection terminal also integrates a fault prediction module, the fault prediction module is used to predict the potential abnormal risk of the detection process in advance. The fault prediction module identifies the high-risk signs that may cause process interruption by modeling and analyzing historical running data (such as resource occupation rate change, error code appearance frequency, execution time fluctuation). For example, when the memory usage rate of a certain detection process continuously and rapidly increases within a unit time, and is accompanied by a significant increase in processing delay, the prediction module will mark it as a potential fault node.
[0135] When it is predicted that a certain detection process will be abnormal, the detection terminal will trigger the task pre-transfer strategy in advance. The strategy includes the following steps: first, freeze the task allocation of the current detection process, and pause the new task distribution; second, backup the intermediate state data of the current processing task to the redundant cache area; third, preferentially select other detection processes in idle state or with low resource occupation as the transfer target; fourth, migrate the backup task state data to the independent cache area of the target detection process, and update the scheduling table.
[0136] In this way, before the fault actually occurs, the detection terminal can switch the task to a healthy detection process in advance, avoid task interruption or repeated execution, and improve the stability and task continuity of the overall system. This strategy not only improves the initiative of the detection process self-healing mechanism, but also significantly reduces the system performance fluctuations caused by process abnormalities in a high-frequency detection environment through fault warning and task dynamic migration.
[0137] S212、If the self-healing strategy fails to recover the detection process, the detection task of the detection process is allocated to other detection processes according to the resource occupation data;
[0138] When the detection process restarts and still fails to resume the execution of the detection task, the detection terminal re-allocates resources according to a preset resource adjustment strategy, that is, the detection terminal temporarily allocates part of the resources originally allocated to the current detection process to other normally running detection processes, so as to ensure that the progress of the overall detection task is not affected.
[0139] S213, generating an error log according to the detection process exception, the error log recording the exception type and the running state when the detection process is abnormal;
[0140] After determining that the detection process cannot continue to execute the detection task, the detection terminal generates a detailed error log according to the detection process exception. The specific error log includes: the specific time of the error (such as 2025-06-17 15:30:22), the exception type (such as "defect exceeds the preset threshold"), the occurrence position (such as "image analysis module of the detection process") and the state of the detection process at that time (such as memory occupancy rate 85%, CPU usage rate 90%). The log file of the error log is stored in the log directory of the detection terminal, and the error log is named by combining the preset error log file name with the time stamp, so as to analyze and troubleshoot the abnormal reason in the future.
[0141] In this embodiment, the error log structure adopts JSON format unified coding, and contains the following fields: "time_stamp" (time stamp), "process_id" (process number), "exception_type" (exception type), "cpu_usage" (CPU occupancy), "mem_usage" (memory occupancy), "stack_trace" (error stack), "task_progress" (detection task progress), "last_cache_state" (cache state). The detection terminal triggers a multi-layer alarm mechanism while recording the log, and alarms through different channels (local pop-up window, sound prompt, administrator email or platform SMS) according to the exception level. The serious level definition includes "more than three times of continuous restart failure", "resource leakage leading to system crash", "detection delay exceeding the standard" and the like, so as to ensure the stability of the detection task and the response efficiency of operation and maintenance.
[0142] S214, when the detection process completes the restart, controlling the detection process after the restart to obtain the intermediate state data of the detection task through the independent cache area, and continuing to execute the detection task according to the intermediate state data.
[0143] The step S214 in this embodiment is similar to the step S106 in the foregoing embodiment, and will not be described here.
[0144] To further improve the resource coordination efficiency and task processing stability of the detection system, in some embodiments, a cooperation mechanism is supported between detection processes to realize information sharing and centralized scheduling of computing resources between tasks. Specifically, the detection terminal sets a main detection process for uniformly collecting the running state information of each detection sub-process, including resource occupation, intermediate state data, task execution progress, etc. Based on the collected information, the main detection process globally schedules and manages the task scheduling order, resource allocation priority, and intermediate data processing order of all detection processes.
[0145] In the case where the detection task is complex or the task chain has a front-back dependency, the detection terminal supports intermediate result sharing between detection processes, i.e., after a certain detection process completes a specific image preprocessing operation, the processing result is stored in a shared buffer area for direct calling by downstream detection processes (such as defect classification processes), avoiding repeated calculation and reducing overall resource consumption. The shared buffer area is internally provided with an access control mechanism and a synchronization flag to ensure data consistency and task scheduling synchronization during concurrent reading and writing.
[0146] In addition, to improve the efficiency of task coordination processing, the detection terminal implements a task slicing and phased parallel mechanism between detection processes. When a certain detection task can be divided into multiple stages (such as image cropping, feature extraction, and defect judgment), the detection terminal assigns different stages to different detection processes for parallel processing, and passes context data through a buffer area at the task switching node, thereby improving processing throughput and system concurrency performance.
[0147] In different execution subjects, the detection system can be deployed in multiple physical terminals in actual situations to build a detection platform that supports distributed scheduling and coordination. The platform includes multiple detection terminals with independent detection capabilities, each detection terminal internally running a material acquisition process and multiple detection processes, and each terminal exchanges data and allocates tasks through a local area network or a wide area network.
[0148] Specifically, the system introduces a global task scheduling unit (GTC), which can be deployed on any detection terminal or independent server, responsible for coordinating task allocation, resource monitoring, and failover of each terminal. When the resource occupation of a certain detection terminal exceeds a threshold, or the number of consecutive failures of a detection process exceeds a certain number, the GTC will automatically migrate the pending tasks to other idle or low-load terminals for execution. The migration process is implemented through a unified task state serialization format and a buffer synchronization mechanism to ensure seamless connection of detection progress and intermediate state.
[0149] To ensure the concurrent consistency among multiple terminals, the system adopts a distributed consistency protocol (such as the RAFT algorithm) to maintain a global task scheduling table and a cache index. Each terminal regularly reports the local state to the GTC, including CPU / memory occupancy, detection progress, error logs, and other indicators, and the GTC makes scheduling decisions accordingly to achieve dynamic resource integration and task redundancy backup mechanisms at the system level.
[0150] By introducing a distributed detection collaboration mechanism, the present application can adapt to high-load, heterogeneous device deployment detection scenarios, such as large-scale industrial detection pipelines and city-level image processing platforms, while ensuring detection continuity and response speed, significantly improving system fault tolerance and processing scale.
[0151] In addition, the embodiment also provides a necessary information visualization scheme for interface design, that is, a user-friendly visualization interface is provided.
[0152] Specifically, the left side of the interface displays a detection progress bar, which reflects the completion of the three detection processes in real time; the right side displays the detection results, including the number of images detected, the types of defects identified, and statistical charts. The bottom of the interface is provided with a system status bar of the detection terminal, which updates the hardware resource usage in real time, such as the current CPU usage of 65% and the memory occupancy of 4.2GB / 16GB. During the detection process, the user finds that the defect detection accuracy is insufficient, adjusts the detection accuracy slider to a higher level through the "Detection Parameters" tab in the interface. After receiving the user input, the detection terminal dynamically adjusts the detection strategy of each detection process. The detection process reloads the model according to the new accuracy parameter and applies it in subsequent detection tasks (which triggers the detection process to restart). After the user adjusts the accuracy parameter of the detection process, the detection terminal will feed back the detection results in real time on the interface, and the user can intuitively compare the differences before and after the adjustment. When the detection terminal detects a major defect (such as a defect area exceeding a preset alarm threshold) or a process itself appears abnormal (such as a process including the material acquisition process fails to restart for three consecutive times), the detection terminal immediately triggers the alarm mechanism. The alarm notifies the user through various ways such as sound prompt (such as continuous buzzing sound), pop-up warning (a red warning box pops up, displaying "Major defect detected, please handle it in time"), and email notification (an alarm email is sent to the preset administrator mailbox with the subject "Defect detection system alarm notification"). After receiving the alarm, the user can view the specific information through the "Alarm Details" button in the interface and take appropriate measures.
[0153] The above describes in detail the method of dynamic scheduling of detection software processes in the embodiments of the present application. The system and device for dynamic scheduling of detection software processes will be described in detail below.
[0154] Please refer to Figure 3An embodiment of the system for detecting dynamic scheduling of software processes is provided, and the embodiment comprises the following steps:
[0155] The first obtaining unit 301 is configured to establish a material obtaining process and a detection process according to detection requirements, the number of the detection processes is not unique, and the detection processes are provided with independent cache areas.
[0156] The second obtaining unit 302 is configured to obtain detection materials through the material obtaining process and input the detection materials into the detection processes for detection according to preset rules.
[0157] The monitoring unit 303 is configured to monitor the detection processes in real time through a monitoring module to obtain resource occupation data of the detection processes.
[0158] The allocation unit 304 is configured to perform dynamic resource allocation on the detection processes according to the resource occupation data.
[0159] The abnormality control unit 305 is configured to automatically restart the detection processes when the detection processes are abnormal, and suspend a working state of the material obtaining process.
[0160] The restart unit 306 is configured to control the restarted detection processes to obtain intermediate state data of a detection task through the independent cache areas when the detection processes are restarted, and continue to execute the detection task according to the intermediate state data.
[0161] In the embodiment, the functions of the units correspond to the steps in the foregoing Figure 1 embodiment, and details are not described herein.
[0162] Please refer to Figure 4 An embodiment of the system for detecting dynamic scheduling of software processes is provided, and the embodiment comprises the following steps:
[0163] The first obtaining unit 401 is configured to establish a material obtaining process and a detection process according to detection requirements, the number of the detection processes is not unique, and the detection processes are provided with independent cache areas.
[0164] The test unit 402 is configured to simulate the detection processes to enter an abnormal state through program codes, test a self-recovery strategy of the detection processes, and the abnormal state includes a memory leakage state, a thread blocking, a file I / O failure, and a model loading delay.
[0165] The second obtaining unit 403 is configured to obtain detection materials through the material obtaining process and input the detection materials into the detection processes for detection according to preset rules.
[0166] The storage unit 404 is configured to store the intermediate state data generated by the detection process in performing a detection task to the independent cache area.
[0167] The monitoring unit 405 is configured to monitor the detection process in real time through a monitoring module to obtain resource occupation data of the detection process.
[0168] The first allocation unit 406 is configured to perform dynamic resource allocation for the detection process according to the resource occupation data.
[0169] The preheating unit 407 is configured to preheat the resources allocated to the detection process through a memory preheating technique.
[0170] The abnormality control unit 408 is configured to automatically restart the detection process when the detection process is abnormal, and suspend the working state of the material acquisition process.
[0171] The self-recovery unit 409 is configured to start a self-recovery strategy when the detection process enters a restart state.
[0172] The second allocation unit 410 is configured to allocate the detection task of the detection process to other detection processes according to the resource occupation data if the self-recovery strategy fails to recover the detection process.
[0173] The generation unit 411 is configured to generate an error log according to the abnormality of the detection process, the error log recording the abnormal type and the running state of the detection process when the detection process is abnormal.
[0174] The restart unit 412 is configured to control the detection process after restart to acquire the intermediate state data of the detection task through the independent cache area, and continue to perform the detection task according to the intermediate state data when the detection process completes the restart.
[0175] In the embodiment, the first allocation unit 406 is specifically configured to:
[0176] Obtain a prediction algorithm;
[0177] Predict the resource occupation state of the detection process according to the prediction algorithm combined with the resource occupation data;
[0178] Perform dynamic resource allocation for the detection process according to the resource occupation state.
[0179] In the embodiment, the functions of each unit correspond to the steps in the foregoing Figure 2 embodiments, which will not be described here.
[0180] Please refer to Figure 5 , an embodiment of the detection software process dynamic scheduling device provided in the present application comprises:
[0181] The processor 501, the memory 502, the input and output unit 503, and the bus 504;
[0182] The processor 501 is connected with the memory 502, the input and output unit 503, and the bus 504;
[0183] The processor 501 specifically performs the operation corresponding to the step in the method of Figures 1 to 2 The specific implementation process of the method is as described in the foregoing method embodiments, and will not be repeated here.
[0184] The application also relates to a computer readable storage medium, and the computer readable storage medium stores a program. When the program runs on a computer, the computer executes any of the above methods.
[0185] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0186] In the several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other ways. For example, the device embodiments described above are only schematic. The division of the units is only a logical function division. There can be another division manner for actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between the units can be indirect couplings or communication connections through some interfaces, devices or units, and can be electrical, mechanical or in other forms.
[0187] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, can be located in one place, or can be distributed on a plurality of network units. According to actual needs, some or all of the units can be selected to achieve the purpose of the embodiment scheme.
[0188] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware, or in the form of a software functional unit.
[0189] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.
Claims
1. A method for detecting dynamic scheduling of software processes, characterized in that, The method includes: Based on the detection requirements, a material acquisition process and a detection process are established. The material acquisition process is allocated independent memory space and thread resources. The number of detection processes is not unique. Each detection process is allocated independent memory space and thread resources. The detection process is used to execute the corresponding detection algorithm according to the detection task. The detection process is set up with an independent cache area. The detection process is simulated to enter an abnormal state by program code, and the self-healing strategy of the detection process is tested. The abnormal state includes memory leak state, thread blocking, file I / O failure, and model loading delay. The detection material is acquired through the material acquisition process, and the detection material is input into the detection process for detection according to preset rules; The detection process is monitored in real time by the monitoring module to obtain the resource usage data of the detection process; Dynamically allocate resources to the detection process based on the resource usage data; When the detection process is abnormal, the detection process will be automatically restarted, and the working state of the material acquisition process will be paused at the same time. When the detection process enters a restart state, a self-healing strategy is initiated; If the self-healing strategy fails to restore the detection process, the detection task of the detection process will be allocated to other detection processes based on the resource usage data. When the detection process restarts, the restarted detection process is controlled to obtain intermediate state data of the detection task through the independent buffer, and continue to execute the detection task according to the intermediate state data; The step of dynamically allocating resources to the detection process based on the resource usage data includes: Obtain the prediction algorithm; The resource usage status of the detection process is predicted based on the prediction algorithm and the resource usage data. The detection process is dynamically allocated resources based on the resource occupancy status.
2. The method according to claim 1, characterized in that, After the detection material is input into the detection process according to preset rules for detection, the method further includes: The intermediate state data generated by the detection process during the execution of the detection task is stored in the independent cache area.
3. The method according to claim 1, characterized in that, After dynamically allocating resources to the detection process based on the resource usage data, the method further includes: The resources allocated to the detection process are preheated using memory preheating technology.
4. The method according to claim 1 or 2, characterized in that, After automatically restarting the detection process when it malfunctions, the method further includes: An error log is generated based on the abnormality of the detection process. The error log records the type of abnormality and the running status when the detection process becomes abnormal.
5. A system for detecting dynamic scheduling of software processes, characterized in that, The system includes: The first acquisition unit is used to establish a material acquisition process and a detection process according to the detection requirements. The number of the detection processes is not unique, and each detection process is set with an independent cache area. The testing unit is used to simulate the detection process entering an abnormal state through program code and to test the self-healing strategy of the detection process. The abnormal states include memory leak state, thread blocking, file I / O failure, and model loading delay. The second acquisition unit is used to acquire detection material through the material acquisition process, and input the detection material into the detection process for detection according to preset rules; The monitoring unit is used to monitor the detection process in real time through the monitoring module and obtain the resource usage data of the detection process; The first allocation unit is used to dynamically allocate resources to the detection process based on the resource occupancy data. An anomaly control unit is used to automatically restart the detection process and pause the working state of the material acquisition process when the detection process is abnormal. The self-healing unit is used to activate the self-healing strategy when the detection process enters the restart state. The second allocation unit is used to allocate the detection task of the detection process to other detection processes according to the resource usage data if the self-healing strategy fails to restore the detection process. The restart unit is used to control the restarted detection process to obtain intermediate state data of the detection task through the independent buffer when the detection process completes the restart, and to continue to execute the detection task according to the intermediate state data. The first allocation unit is specifically used for: Obtain the prediction algorithm; The resource usage status of the detection process is predicted based on the prediction algorithm and the resource usage data. The detection process is dynamically allocated resources based on the resource occupancy status.
6. A device for detecting dynamic scheduling of software processes, characterized in that, The device includes: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor invokes to perform the method as described in any one of claims 1 to 4.
7. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains a program that, when executed on a computer, performs the method as described in any one of claims 1 to 4.
Citation Information
Patent Citations
A linear expansion realization method applied to a distributed communication computing service end
CN109254845A
Hardware detection process exception handling method and device and electronic equipment
CN120492200A