An embedded memory monitoring and cleaning method, system, device and medium

Abstract

The application discloses an embedded memory monitoring and cleaning method, system, device and medium, and relates to the technical field of embedded system reliability management, and comprises the following steps: collecting a memory fragmentation index, a memory leakage rate and a number of times of key task memory application failure in an embedded device running process; and performing grade division on a memory health state of the embedded device according to a collection result, so as to obtain a health state, a sub-health state and a critical state. Through multi-dimensional memory health degree evaluation, business state perception and a three-level reset mechanism, the application realizes active early warning and adaptive cleaning of an embedded device memory risk. By selecting a suitable processing opportunity according to a business window, combining context saving and fast recovery technology, reducing the influence of reset on business, and improving the stability, reliability and user experience of long-term operation of the device through reset frequency control.

Description

Technical Field

[0001] This invention relates to the field of embedded system reliability management technology, specifically to an embedded memory monitoring and cleanup method, system, device, and medium. Background Technology

[0002] With the rapid development of IoT and Industrial Internet technologies, embedded devices have been widely used in various intelligent systems such as smart terminals, industrial control equipment, and communication modules, gradually becoming core nodes for data acquisition, mobile network communication, data transmission, protocol conversion, and remote control. Especially for embedded communication modules, which typically require long-term operation of embedded Linux systems or POSIX-like operating systems to meet complex business processing and network communication needs. Because these devices usually need to operate online for extended periods, and their operating environment is limited by hardware resources, their system stability, real-time performance, and long-term reliable operation capabilities are highly demanding. During long-term operation of embedded devices, system memory management is susceptible to issues such as memory fragmentation and memory leaks. Frequent memory allocation and deallocation operations can gradually reduce the available contiguous memory space. Even if the device still has some remaining memory, the lack of large, contiguous memory blocks can lead to memory allocation failures. Simultaneously, some application tasks or kernel modules may fail to release allocated memory resources in a timely manner due to program defects, resulting in continuous memory consumption. When these problems accumulate over time, they can lead to the failure of critical business tasks, reduced system response speed, and even abnormal system restarts or kernel crashes, severely impacting the operational reliability of embedded devices and the user experience.

[0003] Limitations of existing technologies: Currently, some technical solutions address memory anomalies in embedded devices by using methods such as system reset or process replacement. For example, one existing technology controls memory cleanup based on the number of system warm restarts. This method detects the number of system warm restarts and controls the processor to reset when preset conditions are met, thereby cleaning up memory fragmentation generated during system operation. However, this solution mainly relies on the number of warm restarts as the trigger condition for memory cleanup, without considering the actual memory operating state. It cannot proactively predict and handle based on the degree of memory fragmentation, memory leak trends, and business operation status, easily leading to untimely or unnecessary cleanup. Furthermore, this solution only uses reset, lacking a tiered processing mechanism for different levels of memory anomalies, and the reset process lacks an effective business context saving and rapid recovery mechanism, potentially resulting in prolonged service interruptions. Existing technologies propose methods to predict memory leak risks based on changes in memory capacity. When a leak risk reaches a threshold, a backup process replaces the original process to release memory resources. However, this approach is a reactive measure after a problem occurs, lacking proactive prediction and maintenance capabilities. Furthermore, configuring backup processes for at-risk processes consumes additional memory and processing resources of the embedded device, making it unsuitable for resource-constrained embedded devices requiring long-term stable operation. Therefore, existing technologies still suffer from limitations such as the inability to comprehensively assess memory health, the inability to select appropriate processing times based on business status, the lack of tiered recovery strategies for different levels of anomalies, and insufficient business continuity assurance during recovery. There is an urgent need for an embedded memory monitoring and cleanup technology solution that can proactively predict memory risks, intelligently decide on cleanup timing, and support rapid recovery.

[0004] The information disclosed in the background section is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to provide an embedded memory monitoring and cleanup method, system, device, and medium to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: an embedded memory monitoring and cleanup method, comprising the following steps: The memory fragmentation index, memory leak rate, and number of critical task memory allocation failures during the operation of embedded devices are collected. Based on the collected results, the memory health status of embedded devices is classified into healthy state, sub-healthy state, and critical state. Obtain the current service operation status of the embedded device, determine the processing time window based on the service operation status, and determine the corresponding memory cleanup strategy based on the memory health status. Delay the cleanup operation in the prohibited window, perform application layer smooth reset in the deferable window, perform kernel hot reset in the best window, and perform hardware watchdog reset in the golden window. According to the determined memory cleanup strategy, the corresponding level of reset operation is executed. During the application layer smooth reset, the business process is paused, the business state data is saved, memory resources are released and the business process is resumed. During the kernel hot reset, the critical context information is saved, and the reset is completed and the network connection and critical services are restored through the kernel fast switch method. During the hardware watchdog reset, the minimized context information is saved, and the reset is triggered by the hardware watchdog and the saved information is read to restore system operation. Record the number of daily resets and the duration of sub-health status of the embedded device. Control the reset frequency based on the recorded results. When the memory is in a critical state, execute a hardware watchdog reset. When the memory is in a sub-health state and the number of daily resets is less than the preset number, execute an application-layer smooth reset or a kernel hot reset. When the number of daily resets reaches the preset number, delay the execution of the reset operation. Output an abnormal prompt when the sub-health state lasts for more than the preset time.

[0007] The embedded device's memory health status is classified according to the collected results, including: collecting memory fragmentation index, memory leak rate, and critical task memory allocation failure number at preset intervals. The memory fragmentation index represents the quality of available memory space, the memory leak rate represents the trend of continuous memory resource consumption, and the critical task memory allocation failure number represents the impact of memory anomalies on business task operation. When the memory fragmentation index F < 3%, memory leak rate L < 1% / day, and critical task memory allocation failure number E = 0, the embedded device is determined to be in a healthy state. When 0% ≤ F < 60%, or 1% / day ≤ L < 5%, or 1 time / day ≤ E < 3 times / day, the embedded device is determined to be in a sub-healthy state. When F ≥ 60%, or L ≥ 5% / day, or E ≥ 3% / day, the embedded device is determined to be in a critical state.

[0008] The system obtains the current operational status of embedded devices, including network status detection, task status detection, and processor load detection. Specifically, it uses netstat or / proc / net / dev to detect whether the device is uploading or downloading large amounts of data, detects OTA upgrade flags and remote control sessions to determine if critical tasks exist, reads / proc / loadavg to obtain CPU load information, and determines whether the device is currently in a prohibited window, a deferable window, an optimal window, or a golden window based on the obtained operational information.

[0009] The prohibited window corresponds to the device's OTA upgrade, remote control, or critical data reporting status. Within this window, no memory cleanup operations are performed, and the service status is re-checked after a preset delay. The window can be postponed to the state where the service load is low and the CPU load rate is <0.5% but a network connection exists. Within this window, an application-layer smooth reset is performed. The optimal window corresponds to the device being in an idle state with a CPU idle rate >50%. Within this window, a kernel hot reset is performed. The golden window corresponds to the state before the device enters hibernation or low-power mode. Within this window, a hardware watchdog reset is performed.

[0010] Application-layer smooth reset includes: sending a SIGSTOP signal to the business process to suspend its processing; writing the current state data of the business process to the shared memory area; sending a SIGTERM signal to the business process to exit and release the memory resources it occupies; restarting the business process and reading the state data from the shared memory area to resume business operation; and sending a SIGCONT signal to the business process to allow it to continue execution. During the application-layer smooth reset process, the TCP socket network connection is kept open, and the reset recovery time is controlled within 500ms-1s.

[0011] Kernel hot reset includes: executing a save function to write critical context information to a reserved memory area; loading a new kernel image into a specified memory area; calling the kexec system call and passing the saved context pointer to jump the system to the new kernel entry point; having the new kernel perform minimal hardware initialization; and reading critical context information from the reserved memory area to restore network connectivity and the running state of critical services. Kernel hot reset reduces system recovery time by skipping the bootloader startup process, with a reset completion time of 3-5 seconds.

[0012] Hardware watchdog reset includes: performing minimal context saving in abnormal device conditions; stopping sending watchdog feed signals to the hardware watchdog; triggering a hardware reset signal when the hardware watchdog reaches a preset timeout; detecting the abnormal reset flag through the bootloader and entering fast recovery mode; reading the saved context information from the Flash partition; loading the kernel and restoring device services. The hardware watchdog timeout is set to 8 seconds, the total hardware reset interrupt time is 30-40 seconds, and the network recovery time is reduced to less than 5 seconds.

[0013] The reset frequency is controlled based on the recorded results, including setting a daily reset count counter. and the number of days the sub-health state has not been reset When memory is in a critical state, immediately execute a hardware watchdog reset without incrementing it. Count value; when memory is in a sub-healthy state and At that time, perform an application-level smooth reset or a kernel hot reset, and... Increase by 1; when If so, the reset operation will be delayed until the next day; when Even if a reset operation is not performed, an error message will still be output; among them, It automatically resets to 0 at midnight every day. Reset to 0 when the device returns to a healthy state.

[0014] An embedded memory monitoring and cleanup system includes an application processor, DDR memory, Flash storage, a power management unit, a watchdog timer, and a system bus. The application processor runs an embedded Linux system to monitor the running status in DDR memory, perform memory health status assessment, determine cleanup timing, and control hierarchical reset. DDR memory is connected to the application processor and is used to store the operating system, applications, and dynamic data during operation, serving as a target for memory monitoring and cleanup. Flash storage is connected to the application processor and is used to store context data that needs to be recovered during the reset process, as well as reset count statistics. The context data includes TLS session tickets and APN configuration information. The power management unit is connected to the application processor and the watchdog timer respectively. It is used to manage the power supply status and reset signal of the device, and to perform a reset operation according to the software reset instruction output by the application processor, or to perform a hardware reset according to the hardware reset signal output by the watchdog timer. The watchdog timer connects the application processor and the power management unit to detect the running status of the application processor. When the application processor stops sending watchdog signals, it generates a hardware reset signal and sends it to the power management unit. The system bus connects the application processor, DDR memory, and Flash storage to enable data transfer between the application processor, DDR memory, and Flash storage.

[0015] The technical effects and advantages provided by the present invention in the above technical solution are as follows: This invention constructs a multi-dimensional memory health grading and early warning model, enabling proactive identification and predictive management of memory risks in embedded devices. By collecting multi-dimensional indicators such as memory fragmentation index, memory leak rate, and the number of memory allocation failures for critical tasks, it comprehensively assesses the device's memory operating status and identifies potential memory anomalies in advance based on different health levels, avoiding the passive handling problem of traditional methods that only address issues after system failures occur. This approach simultaneously monitors memory resource usage, memory availability quality, and the development trend of memory anomalies, enabling early detection and tiered handling of memory risks, thus improving the stability of devices during long-term operation.

[0016] This invention utilizes a service status awareness and timing decision-making mechanism to determine the appropriate time window for memory cleanup operations based on the device's current network activity status, critical task execution status, and CPU load status. This ensures the cleanup process avoids critical business phases such as OTA upgrades, remote control, and critical data reporting, minimizing impact on normal business operations. Furthermore, by defining prohibited windows, deferable windows, optimal windows, and golden windows, and selecting corresponding cleanup strategies based on different window states, memory processing operations can be completed seamlessly or with minimal impact on the user, preventing critical task interruptions due to memory cleanup and improving device business continuity and user experience.

[0017] This invention employs a three-level reset mechanism consisting of smooth reset, kernel hot reset, and hardware reset. It selects the appropriate recovery method based on the severity of memory anomalies, ensuring effective memory cleanup while maintaining system continuity. By introducing context saving and fast recovery mechanisms, the long service interruptions during traditional reset processes are reduced to the second level. The first-level reset recovery time is less than 1 second, the second-level reset recovery time is 3-5 seconds, and while the overall interruption time for the third-level reset is 30-40 seconds, the network recovery time is reduced to less than 5 seconds. Furthermore, by statistically analyzing daily reset occurrences and monitoring the duration of sub-optimal memory performance, the reset frequency can be reasonably controlled, and early warnings can be issued for persistent chronic memory problems, effectively improving the reliability, stability, and user experience of embedded devices. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0019] Figure 1 This invention provides a health status classification and early warning model mechanism.

[0020] Figure 2This is the business status perception and timing decision diagram of the present invention.

[0021] Figure 3 This is a diagram of the multi-level reset mechanism of the present invention.

[0022] Figure 4 This is the reset frequency control diagram of the present invention.

[0023] Figure 5 This is an architecture diagram of an embedded memory monitoring and cleanup system according to the present invention. Detailed Implementation

[0024] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the description of this disclosure will be more complete and fully convey the concept of the exemplary embodiments to those skilled in the art.

[0025] This invention provides, for example Figures 1-4 The embedded memory monitoring and cleanup method shown has the following specific steps: During the operation of embedded devices, applications, system tasks, and kernel components continuously perform memory allocation and deallocation operations, which can easily lead to memory fragmentation and memory leaks. To achieve real-time monitoring of the embedded device's memory status, a memory monitoring daemon is created internally. This daemon continuously collects memory status data during operation at a preset period, which can be set to 100ms to ensure timely acquisition of memory status changes. The collected data includes the memory fragmentation index F, the memory leak rate L, and the number of critical task memory allocation failures E. The memory fragmentation index F reflects the current quality of available memory space, i.e., the degree to which contiguous memory space is reduced due to frequent allocation and deallocation operations; the memory leak rate L reflects the trend of a continuous decrease in available memory per unit time due to the failure to release memory resources in a timely manner; and the number of critical task memory allocation failures E reflects situations where task execution is abnormal due to insufficient memory resources during critical business operations. By simultaneously acquiring these multiple dimensions of memory status parameters, not only can the current memory resource usage be detected, but also the quality of memory space and long-term trends can be analyzed, thus avoiding misjudgments caused by judging the device's operating status solely based on memory usage.

[0026] Based on the collected memory fragmentation index F, memory leak rate L, and critical task memory allocation failure count E, the memory health status of embedded devices is assessed in a tiered manner, categorized into healthy, sub-healthy, and critical states. Specifically, when the memory fragmentation index F < 30%, the memory leak rate L < 1% / day, and the critical task memory allocation failure count E = 0, the embedded device is considered to be in a healthy state, indicating stable memory resource operation and no significant memory anomaly risk. When 30% ≤ memory fragmentation index F < 60%, or 1% / day ≤ memory leak rate L < 5% / day, or 1 / day ≤ critical task memory allocation failure count E < 3 / day, the embedded device is considered to be in a sub-healthy state, indicating a potential risk to the current memory status, requiring continuous monitoring and handling based on subsequent changes. When the memory fragmentation index F ≥ 60%, or the memory leak rate L ≥ 5% / day, or the critical task memory allocation failure count E ≥ 3 / day, the embedded device is considered to be in a critical state, indicating that memory anomalies have reached a level affecting system stability, requiring timely cleanup measures.

[0027] The aforementioned memory health grading assessment method transforms the traditional method of relying solely on remaining memory capacity into a multi-dimensional comprehensive judgment approach, simultaneously monitoring changes in memory usage, changes in memory availability and quality, and trends in memory anomalies. Specifically, the memory fragmentation index (F) reflects the distribution of memory space, preventing situations where there is ample overall remaining memory but insufficient contiguous space for requesting; the memory leak rate (L) reflects the continuous consumption trend of memory resources, enabling early detection of potential leaks; and the number of critical task memory request failures (E) directly reflects the impact of memory anomalies on business operations. Through comprehensive analysis of these three indicators, the current memory operating status of embedded devices can be more accurately determined, and risks can be identified early based on different health levels.

[0028] During actual operation, the memory monitoring daemon continuously acquires the aforementioned indicator data and dynamically updates the memory health status based on preset judgment conditions. When a change in memory status from healthy to sub-healthy is detected, potential memory risks can be identified in advance, preventing the problem from escalating and causing critical task anomalies. When the memory status reaches a critical state, subsequent memory cleanup processes can be triggered in a timely manner, reducing the probability of business interruption or device crashes due to memory anomalies. This memory health assessment mechanism, through comprehensive analysis of the current memory status, memory quality, and changing trends, achieves pre-emptive tiered early warning for embedded device operation, enabling the device to identify risks before memory anomalies occur and providing a basis for subsequent judgment on selecting appropriate handling methods based on different risk levels.

[0029] By establishing a memory health grading and early warning mechanism based on the memory fragmentation index F, memory leak rate L, and the number of critical task memory allocation failures E, continuous monitoring and dynamic evaluation of the memory status of embedded devices can be achieved. This mechanism can not only identify memory anomalies that have already occurred, but also detect potential risks in advance based on memory change trends, thereby improving the stability and reliability of embedded devices during long-term operation. Compared with traditional single-indicator monitoring methods, this approach comprehensively considers memory usage, memory availability quality, and memory anomaly development trends to achieve a more comprehensive and accurate assessment of memory health status, providing a reliable data foundation for embedded devices to subsequently perform different levels of memory cleanup and recovery operations.

[0030] During long-term operation, embedded devices need to select appropriate memory cleanup times based on the current business operation status to avoid service interruptions caused by reset operations during critical business execution. Therefore, by acquiring the current business status information inside the device, the device's operating environment can be monitored in real time, and corresponding processing time windows can be divided according to different business states to determine the timing of memory cleanup operations.

[0031] Embedded devices obtain current service status information through internal interfaces. For network activity status, netstat or / proc / net / dev is used to detect whether the device is currently uploading or downloading large amounts of data to determine whether the current network communication task is under high load. OTA upgrade flags and remote control sessions are checked to determine if any critical tasks are currently being executed. The current CPU load information is obtained by reading / proc / loadavg, and combined with the running status of key processes, a comprehensive judgment is made on the current service load of the device.

[0032] Among these, network activity detection identifies whether the device is currently performing continuous data transmission tasks. When a device is detected performing a large-volume data upload or download task, it indicates that the current network service may be in a critical execution phase. Performing memory cleanup operations at this time may affect data transmission stability, so the cleanup operation needs to be delayed. OTA upgrade status detection determines whether the device is performing a system upgrade. Since the upgrade process involves system file updates and changes in the operating environment, reset processing should be avoided during the upgrade process. Remote control session detection determines whether the device has remote maintenance or control tasks, avoiding remote connection abnormalities caused by cleanup operations. CPU load detection assesses the overall operating pressure of the device by reading the CPU load from ` / proc / loadavg`, providing a basis for selecting an appropriate processing window.

[0033] Based on the obtained network status, task status, and CPU load status, the device operating status is divided into four processing time windows: forbidden window, deferable window, optimal window, and golden window. Different windows correspond to different memory cleanup strategies, as detailed below: When a device is in a prohibited window, it indicates that there are important business tasks such as OTA upgrades, remote control, or critical data reporting. In this case, any memory cleanup operations must be delayed to avoid impacting critical business execution due to reset operations. The timing decision process continuously monitors the device's operating status. When the device is detected to be in a prohibited window, the current business status is re-checked after a 30-second delay, and the execution conditions are determined based on the re-check result.

[0034] When a device is in a deferable window, it indicates that the current service load is low and the CPU load rate meets the condition of <0.5%, but the device still maintains network connectivity. At this time, a less impactful application-layer smooth reset operation, i.e., a first-level reset, can be performed. Memory resources are released through application-layer processing, reducing the impact on current network services.

[0035] A CPU load rate of <0.5 indicates that the current device is under low processing pressure and has the conditions to perform smooth application-layer processing. The CPU load rate reflects the current processor resource utilization. When the CPU load rate is below this threshold, it means that the device still has a certain processing capacity and can perform low-impact memory cleanup operations without affecting the operation of the main business.

[0036] When a device is in the optimal window, it indicates that the device is currently in an idle state, for example, there are no data transmission or reception tasks, no remote operation tasks, and the CPU idle rate meets the condition of >50%. At this time, the device has sufficient idle resources and can perform medium-level memory cleanup operations, i.e., a second-level reset. Compared with the deferable window, this window has a lower risk of business impact and can perform more in-depth memory recovery processing.

[0037] A CPU idle rate greater than 50% indicates that more than half of the processor's processing capacity is currently idle, meaning the device is under relatively low workload and is suitable for performing cleanup operations that require more system resources. By determining the CPU idle state, complex recovery operations can be avoided during periods of high device load.

[0038] When the device is in the golden window, which means that the device is about to enter hibernation or low power mode, such as when the network is detected to be idle and there are no business tasks at present, performing a deep cleanup operation at this time will not affect the normal use of the user. Therefore, a third-level reset can be performed to achieve a deep memory cleanup that is imperceptible to the user.

[0039] The timing decision-making process continuously assesses the device's current state and matches the reset level based on the memory health level. When the device is in a prohibited window, the status check is re-performed after a 30-second delay; when the device is in a deferable window, a level 1 or level 3 reset is triggered depending on whether the current memory level is in a sub-healthy or critical state; when the device is in an optimal window, a level 2 or level 3 reset is triggered depending on whether the current memory level is in a sub-healthy or critical state; and when the device is in a golden window, a level 3 reset is triggered depending on whether the current memory level is in a sub-healthy or critical state.

[0040] The specific correspondence is as follows: When in a deferable window: The memory level is in a sub-healthy state, triggering a level 1 reset. The memory level is in a critical state, triggering a level 3 reset.

[0041] When in the optimal window: The memory level is in a sub-healthy state, triggering a level 2 reset; The memory level is in a critical state, triggering a level 3 reset.

[0042] When in the golden window: The memory level is in a sub-healthy state, triggering a level 3 reset; The memory level is in a critical state, triggering a level 3 reset.

[0043] By employing a business status awareness and timing-based decision-making approach, memory cleanup operations are correlated with the actual operating status of the device, avoiding direct reset processing during critical task execution. Simultaneously, by matching different cleanup strategies to different time windows, memory anomaly handling can select the appropriate execution time based on the device's business environment, ensuring business continuity while restoring memory resources.

[0044] This service status awareness mechanism comprehensively utilizes network activity status, OTA upgrade status, remote control status, CPU load status, and critical process status to dynamically assess the device's operating environment. It categorizes windows into prohibited windows, deferable windows, optimal windows, and golden windows based on different statuses, and selects corresponding reset strategies according to window type and memory health level, thus optimizing the timing of memory cleanup operations. Through this approach, the impact of memory cleanup on normal service operation can be reduced, improving the stability and reliability of embedded devices during long-term operation.

[0045] The multi-level reset mechanism divides the memory cleanup process into different levels of reset methods based on the severity of memory anomalies in the embedded device and the impact on current business operations. These include application-layer smooth reset, kernel hot reset, and hardware watchdog reset. Different reset methods correspond to different processing depths and recovery methods, ensuring memory resources are released while minimizing the impact on device business continuity. Specifically, application-layer smooth reset handles minor memory anomalies by releasing memory resources through business process reconstruction; kernel hot reset handles moderate memory anomalies by quickly switching the kernel environment to achieve system recovery; and hardware watchdog reset handles severe anomalies by restoring the device's operating state through a hardware reset mechanism.

[0046] During the application-layer smooth reset process, a state freeze operation is first performed. The main control process sends a SIGSTOP signal to all business processes, causing them to suspend their current business processing. This prevents new data changes from occurring during memory cleanup and ensures that the business state data remains stable. After the business processes are suspended, they write their current running state data to a shared memory area. This shared memory area stores information that needs to be restored during business operation, allowing subsequent business processes to read the original running state upon restart, thus reducing data loss during business recovery.

[0047] After saving the status data, a resource release operation is performed. The main control process sends a SIGTERM signal to the business process, causing the business process to terminate normally and releasing the memory resources it occupies. By actively terminating the business process, memory usage generated during business operation can be released, reducing the impact of memory fragmentation and memory leaks.

[0048] After the business process exits and releases its resources, the master process restarts it, thus rebuilding the business process. The restarted business process reads the previously saved state data from the shared memory area and restores its original running state based on the saved data, allowing it to continue executing its original business processes. Once the state restoration is complete, the master process sends a SIGCONT signal to the business process, resuming its operation and completing the service recovery process.

[0049] During a smooth application-layer reset, the device's network connectivity remains continuous. TCP socket connections, since no closing operation is performed, remain open. This method only has a brief impact on business processing and does not require re-establishing network connections, thus reducing the impact of the reset process on communication services. By pausing processes, saving states, releasing resources, rebuilding processes, and restoring states at the application layer, a low-impact memory cleanup operation is achieved. The reset process recovery time is controlled within the range of 500ms-1s, making it suitable for scenarios where the device continues to run services but needs to release some memory resources.

[0050] When a smooth application-layer reset fails to meet memory recovery requirements, or when the severity of memory anomalies increases further, a kernel hot reset is executed. Kernel hot reset achieves system recovery without requiring a full boot process by saving critical runtime context information and quickly switching to a new kernel runtime environment.

[0051] During a kernel hot reset, a context save operation is performed first, writing critical context data to a reserved memory area via a save function. This critical context data records the information needed for system recovery, enabling the new kernel runtime environment to acquire the running state before the reset. By saving the context information in the reserved memory area, the loss of the running state due to reinitialization during a traditional reboot is avoided.

[0052] After saving the context, the new kernel image is loaded into a specified area of ​​memory, providing a runtime environment for subsequent kernel switching. Then, the kexec system call is invoked, passing the saved context pointer, enabling the system to perform a rapid switch based on the saved context information. During the kexec call, the system jumps directly to the new kernel entry point, bypassing the bootloader stage in the traditional boot process, thus reducing the waiting time during system startup.

[0053] After the kernel entry point switch is complete, the new kernel performs minimal hardware initialization, initializing only the hardware resources required for recovery, thus avoiding the full initialization process of the complete boot process and improving system recovery speed. Once hardware initialization is complete, previously saved context information is read from the reserved memory area to restore network connectivity and the running state of critical services, enabling the device to quickly return to normal operation.

[0054] Kernel hot reset allows for kernel environment switching without a full system reboot, enabling faster system recovery. This method is suitable for situations with high memory anomalies, but where the system can still perform context saving operations. The entire kernel hot reset process takes only 3-5 seconds, significantly reducing service interruption time and improving device continuity compared to traditional device reboot methods.

[0055] When a device experiences a severe memory anomaly and cannot be restored to operation via application-level smooth reset or kernel hot reset, a hardware watchdog reset is used for system recovery. The hardware watchdog reset monitors the device's operating status through an independent hardware timing mechanism and triggers a hardware reset signal in the event of a system anomaly, allowing the device to return to a runnable state.

[0056] During the hardware watchdog reset process, an emergency save operation is performed first, immediately saving minimal context information in the event of a device malfunction. Since this reset method is primarily used to handle severe abnormal situations, the saved content only includes the essential information required for system recovery, minimizing save time and preventing the context saving process from failing due to system abnormalities.

[0057] After saving the minimized context, the system actively stops sending feed signals to the hardware watchdog. When the hardware watchdog detects that no feed signal has been received for a preset time, it triggers a hardware reset signal. The watchdog timeout can be set to 8 seconds. After the timeout period, the hardware watchdog sends a reset request to the device reset control unit, causing the device to perform a hardware-level reset operation.

[0058] After the hardware reset is complete, the bootloader detects the device's abnormal reset flag and enters fast recovery mode based on the detection result. In fast recovery mode, the bootloader does not follow the normal boot process but performs recovery processing specifically for abnormal reset scenarios. Subsequently, it reads the previously saved context information from the dedicated Flash partition to obtain the data required for the device to resume operation.

[0059] After the context read is complete, the system reloads the kernel and restores relevant services, bringing the device back to operational status. Since a hardware reset involves a complete hardware re-initialization process, the overall reset time is approximately 30-40 seconds. However, by performing a minimal context save before the reset and reading the saved information during the recovery process, network re-establishment and service recovery time can be reduced, shortening the network recovery time to less than 5 seconds.

[0060] By employing three different levels of recovery methods—application-layer smooth reset, kernel hot reset, and hardware watchdog reset—the appropriate handling method can be selected for memory anomalies of varying degrees. Application-layer smooth reset focuses on minimizing business impact by rebuilding business processes to release memory resources; kernel hot reset focuses on improving system recovery speed by reducing system interruption time through rapid kernel switching; and hardware watchdog reset focuses on ensuring reliable device recovery by handling severe abnormal states through hardware mechanisms.

[0061] The three reset methods form a hierarchical processing relationship from mild to severe, selecting different recovery levels based on the degree of device memory anomaly. In cases of minor anomalies, application-layer smooth reset is prioritized to minimize service interruption; in cases of moderate anomalies, kernel hot reset is used to improve system recovery efficiency; and in cases of severe anomalies, hardware watchdog reset is employed to ensure the device can resume operation. Through the coordination of different reset mechanisms, rapid recovery and stable operation of embedded devices in the event of memory anomalies are achieved.

[0062] The daily reboot count control mechanism manages the frequency of reset operations performed by embedded devices, preventing frequent resets from affecting normal business operations. It also monitors and alerts for persistent memory anomalies. This mechanism defines a daily reboot count counter. And the number of days of being in a sub-healthy state but not having restarted. By recording the number of device resets and the duration of memory anomalies, the reset behavior under different memory health states can be restricted and adjusted.

[0063] Among them, the daily restart count counter This counter records the number of resets performed on the device that day. It determines whether a reset operation has already been performed within the current date, thus controlling whether subsequent reset operations continue. (Number of days without a restart during sub-health status) This parameter is used to record the number of consecutive days that a device is in a sub-healthy state but has not undergone a reset operation. This parameter is used to determine whether the memory abnormality has been present for a long time, and to trigger an abnormality prompt when the duration reaches a certain condition.

[0064] The daily restart count counter is represented as: in: This indicates the count of the number of times the device performed a restart or reset operation on that day. When the device starts running each day, this count is recalculated based on the date. This count value is used to limit the frequency at which the device performs a reset operation within a single day.

[0065] The duration counter for sub-health state is represented as: in: This indicates the number of consecutive days the device has been in a sub-healthy state without undergoing a restart process; This parameter is used to record long-standing memory anomalies that are not immediately addressed. Once the device returns to a healthy state, this parameter is reset to zero.

[0066] During device operation, the current memory health status is continuously monitored. When the memory status is detected to be in a critical state, it indicates a high degree of memory abnormality that may have affected the normal operation of the device. In this case, a three-level reset operation is immediately performed, which is not subject to the daily reset limit, and this three-level reset is not counted in the daily restart counter. To prevent the device from frequently performing level 3 resets due to critical conditions, it is also necessary to set a maximum number of level 3 resets per day to limit the level 3 reset behavior.

[0067] When memory is in a critical state, the processing logic is as follows: in: Memory status: Indicates the current operating status of the device after a memory health status assessment; Critical state: Indicates that the degree of memory fragmentation, memory leaks, or memory allocation failures for critical tasks have reached a high risk level; Level 3 reset: This indicates that the system recovery operation is performed through a hardware watchdog reset. When performing a three-level reset, no additional steps are added. The count value.

[0068] When memory is detected to be in a sub-optimal state, the highest-level reset operation is not immediately executed. Instead, the number of resets performed that day is first checked. Determine whether the conditions for resetting are met.

[0069] The logic for handling sub-health conditions is as follows: This indicates that no reset operation has been performed that day. At this time, a level 1 reset or level 2 reset is allowed, and the reset count for the day will be updated after the reset is completed. in: This indicates that the number of resets performed on that day was less than 1. This indicates that after completing a Level 1 or Level 2 reset, the number of resets for the day will be increased by 1. Level 1 reset indicates a smooth reset at the application layer; Level 2 reset indicates a core thermal reset.

[0070] This restriction method can prevent the device from performing multiple reset operations on the same day, reducing the impact of frequent recovery processes on business operations.

[0071] When detected: This indicates that a reset operation has already been performed on the same day. Therefore, a new primary or secondary reset will not be performed immediately; instead, the processing will be postponed to the next day. This delayed processing method maintains the equipment in its current operating state while avoiding business continuity degradation due to repeated resets.

[0072] in: This indicates that there has been one or more reset records on that day. When this condition is met, the task of handling the current sub-health status will be postponed to the next day for reassessment; Continuously monitor memory state changes during the delay period.

[0073] For situations where individuals are in a sub-healthy state for an extended period but have not undergone a restart process, through... Perform duration statistics. When the device is in a sub-optimal state for several consecutive days, for example: This indicates that the device has been in a sub-healthy state for more than 3 consecutive days, and an abnormal alarm should be triggered even if no restart operation is performed on that day.

[0074] in: This indicates that the sub-healthy state has lasted for more than 3 days; Record the number of days the sub-healthy state lasts; The error message is used to alert users that the device has a long-term memory risk and requires further attention.

[0075] This mechanism combines a limit on the number of resets with anomaly duration detection to handle short-term and long-term anomalies separately. For critical states with high severity, priority is given to ensuring equipment recovery capabilities, and a level-three reset is executed directly. For sub-healthy states with low risk, the processing frequency is controlled by limiting the number of resets per day to avoid repeated resets affecting equipment operation. For persistent sub-healthy issues, long-term abnormal trends are identified through continuous day statistics, and timely alerts are provided.

[0076] Daily restart count counter The device is automatically reset to 0 at midnight each day to ensure that the count of device resets restarts at the beginning of a new day. The reset logic is as follows: in: Midnight: This indicates the time when the count is refreshed each day when the date changes. This indicates that the number of resets for the day will be reset at the start of a new day.

[0077] Sub-health status without restarting for consecutive days Reset when the device returns to a healthy state: in: Memory restored to healthy state: This means that after monitoring and judgment, the device memory state has once again met the health status conditions; This indicates that the previously accumulated number of days in a sub-healthy state has been cleared and the statistics have started again.

[0078] By employing the above-described reset frequency control method, different handling strategies are adopted for different levels of memory anomalies, achieving reasonable control over reset behavior. In critical states, a three-level reset is prioritized to ensure device recovery capability; in sub-optimal states, a reset is performed... Limit the number of daily processing times, through The system monitors long-term anomaly trends and utilizes a daily automatic reset mechanism to ensure independent operation of the counting cycle. This mechanism can prevent excessive resets while ensuring stable device operation, and promptly detect persistent memory anomalies, providing a management basis for the long-term reliable operation of embedded devices.

[0079] This invention constructs a multi-dimensional memory health grading and early warning model, enabling proactive identification and predictive management of memory risks in embedded devices. By collecting multi-dimensional indicators such as memory fragmentation index, memory leak rate, and the number of memory allocation failures for critical tasks, it comprehensively assesses the device's memory operating status and identifies potential memory anomalies in advance based on different health levels, avoiding the passive handling problem of traditional methods that only address issues after system failures occur. This approach simultaneously monitors memory resource usage, memory availability quality, and the development trend of memory anomalies, enabling early detection and tiered handling of memory risks, thus improving the stability of devices during long-term operation.

[0080] This invention utilizes a service status awareness and timing decision-making mechanism to determine the appropriate time window for memory cleanup operations based on the device's current network activity status, critical task execution status, and CPU load status. This ensures the cleanup process avoids critical business phases such as OTA upgrades, remote control, and critical data reporting, minimizing impact on normal business operations. Furthermore, by defining prohibited windows, deferable windows, optimal windows, and golden windows, and selecting corresponding cleanup strategies based on different window states, memory processing operations can be completed seamlessly or with minimal impact on the user, preventing critical task interruptions due to memory cleanup and improving device business continuity and user experience.

[0081] This invention employs a three-level reset mechanism consisting of smooth reset, kernel hot reset, and hardware reset. It selects the appropriate recovery method based on the severity of memory anomalies, ensuring effective memory cleanup while maintaining system continuity. By introducing context saving and fast recovery mechanisms, the long service interruptions during traditional reset processes are reduced to the second level. The first-level reset recovery time is less than 1 second, the second-level reset recovery time is 3-5 seconds, and while the overall interruption time for the third-level reset is 30-40 seconds, the network recovery time is reduced to less than 5 seconds. Furthermore, by statistically analyzing daily reset occurrences and monitoring the duration of sub-optimal memory performance, the reset frequency can be reasonably controlled, and early warnings can be issued for persistent chronic memory problems, effectively improving the reliability, stability, and user experience of embedded devices.

[0082] This invention provides, for example Figure 5 An embedded memory monitoring and cleanup system is shown, including an application processor, DDR memory, Flash storage, a power management unit, a watchdog timer, and a system bus; The application processor runs an embedded Linux system to monitor the running status in DDR memory, perform memory health status assessment, determine cleanup timing, and control hierarchical reset. DDR memory is connected to the application processor and is used to store the operating system, applications, and dynamic data during operation, serving as a target for memory monitoring and cleanup. Flash storage is connected to the application processor and is used to store context data that needs to be recovered during the reset process, as well as reset count statistics. The context data includes TLS session tickets and APN configuration information. The power management unit is connected to the application processor and the watchdog timer respectively. It is used to manage the power supply status and reset signal of the device, and to perform a reset operation according to the software reset instruction output by the application processor, or to perform a hardware reset according to the hardware reset signal output by the watchdog timer. The watchdog timer connects the application processor and the power management unit to detect the running status of the application processor. When the application processor stops sending watchdog signals, it generates a hardware reset signal and sends it to the power management unit. The system bus connects the application processor, DDR memory, and Flash storage to enable data transfer between the application processor, DDR memory, and Flash storage.

[0083] The embedded memory monitoring and cleanup method provided in this embodiment of the invention is implemented through the above-described embedded memory monitoring and cleanup system. For details of the specific method and process of the embedded memory monitoring and cleanup system, please refer to the embodiment of the above-described embedded memory monitoring and cleanup method, which will not be repeated here.

[0084] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. An embedded memory monitoring and cleanup method, characterized in that, Includes the following steps: The memory fragmentation index, memory leak rate, and number of critical task memory allocation failures during the operation of embedded devices are collected. Based on the collected results, the memory health status of embedded devices is classified into healthy state, sub-healthy state, and critical state. Obtain the current service operation status of the embedded device, determine the processing time window based on the service operation status, and determine the corresponding memory cleanup strategy based on the memory health status. Delay the cleanup operation in the prohibited window, perform application layer smooth reset in the deferable window, perform kernel hot reset in the best window, and perform hardware watchdog reset in the golden window. According to the determined memory cleanup strategy, the corresponding level of reset operation is executed. During the application layer smooth reset, the business process is paused, the business state data is saved, memory resources are released and the business process is resumed. During the kernel hot reset, the critical context information is saved, and the reset is completed and the network connection and critical services are restored through the kernel fast switch method. During the hardware watchdog reset, the minimized context information is saved, and the reset is triggered by the hardware watchdog and the saved information is read to restore system operation. Record the number of daily resets and the duration of sub-health status of the embedded device. Control the reset frequency based on the recorded results. When the memory is in a critical state, execute a hardware watchdog reset. When the memory is in a sub-health state and the number of daily resets is less than the preset number, execute an application-layer smooth reset or a kernel hot reset. When the number of daily resets reaches the preset number, delay the execution of the reset operation. Output an abnormal prompt when the sub-health state lasts for more than the preset time.

2. The embedded memory monitoring and cleanup method according to claim 1, characterized in that, The embedded device's memory health status is classified according to the collected results, including: collecting memory fragmentation index, memory leak rate, and critical task memory allocation failure number at preset intervals. The memory fragmentation index represents the quality of available memory space, the memory leak rate represents the trend of continuous memory resource consumption, and the critical task memory allocation failure number represents the impact of memory anomalies on business task operation. When the memory fragmentation index F < 3%, memory leak rate L < 1% / day, and critical task memory allocation failure number E = 0, the embedded device is determined to be in a healthy state. When 0% ≤ F < 60%, or 1% / day ≤ L < 5%, or 1 time / day ≤ E < 3 times / day, the embedded device is determined to be in a sub-healthy state. When F ≥ 60%, or L ≥ 5% / day, or E ≥ 3% / day, the embedded device is determined to be in a critical state.

3. The embedded memory monitoring and cleanup method according to claim 1, characterized in that, The system obtains the current operational status of embedded devices, including network status detection, task status detection, and processor load detection. Specifically, it uses netstat or / proc / net / dev to detect whether the device is uploading or downloading large amounts of data, detects OTA upgrade flags and remote control sessions to determine if critical tasks exist, reads / proc / loadavg to obtain CPU load information, and determines whether the device is currently in a prohibited window, a deferable window, an optimal window, or a golden window based on the obtained operational information.

4. The embedded memory monitoring and cleanup method according to claim 3, characterized in that, The prohibited window corresponds to the device's OTA upgrade, remote control, or critical data reporting status. Within this window, no memory cleanup operations are performed, and the service status is re-checked after a preset delay. The window can be postponed to the state where the service load is low and the CPU load rate is <0.5% but a network connection exists. Within this window, an application-layer smooth reset is performed. The optimal window corresponds to the device being in an idle state with a CPU idle rate >50%. Within this window, a kernel hot reset is performed. The golden window corresponds to the state before the device enters hibernation or low-power mode. Within this window, a hardware watchdog reset is performed.

5. The embedded memory monitoring and cleanup method according to claim 1, characterized in that, Application-layer smooth reset includes: sending a SIGSTOP signal to the business process to suspend its processing; writing the current state data of the business process to the shared memory area; sending a SIGTERM signal to the business process to exit and release the memory resources it occupies; restarting the business process and reading the state data from the shared memory area to resume business operation; and sending a SIGCONT signal to the business process to allow it to continue execution. During the application-layer smooth reset process, the TCP socket network connection is kept open, and the reset recovery time is controlled within 500ms-1s.

6. The embedded memory monitoring and cleanup method according to claim 1, characterized in that, Kernel hot reset includes: executing a save function to write critical context information to a reserved memory area; loading a new kernel image into a specified memory area; calling the kexec system call and passing the saved context pointer to jump the system to the new kernel entry point; having the new kernel perform minimal hardware initialization; and reading critical context information from the reserved memory area to restore network connectivity and the running state of critical services. Kernel hot reset reduces system recovery time by skipping the bootloader startup process, with a reset completion time of 3-5 seconds.

7. The embedded memory monitoring and cleanup method according to claim 1, characterized in that, Hardware watchdog reset includes: performing minimal context saving in abnormal device conditions; stopping sending watchdog feed signals to the hardware watchdog; triggering a hardware reset signal when the hardware watchdog reaches a preset timeout; detecting the abnormal reset flag through the bootloader and entering fast recovery mode; reading the saved context information from the Flash partition; loading the kernel and restoring device services. The hardware watchdog timeout is set to 8 seconds, the total hardware reset interrupt time is 30-40 seconds, and the network recovery time is reduced to less than 5 seconds.

8. The embedded memory monitoring and cleanup method according to claim 1, characterized in that, The reset frequency is controlled based on the recorded results, including setting a daily reset count counter. and the number of days the sub-health state has not been reset ; When memory is in a critical state, the hardware watchdog timer is immediately reset without incrementing. Count value; When memory is in a sub-healthy state and At that time, perform an application-level smooth reset or a kernel hot reset, and... Increase by 1; when If so, the reset operation will be delayed until the next day; when Even if a reset operation is not performed, an error message will still be output; among them, It automatically resets to 0 at midnight every day. Reset to 0 when the device returns to a healthy state.

9. An embedded memory monitoring and cleanup system, used to implement the embedded memory monitoring and cleanup method according to any one of claims 1-8, characterized in that, This includes the application processor, DDR memory, Flash storage, power management unit, watchdog timer, and system bus; The application processor runs an embedded Linux system to monitor the running status in DDR memory, perform memory health status assessment, determine cleanup timing, and control hierarchical reset. DDR memory is connected to the application processor and is used to store the operating system, applications, and dynamic data during operation, serving as a target for memory monitoring and cleanup. Flash storage is connected to the application processor and is used to store context data that needs to be recovered during the reset process, as well as reset count statistics. The context data includes TLS session tickets and APN configuration information. The power management unit is connected to the application processor and the watchdog timer respectively. It is used to manage the power supply status and reset signal of the device, and to perform a reset operation according to the software reset instruction output by the application processor, or to perform a hardware reset according to the hardware reset signal output by the watchdog timer. The watchdog timer connects the application processor and the power management unit to detect the running status of the application processor. When the application processor stops sending watchdog signals, it generates a hardware reset signal and sends it to the power management unit. The system bus connects the application processor, DDR memory, and Flash storage to enable data transfer between the application processor, DDR memory, and Flash storage.

10. An embedded memory monitoring and cleanup device, characterized in that, The communication device includes: a memory and at least one processor, the memory storing instructions, the memory and the at least one processor being interconnected via a line; the at least one processor invokes the instructions in the memory to cause the communication device to perform an embedded memory monitoring and cleanup method as claimed in any one of claims 1-8.

11. An embedded memory monitoring and cleanup medium, wherein a computer program is stored on a computer-readable storage medium of a communication device, characterized in that, When a computer program is executed by a processor, it implements an embedded memory monitoring and cleanup method as described in any one of claims 1-8.

Images