Load-aware software suspend processing method, apparatus, device, and medium

Abstract

This invention provides a load-aware software suspension handling method, apparatus, device, and medium. The load-aware software suspension handling method includes: using a hierarchical tracing method to detect the target application at the application layer and system layer, obtaining application layer tracing results and system layer tracing results; using inspection rules and triggering early warning methods to determine the software reliability check results based on the application layer tracing results and system layer tracing results; determining the reliability problem type based on the application reliability check results, wherein the reliability problem type includes LHB (Low Load Bus) and heavy load tasks; and generating configuration items based on the reliability problem type, and optimizing the reliability of the target software through the configuration items. The beneficial effects of this invention are: achieving high reliability problem detection with low overhead, thereby improving the reliability of the application.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a load-aware software suspension processing method, apparatus, device, and medium. Background Technology

[0002] Infrastructure software (such as HDFS) forms the foundation for building large-scale systems because it needs to provide low-level, stable, long-term services to higher-level applications. In this context, the reliability of such software plays a crucial role in the normal operation of the entire system. However, when software is running, it often faces complex and variable workloads. At this time, the software may, due to specific loads, enter an abnormally long running state (far exceeding normal operating time), or even become unresponsive to other requests, severely impacting the reliability of the software system. Configuration, as an important means of controlling software behavior and adjusting resource allocation, can help software adapt to different loads and avoid / fix potential software reliability problems. However, not all such unresponsiveness issues are caused by load; the underlying cause may also be a code defect (which can also be triggered by normal workloads) leading to software hang bugs. Such hang bugs can also cause upper-layer application tasks to fail, and may even further damage the entire system.

[0003] The existing software for detecting hangs issues mainly uses:

[0004] (1) Analyzing the software state and discovering potential execution exceptions using runtime log information is highly dependent on the quality of the software's own logs;

[0005] (2) Static program analysis and techniques based on SAT or SMT to prove the termination of code are limited by the complexity of the program.

[0006] When a software system is running an "unusually long-running" task or even stuck in an "unresponsive" state, users often find it difficult to decide whether to kill the task, because they don't know whether the task is currently in an indefinite suspension or is still in progress. Killing a running task (even if it's slow) can affect service stability and lead to the huge overhead of restarting the software service, while waiting for it to be in an indefinite suspension can ultimately seriously damage the system's reliability and performance. Summary of the Invention

[0007] The main objective of this invention is to provide a load-aware software suspension handling method, apparatus, device, and medium, which improves the reliability of applications during long-term operation.

[0008] One aspect of the present invention provides a load-aware software suspension handling method, comprising:

[0009] A hierarchical tracking method is used to detect the target application at the application layer and system layer, and the tracking results at the application layer and system layer are obtained.

[0010] The software reliability check results are determined by using inspection rules and early warning methods on the application layer tracing results and the system layer tracing results;

[0011] The reliability problem type is determined based on the application reliability check results, where the reliability problem type includes LHB and heavy load tasks;

[0012] Based on the type of reliability problem, configuration items are generated, and the reliability of the target software is optimized using these configuration items.

[0013] According to the load-aware software suspension handling method, a hierarchical tracing method is used to detect the target application at the application layer and system layer, obtaining application layer tracing results and system layer tracing results, including:

[0014] Hardware tracing is used to obtain branch instruction records, the address distribution of branch instructions is determined based on the branch instruction records, and the application layer tracing result is determined based on the address distribution of branch instructions.

[0015] The eBPF tracing method is used to trace the events and system calls of the target application during runtime to obtain system-level tracing results. The task types of the events and system calls include file management, communication, memory management, I / O control, process management and synchronization control.

[0016] According to the load-aware software suspension handling method, the branch instruction record is obtained by hardware tracing, and the address distribution of the branch instructions is determined based on the branch instruction record, including:

[0017] Linux performance analysis tools are used to obtain branch instruction records. After filtering the branch instruction records for execution information of non-target applications, the mapping between the branch target address and the called method at runtime of the target application is obtained.

[0018] According to the load-aware software suspension handling method, the application reliability check results are determined by using check rules and triggering early warning methods on the application layer tracing results and the system layer tracing results, including:

[0019] The inspection rules include densely repetitive code execution, access to the same resource, and failure after a specific operation. Densely repetitive code execution determines the application behavior of the target application through the distribution of branch target addresses. Access to the same resource is recorded using a four-tuple, where the four-tuple includes the accessed resource, access operation, access unit, and access content. Failure after a specific operation is also recorded using a four-tuple, where the four-tuple includes the accessed resource, access operation, access unit, and error flag.

[0020] The method of triggering early warning uses a time window to detect repetitive behavior of each inspection rule, and obtains the application reliability inspection results.

[0021] According to the load-aware software hangup handling method, the method employs a time window to detect recurring behavior for each check rule, thereby obtaining application reliability check results, including:

[0022] Based on the time period and number of windows, when the inspection rule is dense and repetitive code execution, the distribution of branch target addresses within the preset number of windows is collected to determine the number of branches and branch percentage of different targets in each time window, thereby determining the LHB when the target application is executed;

[0023] When the check rule is to access the same resource or fail after a specific operation, the first time window is checked. If there is a duplicate access unit, the tracking record sequence of the preset number of time windows is repeated to obtain the LHB when the target application is executed. If there is no duplicate access unit, the start time of the time window is reset.

[0024] According to the load-aware software suspension handling method, configuration items are generated based on the reliability problem type, and the reliability of the target software is optimized using these configuration items, including:

[0025] When the reliability problem type is LHB, the location of the reliability problem is determined by checking the code, and the first configuration item is used to optimize LHB.

[0026] When the reliability problem type is a heavy-load task, the second configuration option is used to optimize the heavy-load task.

[0027] According to the load-aware software suspend handling method, the LHB is optimized using a first configuration item, including:

[0028] When LHB enters the loop, add check code to obtain the loop variable and the loop termination condition, and execute the LHB's loop termination process based on the loop variable and the loop termination condition.

[0029] Alternatively, the maximum number of retries and timeout for LHB can be added through the first configuration item.

[0030] Another aspect of the present invention provides a load-aware software suspension processing apparatus, comprising:

[0031] The first module is used to detect the target application at the application layer and system layer using a hierarchical tracking method, and to obtain the application layer tracking results and the system layer tracking results.

[0032] The second module is used to determine the software reliability check results by applying inspection rules and triggering early warning methods to the application layer tracing results and the system layer tracing results;

[0033] The third module is used to determine the type of reliability problem based on the application reliability check results, wherein the reliability problem types include LHB and heavy load tasks;

[0034] The fourth module is used to generate configuration items based on the reliability problem type, and to optimize the reliability of the target software through the configuration items.

[0035] Another aspect of the present invention provides an electronic device, including a processor and a memory;

[0036] The memory is used to store programs;

[0037] The processor executes the program to implement the method as described above.

[0038] This invention also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium and execute the computer instructions, causing the computer device to perform the methods described above.

[0039] The beneficial effects of this invention are as follows: It utilizes branch instruction target address tracing and lightweight system-level tracing to detect infinite loops that may cause system hangs. By tracing the CPU branch instruction target address, it monitors the execution of the application. Compared with traditional application-layer tracing, branch target tracing is hardware-supported, has relatively low overhead, and does not require any instrumentation in the source code. By analyzing the branch target traces and system call sequences over a continuous time period, it can accurately determine whether the application is in LHB or heavy-load tasks for a long time, and perform corresponding optimizations based on the application state, thereby improving the reliability of the application and achieving high reliability problem detection with low overhead. Attached Figure Description

[0040] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0041] Figure 1 This is a schematic flowchart of a load-aware software suspension processing method according to an embodiment of the present invention.

[0042] Figure 2 This is an example diagram of system call tracing records according to an embodiment of the present invention.

[0043] Figure 3 This is an example diagram illustrating repeated access to the same resource in an embodiment of the present invention.

[0044] Figure 4 This is an example diagram of "failure" at the same stage in an embodiment of the present invention.

[0045] Figure 5 This is the framework and flowchart of RwChecker according to an embodiment of the present invention.

[0046] Figure 6 This is a schematic diagram of a load-aware software suspension processing device according to an embodiment of the present invention. Detailed Implementation

[0047] The embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings. Throughout the description, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions. In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the purpose of illustrative purposes and have no specific meaning in themselves. Therefore, "module," "part," or "unit" can be used interchangeably. Terms such as "first," "second," etc., are used only to distinguish technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the sequential relationship of the indicated technical features. In the following description, the consecutive reference numerals for method steps are for ease of review and understanding. Adjusting the implementation order of steps, in conjunction with the overall technical solution of the present invention and the logical relationship between the various steps, will not affect the technical effect achieved by the technical solution of the present invention. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0048] RwChecker, a load-aware software suspension handling tool according to embodiments of the present invention.

[0049] refer to Figure 1 , Figure 1 This is a schematic flowchart of a load-aware software suspension handling method according to an embodiment of the present invention, which includes, but is not limited to, steps S100 to S400:

[0050] S100 employs a hierarchical tracking method to detect the target application at the application layer and system layer, obtaining application layer tracking results and system layer tracking results.

[0051] In some embodiments, hardware tracing is used to obtain branch instruction records, the address distribution of branch instructions is determined based on the branch instruction records, and the application layer tracing result is determined based on the address distribution of branch instructions.

[0052] In some embodiments, the eBPF tracing method is used to obtain system-level tracing results for events and system calls during the runtime of the target application. The task types of the events and system calls include file management, communication, memory management, I / O control, process management, and synchronization control.

[0053] For application-layer traces, RwChecker collects the LBR (Least Recently Used Branch) records through hardware tracing and analyzes the address distribution of branch instructions to visualize application behavior. For infinite loops of code blocks, branch target addresses should all point to the same one or more addresses. Branch target tracing has low time overhead and does not require code instrumentation. RwChecker filters out branch records within the kernel and only collects execution information of the application.

[0054] For example, RwChecker uses Linux_perf_events for tracing and reporting, and uses perfmap-agent to generate a mapping between branch target addresses and system call trace example methods at runtime.

[0055] In some embodiments, reference Figure 2 This is an example diagram of a system call tracing record. RwChecker uses eBPF tracing technology to track specific system calls. RwChecker focuses on six main task types: file management, communication, memory management, I / O control, process management, and synchronization control. These are common tasks in which applications interact with the system and access corresponding system resources. Each task instance consists of its sub-operations (and their combinations). For example, a file management task instance might first create a non-existent file and then perform several read and write operations. Different tasks have different combinations and sequences of sub-operations. For each task instance record, it contains a unique resource ID to record the accessed resource. RwChecker also records specific parameters in the system call to compare different task instances; the resource ID and parameters can be obtained in each system call.

[0056] S200 uses inspection rules and early warning methods to determine the software reliability inspection results based on the application layer tracing results and system layer tracing results.

[0057] In some embodiments, determining the presence of an LHB by means of:

[0058] Detection is performed using inspection rules to identify potential repetitive behavior rules. These rules include densely repeated code execution, access to the same resource, and failure after a specific operation. Densely repeated code execution is determined by analyzing the distribution of branch target addresses to identify the application's behavior. Access to the same resource is recorded using a four-tuple, which includes the accessed resource, access operation, access unit, and access content. Failure after a specific operation is recorded using a four-tuple, which includes the accessed resource, access operation, access unit, and error flag.

[0059] The method of triggering early warning uses a time window to detect repetitive behavior of each inspection rule, and obtains the application reliability inspection results.

[0060] In some embodiments, for intensive, repetitive code execution, based on branch target address tracing records, when the software gets stuck in an infinite loop, the same code block (function method) will be repeatedly executed without performing other functions. For example, in HBase-14621, in the loadWALsFromQueues method, a retrying infinite loop might cause the task to hang because erroneous logic updating v0 causes it to never equal v1. The code snippet is shown below:

[0061] 1 private Set <string>loadWALsFromQueues(){

[0062] 2-int v0=replicationQueues.getQueuesZNodeCversion();

[0063] 3for(int retry=0;;retry++){

[0064] 4+int v0=replicationQueues.getQueuesZNodeCversion();

[0065] 5... / / load wal from queue

[0066] 6int v1=replicationQueues.getQueuesZNodeCversion();

[0067] 7if(v0==v1)return wals;

[0068] 8}

[0069] 9}

[0070] In this scenario, the `loadWALsFromQueues` method will be executed repeatedly without calling other methods or returning to the calling method. To monitor and detect this type of code execution behavior, RwChecker records branch target addresses over specific time periods to show the execution status of different code blocks. Since the number of branch instructions is often very large, direct analysis on the branch stack is impractical. To address this, RwChecker uses the distribution of branch target addresses to indirectly characterize program execution behavior. In the example shown above, the `loadWALsFromQueues` method accounted for over 98% of the branch targets in the 5-second recording. RwChecker collects user-mode CPU branch instruction address targets within continuous time windows.

[0071] For accessing the same resource and failing after a specific operation, it is based on system call traces.

[0072] In some embodiments, where applications access the same resources very frequently during runtime, a flawed process may repeatedly access the exact same resource with identical content without accessing other different resources during execution. This means the task may get stuck in an abnormal resource interaction state. Take HBase-20865 as an example. Initially, the CreateTableProcedure fails to write a file to HDFS. At this point, part of the file has already been written successfully. During subsequent retries, the CREATE_TABLE_WRITE_FS_LAYOUT state checks the file's existence status each time. Because old files are not cleaned up, this check fails on every retry, triggering an infinite retry loop. The code snippet is shown below:

[0073] 1. Flow executeFromState()

[0074] 2switch(state){

[0075] 3case CREATE_TABLE_WRITE_FS_LAYOUT:

[0076] 4+DeleteTableProcedure.deleteFromFs(...);

[0077] 5newRegions=createFsLayout(); 6...

[0079] 7} 8

[0081] 9HRegionFileSystem createRegionOnFileSystem(){ 10...

[0083] 11Path regionDir=regionFs.getRegionDir();

[0084] 12if fs.exists(regionDir))

[0085] 13throw new IOException(”The specified region already

[0086] (exists on disk); 14...

[0088] 15}

[0089] refer to Figure 3 The diagram illustrates an example of repeated access to the same resource, a system call behavior exhibiting this abnormal resource interaction. In this scenario, CreateTableProcedure retrieves block file information from the metafile and checks the file's status on each retry. Within this infinite retry loop, CreateTableProcedure repeatedly accesses the same file content without performing any further operations or making any actual modifications to these files.

[0090] refer to Figure 4 The example diagram shown illustrates "failure" at the same stage. In this embodiment of the invention, a potential instance (iLoop) of LHB is described using a four-element tuple.

[0091] The `Resource` field records the resources that the process is accessing. This rule dictates that resources should be identical, meaning that software wastes time accessing the same resource repeatedly. In the example above, the resource is:

[0092] iLoop.Resource={meta_file_path(r1),block_file_path(r2)}

[0093] An operation includes all system calls that perform operations on a resource. The set of operations is fixed within the same case, but can be interchangeable in different situations and for different resources. The set of operations for this instance is:

[0094] iLoop.operation={open(o1),read(o2),close(o3),stat(o4)}

[0095] An AccessUnit describes the overall repetitive behavior of accessing a resource. In this example, it manifests as follows:

[0096] iLoop.accessUnit={o1(r1),o2(r1,Content),o3(r1),o4(r2)}

[0097] This access unit will appear cyclically in the system call sequence without being interspersed with other operations. The last element is the Content, which is associated with a specific operation and can be obtained through the specific parameters and return value of the system call. In this case of file access, the content is what is read from the file / socket. In an LHB, the content in each access unit is usually the same, indicating that the process is stuck in repetitive work.

[0098] Localized errors are common in system execution, often resulting from failures occurring at the same stage after identical operations. In LHB, the same error may occur at the same stage after repeated operations. This stage could be a specific system call or signal handler. This means the system lacks effective countermeasures for the error. Figure 4 This example shows an infinite while loop caused by integer overflow (Yarn-8833). The erroneous code snippet is shown below:

[0099] 1void computeSharesInternal(...) 2...

[0101] 3while(resourceUsedWithWeightToResourceRatio(rMax,...)

[0102] 4 <totalResource){

[0103] 5rMax*=2.0;

[0104] 6} 7

[0106] 8-static int resourceUsedWithWeightToResourceRatio(...){

[0107] 9+static long resourceUsedWithWeightToResourceRatio(...){

[0108] 10-int share=computeShare(sched,w2rRatio,type);

[0109] 11+long share=computeShare(sched,w2rRatio,type);

[0110] 12+if(Long.MAX_VALUE-resourcesTaken <share);

[0111] 13 + return Long.MAX_VALUE;

[0112] 14...}

[0113] In this error scenario, the compute-shared thread (running computeSharesInternal) will hold a write lock and prevent the scheduler from performing related operations. The system call traces containing the faulty compute thread and scheduler thread are as follows: Figure 4 As shown, the computation thread repeatedly executes `mprotect()` on the same memory address `addr`. Because the memory state switches between `no_access` and `read_only`, other threads will repeatedly "fail" (receiving a SIGSEGV signal; SEGV_ACCER indicates accessing memory in a way that violates protection) after attempting to access memory address `addr`.

[0114] In this embodiment of the invention, the following situation is further described using a quadruple:

[0115] (iLoop:Resource, Operations, AccessUnit, ErrorSign)

[0116] Error signs indicate that an error occurred after accessing a unit. These signs often represent a more serious situation than common errors that frequently occur during normal task operation.

[0117] In some embodiments, based on the time period and number of time windows, when the inspection rule is dense and repetitive code execution, the branch target address distribution within a preset number of windows is collected to determine the number of branches and branch percentage of different targets in each time window, thereby determining the LHB when the target application is executed;

[0118] In some embodiments, when the check rule is to access the same resource or fail after a specific operation, the first time window is checked. If there is a duplicate access unit, the tracking record sequence of a preset number of time windows is repeated to obtain the LHB when the target application is executed. If there is no duplicate access unit, the start time of the time window is reset.

[0119] In some embodiments, RwChecker checks for repeated occurrences of the loop instance iLoop to determine if a potential LHB exists. RwChecker uses consecutive time windows instead of a fixed time threshold to ensure that recurring behavior is consistent over consecutive time periods. Two parameters adjust the matching process: the time period Δt and the window number n. Users can configure these parameters based on the complexity of the task.

[0120] For the execution of code with dense and repetitive rules, at the window start time T0 (when the user starts running RwChecker), RwChecker collects the distribution of branch target addresses within n time windows. For each time window W i , i (0 < i < n), whose end time is T0 + i * Δt, RwChecker records the number of branches BN i for different targets in each window W i and the branch percentage BP i . For the top 3 most dense target addresses in the distribution, if BP i and BN i / (i * Δt) are equal in each time window (the difference does not exceed 0.1). RwChecker considers that there is a potential LHB during program execution.

[0121] For regular access to the same resource and invalidation after a specific operation, RwChecker attempts to find possible abnormal access units (these access units continuously loop within consecutive time). Specifically, at the start time T0, RwChecker first analyzes the system call sequence of the first time window and finds potential loop access units. If there are no repeatedly occurring potential LHB access units in the first window, RwChecker will directly reset the start time. Otherwise, RwChecker will continue to collect the trace record sequences of n time windows (the end time of W i is T0 + i * Δt). If the access units of regular access to the same resource or invalidation after a specific operation repeatedly occur in each window W i ((0 < i < n)), RwChecker will report the potential LHB, otherwise it will refresh the window start time and return to the first window state.

[0122] S300, determine the type of reliability problem according to the application reliability check result, where the type of reliability problem includes LHB and heavy - load tasks.

[0123] S400, generate configuration items according to the type of reliability problem, and optimize the reliability of the target software through the configuration items.

[0124] In some embodiments, when LHB enters a loop, check code is added. The loop variable and loop termination condition are obtained through the check code, and the loop termination process of LHB is executed according to the loop variable and loop termination condition; or, the maximum retry count and timeout of LHB are added through the first configuration item.

[0125] In some embodiments, the first configuration item is used to limit the method of loop execution. The specific example is as follows in the code segment:

[0126] / *add Hive configuration parameter* /

[0127] 2public static enum ConfVars{ 3...

[0129] 4+HIVE_ICEBERG_METADATA_REFRESH_MAX_RETRIES(

[0130] 5+"hive.iceberg.metadata.refresh.max.retries",2,

[0131] 6+”Max retry count for trying to access metadata location”+

[0132] 7+”in order to refresh metadata during Iceberg table load.”),

[0133] 8} 9

[0135] 10 protected void doRefresh(){ 11...

[0137] 12-refreshFromMetadataLocation(...);

[0138] 13+refreshFromMetadataLocation(...,

[0139] 14+HiveConf.getIntVar(conf,

[0140] 15+HIVE_ICEBERG_METADATA_REFRESH_MAX_RETRIES));

[0141] 16}

[0142] In some embodiments, optimization of heavy-load tasks can be achieved by using time-related configuration items to control the task execution / retry duration, or by using resource-related configuration items to control resource usage.

[0143] In some embodiments, reference Figure 5 The diagram shows the framework and flowchart of RwChecker. It's a framework for automatically monitoring software behavior and identifying potential loops causing hangs in long-running tasks. RwChecker can run when the user becomes aware of a performance alert (e.g., an unusually long-running task) or periodically check long-running processes for potential LHBs (Long-Hard Bots). The RwChecker workflow is as follows: Figure 5 As shown, the framework first uses hierarchical tracing to obtain software behavior from the application and system layers. Then, RwChecker uses inspection rules to identify potential LHBs from the tracing records over consecutive time periods.

[0144] Referring to Table 1, which shows the results of RwChecker identifying LHBs in a real production environment, RwChecker successfully identified 21 out of 24 LHBs in the experiment. The results are shown in Table 1. This section categorizes each case according to the rule instance that was first triggered during monitoring. Rules #2 and #3 were very effective in identifying LHBs, accounting for 81.0% (17 / 21) of all detected cases. #1 through #3 respectively represent intensive, repetitive code execution, access to the same resource, and failure after a specific operation.

[0145] Table 1. Results of RwChecker identifying LHBs in real production environments.

[0146] HBase 8 / 9 1 4 3 HDFS 4 / 5 1 2 1 Yarn 3 / 3 2 / 1 ZooKeeper 2 / 3 / 1 1 Hive 4 / 4 / 3 1 total 21 / 24 4 10 7

[0147] The runtime overhead of RwChecker was evaluated experimentally on 25 test sets. Results showed that the average overhead for branch target tracing was less than 1%, exhibiting relatively stable performance under different environments and task loads. System call tracing had a relatively higher overhead, averaging 5.9%, and was affected by task load. Its overhead depends on the interaction method and frequency between the software and the environment. Since RwChecker does not instrument the software source code, all overhead is introduced only after RwChecker starts and has no impact on the normal operation of the software system. Furthermore, both branch target and system call tracing processes generate log data.

[0148] Regarding the test results: RwChecker incurs 0.9% and 5.9% runtime overhead for branch targets and system call tracing respectively during normal long-running tasks, which is acceptable for production use. Specifically, when the software is running normally, no additional overhead is introduced if RwChecker is not enabled.

[0149] Figure 6 This is a diagram of a load-aware software hangup processing and analysis device according to an embodiment of the present invention. The device includes a first module 610, a second module 620, a third module 630, and a fourth module 640, wherein:

[0150] The first module is used to detect the target application at the application layer and system layer using a hierarchical tracing method, obtaining application layer tracing results and system layer tracing results. The second module is used to determine the software reliability check results by applying inspection rules and triggering early warning methods to the application layer tracing results and system layer tracing results. The third module is used to determine the reliability problem type based on the application reliability check results, where the reliability problem types include LHB and heavy load tasks. The fourth module is used to generate configuration items based on the reliability problem type, and optimize the reliability of the target software through the configuration items.

[0151] For example, with the cooperation of the first, second, third, and fourth modules in the device, the embodiment device can implement any of the aforementioned load-aware software suspension processing methods, namely, using a hierarchical tracing method to detect the target application at the application layer and system layer, obtaining application layer tracing results and system layer tracing results; using inspection rules and triggering early warning methods on the application layer tracing results and system layer tracing results to determine the software reliability check results; determining the reliability problem type based on the application reliability check results, wherein the reliability problem type includes LHB and heavy load tasks; generating configuration items based on the reliability problem type, and optimizing the reliability of the target software through the configuration items. The beneficial effects of this invention are as follows: It utilizes branch instruction target address tracing and lightweight system-level tracing to detect infinite loops that may cause system hangs. By tracing the CPU branch instruction target address, it monitors the execution of the application. Compared with traditional application-layer tracing, branch target tracing is hardware-supported, has relatively low overhead, and does not require any instrumentation in the source code. By analyzing the branch target traces and system call sequences over a continuous time period, it can accurately determine whether the application is in LHB or heavy-load tasks for a long time, and perform corresponding optimizations based on the application state, thereby improving the reliability of the application and achieving high reliability problem detection with low overhead.

[0152] This invention also provides an electronic device, which includes a processor and a memory;

[0153] The memory stores the program;

[0154] The processor executes a program to perform the aforementioned load-aware software suspension processing method; the electronic device has the function of carrying and running a software system for load-aware software suspension processing provided in the embodiments of the present invention, such as a personal computer, minicomputer, mainframe, workstation, network or distributed computing environment, standalone or integrated computer platform, or communicating with charged particle tools or other imaging devices, etc.

[0155] This invention also provides a computer-readable storage medium storing a program that is executed by a processor to implement the load-aware software suspension processing method described above.

[0156] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this invention are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is altered and sub-operations described as part of a larger operation are executed independently.

[0157] This invention also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium and execute the computer instructions, causing the computer device to perform the aforementioned load-aware software suspension processing method.

[0158] Furthermore, although the invention has been described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the described functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the invention. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional skill of an engineer. Therefore, those skilled in the art can implement the invention as set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of the invention, which is determined by the full scope of the appended claims and their equivalents.

[0159] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0160] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0161] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0162] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0163] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0164] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0165] The above is a detailed description of the preferred embodiments of the present invention, but the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.< / string>

Claims

1. A load-aware software suspension handling method, characterized in that, include: A hierarchical tracking method is used to detect the target application at the application layer and system layer, and the tracking results at the application layer and system layer are obtained. The software reliability check results are determined by using inspection rules and early warning methods on the application layer tracing results and the system layer tracing results; The reliability problem type is determined based on the application reliability check results, where the reliability problem type includes LHB and heavy load tasks; Based on the type of reliability problem, configuration items are generated, and the reliability of the target software is optimized using these configuration items. The hierarchical tracking method is used to detect the target application at the application layer and system layer, obtaining application layer tracking results and system layer tracking results, including: Hardware tracing is used to obtain branch instruction records, the address distribution of branch instructions is determined based on the branch instruction records, and the application layer tracing result is determined based on the address distribution of branch instructions. The eBPF tracing method is used to trace the events and system calls of the target application during runtime to obtain system-level tracing results. The task types of the events and system calls include file management, communication, memory management, I / O control, process management and synchronization control. The determination of application reliability check results by using inspection rules and triggering early warning methods on the application layer tracing results and the system layer tracing results includes: The inspection rules include densely repetitive code execution, access to the same resource, and failure after a specific operation. Densely repetitive code execution determines the application behavior of the target application through the distribution of branch target addresses. Access to the same resource is recorded using a four-tuple, where the four-tuple includes the accessed resource, access operation, access unit, and access content. Failure after a specific operation is also recorded using a four-tuple, where the four-tuple includes the accessed resource, access operation, access unit, and error flag. The method of triggering early warning uses a time window to detect repetitive behavior of each inspection rule, and obtains the application reliability inspection results.

2. The load-aware software suspension handling method according to claim 1, characterized in that, The step of acquiring branch instruction records using hardware tracing and determining the address distribution of branch instructions based on these records includes: Linux performance analysis tools are used to obtain branch instruction records. After filtering the branch instruction records for execution information of non-target applications, the mapping between the branch target address and the called method at runtime of the target application is obtained.

3. The load-aware software suspension handling method according to claim 1, characterized in that, The method employing early warning triggers uses a time window to detect recurring behavior for each inspection rule, obtaining application reliability inspection results, including: Based on the time period and number of windows, when the inspection rule is dense and repetitive code execution, the distribution of branch target addresses within the preset number of windows is collected to determine the number of branches and branch percentage of different targets in each time window, thereby determining the LHB when the target application is executed; When the check rule is to access the same resource or fail after a specific operation, the first time window is checked. If there is a duplicate access unit, the tracking record sequence of the preset number of time windows is repeated to obtain the LHB when the target application is executed. If there is no duplicate access unit, the start time of the time window is reset.

4. The load-aware software suspension handling method according to claim 1, characterized in that, The step of generating configuration items based on the reliability problem type, and optimizing the reliability of the target software using the configuration items, includes: When the reliability problem type is LHB, the location of the reliability problem is determined by checking the code, and the first configuration item is used to optimize LHB. When the reliability problem type is a heavy-load task, the second configuration option is used to optimize the heavy-load task.

5. The load-aware software suspension handling method according to claim 1, characterized in that, The optimization of LHB using the first configuration option includes: When LHB enters the loop, add check code to obtain the loop variable and the loop termination condition, and execute the LHB's loop termination process based on the loop variable and the loop termination condition. Alternatively, the maximum number of retries and timeout for LHB can be added through the first configuration item.

6. A load-aware software suspension processing device, characterized in that, include: The first module is used to detect the target application at the application layer and system layer using a hierarchical tracking method, and to obtain the application layer tracking results and the system layer tracking results. The second module is used to determine the software reliability check results by applying inspection rules and triggering early warning methods to the application layer tracing results and the system layer tracing results; The third module is used to determine the type of reliability problem based on the application reliability check results, wherein the reliability problem types include LHB and heavy load tasks; The fourth module is used to generate configuration items based on the reliability problem type, and to optimize the reliability of the target software through the configuration items; The hierarchical tracking method is used to detect the target application at the application layer and system layer, obtaining application layer tracking results and system layer tracking results, including: Hardware tracing is used to obtain branch instruction records, the address distribution of branch instructions is determined based on the branch instruction records, and the application layer tracing result is determined based on the address distribution of branch instructions. The eBPF tracing method is used to trace the events and system calls of the target application during runtime to obtain system-level tracing results. The task types of the events and system calls include file management, communication, memory management, I / O control, process management and synchronization control. The determination of application reliability check results by using inspection rules and triggering early warning methods on the application layer tracing results and the system layer tracing results includes: The inspection rules include densely repetitive code execution, access to the same resource, and failure after a specific operation. Densely repetitive code execution determines the application behavior of the target application through the distribution of branch target addresses. Access to the same resource is recorded using a four-tuple, where the four-tuple includes the accessed resource, access operation, access unit, and access content. Failure after a specific operation is also recorded using a four-tuple, where the four-tuple includes the accessed resource, access operation, access unit, and error flag. The method of triggering early warning uses a time window to detect repetitive behavior of each inspection rule, and obtains the application reliability inspection results.

7. An electronic device, characterized in that, Including the processor and memory; The memory is used to store programs; The processor executes the program to implement the load-aware software suspension processing method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The storage medium stores a program that is executed by a processor to implement the load-aware software suspension processing method as described in any one of claims 1-5.

Images