Load diagnosis and processing method and device, electronic equipment, medium and program product

Abstract

The invention provides a load diagnosis and processing method and device, electronic equipment, a medium and a program product, which can be applied to the technical field of cloud computing. The method comprises the following steps: acquiring a performance index sequence of at least one candidate application process, and in response to meeting a high-load triggering condition, determining a target process to be diagnosed and generating an abnormal event identifier; obtaining thread resource occupation information of the target process in response to the abnormal event identifier, determining an abnormal thread based on the thread resource occupation information, and obtaining execution stack information corresponding to the abnormal thread; thread features are extracted based on the thread resource occupation information and the execution stack information, and a root cause classification label is determined based on the thread features; and generating processing suggestion information for the target application process based on the root cause classification label.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and more specifically to a load diagnosis and processing method, apparatus, device, medium, and program product. Background Technology

[0002] Java-based application servers are widely used in financial and other business scenarios due to their excellent cross-platform capabilities, mature ecosystem, and high reliability. In actual operation, Java application servers need to handle high-concurrency requests, complex business logic, and multi-threaded tasks simultaneously, making them highly dependent on computing resources, especially processor resources. When processor utilization remains consistently high, it can easily lead to problems such as response latency, business timeouts, and even service unavailability, seriously affecting the stable operation of the system.

[0003] In daily operation and maintenance practices, the causes of abnormally high processor utilization are complex and diverse. They may be caused by changes in business load, or related to factors such as program logic defects, thread competition, and blocking waiting. The problem manifests significantly differently under different operating environments. Existing diagnostic methods, which are mainly based on manual troubleshooting, are fragmented, inefficient, and fail to form a holistic understanding of the problem, making them unable to meet the actual needs of complex business systems for rapid and accurate performance diagnosis. Summary of the Invention

[0004] In view of the above problems, this application provides load diagnosis and processing methods, apparatus, devices, media and program products.

[0005] According to a first aspect of this application, a load diagnosis and processing method is provided, the method comprising: acquiring a performance indicator sequence of at least one candidate application process, and determining whether the performance indicator sequence meets a high load triggering condition; in response to meeting the high load triggering condition, identifying a target process to be diagnosed and generating an abnormal event identifier; in response to the abnormal event identifier, acquiring thread resource usage information of the target process, identifying an abnormal thread based on the thread resource usage information, and acquiring execution stack information corresponding to the abnormal thread; extracting thread features based on the thread resource usage information and the execution stack information, and determining a root cause classification label based on the thread features; and generating processing suggestion information for the target application process based on the root cause classification label.

[0006] According to an embodiment of this application, determining whether the performance indicator sequence meets the high load triggering condition includes: collecting performance indicators of at least one candidate application process according to a preset sampling period to form the performance indicator sequence; determining whether the performance indicator sequence meets the continuous abnormal condition within multiple consecutive sampling periods; and determining that the performance indicator sequence meets the high load triggering condition if the continuous abnormal condition is met.

[0007] According to an embodiment of this application, determining whether the performance indicator sequence meets the high load triggering condition includes: selecting at least two performance indicators from the performance indicator sequence of the same candidate application process, comparing the at least two performance indicators with corresponding threshold conditions respectively; determining whether the number of performance indicators that meet the corresponding threshold conditions reaches a preset number; and if the preset number is reached, determining that the performance indicator sequence meets the high load triggering condition.

[0008] According to an embodiment of this application, generating an abnormal event identifier includes: constructing an abnormal event feature group, the abnormal event feature group including at least the process identifier of the target process, the trigger time, and the trigger condition identifier used to characterize the high load triggering mode; performing encoding processing on the abnormal event feature group to generate the abnormal event identifier; and associating and storing the abnormal event identifier and the performance index sequence corresponding to the trigger time to generate an association record.

[0009] According to an embodiment of this application, the method further includes: in response to detecting repeated triggering with the same process identifier and the same triggering condition identifier within a preset suppression window, merging the repeated triggering into the same abnormal event identifier, and updating the associated record.

[0010] According to an embodiment of this application, determining abnormal threads based on the thread resource usage information includes: sampling the thread resource usage information multiple times within a first preset time window to obtain a resource usage sampling sequence for each thread; calculating the continuous usage index and peak usage index for each thread based on the resource usage sampling sequence, and determining candidate abnormal threads based on the continuous usage index and the peak usage index; and determining the corresponding candidate abnormal thread as the abnormal thread if the continuous usage index corresponding to the candidate abnormal thread meets a preset threshold condition and a preset persistence condition.

[0011] According to an embodiment of this application, obtaining the execution stack information corresponding to the abnormal thread includes: performing at least two thread execution stack acquisitions on the target process within a second preset time window to obtain an execution stack acquisition result set; extracting the corresponding execution stack fragment based on the matching result of the thread identifier of the abnormal thread in the execution stack acquisition result set; and performing consistency screening on the execution stack fragment to obtain the execution stack information.

[0012] According to an embodiment of this application, the step of extracting thread features based on the thread resource occupancy information and the execution stack information includes: calculating the persistence and volatility characteristics of processor utilization based on the thread resource occupancy information; extracting synchronization mutual exclusion characteristics, blocking wait characteristics, and high-frequency computation call characteristics based on the execution stack information; and fusing the persistence characteristics, the volatility characteristics, the synchronization mutual exclusion characteristics, the blocking wait characteristics, and the high-frequency computation call characteristics to obtain the thread features.

[0013] A second aspect of this application provides a load diagnosis and processing apparatus, comprising: a data acquisition module, configured to: acquire a performance indicator sequence of at least one candidate application process, determine whether the performance indicator sequence meets a high load triggering condition; and, in response to meeting the high load triggering condition, determine a target process to be diagnosed and generate an abnormal event identifier; an abnormal thread determination module, configured to: in response to the abnormal event identifier, acquire thread resource usage information of the target process, determine an abnormal thread based on the thread resource usage information, and acquire execution stack information corresponding to the abnormal thread; a root cause classification module, configured to: extract thread features based on the thread resource usage information and the execution stack information, and determine a root cause classification label based on the thread features; and a processing suggestion module, configured to: generate processing suggestion information for the target application process based on the root cause classification label.

[0014] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0016] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0017] According to embodiments of this application, the performance index sequence of candidate application processes is used as the trigger entry point. When high load triggering conditions are met, an abnormal event identifier is automatically generated and the subsequent diagnostic process is driven, achieving timely and automated perception of load anomalies. By using the abnormal event identifier as the core, process-level performance monitoring, thread-level resource analysis, and execution stack collection are organically linked, giving the diagnostic process a unified contextual relationship and avoiding the problems of scattered and difficult-to-trace diagnostic evidence in traditional manual investigation. Furthermore, by identifying abnormal threads based on thread resource usage information and extracting thread features by combining the execution stack information corresponding to the abnormal threads, effective drilling down from load phenomena to specific execution paths and code behaviors is achieved. This is beneficial for quickly identifying the key threads and their execution logic that truly cause load anomalies in complex multi-threaded scenarios. At the same time, by fusing and analyzing thread resource features and execution stack features, root cause classification labels are automatically determined, so that root cause determination no longer relies on manual experience judgment, improving the consistency and accuracy of diagnostic results. Attached Figure Description

[0018] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0019] Figure 1 The illustrations depict application scenarios of load diagnosis and processing methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0020] Figure 2 A flowchart illustrating a load diagnosis and processing method according to an embodiment of this application is shown schematically;

[0021] Figure 3 A flowchart illustrating a method for determining an abnormal thread according to some exemplary embodiments of this application is shown schematically.

[0022] Figure 4 A flowchart illustrating a method for extracting thread features according to some exemplary embodiments of this application is shown schematically;

[0023] Figure 5 This schematically illustrates a structural block diagram of a load diagnostic and processing apparatus according to an embodiment of the present application; and

[0024] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a load diagnosis and processing method according to an embodiment of this application. Detailed Implementation

[0025] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0026] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0027] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0028] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0029] With the continuous evolution of information technology and internet applications, enterprise business systems are placing higher demands on stability, real-time response capabilities, and processing performance. As the core infrastructure carrying out business logic execution, load diagnosis, and processing, the operational status of application servers directly affects the overall system performance and the end-user experience. Among various application server technologies, Java-based application servers, with their excellent cross-platform adaptability, mature ecosystem, and high reliability and maintainability, are widely deployed in business scenarios with high stability requirements, such as finance, telecommunications, and e-commerce.

[0030] In real-world operating environments, Java application servers typically need to handle high-concurrency access requests, complex business processing logic, and a large number of parallel multithreaded tasks simultaneously. This makes the system highly dependent on computing resources. Processor resource utilization is one of the most important performance indicators for measuring the operational status of an application server. When processor utilization remains high or even reaches saturation for an extended period, the system often experiences problems such as significantly increased request response times, business processing timeouts, decreased service capacity, and even service unavailability. In severe cases, it can even lead to system-wide failure, adversely affecting business continuity and user experience.

[0031] In daily operations and performance management practices, abnormally high processor utilization is a common performance issue that is difficult to quickly pinpoint the root cause of. The causes of such problems are typically highly diverse and complex, potentially stemming from a sudden surge in business traffic, or related to factors such as poor program design, intensified thread resource contention, abnormal loop execution, synchronous blocking and waiting, and frequent garbage collection. Furthermore, the specific manifestations, scope of impact, and severity of the problem vary significantly under different operating environments, business load characteristics, and system configurations. This multi-factor characteristic makes the problem diagnosis process highly dependent on the experience and judgment of operations personnel, lacking a unified, systematic, and reusable analytical path.

[0032] Currently, the analysis of abnormal processor utilization issues typically relies on manual investigation, such as checking system monitoring metrics, analyzing runtime logs, and collecting thread execution status data to gather clues. While these methods can assist in identifying anomalies to some extent, they generally suffer from drawbacks such as fragmented operational processes, disjointed analytical perspectives, and low diagnostic efficiency. Especially in application systems with complex business structures and tight component dependencies, a single tool or perspective is insufficient to comprehensively reflect the entire problem, often resulting in lengthy problem localization cycles and failing to meet the practical needs for rapid response and precise handling of high-availability systems.

[0033] Based on this, embodiments of this application provide a load diagnosis and processing method, the method comprising: acquiring a performance indicator sequence of at least one candidate application process, determining whether the performance indicator sequence meets a high load triggering condition; in response to meeting the high load triggering condition, identifying a target process to be diagnosed and generating an abnormal event identifier; in response to the abnormal event identifier, acquiring thread resource usage information of the target process, identifying an abnormal thread based on the thread resource usage information, and acquiring execution stack information corresponding to the abnormal thread; extracting thread features based on the thread resource usage information and the execution stack information, and determining a root cause classification label based on the thread features; and generating processing suggestion information for the target application process based on the root cause classification label. According to embodiments of this application, using the performance indicator sequence of a candidate application process as a trigger entry point, an abnormal event identifier is automatically generated and guided to subsequent diagnostic processes when the high load triggering condition is met, realizing timely and automated perception of load anomalies. By using anomaly event identification as the core, process-level performance monitoring, thread-level resource analysis, and execution stack collection are organically linked, giving the diagnostic process a unified contextual relationship and avoiding the problems of scattered and difficult-to-trace diagnostic evidence in traditional manual investigation. Furthermore, by identifying abnormal threads based on thread resource usage information and extracting thread features by combining the execution stack information of the abnormal threads, effective drilling down from load phenomena to specific execution paths and code behaviors is achieved. This is beneficial for quickly identifying the key threads and their execution logic that are truly causing load anomalies in complex multi-threaded scenarios. At the same time, by fusing and analyzing thread resource features and execution stack features, root cause classification labels are automatically determined, so that root cause determination no longer relies on manual experience judgment, improving the consistency and accuracy of diagnostic results.

[0034] It should be noted that the load diagnosis and processing methods, apparatus, devices, media, and program products defined in this application can be used in the fields of cloud computing technology and fintech, and can also be used in a variety of other fields besides cloud computing technology and fintech. The application fields of the load diagnosis and processing methods, apparatus, devices, media, and program products provided in the embodiments of this application are not limited.

[0035] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0036] In scenarios where personal information is used for automated decision-making, the methods, devices, and systems provided in this application all offer users corresponding operation entry points, allowing them to choose to agree to or reject the automated decision results; if the user chooses to reject, the process proceeds to expert decision-making. Here, "expert decision-making" refers to the decision-making activities of personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0037] Figure 1 The illustration shows an application scenario diagram of the load diagnosis and processing method, apparatus, device, medium, and program product according to embodiments of this application.

[0038] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0039] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0040] In the embodiments of this application, the first terminal device 101 can be an example of the first device, and the second terminal device 102 and / or the third terminal device 103 can be an example of at least one second device. The first device and the second device can communicate collaboratively through an internal client mechanism to implement the data distribution and rendering logic described in the load diagnosis and processing method.

[0041] In some embodiments, the first device and at least one second device may be different display modules, windows or screens on the same computing terminal (such as a host), or multiple physical devices that work together through a network, such as different client instances deployed on a desktop computer, tablet terminal or mobile device respectively.

[0042] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smart mobile terminals, tablet computers, laptop computers, and desktop computers.

[0043] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0044] It should be noted that the load diagnosis and processing method provided in this application embodiment can generally be executed by server 105. Correspondingly, the load diagnosis and processing device provided in this application embodiment can generally be located in server 105. The load diagnosis and processing method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the load diagnosis and processing device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0045] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0046] The following will be based on Figure 1 The described scene, through Figures 2-4 The load diagnosis and processing method of the disclosed embodiments will be described in detail.

[0047] Figure 2 A flowchart illustrating a load diagnosis and processing method according to an embodiment of this application is shown schematically.

[0048] like Figure 2 As shown, the load diagnosis and processing method 200 of this embodiment includes operations S210 to S240.

[0049] In operation S210, a performance indicator sequence of at least one candidate application process is obtained, and it is determined whether the performance indicator sequence meets the high load triggering condition; in response to meeting the high load triggering condition, the target process to be diagnosed is identified and an abnormal event identifier is generated.

[0050] In embodiments of this application, the system can continuously or periodically acquire a performance indicator sequence of at least one candidate application process in the runtime environment. The performance indicator sequence is used to characterize the runtime load state of the application process over a period of time. By analyzing the performance indicator sequence, the system can determine whether the current candidate application process is under high load, thereby providing a triggering basis for subsequent diagnostic processes.

[0051] In some embodiments, the performance metric sequence may include a time series of processor utilization changes over time, and may further include metrics that reflect the application's runtime load characteristics, such as changes in the number of threads, changes in request processing time, and memory usage trends. The system can collect the performance metric sequence independently for a single candidate application process, or it can collect the performance metric sequences of multiple candidate application processes in parallel on the same running node and analyze them separately. In this case, the candidate application processes may be different service processes within the same business system, or multiple business processes deployed in the same runtime environment.

[0052] In the embodiments of this application, the high load triggering condition is not limited to whether a single performance indicator exceeds a threshold, but can be determined based on the overall trend of the performance indicator sequence. For example, the system can determine whether the processor utilization rate remains at a high level for multiple consecutive sampling periods, or whether multiple different performance indicators simultaneously exhibit abnormal states, thereby comprehensively determining whether the high load triggering condition is met.

[0053] In some embodiments, high load triggering conditions may include a persistent assessment of a sequence of performance metrics. For example, the system may determine whether processor utilization remains at a high level over multiple consecutive sampling periods, thereby distinguishing short-term transient fluctuations from genuine high load conditions.

[0054] In some embodiments, the high load triggering condition can be adaptively determined by combining the historical operating characteristics of the candidate application process. For example, the system can compare the current performance indicator sequence with the performance indicators of the application process during its historical normal operation phase. When the current indicator deviates significantly from the historical operating range, it can be determined that the candidate application process has entered a high load state.

[0055] In some embodiments, the high load triggering condition can also be based on the joint judgment of multiple performance indicators. The system can select multiple indicators that can reflect the characteristics of the running load from the performance indicator sequence of candidate application processes and analyze them separately. When multiple performance indicators show abnormal states simultaneously within the same time period, the system can determine that the candidate application process meets the high load triggering condition.

[0056] In some embodiments, when multiple candidate application processes exist and at least one of them meets the high-load triggering condition, the system can further compare and analyze among the multiple candidate application processes to determine the target process to be diagnosed. For example, the system can evaluate the load severity or abnormal duration of each candidate application process based on the performance index sequence of different candidate application processes, thereby selecting the application process with a higher load abnormality or a longer duration as the target process. If only one candidate application process exists, then if that candidate application process meets the high-load triggering condition, it is directly identified as the target process to be diagnosed.

[0057] In the embodiments of this application, after determining the target process to be diagnosed, the system can also generate an anomaly event identifier corresponding to the high load anomaly. The anomaly event identifier is used to uniquely identify a high load trigger event and can be associated with the trigger time, the target process, and the corresponding performance indicator sequence. By introducing the anomaly event identifier, subsequent operations such as thread analysis, root cause determination, and processing suggestion generation can be uniformly incorporated into the same event context, avoiding confusion of diagnostic information between different anomaly events.

[0058] In some embodiments, the generation of anomaly event identifiers can be based on the target process's identification information, trigger time, and trigger condition characteristics, which are then encoded. Different anomaly events correspond to different anomaly event identifiers, so even if the same application process triggers high load multiple times at different times, it can be distinguished by different anomaly event identifiers. Through this method, the system can initiate subsequent diagnostic processes in an event-driven manner, ensuring good traceability and scalability throughout the entire load diagnosis and handling process, providing a foundation for subsequent automated analysis and handling.

[0059] In the embodiments of this application, to achieve continuous monitoring of the application process's running status, the system can deploy a lightweight monitoring agent in the runtime environment. The lightweight monitoring agent runs on the same machine or in the same environment as the application process, and is used to collect real-time or near real-time data on the application process's running performance with low resource overhead. The lightweight monitoring agent can obtain performance observation data by calling the process and thread information interfaces provided by the operating system and by using the management interfaces provided by the runtime environment, and write the collected results into a cache queue or report them to the diagnostic component at a preset sampling period.

[0060] In some embodiments, the performance metrics collected by the lightweight monitoring agent may include: processor utilization of the application process, changes in the number of threads, garbage collection trigger frequency, changes in memory usage, and request processing time.

[0061] In operation S220, in response to the exception event identifier, the thread resource usage information of the target process is obtained, the exception thread is determined based on the thread resource usage information, and the execution stack information corresponding to the exception thread is obtained.

[0062] In the embodiments of this application, after generating an exception event identifier, the system can use the exception event identifier as a trigger signal to initiate a thread-level analysis process for the target process. By obtaining the current or near-real-time thread resource usage information of the target process, the system can further refine the overall process load status to the running status of each thread, thereby identifying the key execution units that cause high load.

[0063] In some embodiments, thread resource usage information may include the processor usage ratio of each thread over a period of time, changes in its running state, and thread scheduling-related information. The system can collect thread resource usage information of the target process multiple times within a preset time window, thereby generating sampling results that reflect thread running trends. In this way, not only can the resource usage of a thread at a single moment be captured, but the persistence and stability of thread resource usage can also be observed, which is helpful in distinguishing between short-lived active threads and long-term high-load threads.

[0064] In the embodiments of this application, in response to an abnormal event identifier, after obtaining thread resource usage information, the system can generate a thread mapping relationship to establish a correspondence between operating system threads and virtual machine threads in the target process. Specifically, the system can obtain a resource usage overview of the target process from a process perspective to determine the process identifier to be analyzed, and then obtain the resource usage of each thread within that process to determine the thread identifier of the abnormal thread. The system can also perform format conversion processing on the thread identifier to obtain a converted identifier consistent with the thread identifier format in the execution stack information, and locate the execution stack segment corresponding to the abnormal thread in the execution stack information obtained from multiple acquisitions based on the converted identifier. Furthermore, the system can construct a thread association matrix, which can include the correspondence between thread identifiers and converted identifiers, thread priority information, and the curve shape information of thread resource usage changing over time.

[0065] In the embodiments of this application, based on the acquired thread resource usage information, the system can perform comparative analysis on multiple threads in the target process to identify abnormal threads. An abnormal thread can be understood as a thread that contributes significantly to processor resource usage or maintains prolonged usage during high-load triggering periods. The system can sort or filter threads based on their resource usage information, selecting threads with significant resource usage characteristics as candidate abnormal threads, and further confirming whether they meet preset abnormal judgment conditions, thereby identifying them as abnormal threads.

[0066] In some embodiments, the identification of abnormal threads is not limited to a single judgment rule, but can be based on a comprehensive judgment combining multiple characteristics. For example, the system can simultaneously consider the peak level of thread resource usage and the duration of resource usage, avoiding the misidentification of threads as abnormal threads based solely on short-term resource fluctuations. This can improve the accuracy of abnormal thread identification and allow subsequent diagnosis to focus more on threads that truly have a substantial impact on the load.

[0067] In the embodiments of this application, after identifying the abnormal thread, the system can further obtain the execution stack information corresponding to the abnormal thread. The execution stack information reflects the call path and execution state of the thread at a certain moment or within a certain period of time, and is an important basis for understanding thread behavior. The system can perform multiple thread execution stack acquisition operations on the target process within a preset time window after the abnormal event is triggered, thereby obtaining multiple sets of execution stack data related to the abnormal thread.

[0068] In some embodiments, the system can locate the execution stack segment corresponding to the abnormal thread in the execution stack data collected multiple times based on the thread identifier of the abnormal thread. In this way, the execution path related to the abnormal thread can be accurately extracted from a large amount of thread execution information, avoiding interference from irrelevant thread information in subsequent analysis.

[0069] In the embodiments of this application, to improve the representativeness and stability of the execution stack information, the system can also perform consistency analysis on the extracted multiple execution stack segments. For example, the system can compare execution stack segments at different acquisition times and filter out execution paths that appear or are highly similar in multiple acquisitions, thereby obtaining stable execution stack information.

[0070] In operation S230, thread features are extracted based on thread resource usage information and execution stack information, and root cause classification labels are determined based on thread features.

[0071] In the embodiments of this application, after obtaining the thread resource occupancy information and the corresponding execution stack information, the above information can be processed in a unified manner to transform the original running data into a set of thread features that can characterize the thread behavior characteristics, thereby providing a stable and discriminable input basis for subsequent root cause classification.

[0072] In some embodiments, thread feature extraction can begin with thread resource usage information. This information can exist in time-series format, allowing the system to analyze thread resource usage patterns during periods of high load. For example, it can be determined whether a thread's use of processor resources exhibits a persistent characteristic, i.e., maintaining a high usage level over a prolonged period, or whether it displays frequent fluctuations, i.e., resource usage repeatedly changes between high and low levels.

[0073] In embodiments of this application, thread feature extraction can also be combined with execution stack information. Execution stack information reflects the call paths and execution context experienced by a thread during execution. The system can extract features related to thread behavior from the execution stack information. For example, it can analyze whether specific call paths repeatedly appear in the execution stack, whether there are execution patterns with deep call levels, or whether the thread remains at a certain type of call location for a long time. By extracting the characteristics of the execution stack structure, the behavioral characteristics of abnormal threads can be characterized from the perspective of code execution.

[0074] In some embodiments, thread resource consumption characteristics and execution stack characteristics can be fused. The system can combine characteristics reflecting resource usage trends with characteristics reflecting execution path characteristics to form a more comprehensive thread characteristic representation. Through fusion, thread characteristics can not only reflect "how many resources a thread consumes" but also "what the thread is doing," thus providing a more sufficient basis for root cause determination.

[0075] In the embodiments of this application, after obtaining thread characteristics, the system can determine root cause classification labels based on the thread characteristics. Root cause classification labels are used to characterize the main type of cause leading to abnormal resource consumption by a thread, such as being related to computationally intensive behavior, waiting for external resources, or internal execution logic characteristics. The system can analyze thread characteristics and map them to corresponding root cause classification labels using preset judgment rules, feature matching relationships, or classification strategies.

[0076] In some embodiments, the root cause classification process can be based on a comprehensive judgment of multiple thread characteristics. For example, when thread resource usage characteristics show that a thread continuously occupies processor resources for a long time, and execution stack characteristics indicate that the thread repeatedly executes the same call path, the system can classify the root cause of the thread as being related to repetitive computation behavior. When thread resource usage characteristics show that thread resource usage changes intermittently, and execution stack characteristics show frequent occurrences of call paths related to waiting states, the system can classify it as being related to waiting behavior.

[0077] In the embodiments of this application, the root cause classification label determination process is not limited to a single abnormal thread. It can also be performed separately for each abnormal thread when multiple abnormal threads exist, or a comprehensive root cause classification result for the target process can be given after combining the characteristics of multiple abnormal threads. This flexible determination method can adapt to application scenarios of varying complexity.

[0078] In the embodiments of this application, to determine the root cause classification label, the system can adopt a dual-path root cause classification strategy, that is, simultaneously supporting rule-based and model-based determination methods. Specifically, the system can input thread features obtained from thread resource usage information and execution stack information into the rule determination process to output a first root cause determination result based on a preset rule set; simultaneously, the system can also input the thread features into the root cause discrimination model to output a second root cause determination result. The system can fuse the first and second root cause determination results to obtain the final root cause classification label, thereby improving the adaptability to complex scenarios while ensuring interpretability.

[0079] In some embodiments, the rule-based judgment process can set corresponding judgment conditions for different feature dimensions. For example, for synchronization and mutual exclusion related features, the system can determine whether a thread exhibits obvious lock contention behavior based on the proportion or frequency of synchronization and mutual exclusion related calls in the execution stack information; for high-frequency computation call features, the system can determine whether a thread exhibits computationally intensive behavior based on the density of computation-related calls within a unit stack depth or unit time window in the execution stack information; for blocking and waiting related features, the system can determine whether a thread exhibits waiting behavior caused by external dependencies based on the occurrence of read, wait, or blocking related calls in the execution stack information. The above rules are only examples, and specific threshold conditions and judgment methods can be configured or adjusted according to different application scenarios.

[0080] In the embodiments of this application, the root cause discrimination model can output confidence information corresponding to each root cause category based on thread features. The confidence information is used to characterize the degree of matching between the thread feature and a certain root cause category. When outputting root cause classification labels, the system can simultaneously output the root cause category and the corresponding confidence value, for example, in the form of "lock contention - confidence is a certain value," so that the subsequent processing suggestion generation process can adjust the suggestion priority according to the confidence level and provide a reference for manual review.

[0081] In operation S240, processing recommendations for the target application process are generated based on root cause classification labels.

[0082] In the embodiments of this application, after obtaining the root cause classification label, the system can use the root cause classification label as a decision input to guide the generation of subsequent processing strategies. In this way, the system can directly apply the analysis conclusions formed in the aforementioned diagnostic stage to the problem handling stage, making the load diagnosis results executable, rather than just remaining at the cause identification level.

[0083] In some embodiments, the system can pre-establish a correspondence between root cause classification labels and processing strategies. Once a root cause classification label is determined, the system can automatically match the corresponding processing approach based on the label and generate processing suggestions for the target application process. For example, when a root cause classification label characterizes a certain type of resource usage behavior, the processing suggestions can be generated around how to optimize the usage of that type of resource, thus providing a clear direction for subsequent manual or automated processing.

[0084] In the embodiments of this application, the processing suggestion information can be presented in various forms. The system can generate comprehensive suggestion information that includes a description of the processing direction, a description of the key points of concern, and expected improvement goals, to assist operation and maintenance personnel or system administrators in understanding the causes of the current load anomaly and its possible improvement paths.

[0085] In some embodiments, the processing recommendations can also be generated in conjunction with the runtime context of the target application process. For example, the system can adjust the urgency or priority of the processing recommendations based on the performance changes of the target application process before and after the abnormal event is triggered, so that the generated processing recommendations are more in line with the actual running state.

[0086] In the embodiments of this application, the processing suggestion information can be further associated with and stored in conjunction with anomaly event identifiers. By binding the processing suggestion information with the corresponding anomaly event identifier, the complete process from anomaly triggering, cause analysis to processing suggestion generation can be clearly reconstructed during subsequent review or debriefing. This associated storage method facilitates the formation of traceable handling records.

[0087] In some embodiments, when the same target application process exhibits similar root cause classification labels multiple times at different times, the system can perform inductive processing when generating processing suggestion information. For example, it can supplement existing processing suggestions with new observations or appropriately adjust existing processing suggestion information to avoid repeatedly generating identical suggestion content.

[0088] In the embodiments of this application, the generation of processing suggestion information is not limited to a single output, but can generate multiple alternative processing suggestions as needed. The system can provide suggestions on different processing approaches for the same root cause classification label, for subsequent manual decision-making or system selection. By providing diverse processing suggestions, it helps to adapt to the needs of different operating environments and management strategies.

[0089] In some embodiments, the system can generate corresponding processing suggestions based on the final root cause classification label and provide exemplary handling directions. For example, when the root cause classification label represents lock contention behavior, the processing suggestions may include reducing lock granularity, reducing shared resource contention, and optimizing critical section logic; when the root cause classification label represents computationally intensive behavior, the processing suggestions may include optimizing algorithm implementation, reducing redundant computation, introducing asynchronous processing, or distributing computational load; when the root cause classification label represents waiting behavior, the processing suggestions may include optimizing external call methods, adjusting timeout and retry strategies, and introducing caching to reduce blocking and waiting. Through these methods, the system can transform the root cause determination result into executable handling guidelines, improving the closed-loop efficiency from diagnosis to processing.

[0090] According to embodiments of this application, by analyzing the performance index sequence of at least one candidate application process and setting high-load trigger conditions, abnormal states can be automatically identified in the early stages of load anomalies. By generating anomaly event identifiers, a single load anomaly can be managed uniformly as an event, effectively avoiding misjudgments caused by lag in manual monitoring or instantaneous fluctuations. This mechanism improves the timeliness, stability, and traceability of load anomaly detection. By performing thread-level analysis of the target process driven by the anomaly event identifiers, the high-load phenomenon at the process level is refined to the specific thread level, and further, the execution stack information corresponding to the abnormal thread is obtained. This allows the diagnostic process to delve from "load results" to "execution behavior," significantly improving the accuracy and specificity of problem localization. This approach avoids the limitations of relying solely on overall resource indicators for coarse-grained analysis, enabling the system to quickly identify key execution units that have a substantial impact on load anomalies. Furthermore, by jointly analyzing thread resource usage information and execution stack information, discriminative thread features are extracted, and root cause classification labels are determined based on these thread features, achieving an effective transformation from low-level operational data to high-level cause determination. By generating targeted processing suggestions based on root cause classification labels, diagnostic results are directly transformed into guidance outputs for remediation. This allows load diagnostics to go beyond problem analysis and directly contribute to problem resolution. Furthermore, by associating processing suggestions with anomaly event identifiers, a complete processing log can be created, facilitating subsequent backtracking and optimization.

[0091] The load diagnosis and processing method of this application will be specifically described below by way of preferred embodiments.

[0092] In the embodiments of this application, to determine whether the performance indicator sequence meets the high-load triggering condition, the system can periodically collect performance indicators of at least one candidate application process according to a preset sampling period, thereby forming a performance indicator sequence corresponding to the time sequence. Performance indicators are used to characterize the load state of the candidate application process during operation and may include indicators that reflect the application's operating pressure, such as processor resource utilization, changes in the number of active threads, and changes in request processing time. By continuously collecting the above performance indicators and forming a performance indicator sequence, the system can comprehensively reflect the trend of the candidate application process's operating load over a period of time.

[0093] In some embodiments, after obtaining a performance indicator sequence, the system can analyze the changes in the performance indicator sequence over multiple consecutive sampling periods to determine whether a continuous abnormal condition is met. For example, the system can determine whether the processor utilization rate is continuously higher than a preset load reference level over multiple consecutive sampling periods, or whether the number of threads is continuously in an abnormal growth state over multiple consecutive sampling periods, or whether the request processing time deviates significantly from the normal operating range over a continuous period of time. By introducing a judgment mechanism over multiple consecutive sampling periods, short-term load fluctuations and continuous high load states can be effectively distinguished.

[0094] In the embodiments of this application, the persistent abnormal condition is not limited to the persistent abnormality of a single performance indicator, but can also be determined based on the combination of multiple performance indicators. For example, while determining that the processor utilization rate is continuously at a high level, the system can further determine whether the number of thread activities is synchronously abnormal, thereby determining that the candidate application process is in a state of continuous high load when multiple indicators jointly meet the abnormal characteristics.

[0095] When the system determines that the performance index sequence meets the continuous abnormal conditions within multiple consecutive sampling periods, it can determine that the performance index sequence meets the high load triggering condition and further trigger the subsequent diagnostic process.

[0096] Through the embodiments of this application, while ensuring timely detection of load anomalies, it is possible to effectively suppress misjudgments caused by instantaneous operational changes, providing accurate triggering basis for the determination of subsequent target processes and the generation of abnormal event identifiers, thereby improving the stability of the entire load diagnosis and processing process.

[0097] In the embodiments of this application, the system can determine whether a high load triggering condition is met by using a multi-performance indicator joint judgment method based on the performance indicator sequence of the same candidate application process. Specifically, the system can select at least two performance indicators that can reflect the application's operating load status from the performance indicator sequence, and compare each performance indicator with its corresponding threshold condition, thereby avoiding the possible bias caused by relying on a single indicator for judgment.

[0098] In some embodiments, the selected performance metrics may include indicators from different dimensions such as processor resource utilization, changes in the number of active threads, and changes in request processing time. For example, the system may simultaneously select processor utilization and thread count as metrics, comparing each with its respective threshold conditions. When processor utilization remains consistently high and the number of threads simultaneously shows an abnormal increase, the application process's load status can be considered significantly abnormal. In this way, the overall load status of the application process during operation can be reflected more comprehensively.

[0099] In the embodiments of this application, after the system completes the threshold comparison of at least two performance indicators, it can further determine whether the number of performance indicators that meet the corresponding threshold conditions has reached a preset number. The preset number is used to limit the number of performance indicators that need to meet the abnormal conditions at the same time. For example, it can be set to at least two performance indicators that meet the abnormal conditions at the same time, thereby avoiding triggering a high load judgment when a single indicator is abnormal for a short time, and improving the stability of the triggering conditions.

[0100] In some embodiments, the multi-performance indicator joint judgment method can be flexibly adapted to different types of application processes. For computationally intensive application processes, processor resource usage indicators and request processing time indicators can be selected for joint judgment; for concurrent processing application processes, thread activity change indicators and processor usage indicators can be selected for joint judgment.

[0101] In the embodiments of this application, when the system determines that the number of performance indicators that meet the corresponding threshold conditions reaches a preset number, it can determine that the performance indicator sequence meets the high load triggering condition and further trigger the subsequent diagnostic process. For example, the system can generate an abnormal event identifier after the high load triggering condition is met, and use the abnormal event identifier as the trigger point to start thread-level analysis and root cause determination operations, thereby ensuring that the subsequent diagnostic process is based on a clear and reliable triggering premise.

[0102] By employing the aforementioned high-load triggering conditions based on multiple performance indicators, the embodiments of this application can more accurately identify true high-load states in complex operating environments. On one hand, by requiring at least two performance indicators to simultaneously meet threshold conditions, misjudgments caused by abnormalities or instantaneous fluctuations in a single indicator can be effectively suppressed. On the other hand, by comprehensively analyzing multiple performance dimensions of the same candidate application process, the operational pressure of the application process can be more comprehensively reflected. Therefore, the embodiments of this application achieve reliable screening of abnormal states during the high-load triggering stage, providing a more robust triggering foundation for subsequent thread analysis, root cause classification, and processing suggestion generation.

[0103] In the embodiments of this application, in order to uniformly identify and manage a high-load anomaly, the system can execute an anomaly event identifier generation process after determining the target process to be diagnosed. Specifically, the system can construct an anomaly event feature group, which is used to characterize the basic attributes of a high-load anomaly event. The anomaly event feature group can at least include the process identifier of the target process, the specific time that triggered the high-load judgment, and a trigger condition identifier used to characterize the high-load triggering method, thereby describing a high-load anomaly from multiple dimensions such as time, object, and triggering method.

[0104] In some embodiments, the process identifier is used to uniquely identify the application process that experienced the high load anomaly, the trigger time is used to characterize the point in time when the anomaly was identified, and the trigger condition identifier is used to distinguish whether the high load anomaly was triggered by a persistent anomaly judgment, a joint judgment of multiple performance indicators, or other triggering methods. By introducing the trigger condition identifier into the anomaly event feature group, richer contextual information can be provided for subsequent analysis, enabling the system to have better distinguishing capabilities when handling anomalies under different triggering scenarios.

[0105] In the embodiments of this application, after constructing the abnormal event feature group, the system can perform encoding processing on the abnormal event feature group to generate an abnormal event identifier corresponding to the abnormal event. The encoding processing can combine, map, or summarize the information in the abnormal event feature group to obtain an abnormal event identifier that can uniquely identify the abnormal event. Generating abnormal event identifiers through encoding processing ensures clear distinction between different abnormal events while avoiding the risk of conflicts arising from relying on a single field for identification.

[0106] In some embodiments, the generated exception event identifier can serve as a unified index for subsequent diagnostic processes. When the system subsequently obtains thread resource usage information, execution stack information, root cause classification results, and processing suggestions, it can associate these diagnostic data with the corresponding exception event identifiers, thereby ensuring that the entire diagnostic and processing process revolves around the same exception event and avoiding data confusion between different exception events.

[0107] In embodiments of this application, after generating an anomaly event identifier, the system can further associate and store the anomaly event identifier with the performance indicator sequence corresponding to the trigger time, generating an association record. The association record is used to save performance background information at the time of the anomaly, enabling the system to accurately reconstruct the operating state at the time of the anomaly during subsequent analysis or backtracking. Through this association storage method, a stable mapping relationship can be established between abstract anomaly event identifiers and specific performance indicator data.

[0108] In some embodiments, correlation records can serve as important evidence for subsequent analysis. For example, during root cause analysis or effect evaluation, the system can compare changes in operational status before and after an anomaly based on the performance indicator sequence in the correlation records, thereby assisting in determining the effectiveness of the handling measures. By binding anomaly event identifiers with performance indicator sequences, the system can form a complete anomaly event context, providing data support for subsequent processing.

[0109] By employing the aforementioned method for generating and associating abnormal event identifiers, the embodiments of this application can manage a high-load anomaly in a unified manner as an event. On the one hand, through abnormal event feature groups and abnormal event identifiers, high-load anomalies under different times, processes, and triggering methods can be clearly distinguished, avoiding the mixing of diagnostic data. On the other hand, by associating and storing abnormal event identifiers with corresponding performance indicator sequences, the operational background information at the time of the anomaly can be completely preserved, facilitating subsequent analysis, backtracking, and evaluation, significantly improving the traceability and management efficiency of the load diagnosis and processing flow.

[0110] In the embodiments of this application, to avoid multiple duplicate abnormal events caused by repeated triggering of the same high-load state within a short period of time, after generating abnormal event identifiers and establishing associated records, the system can also introduce a suppression window mechanism to merge duplicate triggering situations. Specifically, after generating abnormal event identifiers, the system can start a suppression window of a preset duration, and continuously monitor whether a high-load triggering condition is detected again within the suppression window.

[0111] In the embodiments of this application, the suppression window is used to limit the time range for repeatedly triggering the judgment of the same high load state. In essence, it is a pre-set time interval used to characterize the effective time span in which the system believes that "the same high load state is still continuing". The suppression window is set to avoid the problem of excessive number of abnormal events and repeated restarts of the diagnostic process due to the continuous satisfaction of the triggering conditions of performance indicators when the high load state has not subsided.

[0112] In some embodiments, the suppression window can be started synchronously when the abnormal event identifier is generated. Its start time can be set to the trigger time when the high load trigger condition is first detected, and its end time is a preset time length extended after the start time. During the effective period of the suppression window, the system can continuously monitor the running status of candidate application processes. However, when a re-trigger with the same process identifier and the same trigger condition identifier as the already generated abnormal event is detected, it will no longer be regarded as a new independent abnormal event, but will be treated as a repeated trigger of the same abnormal event.

[0113] In the embodiments of this application, the duration of the suppression window can be configured according to the actual operating environment and application characteristics. For example, for application processes with relatively gentle load changes, a relatively long suppression window can be set to cover the entire high-load continuous phase; for application processes with frequent load changes, a shorter suppression window can be set to promptly identify new abnormal events after the high-load state subsides. By flexibly configuring the suppression window length, a balance can be achieved between abnormal event aggregation and anomaly identification sensitivity.

[0114] In some embodiments, when the system detects a high-load trigger condition again within the suppression window, it can compare the process identifier and trigger condition identifier corresponding to this trigger. If the comparison result shows that the process identifier of this trigger is consistent with that of an existing abnormal event, and the trigger condition identifier is consistent, then the system can determine that this trigger is a repeated trigger under the same high-load state, rather than a new independent abnormal event.

[0115] For cases identified as repeated triggers, the system may refrain from generating new exception event identifiers. Instead, it can merge the repeated triggers under existing exception event identifiers for unified management. The merging operation may include incorporating information such as the new trigger time and the corresponding performance metric sequence into the original exception event's associated record. This allows the associated record to reflect the persistence or change of the high load state within the suppression window.

[0116] In some embodiments, the method of updating associated records can be adjusted according to actual needs. For example, the system can update the most recent trigger time, the cumulative number of triggers, or supplement new performance indicator sequence data in the associated records. By continuously updating the associated records, the system can gradually improve the description of the abnormal event, so that it not only reflects the abnormal state at a single moment, but also reflects the development of the abnormal state over a period of time.

[0117] By employing the aforementioned repeated trigger merging mechanism, the embodiments of this application can effectively prevent the proliferation of abnormal events caused by the repeated triggering of the same high-load state within a short period of time. On the one hand, by merging triggers with consistent process identifiers and trigger condition identifiers within the suppression window, the number of repeated abnormal events generated can be reduced, thereby lowering the system management and analysis burden. On the other hand, by continuously updating the associated records, the continuous process and evolution of the high-load state can be reflected more completely, thus improving the efficiency and orderliness of abnormal event management while ensuring the accuracy of load anomaly identification.

[0118] In the embodiments of this application, in order to solve the problem of difficulty in accurately identifying the execution thread that actually causes the load abnormality in the high load scenario of application process processor, the system can perform multiple sampling and comprehensive analysis of thread resource usage information to characterize thread behavior from the time dimension and usage intensity dimension, thereby effectively distinguishing short-term active threads from continuously high load threads in a multi-threaded concurrent running environment.

[0119] Figure 3 The flowchart illustrating a method for determining an abnormal thread according to some exemplary embodiments of this application is shown schematically.

[0120] like Figure 3 As shown, the method for identifying abnormal threads includes operations S310 to S330.

[0121] In operation S310, thread resource usage information is sampled multiple times within a first preset time window to obtain a resource usage sampling sequence for each thread. Thread resource usage information can be used to reflect the resource usage of each thread during operation, such as the degree of processor resource usage by the thread and the changes in the thread's running state over time. By sampling multiple times within the time window, the changing trend of thread resource usage can be obtained, rather than just the state at a single moment.

[0122] In operation S320, the continuous usage index and peak usage index of each thread are calculated based on the resource usage sampling sequence, and candidate abnormal threads are determined based on the continuous usage index and peak usage index.

[0123] The sustained resource usage metric characterizes the degree to which a thread maintains high resource usage within a first preset time window. For example, it can reflect the proportion or duration of a thread in a high-utilization state across multiple sampling points. The peak resource usage metric characterizes the highest resource usage level of a thread within the first preset time window. For example, it can reflect the maximum resource usage value reached by a thread at any sampling point. The system can filter threads based on the combined performance of the sustained and peak resource usage metrics to obtain a set of candidate abnormal threads that may cause high load on the target process, thereby focusing subsequent analysis on a smaller range of critical threads.

[0124] In operation S330, if the continuous occupancy index corresponding to the candidate abnormal thread meets the preset threshold condition and the preset persistence condition, the corresponding candidate abnormal thread is identified as an abnormal thread.

[0125] In the embodiments of this application, the system can perform further verification on candidate abnormal threads to reduce misjudgments caused by occasional spikes or short-term disturbances. Specifically, if the continuous occupancy index corresponding to a candidate abnormal thread meets both a preset threshold condition and a preset persistence condition, the system determines the corresponding candidate abnormal thread as an abnormal thread. The preset threshold condition can be used to limit the minimum requirement for the continuous occupancy index to reach an abnormal level, and the preset persistence condition can be used to limit the minimum continuity or minimum coverage that the high occupancy state needs to maintain. By simultaneously meeting the threshold condition and the persistence condition, the system can prioritize identifying threads that continuously contribute to high load, rather than threads that only briefly occupy high resources at a certain moment, thereby improving the stability of abnormal thread identification.

[0126] According to the embodiments of this application, by sampling thread resource usage information multiple times within a first preset time window and forming a sampling sequence, the system can capture the dynamic trend of thread resource usage changes and avoid occasional errors caused by single-point sampling. By simultaneously introducing continuous usage indicators and peak usage indicators, and further requiring the fulfillment of preset threshold conditions and preset persistence conditions during the candidate thread confirmation stage, the interference of factors such as instantaneous fluctuations and short-term spikes on the judgment of abnormal threads can be effectively suppressed, making the determination result closer to the real load cause. This allows for more accurate identification of abnormal threads that have a substantial impact on the high load of the target process, thereby improving the efficiency and accuracy of the overall load diagnosis and processing process.

[0127] In the embodiments of this application, in order to further obtain call path information that reflects the main execution behavior after identifying the abnormal thread, the target process can be sampled multiple times within a second preset time window, and the sampling results can be matched and screened for consistency, thereby reducing the interference of occasional execution paths and obtaining more representative and stable execution stack information.

[0128] In the embodiments of this application, the system can perform at least two thread execution stack acquisitions on the target process within a second preset time window to obtain an execution stack acquisition result set. The second preset time window can be set as a time interval after the abnormal event identifier is generated, used to cover the critical stage when the abnormal thread is in a high-load state. By performing at least two acquisitions within the second preset time window, the system can obtain execution stack snapshots of each thread of the target process at different acquisition times, thereby avoiding the occasional bias caused by relying solely on a single acquisition, and enabling subsequent analysis to be based on more sufficient evidence data.

[0129] After obtaining the execution stack collection result set, the corresponding execution stack fragment can be extracted based on the matching results of the abnormal thread's thread identifier in the execution stack collection result set. Since the execution stack collection result set contains execution stack information of multiple threads in the target process, the system can locate the stack content corresponding to the abnormal thread through the thread identifier, and extract the execution stack fragment of the abnormal thread from each collection result, thereby focusing the analysis on the abnormal thread itself and reducing the impact of irrelevant thread information on subsequent judgments.

[0130] To further improve the stability and representativeness of execution stack information, the system can perform consistency screening on the execution stack fragments to obtain the execution stack information. Consistency screening identifies common or highly similar execution paths among multiple collected execution stack fragments, thereby filtering out occasional stack fragments caused by factors such as thread scheduling changes and short-term branch execution. The execution stack information obtained through consistency screening can more accurately reflect the main execution path of abnormal threads during high load periods, making subsequent root cause determination based on execution stack characteristics more reliable.

[0131] In some embodiments, the implementation of consistency filtering can be flexible. For example, the system can determine whether different execution stack segments meet the consistency requirements based on the similarity of call paths, the consistency of key call locations, or the consistency of call hierarchy structures, and generate stable execution stack information from the execution stack segments that meet the consistency requirements. In this way, the natural fluctuations of execution paths in different scenarios can be taken into account, while ensuring that the final output execution stack information has good interpretability and analytical value.

[0132] According to the embodiments of this application, stable and reliable call path evidence can be further provided on the basis of abnormal thread identification: by performing at least two thread execution stack acquisitions within a second preset time window, the occasional error caused by a single sampling can be reduced, making the execution stack information more representative; by matching and extracting based on the abnormal thread identifier, the interference of a large amount of irrelevant thread information on the analysis can be avoided, improving the targeting of execution stack acquisition; by performing consistency screening on the execution stack fragments, short-term branches or occasional call paths can be effectively filtered, making the final obtained execution stack information more reflective of the main execution behavior of the abnormal thread.

[0133] Figure 4 The flowchart illustrating a method for extracting thread features according to some exemplary embodiments of this application is shown schematically.

[0134] like Figure 4 As shown, the method for extracting thread features may include operations S410~S430.

[0135] When operating the S410, the persistent and fluctuating characteristics of processor utilization are calculated based on thread resource usage information.

[0136] Persistence features are used to characterize the extent to which a thread maintains a high processor utilization state over a period of time. For example, they can be used to reflect the coverage or duration of a thread being in a high utilization state across multiple sampling points. Volatility features are used to characterize the degree of fluctuation in processor utilization over time. For example, they can be used to reflect the frequency or magnitude of changes in thread utilization levels between high and low states.

[0137] When operating the S420, based on the execution stack information, we extract the characteristics of synchronization and mutual exclusion, blocking and waiting, and high-frequency computation call.

[0138] Synchronization and mutual exclusion features characterize whether frequent synchronization and mutual exclusion-related behaviors exist during thread execution. For example, they can reflect the occurrence or proportion of synchronization and mutual exclusion-related call paths in the execution stack. Blocking and waiting features characterize whether threads exhibit significant waiting behavior. For example, they can reflect the occurrence of waiting or blocking-related call positions in the execution stack. High-frequency computation call features characterize whether threads repeatedly execute computation-related calls. For example, they can reflect the repetitive occurrence or concentrated occurrence of certain computation-type calls in the execution stack. By extracting these features from the execution stack information, the system can depict the main behavioral patterns of threads during high loads from the perspective of execution paths, giving thread features stronger semantic interpretability.

[0139] By operating the S430, thread characteristics are obtained by integrating persistent characteristics, volatile characteristics, synchronous mutual exclusion characteristics, blocking and waiting characteristics, and high-frequency computation call characteristics.

[0140] Feature fusion can unify the representation of different types of features through methods such as combination, splicing, or normalization, so that the final thread features can simultaneously reflect resource consumption trends and execution behavior characteristics. Through fusion processing, the system can form a more complete profile of thread behavior, thereby more accurately distinguishing different types of high load causes in the subsequent root cause classification stage.

[0141] According to embodiments of this application, by calculating persistence and volatility characteristics based on thread resource occupancy information, the system can characterize the thread's processor resource occupancy pattern from a time dimension, avoiding judgment bias caused by relying solely on single-point occupancy values; by extracting synchronization and mutual exclusion features, blocking and waiting features, and high-frequency computation call features based on execution stack information, the system can understand the main behavioral characteristics of threads from an execution path dimension, improving the semantic expression capability of thread behavior recognition; by fusing multiple types of features to form a unified thread feature representation, subsequent root cause classification can simultaneously utilize complementary information of resource trends and execution behavior, thereby enhancing the ability to distinguish between different high-load scenarios.

[0142] Corresponding to the above-described load diagnosis and processing method, embodiments of this application also provide a load diagnosis and processing apparatus.

[0143] Figure 5 A schematic block diagram of a load diagnostic and processing apparatus according to an embodiment of this application is shown.

[0144] like Figure 5 As shown, the load diagnosis and processing device 500 of this embodiment includes a data acquisition module 510, an abnormal thread determination module 520, a root cause classification module 530, and a processing suggestion module 540.

[0145] The data acquisition module 510 can be used to acquire a performance indicator sequence of at least one candidate application process, determine whether the performance indicator sequence meets the high load triggering condition, and in response to meeting the high load triggering condition, identify the target process to be diagnosed and generate an abnormal event identifier. In one embodiment, the data acquisition module 510 can be used to perform the operation S210 described above, which will not be repeated here.

[0146] The abnormal thread determination module 520 can be used to obtain the thread resource usage information of the target process in response to an abnormal event identifier, determine the abnormal thread based on the thread resource usage information, and obtain the execution stack information corresponding to the abnormal thread. In one embodiment, the abnormal thread determination module 520 can be used to perform the operation S220 described above, which will not be repeated here.

[0147] The root cause classification module 530 can be used to extract thread features based on thread resource usage information and execution stack information, and determine root cause classification labels based on thread features. In one embodiment, the root cause classification module 530 can be used to perform the operation S230 described above, which will not be repeated here.

[0148] The processing suggestion module 540 can be used to generate processing suggestion information for the target application process based on root cause classification labels. In one embodiment, the processing suggestion module 540 can be used to perform the operation S240 described above, which will not be repeated here.

[0149] According to an embodiment of this application, the data acquisition module 510 can also be used to collect performance indicators of at least one candidate application process according to a preset sampling period to form a performance indicator sequence; determine whether the performance indicator sequence meets the continuous abnormal conditions in multiple consecutive sampling periods; and determine that the performance indicator sequence meets the high load triggering condition if the continuous abnormal conditions are met.

[0150] According to an embodiment of this application, the data acquisition module 510 can also be used to select at least two performance indicators from the performance indicator sequence of the same candidate application process, compare the at least two performance indicators with the corresponding threshold conditions respectively; determine whether the number of performance indicators that meet the corresponding threshold conditions has reached a preset number; and if the preset number has been reached, determine that the performance indicator sequence meets the high load triggering condition.

[0151] According to an embodiment of this application, the data acquisition module 510 can also be used to construct an abnormal event feature group, which includes at least the process identifier of the target process, the trigger time, and the trigger condition identifier used to characterize the high load triggering mode; perform encoding processing on the abnormal event feature group to generate an abnormal event identifier; and associate and store the abnormal event identifier and the performance index sequence corresponding to the trigger time to generate an association record.

[0152] According to an embodiment of this application, the data acquisition module 510 can also be used to respond to repeated triggering with the same process identifier and the same triggering condition identifier detected within a preset suppression window, merge the repeated triggering into the same abnormal event identifier, and update the associated record.

[0153] According to an embodiment of this application, the abnormal thread determination module 520 can also be used to sample thread resource usage information multiple times within a first preset time window to obtain a resource usage sampling sequence for each thread; calculate the continuous usage index and peak usage index for each thread based on the resource usage sampling sequence, and determine candidate abnormal threads based on the continuous usage index and peak usage index; and determine the corresponding candidate abnormal thread as an abnormal thread if the continuous usage index corresponding to the candidate abnormal thread meets a preset threshold condition and a preset persistence condition.

[0154] According to an embodiment of this application, the abnormal thread determination module 520 can also be used to perform at least two thread execution stack acquisitions on the target process within a second preset time window to obtain an execution stack acquisition result set; extract the corresponding execution stack fragment based on the matching result of the thread identifier of the abnormal thread in the execution stack acquisition result set; and perform consistency screening on the execution stack fragment to obtain execution stack information.

[0155] According to embodiments of this application, the root cause classification module 530 can also be used to calculate the persistence and volatility characteristics of processor utilization based on thread resource utilization information; extract synchronization mutual exclusion characteristics, blocking waiting characteristics and high-frequency computation call characteristics based on execution stack information; and fuse persistence characteristics, volatility characteristics, synchronization mutual exclusion characteristics, blocking waiting characteristics and high-frequency computation call characteristics to obtain thread characteristics.

[0156] According to embodiments of this application, any multiple modules among the data acquisition module 510, the abnormal thread determination module 520, the root cause classification module 530, and the processing suggestion module 540 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the data acquisition module 510, the abnormal thread determination module 520, the root cause classification module 530, and the processing suggestion module 540 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the data acquisition module 510, the abnormal thread determination module 520, the root cause classification module 530, and the processing suggestion module 540 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0157] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a load diagnosis and processing method according to an embodiment of this application.

[0158] like Figure 6As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0159] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 602 and / or RAM 603. It should be noted that the programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0160] According to embodiments of this application, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0161] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0162] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.

[0163] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the load diagnosis and processing methods provided in the embodiments of this application.

[0164] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0165] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0166] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0167] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0168] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0169] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0170] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Without departing from the scope of this application, those skilled in the art can make various substitutions and modifications, all of which should fall within the scope of this application.

Claims

1. A load diagnosis and processing method, characterized in that, The method includes: Obtain a performance indicator sequence of at least one candidate application process, determine whether the performance indicator sequence meets the high load triggering condition; in response to meeting the high load triggering condition, determine the target process to be diagnosed and generate an abnormal event identifier; In response to the abnormal event identifier, the thread resource usage information of the target process is obtained, the abnormal thread is determined based on the thread resource usage information, and the execution stack information corresponding to the abnormal thread is obtained. Thread features are extracted based on the thread resource usage information and the execution stack information, and root cause classification labels are determined based on the thread features; and Based on the root cause classification labels, processing suggestions are generated for the target application process.

2. The method according to claim 1, characterized in that, The step of determining whether the performance index sequence meets the high load triggering condition includes: The performance metrics of at least one candidate application process are collected according to a preset sampling period to form the performance metric sequence. Determine whether the performance index sequence meets the continuous anomaly condition within multiple consecutive sampling periods; and If the continuous abnormal condition is met, the performance index sequence is determined to meet the high load trigger condition.

3. The method according to claim 1 or 2, characterized in that, The step of determining whether the performance index sequence meets the high load triggering condition includes: Select at least two performance metrics from the performance metric sequence of the same candidate application process, and compare the at least two performance metrics with the corresponding threshold conditions respectively. Determine whether the number of performance indicators that meet the corresponding threshold conditions has reached the preset number; and If the preset quantity is reached, the performance index sequence is determined to meet the high load triggering condition.

4. The method according to claim 1, characterized in that, The generated exception event identifier includes: Construct an abnormal event feature group, which includes at least the process identifier of the target process, the trigger time, and the trigger condition identifier used to characterize the high load triggering mode; Encoding processing is performed on the abnormal event feature group to generate the abnormal event identifier; and The abnormal event identifier and the performance indicator sequence corresponding to the trigger time are associated and stored to generate an association record.

5. The method according to claim 4, characterized in that, The method further includes: In response to the detection of repeated triggers with the same process identifier and the same trigger condition identifier within a preset suppression window, the repeated triggers are merged into the same abnormal event identifier, and the associated record is updated.

6. The method according to claim 1, characterized in that, The process of determining abnormal threads based on the thread resource usage information includes: Within a first preset time window, the thread resource usage information is sampled multiple times to obtain the resource usage sampling sequence for each thread; Based on the resource usage sampling sequence, the continuous usage index and peak usage index of each thread are calculated, and candidate abnormal threads are determined based on the continuous usage index and the peak usage index; and If the persistent occupancy index corresponding to the candidate abnormal thread meets the preset threshold condition and the preset persistence condition, the corresponding candidate abnormal thread is determined as the abnormal thread.

7. The method according to claim 1, characterized in that, The step of obtaining the execution stack information corresponding to the abnormal thread includes: Within a second preset time window, perform thread execution stack sampling on the target process at least twice to obtain an execution stack sampling result set; Based on the matching result of the thread identifier of the abnormal thread in the execution stack acquisition result set, the corresponding execution stack segment is extracted; and A consistency filter is performed on the execution stack fragment to obtain the execution stack information.

8. The method according to claim 1, characterized in that, The extraction of thread features based on the thread resource usage information and the execution stack information includes: Based on the thread resource usage information, calculate the persistence and fluctuation characteristics of processor utilization. Based on the execution stack information, characteristics of synchronization and mutual exclusion, blocking and waiting, and high-frequency computation call features are extracted; and The thread characteristics are obtained by integrating the persistence characteristics, volatility characteristics, synchronization and mutual exclusion characteristics, blocking and waiting characteristics, and high-frequency computation call characteristics.

9. A load diagnosis and processing device, characterized in that, The device includes: The data acquisition module is configured to: acquire a performance indicator sequence of at least one candidate application process, determine whether the performance indicator sequence meets a high load triggering condition, and, in response to meeting the high load triggering condition, identify the target process to be diagnosed and generate an abnormal event identifier. An abnormal thread determination module is used to: in response to the abnormal event identifier, obtain the thread resource usage information of the target process, determine the abnormal thread based on the thread resource usage information, and obtain the execution stack information corresponding to the abnormal thread; The root cause classification module is used to: extract thread features based on the thread resource usage information and the execution stack information, and determine root cause classification labels based on the thread features; and The processing suggestion module is used to generate processing suggestion information for the target application process based on the root cause classification label.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images