Method for diagnosing performance faults and computer device

Abstract

This invention relates to the field of computer technology, and more particularly to a method and computer device for performance fault diagnosis. The method includes: acquiring at least two program slices corresponding to a target program; acquiring first performance information corresponding to each program slice; classifying each program slice based on the first performance information; confirming the classification result; determining the target process in the target program where a fault has occurred based on the classification result and the first performance information; and determining the cause of the performance fault in the target program based on the faulty target process and a pre-constructed performance fault decomposition architecture. This method only requires capturing the function call process during program execution, and then analyzing and outputting results based on the captured results for the target program slices, greatly protecting the security and privacy of the tested program and significantly improving work efficiency.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and computer device for diagnosing performance faults. Background Technology

[0002] Performance jitter has become a serious problem on large-scale supercomputers and cloud computing platforms. This problem stems from a variety of causes, including operating system interruptions, memory errors, cache conflicts, I / O contention, virtual machine monitor operation, network communication contention, and other software or hardware issues. Due to performance jitter, the performance of parallel programs varies across multiple runs. Performance jitter is widespread on large-scale clusters, and users cannot easily predict or detect this phenomenon. Existing work has found that even on the same compute nodes, performance jitter in repeatedly run programs can reach 3 to 4 times. Performance jitter not only leads to program performance degradation and resource waste but also makes application behavior unstable and difficult to understand. Therefore, performance fault diagnosis is of great importance and value.

[0003] Currently, diagnosing performance faults requires inserting detection code into the code of the program being tested. However, this method relies on known code segments and cannot be used when dealing with compiled binary programs whose source code is unknown. Summary of the Invention

[0004] This application provides a method and computer device for diagnosing performance faults, in order to solve the technical problem that performance fault diagnosis cannot be performed on programs with unknown code in the prior art.

[0005] Firstly, this application provides a method for diagnosing performance faults, including:

[0006] Obtain at least two program slices corresponding to the target program;

[0007] Based on each program slice, obtain the first performance information corresponding to each program slice;

[0008] Based on the first performance information corresponding to each program slice, each program slice is classified and the classification results are confirmed.

[0009] Based on the classification results and primary performance information, the target process in the target program that has experienced a failure is identified.

[0010] Based on the target process that failed and the pre-built performance failure decomposition architecture, the cause of the performance failure in the target program is determined.

[0011] In one possible implementation, at least two program slices corresponding to the target program are obtained, including:

[0012] Determine whether the target program makes external function calls;

[0013] When the target function makes at least one function call, a call identifier corresponding to each function is generated;

[0014] Based on the call identifier, the target program is segmented to obtain at least two program slices.

[0015] In one possible implementation, based on each program slice, the first performance information corresponding to each program slice is obtained, including:

[0016] Based on each program slice, obtain various performance indicators corresponding to each program slice;

[0017] Based on various performance indicators, determine the primary performance information.

[0018] In one possible implementation, based on the first performance information corresponding to each program slice, the program slices are classified, and the classification results are confirmed, including:

[0019] The first performance information corresponding to each program slice is compared with a pre-set classification threshold to obtain the comparison results.

[0020] Based on the comparison results, each program slice is classified to determine at least one type of program slice.

[0021] In one possible implementation, the target program slice includes identification information of the target process to which the target program slice belongs. Based on the classification result and the first performance information, the target process in the target program that has experienced a failure is identified, including:

[0022] Perform a first normalization process on the first performance information corresponding to each type of target program slice to obtain the first normalization process result corresponding to each type of target program slice;

[0023] The weight of the first normalization result is determined based on the performance index corresponding to each type of target program slice.

[0024] Based on the identification information, determine all target program slices corresponding to each target process;

[0025] Based on the first normalization result of each target program slice in all target program slices corresponding to each target process, and the weight corresponding to the first normalization result, the second performance information corresponding to the target process is determined. The first normalization result and the weight corresponding to each type of target program slice are the corresponding parameters of each target program slice in each type of target program slice.

[0026] When the second performance information is less than the preset fault threshold, it is determined that the target process has failed.

[0027] In one possible implementation, based on the failed target process and a pre-built performance failure decomposition architecture, the cause of the performance failure of the target program corresponding to the failed target process is determined, including:

[0028] Obtain the performance metrics corresponding to the target process that failed;

[0029] Determine whether the performance metric corresponding to the target process that failed can be quantified in terms of time.

[0030] If the performance metrics corresponding to the target process that failed can be quantified as time metrics, then the cause of the performance failure can be determined based on the performance failure decomposition architecture and the first time metric corresponding to the target process that failed.

[0031] In one possible implementation, the method further includes:

[0032] When the performance metric corresponding to the target process that has failed cannot be quantified as time, the performance metric is subjected to a second normalization process to obtain the result of the second normalization process.

[0033] Based on the second normalization result, the performance index corresponding to the target process that has failed is quantified into a second time index.

[0034] Based on the second time metric and the performance failure decomposition architecture, the causes of performance failures are determined.

[0035] Secondly, this application provides a performance fault diagnosis device, comprising:

[0036] The acquisition unit is used to acquire at least two program slices corresponding to the target program; and based on each program slice, acquire the first performance information corresponding to each program slice.

[0037] The classification unit is used to classify each program slice based on the first performance information corresponding to each program slice and to confirm the classification result.

[0038] The processing unit is used to determine the target process that has failed in the target program based on the classification results and the first performance information; and to determine the cause of the performance failure of the target program based on the target process that has failed and the performance failure decomposition architecture.

[0039] Thirdly, this application provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the steps of any of the methods in the first aspect.

[0040] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method as described in any of the first aspects.

[0041] The present invention provides a performance fault diagnosis method, which involves obtaining at least two program slices corresponding to a target program, obtaining first performance information corresponding to each program slice, classifying each program slice based on the first performance information, confirming the classification results, further determining the target process in the target program that has a fault based on the classification results and the first performance information, and finally determining the cause of the performance fault in the target program based on the target process that has a fault and a pre-built performance fault decomposition architecture.

[0042] This method overcomes the shortcomings of existing technologies that require reading the program's source code to detect faults. This solution only needs to capture the function call process during program execution, then slice and analyze the target program based on the captured results, and output the results. No code needs to be inserted into the source code, greatly protecting the security and privacy of the program under test. Furthermore, after a fault is detected, the corresponding method can promptly output the cause of the fault, ensuring that relevant personnel can repair the fault accurately and in a timely manner, greatly improving work efficiency. Attached Figure Description

[0043] Figure 1 This is a schematic flowchart of a performance fault diagnosis method provided in an embodiment of the present invention;

[0044] Figure 2 This is a schematic diagram of a state transition diagram provided in an embodiment of the present invention;

[0045] Figure 3 A schematic diagram of the performance fault decomposition architecture provided in an embodiment of the present invention;

[0046] Figure 4 This is a schematic diagram of a device structure for performance fault diagnosis provided in an embodiment of the present invention;

[0047] Figure 5 This invention provides a schematic diagram of a computer device structure. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0049] To facilitate understanding of the embodiments of the present invention, further explanations and descriptions will be provided below with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0050] To address the technical problems mentioned in the background section, this application provides a method for diagnosing performance faults, as detailed below. Figure 1 As shown. Figure 1 This is a schematic flowchart of a performance fault diagnosis method provided in an embodiment of the present invention.

[0051] Step 110: Obtain at least two program slices corresponding to the target program.

[0052] Specifically, the first step is to establish an intermediate dynamic link library to determine whether the target program makes external function calls. When the target function makes at least one function call, a call identifier corresponding to each function is generated. Finally, the call identifier is used to segment the target program.

[0053] In a specific example, suppose there exists a program alpha, and we assume that program alpha contains the following processes: internal operation A, calling a communication function; internal operation B, calling a screen printing function; and internal operation C. Furthermore, there is a logical relationship between internal operations A, B, and C; that is, internal operation B can only be executed after internal operation A is completed, and internal operation C can only be executed after internal operation B is completed. When program alpha calls the communication function, it first sends the call instruction to an intermediate dynamic link library. After receiving the call signal, the intermediate dynamic link library first generates a call identifier 1, then sends the instruction to an external function library for invocation. After the invocation is completed, the corresponding function is returned to program alpha. The call identifier 2 for calling the screen printing function is generated in the same way as call identifier 1. After obtaining the corresponding call identifiers 1 and 2, the target program alpha is sliced ​​based on these two call identifiers, resulting in three target program slices. Suppose we have target program slices A, B, and C, respectively. Clearly, target program slice A corresponds to internal operation A, target program slice B corresponds to internal operation B, and target program slice C corresponds to internal operation C. In this example, the communication function and the screen printing function also generate their own corresponding program slices, denoted as program slices P and Q.

[0054] Furthermore, the state transition diagram can be determined based on the logical relationships between the various slices.

[0055] In a specific example, see Figure 2 As shown, taking the target program slices A, B, C, P, and Q as an example, logically, target program slice A must exist first. Target program slice C can only be obtained through program slice P, B, and Q. Program slices P and Q are respectively attached to two points in the state transition diagram. Target program slice B is attached to an edge pointing from the point of program slice P to the point of target program slice Q.

[0056] Step 120: Based on each program slice, obtain the first performance information corresponding to each program slice.

[0057] Specifically, the first step is to collect performance metrics corresponding to each program slice. These metrics are collected during the target program slicing process and include, but are not limited to, the following: communication time, runtime, function parameters, number of executed instruction lines, number of memory access instructions, etc. Finally, the various performance metrics are integrated and calculated to obtain the first performance information, which represents the performance status of the current slice. The integration process can be a simple summation or, depending on the specific application, the corresponding conversion formula in this field can be applied.

[0058] In a specific example, suppose there is a target program slice that, after running, can collect 100 executed instructions and 100 memory access instructions, then the performance information is 200.

[0059] It is important to note that in the example above, the performance metrics include the number of executed instructions and the number of memory access instructions, and the performance information is the sum of the two. However, in practical applications, performance metrics are not limited to these two metrics, and performance information can be expressed in various ways. Calculating performance information using performance metrics is not limited to simple addition of metrics; it can be obtained through various calculation methods, depending on the specific application.

[0060] Step 130: Based on the first performance information corresponding to each program slice, classify each program slice and confirm the classification results.

[0061] Specifically, the first performance information corresponding to each program slice can be compared with a pre-set classification threshold to obtain the comparison result. Based on the comparison result, each program slice can be classified to determine at least one type of program slice.

[0062] In a specific example, suppose there are four program slices. Let these four slices be slice 1, slice 2, slice 3, and slice 4. Assume the number of instructions is used as the first performance information for each slice, with 1000, 1050, 200, and 210 instructions respectively. Assume a preset classification threshold is that the difference between the number of instructions in the slice with the most instructions and the slice with the fewest instructions in each category cannot exceed 5% of the number of instructions in the slice with the fewest instructions. After obtaining the four program slices, first sort them according to the number of instructions, from most to least, as follows: Slice 2, Slice 1, Slice 4, Slice 3. Then, select the first program slice in the sorted list: Slice 2. Subtract the number of instructions for Slice 1, Slice 4, and Slice 3 from the number of instructions for Slice 2, respectively, to obtain differences in the number of instructions: 50, 840, and 850. Dividing the difference in instruction counts by the corresponding instruction counts of slice 1, slice 4, and slice 3, respectively, yields percentages of 5%, 84%, and 85%. The difference between slice 2 and slice 1 is 5% of the instruction count of slice 1, which is less than the threshold of 5%. Therefore, slice 1 and slice 2 belong to the same category. Similarly, slice 2, slice 3, and slice 4 do not belong to the same category. Following the same method, slice 3 and slice 4 are classified, ultimately resulting in slice 1 and slice 2 belonging to the same category, and slice 3 and slice 4 belonging to the same category.

[0063] Step 140: Based on the classification results and the first performance information, determine the target process in the target program that has failed.

[0064] Specifically, the first step is to perform a first normalization process on the first performance information corresponding to each type of target program slice to obtain the first normalization result corresponding to each type of target program slice.

[0065] In a specific example, suppose there are three target program slices in a class, with execution times of 1 second, 2 seconds, and 4 seconds respectively, and assume that 1 second represents the optimal performance, which is set to 1. Then, normalizing these three target program slices to a value between 0 and 1 according to their optimal performance, the first normalization results are as follows:

[0066] Furthermore, based on the performance metrics corresponding to each type of target program slice, the weight of the first normalization processing result is determined;

[0067] In a specific example, suppose there are three types of program slices: A, B, and C. Assume time is used as the performance metric, and that a program contains only one slice of each type. Suppose the program runs for 10 minutes, with 5 minutes spent executing slice A, 3 minutes executing slice B, and 2 minutes executing slice C. The weight of each slice type can be determined by the proportion of its execution time within the total execution time.

[0068]

[0069] Similarly, it can be calculated that the value for class B is 0.3 and the value for class C is 0.2.

[0070] Furthermore, based on the identification information, all target program slices corresponding to each target process are identified;

[0071] In a specific example, suppose a target program has only two processes and four program slices, which are recorded as program slice a, program slice b, program slice c, and program slice d respectively. In the program slices, the target program slice includes the identification information of the target process to which the target program slice belongs: program slice a - process 1, program slice b - process 1, program slice c - process 2, program slice d - process 2. Then, process 1 contains program slice a and program slice b, and process 2 contains program slice c and program slice d.

[0072] Furthermore, based on the first normalization result of each target program slice in all target program slices corresponding to each target process, and the weight corresponding to the first normalization result, the second performance information corresponding to the target process is determined. Here, the first normalization result and the weight corresponding to each type of target program slice are the corresponding parameters of each target program slice in each type of target program slice.

[0073] In a specific example, suppose there is a process containing program slice alpha and program slice beta, where the first normalization result of program slice alpha is 0.7 and the weight is 0.5, and the first normalization result of program slice beta is 0.7 and the weight is 0.5. Then the second performance information of the final process can be calculated according to the following formula.

[0074] Second performance information = 0.7 × 0.5 + 0.7 × 0.5 = 0.7

[0075] Furthermore, when the second performance information is less than a preset fault threshold, it is determined that the target process has failed.

[0076] In a specific example, assuming the preset fault threshold is 0.8, and still taking the second fault information mentioned above as an example, in the above example, the second performance information is 0.7, which is less than the preset fault threshold of 0.8, so the above process fails.

[0077] Step 150: Based on the target process that failed and the pre-built performance failure decomposition architecture, determine the cause of the performance failure in the target program.

[0078] Specifically, the first step is to build a performance fault decomposition architecture that includes all factors that cause faults.

[0079] In a specific example, see Figure 3 The diagram illustrates a performance fault decomposition architecture. Assume there are three layers of causes: S1, S2, and S3. These three layers are progressive, meaning S2 causes S1, and S3 causes S2. The fault causes in S1 include: front-end constraints, error prediction, emission, back-end constraints, and suspension. Back-end constraints and suspensions each contain their own S2 causes: core constraints, storage constraints, page faults, context switches, and semaphores. Storage constraints, page faults, and context switches each contain their own S3 causes: region constraint 1, region constraint 2, region constraint 3, memory constraint, soft page fault, hard page fault, active context switch, and passive context switch. Among all fault causes, front-end constraints, error prediction, emission, back-end constraints, suspension, core constraints, storage constraints, region constraint 1, region constraint 2, region constraint 3, and memory constraints can be quantified in terms of time. However, page faults, context switches, semaphores, soft page faults, hard page faults, active context switches, and passive context switches cannot be quantified in terms of time.

[0080] Furthermore, if the performance metrics corresponding to the target process that failed can be quantified as time metrics, then the cause of the performance failure can be determined based on the performance failure decomposition architecture and the first time metric corresponding to the target process that failed.

[0081] In a specific example, if the backend runtime of the faulty process is found to be 10 seconds, while the normal backend runtime is 1 second, then the cause of the fault in the target program corresponding to the target process is determined to be a backend limitation. However, the diagnosis does not specify this because backend limitations include two other causes: kernel limitations and storage limitations. Further assuming the faulty process finds a kernel runtime of 9.5 seconds and a storage runtime of 0.5 seconds, but under normal circumstances, both kernel and storage runtimes are 0.5 seconds, it can be clearly determined that the cause of the fault in the target program corresponding to the target process is a kernel limitation. Since there are no further causes under kernel limitations, the result can be directly output as: the fault is caused by kernel limitations.

[0082] Furthermore, when the performance metrics corresponding to the failed target process cannot be quantified as time, a second normalization process is performed on the performance metrics to obtain the second normalization result. Based on the second normalization result, the performance metrics corresponding to the failed target process are quantified as a second time metric. Based on the second time metric and the performance failure decomposition architecture, the cause of the performance failure is determined.

[0083] In a specific example, suppose the performance metric corresponding to the faulty process is 5 page faults. Obviously, the number of page faults is not a corresponding time factor. First, based on historical results, for example, the historical maximum number of page faults of 10 is regarded as 1, and the corresponding target program slice execution time is counted as 12 seconds. The best case of 0 page faults is regarded as 0, and the execution time is counted as 2 seconds. The current performance metric of 5 page faults is first normalized and recorded as 0.5. Then, the normalized data is further linearly calculated based on time, and 5 page faults are regarded as 5 seconds. Assuming that a normal page fault is 2 seconds, it is clear that the target program failure is caused by page faults.

[0084] It should be noted that, in Figure 3 The example provided illustrates a performance fault decomposition architecture. However, in real-world applications, the causes of faults are not limited to this, and the fault hierarchy is not limited to three layers. This is merely an example, and the progression between faults is not limited to what is shown in the diagram. The actual application shall prevail.

[0085] This invention provides a performance fault diagnosis method, which involves obtaining at least two program slices corresponding to a target program, then obtaining performance information corresponding to each program slice based on each program slice, classifying each program slice based on the performance information, confirming the classification results, further determining the target process in the target program that has a fault based on the classification results and performance information, and finally determining the cause of the performance fault in the target program based on the target process that has a fault and a pre-built performance fault decomposition architecture.

[0086] This method overcomes the shortcomings of existing technologies that require reading the program's source code to detect faults. This solution only needs to capture the function call process during program execution, then slice and analyze the target program based on the captured results, and output the results. No code needs to be inserted into the source code, greatly protecting the security and privacy of the program under test. Furthermore, after a fault is detected, the corresponding method can promptly output the cause of the fault, ensuring that relevant personnel can repair the fault accurately and in a timely manner, greatly improving work efficiency.

[0087] Figure 4 A user identification device provided in this embodiment of the invention, see details below. Figure 4 As shown, the device includes: an acquisition unit 401, a classification unit 402, and a processing unit 403.

[0088] The acquisition unit 401 is used to acquire at least two program slices corresponding to the target program; and based on each program slice, acquire the first performance information corresponding to each program slice.

[0089] The classification unit 402 is used to classify each program slice based on the first performance information corresponding to each program slice and to confirm the classification result.

[0090] The processing unit 403 is used to determine the target process that has failed in the target program based on the classification results and the first performance information; and to determine the cause of the performance failure of the target program based on the target process that has failed and the performance failure decomposition architecture.

[0091] Optionally, the acquisition unit 401 is used to determine whether the target program makes an external function call;

[0092] When the target function makes at least one function call, a call identifier corresponding to each function is generated;

[0093] Based on the call identifier, the target program is segmented to obtain at least two program slices.

[0094] Optionally, the acquisition unit 401 is used to acquire various performance indicators corresponding to each program slice based on each program slice;

[0095] Based on various performance indicators, determine the primary performance information.

[0096] Optionally, the classification unit 402 is used to compare the first performance information corresponding to each program slice with a preset classification threshold to obtain a comparison result;

[0097] Based on the comparison results, each program slice is classified to determine at least one type of program slice.

[0098] Optionally, the processing unit 403 is used to perform a first normalization process on the first performance information corresponding to each type of target program slice to obtain the first normalization process result corresponding to each type of target program slice.

[0099] The weight of the first normalization result is determined based on the performance index corresponding to each type of target program slice.

[0100] Based on the identification information, determine all target program slices corresponding to each target process;

[0101] Based on the first normalization result of each target program slice in all target program slices corresponding to each target process, and the weight corresponding to the first normalization result, the second performance information corresponding to the target process is determined. The first normalization result and the weight corresponding to each type of target program slice are the corresponding parameters of each target program slice in each type of target program slice.

[0102] When the second performance information is less than the preset fault threshold, it is determined that the target process has failed.

[0103] Optionally, the processing unit 403 is used to acquire performance metrics corresponding to the target process that has failed;

[0104] Determine whether the performance metric corresponding to the target process that failed can be quantified in terms of time.

[0105] If the performance metrics corresponding to the target process that failed can be quantified as time metrics, then the cause of the performance failure can be determined based on the performance failure decomposition architecture and the first time metric corresponding to the target process that failed.

[0106] Optionally, the processing unit 403 is used to perform a second normalization process on the performance index when the performance index corresponding to the target process that has failed cannot be quantified as time, and obtain the second normalization result of the performance index.

[0107] Based on the second normalization result, the performance index corresponding to the target process that has failed is quantified into a second time index.

[0108] Based on the second time metric and the performance failure decomposition architecture, the causes of performance failures are determined.

[0109] Further functional descriptions of the above modules are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0110] This invention also provides an electronic device having the above-described features. Figure 4 The device shown is for diagnosing performance faults.

[0111] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device provided in an optional embodiment of the present invention, such as... Figure 5 As shown, the electronic device may include: at least one processor 51, such as a CPU (Central Processing Unit), at least one communication interface 53, memory 54, and at least one communication bus 52. The communication bus 52 is used to enable communication between these components. The communication interface 53 may include a display screen or a keyboard; optionally, the communication interface 53 may also include a standard wired interface or a wireless interface. The memory 54 may be high-speed RAM (Random Access Memory) or non-volatile memory, such as at least one disk storage device. Optionally, the memory 54 may also be at least one storage device located remotely from the aforementioned processor 51. The processor 51 may be combined with... Figure 5 The described apparatus has an application program stored in memory 54, and the processor 51 calls the program code stored in memory 54 to perform any of the above method steps.

[0112] The communication bus 52 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication bus 52 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0113] The memory 54 may include volatile memory, such as random-access memory (RAM); the memory may also include non-volatile memory, such as flash memory, hard disk drive (HDD) or solid-state drive (SSD); the memory 54 may also include a combination of the above types of memory.

[0114] The processor 51 can be a central processing unit (CPU), a network processor (NP), or a combination of CPU and NP.

[0115] The processor 51 may further include a hardware chip. This hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0116] Optionally, memory 54 is also used to store program instructions. Processor 51 can invoke program instructions to implement the performance fault diagnosis method as shown in any embodiment of this application.

[0117] This invention also provides a non-transitory computer storage medium storing computer-executable instructions that can execute the performance fault diagnosis method described in any of the above method embodiments. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium may also include combinations of the above types of memory.

[0118] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A method for diagnosing performance faults, characterized in that, include: Obtain at least two program slices corresponding to the target program, wherein the program slices include the identification information of the target process to which the program slices belong; Based on each program slice, obtain the first performance information corresponding to each program slice; Based on the first performance information corresponding to each program slice, the program slices are classified, and the classification results are confirmed. Based on the classification results and the first performance information, the target process in the target program that has experienced a failure is identified. Based on the target process that failed and the pre-built performance failure decomposition architecture, the cause of the performance failure of the target program is determined. The step of determining the target process that has failed in the target program based on the classification result and the first performance information includes: Perform a first normalization process on the first performance information corresponding to each type of program slice to obtain the first normalization process result corresponding to each type of program slice; The weight of the first normalization result is determined based on the performance index corresponding to each type of program slice. Based on the identification information, all program slices corresponding to each target process are determined; Based on the first normalization result of each program slice in all program slices corresponding to each target process, and the weight corresponding to the first normalization result, the second performance information corresponding to the target process is determined, wherein the first normalization result and the weight corresponding to each type of program slice are the corresponding parameters of each program slice in each type of program slice. When the second performance information is less than a preset fault threshold, it is determined that the target process has failed.

2. The method according to claim 1, characterized in that, The acquisition of at least two program slices corresponding to the target program includes: Determine whether the target program makes an external function call; When the target program makes at least one function call, a call identifier corresponding to each function is generated; Based on the call identifier, the target program is segmented to obtain at least two program slices.

3. The method according to claim 1, characterized in that, The step of obtaining the first performance information corresponding to each program slice based on each program slice includes: Based on each program slice, obtain various performance indicators corresponding to each program slice; The first performance information is determined based on the various performance indicators.

4. The method according to any one of claims 1-3, characterized in that, The step of classifying each program slice based on the first performance information corresponding to each program slice and confirming the classification result includes: The first performance information corresponding to each program slice is compared with a pre-set classification threshold to obtain the comparison result; Based on the comparison results, each program slice is classified to determine at least one type of program slice.

5. The method according to claim 1, characterized in that, Based on the failed target process and the pre-built performance fault decomposition architecture, the cause of the performance fault in the target program corresponding to the failed target process is determined, including: Obtain the performance metrics corresponding to the target process that has experienced the failure; Determine whether the performance metric corresponding to the target process that experienced the failure is quantifiable in terms of time. If the performance metric corresponding to the target process that failed can be quantified as a time metric, then the cause of the performance failure is determined based on the performance failure decomposition architecture and the first time metric corresponding to the target process that failed.

6. The method according to claim 5, characterized in that, The method further includes: When the performance metric corresponding to the target process that has failed cannot be quantified as time, the performance metric is subjected to a second normalization process to obtain the second normalization result of the performance metric. Based on the second normalization result, the performance index corresponding to the target process that has failed is quantified into a second time index. Based on the second time metric and the performance failure decomposition architecture, the cause of the performance failure is determined.

7. A performance fault diagnosis device, characterized in that, include: The acquisition unit is used to acquire at least two program slices corresponding to the target program, wherein the program slices include the identification information of the target process to which the program slices belong; Based on each program slice, obtain the first performance information corresponding to each program slice; A classification unit is used to classify each program slice based on the first performance information corresponding to each program slice and to confirm the classification result. The processing unit is configured to determine the target process in the target program that has experienced a failure based on the classification results and the first performance information. Based on the target process that failed and the performance failure decomposition architecture, the cause of the performance failure of the target program is determined. Specifically, the processing unit is used for: Perform a first normalization process on the first performance information corresponding to each type of program slice to obtain the first normalization process result corresponding to each type of program slice; The weight of the first normalization result is determined based on the performance index corresponding to each type of program slice. Based on the identification information, all program slices corresponding to each target process are determined; Based on the first normalization result of each program slice in all program slices corresponding to each target process, and the weight corresponding to the first normalization result, the second performance information corresponding to the target process is determined, wherein the first normalization result and the weight corresponding to each type of program slice are the corresponding parameters of each program slice in each type of program slice. When the second performance information is less than a preset fault threshold, it is determined that the target process has failed.

8. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the steps of the method as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1-6.

Images