Memory leak detection methods, devices, equipment, storage media, and software products

Abstract

This application relates to the field of data destruction and provides a method, apparatus, device, storage medium, and program product for detecting memory leaks. The method includes: creating destruction tasks for multiple volumes to be destroyed and assigning these tasks to multiple nodes; obtaining the number of destruction tasks being executed by each node under different operating states and the load balancing conditions; and determining whether the destruction tasks are in a load-balanced state based on the number of destruction tasks being executed by each node under different operating states and the load balancing conditions. By assigning multiple destruction tasks to nodes and determining whether the destruction tasks are load-balanced based on whether the number of destruction tasks being executed by each node meets the load balancing conditions, the time-consuming and laborious problem of manually checking whether the destruction tasks are load-balanced is avoided, achieving efficient and rapid verification of whether the storage system is load-balanced during the data destruction process.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, device, storage medium, and program product for detecting memory leaks. Background Technology

[0002] A memory leak occurs when an application dynamically allocates memory during runtime but fails to release that memory properly and promptly when it is no longer needed. This results in the memory being permanently occupied and unusable. Over time and as the application continues to run, the amount of unreleased memory gradually increases, potentially exhausting system resources, impacting application performance, and even causing system or application crashes.

[0003] In the process of detecting memory leaks in storage systems, because the core software allocates a large amount of memory during operation and memory fluctuations are relatively small, it is necessary to accumulate a large number of creation, deletion, startup, and shutdown operations before problems can be discovered. Related technologies require testers to repeatedly execute millions or even hundreds of millions of creation and deletion operations, continuously recording the memory deviations after each creation and deletion operation—a tedious and time-consuming process. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a memory leak detection method, apparatus, device, storage medium, and program product that automates the testing of software for memory leaks, reducing the complexity of the detection operation and improving detection efficiency.

[0005] In a first aspect, this application provides a memory leak detection method, which includes: using a first process to control the software under test to run a set service multiple times according to pre-configured resource parameters; using a second process to record the single memory change value and / or cumulative memory change value after the set service runs are completed; and when it is determined that the memory leak detection conditions are met, using the second process to determine whether the software under test has a memory leak based on the single memory change value and / or cumulative memory change value after the set service runs are completed.

[0006] Secondly, this application provides a memory leak detection device, which includes: a service operation module, used to control the software under test to run a set service multiple times according to pre-configured resource parameters using a first process; a memory change value recording module, used to record the single memory change value and / or cumulative memory change value after the set service runs are completed using a second process; and a memory leak judgment module, used to determine whether the software under test has a memory leak when it is determined that the memory leak detection conditions are met, using the second process based on the single memory change value and / or cumulative memory change value after the set service runs are completed.

[0007] Thirdly, this application provides an electronic device including a memory leak detection device, the device comprising: one or more processors; a storage device for storing one or more programs; and when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the memory leak detection method as described in the first aspect above.

[0008] Fourthly, this application provides a storage medium, which may be a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the memory leak detection method as described in the first aspect above.

[0009] Fifthly, embodiments of this application provide a computer program product, which includes a computer program or instructions that, when executed by a processor, implement any of the memory leak detection methods described in the first aspect above.

[0010] This application provides a memory leak detection method, apparatus, device, storage medium, and program product. According to pre-configured resource parameters, a first process controls the software under test to run a set service multiple times; a second process records the single memory change value and / or cumulative memory change value after the set service runs are completed; when the memory leak detection conditions are met, the second process determines whether the software under test has a memory leak based on the single memory change value and / or cumulative memory change value after the set service runs are completed. Because the first process controls the software under test to execute the service multiple times, and the second process records the memory changes after the service execution, the existence of a memory leak is determined based on the memory changes. This automated method of testing for memory leaks reduces the complexity of the detection operation and improves detection efficiency. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A flowchart illustrating a memory leak detection method provided in an embodiment of this application;

[0014] Figure 2 A flowchart illustrating the interaction of three processes is provided for an embodiment of this application;

[0015] Figure 3 This application provides a flowchart illustrating the process of recording memory changes in a first process.

[0016] Figure 4 A schematic diagram illustrating the process of setting up business operations for the second process control provided in this application embodiment;

[0017] Figure 5 A flowchart illustrating the third process monitoring and memory killing mechanism provided in this application embodiment;

[0018] Figure 6 This is a schematic diagram of the structure of a memory leak detection device provided in an embodiment of this application;

[0019] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] To better understand the above-mentioned objectives, features, and advantages of this application, the solution of this application will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0021] Many specific details are set forth in the following description in order to provide a full understanding of this application, but this application may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some embodiments of this application, and not all embodiments.

[0022] A memory leak occurs when an application dynamically allocates memory during runtime but fails to release that memory properly and promptly when it is no longer needed. This results in the memory being permanently occupied and unusable. Over time and as the application continues to run, the amount of unreleased memory gradually increases, potentially exhausting system resources, impacting application performance, and even causing system or application crashes.

[0023] Memory leaks typically don't cause immediate errors but accumulate gradually, impacting overall system performance. In production applications, the risk of memory leaks is significant. Exhaustion of memory leads to insufficient system memory, causing program crashes or malfunctions. This manifests as decreased application performance, slower application execution, longer response times, and may even trigger system crashes or deadlocks, resulting in data loss or system failure. Furthermore, memory leaks can lead to the leakage of sensitive data, such as passwords and user information. This sensitive information can be exploited by malicious programs or attackers, creating security vulnerabilities.

[0024] The Out-Of-Memory Killer (OOM Killer) is a mechanism in the operating system used to select and terminate processes that consume excessive memory when system memory is insufficient, thereby freeing up memory and maintaining normal system operation. Its working principle is that when system memory is insufficient to meet the needs of processes, the operating system kernel first attempts to free up memory by swapping some memory pages to swap space or using page reclamation techniques (such as deleting long-inactive pages). If these methods still cannot meet the system's memory needs, the kernel triggers the OOM Killer mechanism. The OOM Killer mechanism scans the processes in the system, evaluates their memory usage, and selects the most suitable process to terminate to free up memory. Typically, the OOM Killer selects processes that consume a large amount of memory but have a relatively small impact on the overall system as the processes to be terminated.

[0025] In related technologies, memory leak detection methods and tools are based on application-level management software. However, for storage systems, which have their own independent operating systems, detecting memory leaks requires delving into the core software layer. This means checking whether the core software has memory leaks or inappropriate memory allocation. Because the core software allocates a large amount of memory during operation and memory fluctuations are relatively small, problems often only become apparent after a large number of creation, deletion, startup, and shutdown operations have accumulated. Short-term observation can easily lead to overlooking these issues.

[0026] In the process of memory leak detection in storage systems, it is crucial for users to assess whether the functions provided by the storage system, including the creation and reclamation of various types of pool volumes, contain memory leaks. Identifying memory leak risks requires continuously recording memory changes during repeated creation, deletion, startup, and shutdown tests to evaluate the presence of memory leaks. For testers, building resources according to different business types and repeatedly executing millions or even hundreds of millions of creation and deletion operations, while continuously recording memory deviations after each creation and deletion, is a tedious and time-consuming testing process that cannot be accomplished manually alone.

[0027] To address the aforementioned technical problems, embodiments of this application provide a memory leak detection method, apparatus, device, storage medium, and program product. According to pre-configured resource parameters, a first process controls the software under test to run a set service multiple times; a second process records the single memory change value and / or cumulative memory change value after the set service runs are completed; when it is determined that the memory leak detection conditions are met, the second process uses the single memory change value and / or cumulative memory change value after the set service runs are completed to determine whether the software under test has a memory leak. Because the first process controls the software under test to execute the service multiple times, and the second process records the memory changes after the service execution, the existence of a memory leak is determined based on the memory changes. This automated method of testing for memory leaks reduces the complexity of the detection operation and improves detection efficiency.

[0028] The memory leak detection method provided in this application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0029] Figure 1 This is a flowchart of a memory leak detection method in an embodiment of this application. This embodiment can be applied to detect whether a memory leak occurs during software operation. The method can be executed by a memory leak detection device, which can be implemented in software and / or hardware. The key point detection device can be configured in the controller of the storage system.

[0030] like Figure 1 As shown, the memory leak detection method provided in this application mainly includes steps S101-S103.

[0031] S101. According to the pre-configured resource parameters, the software under test is controlled by the first process to run the set business multiple times.

[0032] The pre-configured resource parameters are used to control the multiple executions of a specific service by the software under test. Specifically, a resource configuration structure is pre-created, containing four variables: the first variable, `shell_N`, pre-configures the full path name of the script for the specified service; the second variable, `cnum`, pre-configures the number of volumes to be executed by the specified service; the third variable, `cnum`, pre-configures the number of threads for concurrent execution of the specified service; and the fourth variable, `count`, pre-configures the number of times the specified service will be run, i.e., the number of times the software under test needs to run the specified service.

[0033] The software under test refers to the software whose memory leak needs to be tested for. Optionally, the software under test can be the core software of the storage system. Core software may include, but is not limited to, operating systems, file systems, volume managers, RAID software, snapshot and replication services, etc. The aforementioned configured services can be any creation or deletion operation that the software under test can perform. This application embodiment does not specifically limit this.

[0034] The memory leak detection method provided in this application uses two processes: a first process and a second process. The first process is primarily used to control the multiple executions of a set service. The second process is primarily used to record memory changes after each execution of the set service and to determine whether the software under test has a memory leak based on these changes.

[0035] S102. Use the second process to record the single memory change value and / or cumulative memory change value after the business operation ends.

[0036] The second process is mainly used to record memory changes after each set business operation ends, and to determine whether the software under test has a memory leak based on the memory changes.

[0037] It should be noted that the first and second processes execute alternately. In the initialization state, the second process first records the initial memory values ​​before the configured service runs. Then, the first process controls the software under test to run the configured service. After the configured service runs, the second process records memory changes and determines whether there is a memory leak. If a memory leak is found, an alarm is generated, and the memory leak detection process exits. If no memory leak is found, the first process controls the software under test to run the configured service again, and this process repeats until the configured service has been run a specified number of times, and the second process confirms that there is no memory leak. At this point, the user is notified that there is no memory leak, and the memory leak detection process exits.

[0038] The single memory change value can be understood as the difference between the available memory after the current set service execution and the available memory after the previous set service execution. The cumulative memory change value can be understood as the difference between the available memory after the current set service execution and the available memory before the set service execution.

[0039] The second process records the single memory change value after the end of the set service operation, including: using the second process to record the available memory value after each run of the set service, and subtracting the available memory value after the previous run from the available memory value after the current run to obtain the single memory change value after the current run.

[0040] The second process records the cumulative memory change value after the set service runs, including: accumulating the single memory change value recorded after each set service run to obtain the cumulative memory change value after the current run. Alternatively, it records the available memory value before the set service runs, and subtracts the available memory value before the set service runs to obtain the cumulative memory change value after the current run.

[0041] S103. When the memory leak detection conditions are met, the second process is used to determine whether the software under test has a memory leak based on the single memory change value and / or cumulative memory change value after the end of the set business operation.

[0042] In one possible implementation, determining whether a memory leak detection condition is met includes: detecting that a set service has ended; and / or detecting an insufficient memory state.

[0043] The detection of the completion of a designated service operation can be understood as the detection of the termination of the first process's control over the designated service operation. After the termination of the first process's control over the designated service operation, the second process uses the single memory change value and / or cumulative memory change value after the completion of the designated service operation to determine whether there is a memory leak in the software under test.

[0044] A detected low memory status can be understood as the operating system's built-in memory management mechanism being triggered. If this mechanism is activated, it indicates that the system memory is insufficient and selects the most suitable process to terminate to release memory. Therefore, a second process is needed to determine if the software under test has a memory leak based on single and / or cumulative memory changes after the specified business process has finished running. In other words, after the operating system's built-in memory management mechanism is detected, a second process is needed to determine whether the low memory is due to a memory leak in the software under test.

[0045] In one possible implementation, a second process is used to determine whether the software under test has a memory leak based on the cumulative memory change value after the end of a set service operation. This includes: determining whether the cumulative memory change value recorded after the end of the set service operation is greater than a first set threshold; determining that the software under test has a memory leak when the second process determines that the cumulative memory change value recorded after the end of the set service operation is greater than the first set threshold; and determining that the software under test does not have a memory leak when the second process determines that the cumulative memory change value recorded after the end of the set service operation is less than or equal to the first set threshold.

[0046] The first set threshold can be understood as the standard for determining whether a memory leak exists. A second process records the cumulative memory change. The cumulative memory change value refers to the net increment remaining after all memory allocation and release operations from before the start of the current service to the end of that service's execution.

[0047] The final cumulative memory change value is compared with a preset first threshold. If the cumulative memory change value is greater than the first threshold, it means that a large amount of memory was not properly released after the current service run, which may indicate a memory leak. In this case, the second process will report a memory leak in the software under test. Conversely, if the cumulative memory change value is less than or equal to the first threshold, it means that most of the memory has been properly reclaimed, and therefore it can be considered that the software under test did not exhibit obvious memory leaks during this service run.

[0048] In this embodiment, a simple threshold comparison method is used to achieve fast and effective detection of memory leaks.

[0049] In one possible implementation, a second process is used to determine whether the software under test has a memory leak based on the single memory change value after the end of a set business operation. This includes: determining whether the single memory change value recorded after multiple set business operations have an increasing trend; and using the second process to determine that the single memory change value recorded after multiple set business operations have an increasing trend, thus determining that the software under test has a memory leak.

[0050] As mentioned above, a single memory change value refers to the change in memory usage after a set business operation has ended. A single memory change value reflects the amount of memory allocated but not released during this business operation.

[0051] An increasing trend can be understood as the recorded memory change value after each business operation shows a gradual increase. If the memory change value is larger each time after several consecutive business operations than the previous one, it is considered that there is an increasing trend.

[0052] Under normal circumstances, even if there are small fluctuations in the value of a single memory change, in the long run, the value of a single memory change should tend to stabilize rather than continue to increase.

[0053] The second process analyzes multiple consecutive single memory change values. If these values ​​show an increasing trend—meaning the single memory change after each run gradually increases with the number of business operations—it indicates a potential memory leak. If this increasing trend is confirmed, the software under test is confirmed to have a potential memory leak. If the increasing trend is not observed, the software under test is confirmed not to have a memory leak.

[0054] Analyzing the trends of multiple consecutive single memory change values ​​can help identify potential memory leaks, making it particularly useful for applications that may experience memory leaks under long-running or high-load conditions.

[0055] This application provides a memory leak detection method, apparatus, device, storage medium, and program product. According to pre-configured resource parameters, a first process triggers the software under test to run a set service multiple times. A second process records the single memory change value and / or cumulative memory change value after the set service runs. When it is determined that the memory leak detection conditions are met, the second process uses the single memory change value and / or cumulative memory change value after the set service runs to determine whether the software under test has a memory leak. Because the first process controls the software under test to execute the service multiple times, and the second process records the memory changes after the service execution, the existence of a memory leak is determined based on the memory changes. This automated method of testing for memory leaks reduces the complexity of the detection operation and improves detection efficiency.

[0056] Based on the above embodiments, this application further optimizes the memory leak detection method. The memory leak detection method provided in this application mainly utilizes three processes to execute the memory leak detection method: a first process, a second process, and a third process. The first process is mainly used to control the multiple execution of a set service. The second process is mainly used to record memory changes after each execution of the set service and determine whether the software under test has a memory leak based on the memory changes. The third process is mainly used to monitor whether the system's built-in memory detection mechanism is triggered.

[0057] In this embodiment, three flag bits are pre-configured: a first flag bit o_m, a second flag bit s_m, and a third flag bit c_m. Each flag bit has two states: a first state and a second state. The first state and the second state are different states. In this embodiment, the first state is 0 and the second state is 1. In practical applications, the first state and the second state can also be represented in other ways, which are not specifically limited in this embodiment.

[0058] The first flag, o_m, indicates whether the memory is insufficient. O_m = 0 indicates no memory shortage, while o_m = 1 indicates a memory shortage. The first flag o_m is initially 0. The second flag, s_m, controls the start and stop of the first process. S_m = 0 indicates the first process is stopped, meeting the start condition; s_m = 1 indicates the first process is running, meeting the stop condition. The second flag s_m is initially 0. The third flag, c_m, controls the start and stop of the second process. C_m = 0 indicates the second process is stopped, meeting the start condition; c_m = 1 indicates the third process is running, meeting the stop condition. The third flag c_m is initially 1.

[0059] In this embodiment, the interaction relationship between the three processes is first explained.

[0060] S201. When the third flag is detected to be in the second state, start the second process.

[0061] When the third flag c_m is detected to be in the second state, the second process is started. This can include: when the third flag c_m is detected to be in the second state, the second flag s_m is in the first state, and the first flag o_m is in the first state, the second process is started.

[0062] In one possible implementation, during the initialization of the memory leak detection method, the third flag c_m is initialized to the second state, the second flag s_m is initialized to the first state, and the first flag o_m is initialized to the first state.

[0063] In another possible implementation, after the first process controls the operation of the software under test and sets the business to end, the first process sets the third flag c_m to the second state and the second flag s_m to the first state. The third process does not detect that the memory killing mechanism is triggered, and the first flag o_m remains unchanged in the first state.

[0064] S202. Use the second process to record the single memory change value and / or cumulative memory change value after the business operation ends, and use the second process to set the third flag c_m to the first state and the second flag s_m to the second state.

[0065] In this embodiment, after starting the second process, the current available memory value is obtained, and it is determined whether the memory leak calculation task is being started for the first time. If it is, the second process uses the current available memory value as the initial memory value and records it. After the second process finishes recording, it sets the third flag c_m to the first state, the second flag s_m to the second state, and keeps the first flag o_m unchanged. At this point, the first process is ready to start.

[0066] If this is not the first time the memory leak calculation task has been initiated, the second process records the single memory change value and the cumulative memory change value after the set business operation ends. Based on the cumulative memory change value after the set business operation ends, the second process determines whether the software under test has a memory leak. If a memory leak is found, the second process sets the third flag c_m to the first state, generates an alarm message, and exits the memory leak detection process. If no memory leak is found, the second process sets the third flag c_m to the first state, sets the second flag s_m to the second state, and keeps the first flag o_m unchanged. At this point, the first process is ready to start.

[0067] S203. If the second flag is detected to be in the second state, the first process is started, and the first process is used to control the software under test to run the set services.

[0068] If the second flag s_m is detected to be in the second state, the first flag o_m to be in the first state, and the third flag c_m to be in the first state, then the first process is started. According to the pre-configured resource parameters, the first process controls the software under test to run the set services.

[0069] S204. During the process of setting up business operations in the software under test, use a third process to monitor whether the memory killing mechanism is triggered.

[0070] When the first process triggers the set business operation of the software under test, a third process is started, and the third process is used to monitor whether the memory killing mechanism is triggered.

[0071] If the memory killing mechanism is not triggered when monitored by the third process, the first flag o_m remains in the first state. If the memory killing mechanism is triggered when monitored by the third process, the first flag o_m is changed from the first state to the second state.

[0072] S205. After the set business operation of the software under test is completed, determine whether the first flag bit is in the first state.

[0073] After the configured service operation of the software under test (SUBUT) is completed, the first flag bit o_m is read, and it is determined whether the first flag bit o_m is in the first state. If the first flag bit o_m is in the first state, it indicates that the memory was healthy during the configured service operation of the STBUT, and no memory shortage occurred. If the first flag bit o_m is in the second state, it indicates that the memory detection mechanism was triggered during the configured service operation of the STBUT, resulting in a memory shortage. Further determination is needed to determine whether a memory leak has occurred in the STBUT, i.e., execute S208.

[0074] S206. If the first flag is in the first state, then set the second flag to the first state, set the third flag to the second state, and return to execute S201.

[0075] If the first flag bit o_m is in the first state, it indicates that the memory is healthy and no memory shortage has occurred during the operation of the software under test. At this point, the startup conditions for the second process are met, so the second flag bit s_m is set to the first state, and the third flag bit c_m is set to the second state. Then, execution returns to step S201.

[0076] S207. If, during the process of setting up business operations in the software under test, the memory killing mechanism is triggered by monitoring the third process, then the first flag bit is changed from the first state to the second state.

[0077] If the memory killing mechanism is triggered by the third process monitoring, it indicates that the system memory is insufficient. The first flag bit o_m is changed from the first state to the second state to start the second process.

[0078] S208. If the first flag is detected to be in the second state, the second process uses the single memory change value and cumulative memory change value after the end of the set service operation to determine whether the software under test has a memory leak.

[0079] If the first flag bit o_m is detected to be in the second state, the second process uses the single memory change value and cumulative memory change value after the end of the set service operation to determine whether there is a memory leak in the software under test. If a memory leak exists, an alarm message is generated and the memory leak detection process is exited. If no memory leak exists, the first flag bit o_m is set to the first state.

[0080] The second process determines whether the software under test has a memory leak based on the single memory change value and cumulative memory change value after the completion of the set service operation. This includes: determining whether the single memory change value recorded after multiple completions of the set service operation shows an increasing trend; if the single memory change value recorded after multiple completions of the set service operation shows an increasing trend, the second process determines that the software under test has a memory leak. If the single memory change value recorded after multiple completions of the set service operation does not show an increasing trend, the second process determines whether the cumulative memory change value recorded after the completion of the set service operation is greater than a first set threshold; if the second process determines that the cumulative memory change value recorded after the completion of the set service operation is greater than the first set threshold, the second process determines that the software under test has a memory leak; if the second process determines that the cumulative memory change value recorded after the completion of the set service operation is less than or equal to the first set threshold, the second process determines that the software under test does not have a memory leak.

[0081] In this embodiment, three flags are used as switches to start and stop three processes: memory leak calculation, business operation, and business monitoring. These three processes cooperate to assess the existence of memory leak risks. This reduces the complexity of testing operations and provides an effective testing method for simulating long-term business operation and accumulating memory leak monitoring, thereby improving product quality and accuracy.

[0082] Based on the above embodiments, this application optimizes the process of the second process recording memory changes. For example... Figure 3 As shown, the process of the second process recording memory changes includes S301-S304.

[0083] S301. When the third flag bit is detected to be in the second state, start the second process.

[0084] In this embodiment, a process configuration structure is pre-created to record the memory changes after each run of a specified service. The process configuration structure includes four variables: the first variable, `nem_dict.o_m`, records the available memory after the first run of the specified service; the second variable, `nem_dict.n_m`, records the available memory after the nth run of the specified service; the third variable, `nem_dict.add_m`, records the cumulative memory change after each run of the specified service; and the fourth variable, `curve`, is a list that records the word memory change after each run of the specified service, with a default value of 0. The `curve` list is empty by default.

[0085] Specifically, starting the second process when the third flag c_m is detected to be in the second state can include: starting the second process when the third flag c_m is detected to be in the second state, the second flag s_m is in the first state, and the first flag o_m is in the first state.

[0086] In one possible implementation, during the initialization of the memory leak detection method, the third flag c_m is initialized to the second state, the second flag s_m is initialized to the first state, and the first flag o_m is initialized to the first state.

[0087] In another possible implementation, after the first process controls the operation of the software under test and sets the business to end, the first process sets the third flag c_m to the second state and the second flag s_m to the first state. If the third process does not detect that the memory killing mechanism has been triggered, the first flag o_m remains unchanged in the first state.

[0088] S302. Use the second process to obtain the available memory value.

[0089] Memory availability typically refers to the amount of physical memory in a storage system that can be immediately used by programs or processes. Memory availability represents the amount of currently unoccupied free memory in the storage system that can be directly allocated to new tasks, as well as the total number of memory pages that have been marked as reclaimable.

[0090] Specifically, when the third flag c_m is detected to be in the second state, the second flag s_m is in the first state and the first flag o_m is in the first state, and the current available memory value in the storage system is obtained.

[0091] Furthermore, the current available memory value, MemAvailable, is obtained. Due to differences in operating system versions, the unit of memory used by each system is uncertain. To ensure the accuracy of memory change detection, the queried available memory unit is converted to bits and stored as the variable ma.

[0092] S303. Use the second process to determine whether this is the first time the memory leak calculation task has been executed.

[0093] In one possible implementation, the second process is used to determine whether it is the first execution of the memory leak calculation task, including: using the second process to determine that the initial memory value variable is a first set value; and using the second process to determine that the initial memory value variable is not the first set value, then determining that it is not the first execution of the memory leak calculation task.

[0094] The initial memory value variable refers to the first variable, `nem_dict.o_m`, in the procedure configuration structure. It records the available memory value before the set business runs. The initial value can be 0.

[0095] The second process checks if the memory initialization variable `nem_dict.o_m` is 0. If `nem_dict.o_m` is 0, it indicates that the second process has not recorded the memory initialization value, thus confirming that this is the first execution of the memory leak calculation task. If `nem_dict.o_m` is 0, it indicates that the second process has previously recorded the memory initialization value, thus confirming that this is not the first execution of the memory leak calculation task.

[0096] The second process is used to determine the initial execution of the memory leak calculation task. At this point, the initial memory value variable nem_dict.o_m needs to be recorded as ma. The intermediate value variable is also recorded as ma to facilitate subsequent calculations of memory changes.

[0097] When performing the memory leak calculation task for the first time, the initial memory value variable `nem_dict.o_m` needs to be recorded as `ma`. At this time, the intermediate value variable is also recorded as `ma`. Since this is the first execution of the memory leak calculation task and the business logic has not yet started, it is not necessary to determine whether there is a memory leak risk. After recording the obtained available memory values, the second process sets the third flag `c_m` to 0 and the second flag `s_m` to 1, indicating that the execution of the second process is paused and the first process is ready to execute.

[0098] S304. Utilize the second process to perform the memory leak calculation task on a non-first basis, and obtain the single memory change value after the current run of the set service ends by the difference between the memory available value after the current run of the set service ends and the memory available value after the previous run of the set service ends.

[0099] The second process checks whether the memory initialization variable nem_dict.o_m is 0. If the memory initialization variable nem_dict.o_m is 0, it indicates that the second process has recorded the memory initialization value before, which means that at least one configuration operation has been completed. Therefore, it is determined that this is not the first time the memory leak calculation task has been executed.

[0100] After querying the current available memory value, calculate the single-time memory change value diff. The single-time memory change value diff is equal to the difference between the available memory value ma after the current run of the specified service and the available memory value mem_dict[n_m] after the previous run of the specified service. Then update the intermediate memory value mem_dict[n_m] = ma.

[0101] Furthermore, the single memory change value diff is stored in a list mem_dict[Curve].append(diff).

[0102] S305. Add the cumulative memory change value after the previous run of the set service ends to the single memory change value after the current run of the set service ends, to obtain the cumulative memory change value after the current run of the set service ends.

[0103] Furthermore, update the cumulative memory change value. Specifically, the cumulative memory change value is the sum of the single memory change value (diff) after the current run of the set service ends and the cumulative memory change value (mem_dict[add_m]) after the previous run of the set service ends.

[0104] Then, it checks whether the cumulative memory change after the current run of the set service has exceeded the first set threshold. If it has not exceeded the first set threshold, the second process sets the third flag c_m to 0 and the second flag s_m to 1, indicating that the execution of the second process is paused and the first process has the conditions to execute. If it exceeds the first set threshold, it is determined that there is a risk of memory leak, the second process sets the third flag c_m to 0, generates an alarm log, and exits.

[0105] In another possible implementation, if the first flag bit o_m is detected to be 1, or the third flag bit c_m and the second flag bit s_m are both 0, then the second process uses the single memory change value and the cumulative memory change value after the end of the set service operation to determine whether there is a memory leak in the software under test. If a memory leak exists, an alarm message is generated and the memory leak detection process is exited. If no memory leak exists, the first flag bit o_m is set to 0.

[0106] If the first flag bit o_m is 1, it indicates a potential risk of insufficient memory. If the third flag bit c_m and the second flag bit s_m are both 0, it indicates that the memory leak detection method needs to be terminated for some reason.

[0107] The second process determines whether the software under test has a memory leak based on the single memory change value and cumulative memory change value after the completion of the set service operation. This includes: determining whether the single memory change value recorded after multiple completions of the set service operation shows an increasing trend; if the single memory change value recorded after multiple completions of the set service operation shows an increasing trend, the second process determines that the software under test has a memory leak. If the single memory change value recorded after multiple completions of the set service operation does not show an increasing trend, the second process determines whether the cumulative memory change value recorded after the completion of the set service operation is greater than a first set threshold; if the second process determines that the cumulative memory change value recorded after the completion of the set service operation is greater than the first set threshold, the second process determines that the software under test has a memory leak; if the second process determines that the cumulative memory change value recorded after the completion of the set service operation is less than or equal to the first set threshold, the second process determines that the software under test does not have a memory leak.

[0108] In this embodiment of the application, a specific process is provided for calculating the memory change value after each set service operation ends using a second process, so as to further improve the accuracy of memory leakage judgment.

[0109] Based on the above embodiments, this application optimizes the method for the first process to trigger the software under test to execute a set service. For example... Figure 4 As shown, the process by which the first process triggers the software under test to execute the set business includes S401-S404.

[0110] S401. Determine whether the number of times the software under test runs the set service has reached the pre-configured number of times the set service has been run. If not, determine whether the second flag bit is in the second state.

[0111] In one specific implementation, a resource configuration structure is created. The resource configuration structure is mainly used to pre-configure the resource parameters required by the software under test to perform the set tasks.

[0112] The resource configuration structure includes four variables: the first variable, `Selist.shell_N`, pre-configures the full path name of the script for the specified business function of the software under test; the second variable, `Selist.cnum`, pre-configures the number of creation and deletion operations required for the specified business function; the third variable, `Selist.pnum`, pre-configures the number of threads for concurrent execution of the specified business function; and the fourth variable, `Selist.count`, pre-configures the number of times the script for the specified business function will be executed.

[0113] Specifically, the fourth variable, Selist.count, records the remaining execution count of the set service. Checking Selist.count and determining if it's greater than 0, if it is not, indicates that the set service iterations have reached the pre-configured number of runs, and the first process exits directly. If Selist.count is greater than 0, it indicates that the set service iterations have not reached the pre-configured number of runs, and the set service continues to execute.

[0114] The process checks if the second flag bit s_m is 1, and if the first flag bit o_m and the third flag bit c_m are both 0. If not, it checks if the first flag bit o_m is 1, or if the third flag bit c_m and the second flag bit s_m are both 0. If the first flag bit o_m is 1, or if the third flag bit c_m and the second flag bit s_m are both 0, it uses the single memory change value and cumulative memory change value after the set business operation ends, based on the second process, to determine if there is a memory leak in the software under test. If a memory leak is found, an alarm message is generated, and the memory leak detection process exits. If no memory leak is found, the first flag bit is set to 0.

[0115] If the second flag bit s_m is 1, and the first flag bit o_m and the third flag bit c_m are both 0, then the software under test will be controlled to run the set services.

[0116] S402. If the second flag is in the second state, then the first process is used to create a set number of business threads, and each business thread is assigned a thread identifier. The set number is the same as the pre-configured number of concurrent executions.

[0117] If the second flag bit s_m is 1, and the first flag bit o_m and the third flag bit c_m are both 0, then the software under test will be controlled to run the set services.

[0118] The first process creates an equal number of business threads (sub_load_shell) according to the requirements of the resource configuration structure Selist.pnum, and simultaneously starts the third process.

[0119] S403. The first process calls the script of the set business based on the script path of the set business, and passes the thread identifier of each business thread to the script of the set business, so that the script of the set business executes the business thread corresponding to each thread identifier concurrently.

[0120] After all threads have finished executing, check if the first flag bit o_m is 0. If the first flag bit o_m is 0, it means that no OOM was triggered during the execution of the set business, and the state is healthy. Set the second flag bit s_m to 1 and the third flag bit c_m to 0. Decrement the Selist.Count iteration count by one, indicating that the second process has finished running and the conditions for the second process to execute are met. After waiting for 30 seconds, execute the process provided in this embodiment of the application to trigger the software under test to execute the set business again.

[0121] Furthermore, the scripts for defining business operations are used to concurrently execute the business threads corresponding to each thread identifier, including: creating a storage pool using the scripts for defining business operations; creating multiple volumes in the storage pool using the scripts for defining business operations, and performing asynchronous write operations on the multiple volumes, wherein the number of volumes created is greater than the number of volumes pre-configured; and deleting volumes created in the storage pool using the scripts for defining business operations, wherein the number of volumes deleted is greater than the number of volumes pre-configured.

[0122] In one possible implementation, a script defining the business logic is used to create multiple volumes in the storage pool and perform asynchronous write operations on these volumes. This includes: using the script defining the business logic to determine if the number of created volumes is less than the pre-configured number of volumes; if the script defining the business logic determines that the number of created volumes is less than the pre-configured number of volumes, then creating a new volume in the storage pool and performing asynchronous write operations on the newly created volume; incrementing the number of created volumes by a third pre-defined value to obtain a new number of created volumes, and then returning to the step of using the script defining the business logic to determine if the number of created volumes is less than the pre-configured number of volumes.

[0123] In one possible implementation, deleting created volumes in the storage pool using a script configured for a specific business function includes: determining whether the number of created volumes is less than the pre-configured number of volumes; determining whether the number of created volumes is greater than or equal to the pre-configured number of volumes, then deleting one volume in the storage pool and counting the number of deleted volumes; and determining whether the number of deleted volumes is greater than or equal to the pre-configured number of volumes, then deleting the storage pool.

[0124] The most common business logic involves creating and deleting pooled volumes. Pooled volumes come in many combinations, including regular pooled volumes, thinned pooled volumes, self-thinned volumes, local replication, and remote replication, etc., but the logic is largely the same. In this embodiment, a basic pooled volume is used to create a storage pool and a disk array. A counter variable `num` is defined as 0. If the counter variable `num` is less than the pre-configured number of volumes `cnum` (typically greater than 10,000), a device volume `vidisk_tid_num` is created, and the counter variable `num` is incremented by 1. The asynchronous driver `vdbench` writes 100MB of data to the raw device volume `vidisk_tid_num`. This operation is repeated until the counter variable `num` is greater than or equal to the pre-configured number of volumes `cnum`. The counter variable `num` is then reset to the current value minus the pre-configured number of volumes `cnum`. The device volume `vidisk_tid_num` is deleted, and the counter variable `num` is incremented by 1. The system then checks if the counter variable `num` is less than the pre-configured number of volumes `cnum`. If not, the deletion loop continues. If the count is less than the pre-configured number of volumes `cnum`, the loop ends, the storage pool and disk array are deleted, and the script exits.

[0125] Furthermore, because volumes are created serially and data is written asynchronously via I / O, as the number of volumes increases, although the amount of I / O writes is relatively small, the execution speed will also be slow. Even after creating 10,000 volumes, the I / O for the last few hundred volumes may still be incomplete. Therefore, it is necessary to start deleting from the first created volume to ensure that all services stop.

[0126] In this embodiment of the application, memory pressure is increased by merging asynchronous I / O actions to further improve the accuracy of memory leak detection.

[0127] Based on the above embodiments, the workflow of the third process in this application embodiment has been further optimized, such as... Figure 5 As shown, the process for detecting insufficient memory mainly includes S501-S504.

[0128] During the execution of the script for the set business, a third-party process is used to monitor whether the memory killing mechanism is triggered.

[0129] S501. Use a third process to obtain at least one thread identifier corresponding to the set business.

[0130] Specifically, the second process transmits each thread identifier to the third process, and the third process obtains the thread identifiers transmitted by the second process.

[0131] S502. Use a third process to query whether the set character exists in the log corresponding to at least one thread identifier.

[0132] After the third process obtains the thread identifiers, it checks whether the dmsg logs of each thread identifier contain characters such as 'kill|oom|out of memory'.

[0133] S503. Use a third process to query the setting character and store the setting character in the setting variable.

[0134] If the dmsg logs of each thread identifier contain characters such as 'kill|oom|out of memory', then store these characters in the dmsg logs of each thread identifier into a designated variable dm.

[0135] S504. If the specified character is detected in the specified variable, the memory killing mechanism is triggered.

[0136] If the variable dm is not empty, it means that the system has started the memory killing mechanism, set the first flag o_m to 1, kill the business process according to the PID and then exit.

[0137] If the content of the variable dm is not empty, check if the second flag s_m is equal to 1. If it is, it means that the business process has not been terminated. Wait 5 seconds and continue monitoring. If the second flag s_m is equal to 0, it means that the business process has been completed and the monitoring process ends.

[0138] In this embodiment of the application, the set characters in the third process monitoring log are used to quickly determine whether the memory killing mechanism has been triggered.

[0139] Figure 6 This is a schematic diagram of the structure of a memory leak detection device according to an embodiment of this application, such as... Figure 6 As shown, the memory leak detection device 60 provided in this application embodiment mainly includes: a service operation module 61, used to control the software under test to run a set service multiple times according to pre-configured resource parameters using a first process; a memory change value recording module 62, used to record the single memory change value and / or cumulative memory change value after the set service runs are completed using a second process; and a memory leak judgment module 63, used to determine whether the software under test has a memory leak when it is determined that the memory leak detection conditions are met, using the second process based on the single memory change value and / or cumulative memory change value after the set service runs are completed.

[0140] In one possible implementation, the memory leak detection module 63 is specifically used to determine whether the cumulative memory change value recorded after the end of the set service operation is greater than a first set threshold when the memory leak detection conditions are met; if the second process determines that the cumulative memory change value recorded after the end of the set service operation is greater than the first set threshold, then the software under test is determined to have a memory leak; if the second process determines that the cumulative memory change value recorded after the end of the set service operation is less than or equal to the first set threshold, then the software under test is determined not to have a memory leak.

[0141] In one possible implementation, the memory leak detection module 63 is specifically used to determine whether the single memory change value recorded after multiple set business operations are completed is increasing when the memory leak detection conditions are met; if the second process determines that the single memory change value recorded after multiple set business operations are completed is increasing, then it is determined that the software under test has a memory leak.

[0142] In one possible implementation, the memory leak detection module 63 is used to determine when the memory leak detection conditions are met, specifically when the execution of a set service is detected to have ended; and / or when an insufficient memory state is detected.

[0143] In one possible implementation, the memory leak detection module 63 is used to detect an insufficient memory state. Specifically, during the process of setting up business in the software under test, it uses a third process to monitor whether the memory killing mechanism is triggered. If the memory killing mechanism is detected to be triggered by the third process, the first flag is changed from the first state to the second state. If the first flag is detected to be in the second state, an insufficient memory state is detected.

[0144] In one possible implementation, the memory leak detection module 63 is used to monitor whether the memory killing mechanism is triggered by a third process. Specifically, it uses the third process to obtain at least one thread identifier corresponding to the set business; it uses the third process to query whether the set character exists in the log corresponding to the at least one thread identifier; the memory leak detection module 63 is used to monitor whether the memory killing mechanism is triggered by the third process and change the first flag from the first state to the second state. Specifically, it uses the third process to query the set character and store the set character in the set variable; if the set character is detected in the set variable, it changes the first flag from the first state to the second state.

[0145] In one possible implementation, the memory leak detection module 63 is used to detect when the set service has finished running. Specifically, it uses the first process to determine that all threads of the set service have finished executing, and then modifies the second flag bit from the second state to the first state; if the second flag bit is detected to be in the first state, the set service has finished running.

[0146] In one possible implementation, the memory change value recording module 62 is specifically used to start a second process when the third flag bit is detected to be in the second state; and to use the second process to record the single memory change value and / or cumulative memory change value after the end of the set business operation.

[0147] In one possible implementation, the memory change value recording module 62 is specifically used to obtain the available memory value using a second process; to determine whether it is the first time the memory leak calculation task is executed using the second process; to determine whether it is not the first time the memory leak calculation task is executed using the second process; to obtain the single memory change value after the current run of the set service ends by the difference between the available memory value after the previous run of the set service ends and the available memory value after the previous run of the set service ends; and to add the cumulative memory change value after the previous run of the set service ends and the single memory change value after the current run of the set service ends to obtain the cumulative memory change value after the current run of the set service ends.

[0148] In one possible implementation, the memory change value recording module 62 is used to determine whether the set business is the first execution of the memory leak calculation task by using the second process. Specifically, it is used to determine whether the initial memory value variable is the first set value by using the second process; if the second process determines that the initial memory value variable is not the first set value, then it is determined that it is not the first execution of the memory leak calculation task.

[0149] In one possible implementation, the pre-configured resource parameters include the pre-configured number of times the set service is run; the service operation module 61 is specifically used to determine whether the number of times the software under test runs the set service has reached the pre-configured number of times the set service is run, and if not, to determine whether the second flag bit is in the second state; if the second flag bit is in the second state, the first process is used to control the software under test to run the set service.

[0150] In one possible implementation, the pre-configured resource parameters include the pre-configured number of concurrent executions and the script path for the set business; the business execution module 61 is specifically used to create a set number of business threads using the first process, and assign thread identifiers to each business thread, with the set number being the same as the pre-configured number of concurrent executions; the first process calls the script for the set business based on the script path for the set business, and passes the thread identifiers of each business thread to the script for the set business, so that the script for the set business executes the business threads corresponding to each thread identifier concurrently.

[0151] In one possible implementation, the process of concurrently executing the business script corresponding to each thread identifier includes: creating a storage pool using the business script; creating multiple volumes in the storage pool using the business script and performing asynchronous write operations on the multiple volumes, wherein the number of created volumes is greater than the pre-configured number of volumes; and deleting the created volumes in the storage pool using the business script, wherein the number of deleted volumes is greater than the pre-configured number of volumes.

[0152] The memory leak detection device provided in this application embodiment can execute the memory leak detection method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0153] Figure 7 This is a schematic diagram of the structure of an electronic device provided in this embodiment. The electronic device may include a memory leak detection device, such as... Figure 7 As shown, the electronic device 700 includes a processor 710, a memory 720, an input device 730, and an output device 740; the number of processors 710 in the electronic device can be one or more. Figure 7 Taking a processor 710 as an example; the processor 710, memory 720, input device 730, and output device 740 in the electronic device can be connected via a bus or other means. Figure 7 Taking the example of a connection between China and Israel via a bus.

[0154] The memory 720, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the memory leak detection method in this embodiment of the invention. The processor 710 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory 720, thereby implementing the memory leak detection method provided in this embodiment of the invention.

[0155] The memory 720 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function; the data storage area may store data created based on terminal usage. Furthermore, the memory 720 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 720 may further include memory remotely located relative to the processor 710, which can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0156] Input device 730 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of electronic devices, and may include a keyboard, mouse, etc. Output device 740 may include display devices such as a display screen.

[0157] This embodiment also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to implement the memory leak detection method provided in this embodiment of the invention.

[0158] Of course, the computer-executable instructions provided in the embodiments of the present invention are not limited to the method operations described above, but can also perform related operations in the memory leak detection method provided in any embodiment of the present invention.

[0159] Based on the above description of the implementation methods, those skilled in the art can clearly understand that the present invention can be implemented using software and necessary general-purpose hardware, and of course, it can also be implemented using hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0160] It is worth noting that in the above embodiments of the memory leak detection device, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of the present invention.

[0161] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0162] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for detecting memory leaks, characterized in that, include: According to the pre-configured resource parameters, the software under test is controlled by the first process to run the set service multiple times. The pre-configured resource parameters include the pre-configured number of times the set service will be run, the pre-configured number of concurrent executions, the script path of the set service, and the number of volumes that the set service needs to execute. The second process records the single memory change value and / or cumulative memory change value after the set service operation ends; wherein, the single memory change value is the difference between the available memory value after the current set service operation ends and the available memory value after the previous set service operation ends; the cumulative memory change value is the difference between the available memory value after the current set service operation ends and the available memory value before the set service operation begins; the process of using the second process to record the single memory change value and / or cumulative memory change value after the set service operation ends includes starting the second process when the third flag bit is detected to be in the second state; and using the second process to record the single memory change value and / or cumulative memory change value after the set service operation ends. During the operation of the software under test and the set service, a third process is used to monitor whether the memory killing mechanism is triggered. The monitoring of whether the memory killing mechanism is triggered by the third process includes: using the third process to obtain at least one thread identifier corresponding to the set service; using the third process to query whether a set character exists in the log corresponding to at least one of the thread identifiers; using the third process to query the set character and store the set character in a set variable; if the set character is detected in the set variable, the first flag is changed from a first state to a second state. If the first flag is detected to be in the second state, then an insufficient memory state is detected, and it is determined that the memory leak condition is met; When the memory leak detection conditions are met, the second process uses the single memory change value and / or cumulative memory change value after the end of the set service operation to determine whether the software under test has a memory leak.

2. The memory leak detection method according to claim 1, characterized in that, When the memory leak detection conditions are met, the second process uses the cumulative memory change value after the end of the set service operation to determine whether the software under test has a memory leak, including: When it is determined that the memory leak detection conditions are met, it is judged whether the cumulative memory change value recorded after the set service runs is greater than the first set threshold. If the cumulative memory change value recorded after the end of the set service operation is determined by the second process to be greater than the first set threshold, then it is determined that the software under test has a memory leak. If the cumulative memory change value recorded after the end of the set service operation is determined by the second process to be less than or equal to the first set threshold, then it is determined that the software under test does not have a memory leak.

3. The memory leak detection method according to claim 2, characterized in that, When the memory leak detection conditions are met, the second process uses a single memory change value after the set service execution ends to determine whether the software under test has a memory leak, including: When it is determined that the memory leak detection conditions are met, it is judged whether the single memory change value recorded after multiple executions of the set service shows an increasing trend. If the second process determines that the single memory change value recorded after multiple runs of the set service is in an increasing trend, then it is determined that the software under test has a memory leak.

4. The memory leak detection method according to any one of claims 1-3, characterized in that, The determination that the memory leak detection conditions are met includes: The system detects that the set service has ended; and / or detects that there is insufficient memory.

5. The memory leak detection method according to claim 4, characterized in that, The detection that the set service has ended includes: Once the first process determines that all threads of the defined service have completed execution, the second flag is changed from the second state to the first state. If the second identifier is detected to be in the first state, the operation of the set service is detected to have ended.

6. The memory leak detection method according to claim 1, characterized in that, The process of using a second process to record single memory change values ​​and / or cumulative memory change values ​​after the completion of the set service operation includes: The second process is used to obtain the available memory value; The second process is used to determine whether this is the first time the memory leak calculation task has been executed. Using the second process to determine whether it is the first time to execute the memory leak calculation task, the difference between the available memory value after the current run of the set service and the available memory value after the previous run of the set service is used to obtain the single memory change value after the current run of the set service. The cumulative memory change value after the previous run of the specified service is completed is added to the single memory change value after the current run of the specified service is completed, to obtain the cumulative memory change value after the current run of the specified service.

7. The memory leak detection method according to claim 6, characterized in that, The step of using the second process to determine whether the set service is the first execution of the memory leak calculation task includes: The second process is used to determine that the initial memory value variable is the first set value; If the second process determines that the initial memory value variable is not the first set value, then it is determined that this is not the first time the memory leak calculation task has been executed.

8. The memory leak detection method according to claim 1, characterized in that, The step of controlling the software under test to run a set service multiple times according to pre-configured resource parameters using a first process includes: Determine whether the number of times the software under test runs the set service has reached the number of times the set service has been run in the pre-configured way. If not, determine whether the second flag is in the second state. If the second flag is in the second state, then the first process is used to control the software under test to run the set services.

9. The memory leak detection method according to claim 8, characterized in that, The first process controls the software under test to run specified services, including: A set number of business threads are created using the first process, and a thread identifier is assigned to each of the business threads. The set number is the same as the pre-configured number of concurrent executions. The first process invokes the script of the defined service based on the script path of the defined service, and passes the thread identifiers of each service thread to the script of the defined service, so that the script of the defined service executes the service threads corresponding to each thread identifier concurrently.

10. The memory leak detection method according to claim 9, characterized in that, The process of concurrently executing the script for the defined business function on the business threads corresponding to each of the thread identifiers includes: Create a storage pool using the script for the specified business; The script for the specified service creates multiple volumes in the storage pool and performs asynchronous write operations on the multiple volumes, wherein the number of volumes created is greater than the number of volumes pre-configured; The script for the specified service is used to delete the volumes already created in the storage pool, wherein the number of deleted volumes is greater than the pre-configured number of volumes.

11. A memory leak detection device, characterized in that, The device includes: The business operation module is used to control the software under test to run a set business multiple times according to the pre-configured resource parameters. The pre-configured resource parameters include the pre-configured number of times the set business will run, the pre-configured number of concurrent executions, the script path of the set business, and the number of volumes that the set business needs to execute. The memory change value recording module is used to detect that the third flag bit is in the second state, indicating that the third process is in a running state. If the conditions for stopping the second process are met, the second process is started. The second process records the single memory change value and / or cumulative memory change value after the set service runs are completed. The single memory change value is the difference between the available memory value after the current set service runs are completed and the available memory value after the previous set service runs are completed. The cumulative memory change value is the difference between the available memory value after the current set service runs are completed and the available memory value before the set service runs are executed. The memory leak detection module is used to determine whether the software under test has a memory leak when the memory leak detection conditions are met, by using a second process based on the single memory change value and / or cumulative memory change value after the end of the set business operation. The memory leak detection module is used to detect an insufficient memory state. Specifically, during the operation of a set service in the software under test, it uses a third process to obtain at least one thread identifier corresponding to the set service; uses the third process to query whether a set character exists in the log corresponding to at least one of the thread identifiers; uses the third process to query the set character and stores the set character in a set variable; if the set character is detected in the set variable, it changes a first flag from a first state to a second state; if the first flag is detected to be in the second state, an insufficient memory state is detected, and the memory leak condition is determined to be met.

12. An electronic device, characterized in that, The device includes: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the memory leak detection method as described in any one of claims 1-10.

13. A storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the memory leak detection method as described in any one of claims 1-10.

14. A computer program product comprising a computer program or instructions that, when executed by a processor, implement the memory leak detection method as described in any one of claims 1-10.

Images