Method for analyzing server performance and electronic device

Abstract

The application discloses a server performance analysis method and electronic equipment, and relates to the technical field of electric digital data processing, can perform performance analysis according to the running data of the server when the user has performance analysis demand, and in the case that the server is determined to be in a business state and the frequency of the central processing unit is less than a frequency threshold, the actual analysis intention in the user description information is used to perform a loss output ratio calculation, and then the performance bottleneck type of the server is determined, the analysis of the server performance is realized, the technical problem that it is difficult to determine the performance analysis direction from the user's subjective and fuzzy description sentence in the related art is solved, the performance analysis result does not match the target expected to be improved by the user, and the user experience is reduced, the analysis direction is consistent with the scene direction described by the user, and invalid analysis caused by disconnection of the intention is avoided.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing technology, and in particular to methods for analyzing server performance and electronic devices. Background Technology

[0002] In related technologies, due to the complexity of server business systems, when performance bottlenecks occur, it is difficult to effectively determine the actual root cause of the bottleneck by relying solely on software and hardware indicators. Furthermore, since different users have different concerns regarding the same server operating conditions, using fixed indicators for performance bottleneck analysis may lead users to believe that the server performance is poor, even when the actual server operating data does not meet the warning indicators, thus affecting the user experience. This situation urgently needs improvement. Summary of the Invention

[0003] This application provides a method and electronic device for analyzing server performance, in order to at least solve the technical problem in related technologies that it is difficult to determine the direction of performance analysis from vague subjective descriptions by users, resulting in performance analysis results that do not match the user's expected improvement goals, thereby reducing the user experience.

[0004] This application provides a method for analyzing server performance, including: in response to user-input descriptive information, obtaining the server's current operating data; when the server is determined to be in a business state based on multiple current feature values, and the CPU's operating frequency is less than or equal to a preset frequency threshold, identifying the user's actual analysis intent based on the descriptive information; combining the actual analysis intent and multiple current feature values, calculating the server's consumption-output ratio, using the consumption-output ratio to determine the server's bottleneck type, and using the bottleneck type and current operating data to analyze the server's performance bottleneck, thereby obtaining the server's performance analysis results.

[0005] This application also provides a server performance analysis device, comprising: an acquisition module for acquiring current server operating data in response to user-input descriptive information; an identification module for identifying the user's actual analysis intent based on the descriptive information when the server is determined to be in a business state based on multiple current feature values ​​and the operating frequency of the central processing unit is less than or equal to a preset frequency threshold; and an analysis module for calculating the server's consumption-output ratio by combining the actual analysis intent and multiple current feature values, determining the server's bottleneck type using the consumption-output ratio, and analyzing the server's performance bottleneck using the bottleneck type and current operating data to obtain the server's performance analysis results.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described server performance analysis methods.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described server performance analysis methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described server performance analysis methods.

[0009] This application enables performance analysis when users have performance analysis needs. By standardizing and mapping runtime data, it achieves adaptation to servers with different architectures. Then, it uses the standardized mapped runtime values ​​for performance analysis. When it is determined that the server is in a business state and the CPU frequency is below the frequency threshold, it calculates the cost-benefit ratio based on the actual analysis intent in the user's description, thereby determining the type of server performance bottleneck. This solves the technical problem in related technologies where it is difficult to determine the direction of performance analysis from the user's subjective and vague description, resulting in performance analysis results that do not match the user's expected improvement goals, thus reducing the user experience. This ensures that the analysis direction is consistent with the scenario described by the user, avoiding ineffective analysis caused by a disconnect between intent and reality. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating a server performance analysis method according to an embodiment of this application; Figure 2 This is a flowchart of a server performance analysis method according to an embodiment of this application; Figure 3 This is a schematic diagram of a server performance analysis device provided according to an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0015] It is understandable that there are many server platforms, and the server architectures of different platforms vary greatly. In addition, the business systems of servers are becoming increasingly complex. When business slows down or errors occur, it is difficult to quickly find the root cause. Furthermore, due to differences in user experience and focus, users may perceive server performance differently. Even if no error occurs, some users may feel that the server is running slowly. However, since no error is received, it is difficult to conduct effective bottleneck root cause analysis and troubleshooting.

[0016] Taking database operations as an example, there are many aspects involved. The database's built-in monitoring shows everything is normal, with no lock waits or slow queries. However, system-level metrics, such as CPU (Central Processing Unit) utilization and disk I / O (Input / Output), are not at their bottlenecks. In this situation where neither software nor hardware alarms are triggered, but the business is still slow, it is difficult to conduct effective analysis using relevant technologies.

[0017] In summary, the relevant technologies suffer from several technical problems, such as significant architectural differences requiring specific adaptations for servers with different architectures, difficulty in determining the direction of performance analysis from vague subjective descriptions by users, and performance analysis results that do not match the user's expected improvement goals.

[0018] To address the aforementioned technical issues, the server performance analysis method of this application embodiment can achieve adaptation to servers with different architectures by standardizing and mapping the running data. When it is determined that the server is in a business state and the frequency of the central processing unit is less than the frequency threshold, the consumption-output ratio is calculated based on the actual analysis intent in the user description information, thereby determining the type of server performance bottleneck. This ensures that the analysis direction is consistent with the scenario described by the user, avoiding invalid analysis caused by a disconnect between intent and reality.

[0019] like Figure 1As shown, an embodiment of this application provides a method for analyzing server performance, including the following steps: In step S101, in response to the description information input by the user, the current running data of the server is obtained, and the current running data is mapped to multiple current feature values ​​that meet preset standard conditions.

[0020] In actual implementation, the embodiments of this application can obtain descriptive information input by the user. The input methods can be various, such as text input, voice-to-text input, etc. The descriptive information includes the user's original performance analysis requirements, such as performance symptom descriptions (slow response, lag), business scenarios (accessing database A), etc.

[0021] This application embodiment can analyze whether the description information is a normal server instruction or a performance analysis requirement. It needs to identify the user's intent from the user's voice, and only respond to the user's input description information after confirming that the user has the intent to perform server performance analysis.

[0022] After responding to the description information input by the user, embodiments of this application can obtain multiple operational data of the server based on register values.

[0023] It should be noted that the underlying hardware implementation status data collected by servers with different architectures have platform differences. In order to solve this problem, the embodiments of this application can perform cross-platform difference elimination processing on the collected current running data.

[0024] For example, embodiments of this application can directly read the original PMU counter and map these fragmented register values ​​into unified standardized eigenvalues ​​or standardized eigenvectors V. std This ensures that the format of metrics entering the inference engine remains completely consistent regardless of hardware changes, thus resolving the issue of inapplicability of cross-platform metrics.

[0025] As shown in Table 1, the embodiments of this application can perform metadata identification and parsing logic to identify supplier information, extract hardware information, and establish a unified time baseline; based on the identified supplier, the corresponding mapping dictionary is called to convert the private indicator name into a standardized feature value or a standardized feature vector V. std Collect the baseline value V of the standard system feature vector of the server system under no business load. base_std The current value V of the standard system eigenvector under business load. curr_std .

[0026] Table 1

[0027] In this embodiment of the application, the baseline value V of the standard system feature vector under no service load can be used. base_std The current value V of the standard system eigenvector under business load. curr_std Encapsulate the code for use in subsequent bottleneck root cause analysis.

[0028] Optionally, in one embodiment of this application, after mapping the current running data to multiple current feature values ​​that meet preset standard conditions, the method further includes: calculating the maximum activity value of multiple physical cores of the server based on the multiple current feature values; determining that the server is in a silent idle state when the maximum activity value is less than a preset activity threshold; and determining that the server is in a business state when the maximum activity value is greater than or equal to the preset activity threshold.

[0029] The embodiments of this application can first determine whether the server is in a business state.

[0030] As one possible implementation method, embodiments of this application can extract the maximum activity values ​​of each physical core of the server. The calculation formula is as follows: ) in, It represents the percentage of idle cores within a server's system.

[0031] The embodiments of this application can be based on The first level of judgment is to determine whether there is any business pressure on the entire system. If it is determined to be in a silent, unloaded state, no performance bottleneck analysis will be performed; if This is determined to be a business status for further assessment.

[0032] This application embodiment uses maximum value judgment to capture single-core operating conditions, reducing the probability of false judgments of idleness, and avoiding unnecessary performance analysis when the server is in a silent idle state, thus saving resources.

[0033] In step S102, if the server is determined to be in a business state based on multiple current feature values ​​and the operating frequency of the central processing unit is less than or equal to a preset frequency threshold, the user's actual analysis intent is identified based on the description information.

[0034] The embodiments of this application can perform step-by-step judgment. The first level judges whether the server is in a business state. If it is in a business state, the second level judges whether the operating frequency of the central processing unit is abnormal.

[0035] For example, the second-level judgment can utilize This is implemented to determine whether the CPU operating frequency is normal under the whole system.

[0036] like This is determined to be a frequency anomaly, indicating that the CPU core operating frequency is abnormal; like The frequency is determined to be normal, and the third-level judgment is unlocked.

[0037] in, This is the threshold for the utilization of a single core in actual business operations, i.e., the non-idle ratio threshold. It can be adjusted according to the actual CPU architecture platform or business scenario. For example, it can be set to 0.65.

[0038] Furthermore, in this embodiment of the application, if it is determined that the server is in a business state and the operating frequency of the central processing unit is normal, it can be determined that the server needs to perform a third-level judgment. At this time, it is necessary to combine the user's actual analysis intention to determine the subsequent analysis direction.

[0039] Optionally, in one embodiment of this application, identifying a user's actual analytical intent based on descriptive information includes: extracting multiple keywords from the descriptive information; mapping the multiple keywords to corresponding sensitivity components based on preset tags and a pre-constructed component mapping table to obtain the user's analytical tendencies; and determining the user's actual sensitivity weights based on the analytical tendencies to determine the analytical intent using the actual sensitivity weights.

[0040] The embodiments of this application can perform preliminary text cleaning on the descriptive information.

[0041] This application embodiment can utilize NLP (Natural Language Processing) technology to convert user descriptions into intent vectors, such as keywords "low performance" or "slow response". It can identify the semantic closest to the pre-set label "lag / slow response" and then use the parsing engine to identify the business scenario (stream testing / network throughput intensive) and symptom characteristics (SSH (Secure Shell) latency / slow response).

[0042] At this point, the embodiments of this application can retrieve the corresponding intent weight matrix from a pre-set knowledge base to compare the identified keywords. For example, if symptoms related to "latency" are identified, the weight of attention to underlying indicators such as "memory access latency" and "instruction synchronization overhead" is automatically increased. .in, A vector consists of three core components: , , These represent the server's sensitivity to computing efficiency, backend obstruction, and kernel overhead, respectively.

[0043] In this embodiment of the application, the initial mapping table can be defined as follows: -{"Slow", "Timeout", "Cannot run", "Low performance computing score"...} Slow database queries, slow big data processing, slow response times, high latency in distributed storage, etc. System crashes, disconnections, high latency, packet loss, performance jitter, etc.

[0044] Among them, the normalization constraint principle is satisfied: Its initial value is: If users tend The initial value is:

[0045] If users tend The initial value is:

[0046] If users tend The initial value is:

[0047] For example, if the user inputs a description such as "the database is slow and has high latency", this application embodiment can obtain multiple keywords such as "database", "slow" and "latency".

[0048] Based on the above keywords, the embodiments of this application can refer to the mapping table to count the hit components. , , The number of keywords is used to determine the user's analytical tendency, and then the corresponding actual sensitivity weight is output.

[0049] By using preset labels and component mapping tables, this application embodiment can quantify user intent, thereby making the subsequent calculated cost-output ratio based on the relative value of user intent, thus clarifying the analysis direction of user expectations.

[0050] In step S103, the server's consumption-output ratio is calculated by combining the actual analysis intent and multiple current feature values. The bottleneck type of the server is determined by the consumption-output ratio, and the server's performance bottleneck is analyzed by using the bottleneck type and multiple current feature values ​​to obtain the server's performance analysis results.

[0051] Among them, the waste-to-output ratio can be used to characterize the user's analytical tendencies, which is the ratio between the server's theoretical maximum computing power and the actual wasted computing power.

[0052] Therefore, the embodiments of this application can combine the actual analysis intent and the current characteristic value that characterizes the actual loss of the server to calculate the loss output ratio, so as to determine the loss components of the server. Then, based on the judgment interval of multiple pre-set loss output ratios, the bottleneck type of the server can be determined. Under the constraint of the bottleneck type, more detailed performance bottleneck root cause localization can be performed based on the current characteristic value, thereby obtaining the analysis results of server performance.

[0053] Optionally, in one embodiment of this application, the loss-to-output ratio of the server is calculated by combining the actual analysis intent and multiple current feature values, including: calculating the server's loss score by combining the actual sensitivity weight corresponding to the analysis intent and multiple current feature values; and calculating the loss-to-output ratio by using the loss score and the server's current instruction output efficiency.

[0054] In some embodiments, the sensitivity weight and loss weight corresponding to the actual analysis intent can be weighted and summed. The detailed calculation formula is as follows:

[0055] Introducing the loss-output ratio The formula for calculating the loss-to-output ratio is as follows:

[0056] in, For the current instruction output efficiency; The characteristic gain constant is used to control the steepness of the mapping curve. Its value ranges from 0.1 to 10. It can be adjusted according to the loss sensitivity of the business. The default value is 1. It can be set to the point where the loss equals the output, which is the half-saturation point. As a smoothing factor, in cases where the system is extremely frozen or completely idle, the denominator may become 0, causing the program to crash. It can be set to 0.001.

[0057] By incorporating the user's analytical intent, root cause analysis becomes more relevant to the user's actual business scenarios, reducing the need for the user's professional knowledge.

[0058] Optionally, in one embodiment of this application, the method further includes: obtaining the actual performance bottleneck of the server as input by the user; and optimizing the sensitivity weight in the component mapping table based on the actual performance bottleneck if the actual performance bottleneck and the performance analysis results do not meet a preset consistency condition.

[0059] In this embodiment of the application, the sensitivity weights in the component mapping table are not fixed. Based on the actual performance bottlenecks reported by the user, or the user's evaluation of the root cause of the bottleneck in the analysis (such as the user believing that the analysis is wrong), the sensitivity weights in the component mapping table are optimized so that the analysis in this embodiment of the application can better fit the user's intention.

[0060] In this embodiment of the application, the bottleneck type can be obtained by analyzing the current sensitivity weight in the component mapping table, and the root cause of the bottleneck can be further analyzed based on the bottleneck type (this content will be described below and will not be repeated here).

[0061] In some embodiments, the actual performance bottleneck input by the user can be obtained and compared with the root cause of the bottleneck to determine whether the two are consistent. If they are inconsistent, it means that the content of this analysis does not match the user's expectations. Therefore, the sensitivity weight needs to be optimized.

[0062] In other embodiments, user-inputted evaluations of the analysis can be obtained, such as the user believing the analysis is incorrect, or the user performing server maintenance based on the analysis results but still failing to resolve the user's problem. In this case, it indicates that the content of the analysis does not meet the user's expectations, and therefore, the sensitivity weights need to be optimized.

[0063] Optionally, in one embodiment of this application, optimizing the sensitivity weights in the component mapping table based on actual performance bottlenecks includes: generating multiple sets of candidate sensitivity weights based on actual performance bottlenecks and a preset adjustment step size; using the multiple sets of sensitivity weights in conjunction with multiple sets of historical operating data from the server to obtain the predicted bottleneck types corresponding to the multiple sets of historical operating data; comparing the predicted bottleneck types with the corresponding actual bottleneck types to obtain the pass rate of the multiple sets of candidate sensitivity weights; and based on the pass rate, selecting the target sensitivity weight from the multiple sets of candidate sensitivity weights to replace the sensitivity weights.

[0064] In actual implementation, the embodiment of this application can pre-set the step size for each fine-tuning (e.g., 0.01). After user feedback, the embodiment of this application can generate multiple sets of candidate sensitivity weights according to the pre-set adjustment step size. For example, if the original sensitivity weight is (0.6, 0.1, 0.3), the fine-tuned candidate sensitivity weights can be (0.59, 0.11, 0.3), (0.61, 0.09, 0.3), or (0.59, 0.1, 0.31), etc.

[0065] For the multiple candidate sensitivity weights obtained, this application embodiment can acquire multiple sets of historical operating data to recalculate the historical feature values ​​in the historical operating data, thereby obtaining the predicted bottleneck type inferred by each set of candidate sensitivity weights based on the historical feature values.

[0066] The predicted bottleneck type is compared with the actual bottleneck type corresponding to the actual analysis results of historical operating data. If the results are consistent, the cumulative number is incremented by 1. The number of consistent results for each group of candidate sensitivity weights is counted. The pass rate is calculated by combining the total number of historical operating data. Then, the candidate sensitivity weight with the highest pass rate is selected as the target sensitivity weight from multiple groups of candidate sensitivity weights to optimize the sensitivity weight.

[0067] By recalculating historical operating data, it can be ensured that the new sensitivity weights after fine-tuning are in line with user preferences, reducing the probability of reverse modification.

[0068] Optionally, in one embodiment of this application, before replacing the sensitivity weight with the target sensitivity weight, the method further includes: obtaining the historical pass rate corresponding to the sensitivity weight; and replacing the sensitivity weight with the target sensitivity weight if the pass rate is greater than the historical pass rate.

[0069] It is understandable that there may be situations where the sensitivity weight used in the current component mapping table has a higher historical pass rate. In this case, if the target sensitivity weight is used to replace the sensitivity weight, it may increase the difference with user preferences, leading to a backward update.

[0070] Therefore, in this embodiment, parameters are only updated when the pass rate of the target sensitivity weight is higher than the pass rate of the sensitivity weight; otherwise, the update is discarded, thus enabling the bottleneck analysis algorithm to continuously iterate and learn. By using historical feature values ​​as a regression test set, it is ensured that the dynamically adjusted intent weight and feature gain can take into account typical historical scenarios, achieving convergence of the algorithm over long periods of operation.

[0071] Optionally, in one embodiment of this application, determining the bottleneck type of a server using the attrition-output ratio includes: calculating a corresponding correction parameter using the attrition-output ratio and multiple current feature values; and determining the bottleneck type by combining the correction parameter and the attrition-output ratio.

[0072] Understandably, the attrition-to-output ratio can only determine the severity of the attrition. However, server lag could be caused by insufficient memory bandwidth (hardware) or by issues with the operating logic. Relying solely on the attrition-to-output ratio to determine the bottleneck type makes it difficult to accurately identify the bottleneck.

[0073] Therefore, while determining the loss ratio, this application introduces a root cause localization and nonlinear correction parameter D, which is defined as follows:

[0074] By combining the correction parameters and the cost-to-output ratio, the embodiments of this application can determine the direction (bottleneck type) of the performance bottleneck, so as to facilitate further detailed analysis based on the bottleneck type to pinpoint the root cause of the bottleneck.

[0075] Optionally, in one embodiment of this application, determining the bottleneck type by combining the correction parameter and the loss-output ratio includes: determining the bottleneck type as a hardware-level bottleneck type when the loss-output ratio is greater than a first preset loss threshold and the correction parameter is less than or equal to a first preset correction threshold; determining the bottleneck type as a hybrid bottleneck type when the loss-output ratio is greater than the first preset loss threshold, the correction parameter is greater than the first preset correction threshold, and the correction parameter is less than or equal to a second preset correction threshold, wherein the second preset correction threshold is greater than the first preset correction threshold; and determining the bottleneck type as an internal friction overload bottleneck type when the loss-output ratio is greater than the first preset loss threshold and the correction parameter is greater than the second preset correction threshold.

[0076] In actual judgment, embodiments of this application can set judgment thresholds for the correction parameters and the consumption output ratio respectively, so as to determine the bottleneck type based on the judgment thresholds.

[0077] For example, when Therefore, the embodiments of this application can determine that the server's system output efficiency is high and the current loss is within the tolerance range; when According to the embodiments of this application, it can be determined that the loss is greater than half of the output, and the computing power has not been used for effective output. According to the embodiments of this application, the bottleneck type can be further determined based on the correction parameter D. when This indicates that more than 60% of the loss comes from non-kernel factors, such as memory access latency. In this case, the embodiment of this application can determine that the bottleneck type is a hardware-level bottleneck. when Since it is difficult to attribute a single cause, the embodiments of this application can determine that the bottleneck type is a hybrid bottleneck. when According to the embodiments of this application, it can be determined that kernel-mode overhead accounts for the majority. Therefore, the bottleneck can be determined as system-mode internal friction overload, that is, the bottleneck type is internal friction overload bottleneck type.

[0078] By classifying bottleneck types, complex microarchitectural events can be divided into three types, providing analytical direction for subsequent detailed analysis.

[0079] Optionally, in one embodiment of this application, when the bottleneck type is an internal friction overload bottleneck type, the performance bottleneck of the server is analyzed using the bottleneck type and multiple current feature values, including: obtaining a list of currently called functions of the server to obtain multiple currently called functions; sorting the multiple currently called functions according to the CPU time corresponding to the multiple currently called functions based on the multiple current feature values ​​to obtain the target called function; using the target called function as the bottleneck function to determine the root cause of the server's bottleneck based on the bottleneck function, and generating performance analysis results based on the root cause of the bottleneck.

[0080] In cases where the bottleneck type is internal friction overload bottleneck, this application embodiment can use a performance analysis (profiling) tool, utilizing a hardware performance monitoring unit and kernel trace points, to determine the code currently running by the CPU and generate a list of currently called functions.

[0081] Furthermore, in this embodiment, the currently called functions in the list of currently called functions can be displayed in descending order according to CPU time consumption, and the calling function with the highest internal consumption can be highlighted in red and marked as the bottleneck function.

[0082] The embodiments of this application can trace back the call chain of the bottleneck function. By combining the function name characteristics of the bottleneck function with the call chain context, the embodiments of this application can determine the root cause of the performance bottleneck.

[0083] After identifying the target calling function, the embodiments of this application can achieve automated analysis by combining the function name characteristics of the bottleneck function and the call chain context, without the need to understand the function logic, thus reducing the reliance on the intervention of technical personnel.

[0084] Optionally, in one embodiment of this application, when the bottleneck type is a hardware-level bottleneck type or a hybrid bottleneck type, analyzing the server's performance bottleneck using the bottleneck type and multiple current feature values ​​includes: extracting multiple current running values ​​that match the hardware-level bottleneck type or the hybrid bottleneck type from the multiple current feature values; calculating the differences between the multiple current running values ​​and their corresponding baseline running values ​​to obtain multiple baseline differences; sorting the multiple current running values ​​based on the absolute values ​​of the multiple baseline differences to obtain a first sorting result, and determining the root cause of the server's bottleneck based on the first sorting result.

[0085] When the bottleneck type is a hardware-level bottleneck or a hybrid bottleneck type, the embodiments of this application can perform differential calculations on some feature values, i.e., the current running values. The calculation expression can be as follows:

[0086] Among them, the baseline operating value Current running value benchmark difference = .

[0087] This application embodiment can sort multiple current operating values ​​according to the absolute value of the benchmark difference, and determine the current operating value with the largest deviation from the benchmark based on the sorting result, and determine the bottleneck root cause based on the current operating value with the largest benchmark deviation, so as to achieve accurate location of the bottleneck root cause.

[0088] Optionally, in one embodiment of this application, multiple current running values ​​are sorted based on the absolute values ​​of multiple benchmark differences to obtain a first sorting result, and the bottleneck root cause of the server is determined based on the first sorting result, including: obtaining a first target running value at a target position in the sorting result; if the first target running value is a front-end bottleneck value, determining that the bottleneck root cause is limited by the central processing unit core; if the first target running value is a speculative bottleneck value, determining that the bottleneck root cause is abnormal business code logic or abnormal concurrency logic; if the first target running value is a back-end bottleneck value, determining that the bottleneck root cause is limited by memory or cache.

[0089] The embodiments of this application can be used for... Sort the data, then display it from largest to smallest, selecting only the maximum value for four-level analysis. The highest value indicates a detected front-end supply shortage, with the current bottleneck located within the CPU core; if... The largest value indicates that CPU branch prediction failure was detected, and the current bottleneck lies in complex business logic or complex concurrency logic; if The highest value indicates that a backend supply shortage has been detected, and the current bottleneck is either due to limited memory or core resources being limited by cache.

[0090] By using the operating value with the largest deviation from the benchmark, the embodiments of this application can determine the root cause of the bottleneck, thereby enabling automatic analysis of the root cause of the bottleneck, facilitating the generation of analysis results, and guiding subsequent server maintenance.

[0091] Optionally, in one embodiment of this application, when the bottleneck root cause is memory or cache limitation, the actual performance of the server is analyzed using the bottleneck type and current running data, including: extracting L3 cache miss rate, hyper-threading contention loss value, remote memory bandwidth ratio, cross-physical CPU chip access traffic ratio, and main memory bandwidth saturation from multiple current feature values ​​based on the bottleneck root cause of memory or cache limitation; sorting the L3 cache miss rate, hyper-threading contention loss value, remote memory bandwidth ratio, cross-physical CPU chip access traffic ratio, and main memory bandwidth saturation according to a preset order to obtain a second sorting result; determining at least one second target running value that meets the preset sorting conditions based on the second sorting result; and setting the second target running value as the L3 cache miss rate and hyper-threading contention loss value. Under the condition of limited cache resources, the bottleneck root cause is determined to be limited memory access resources. Under the condition of the second target operating value being the proportion of remote memory bandwidth and the proportion of cross-physical CPU chip access traffic, the bottleneck root cause is determined to be limited non-consistent memory access resources. Specifically, the proportion of cross-physical CPU chip access traffic is compared with the corresponding second preset bottleneck threshold. If the proportion of cross-physical CPU chip access traffic is greater than the second preset percentage of the second preset bottleneck threshold, the bottleneck root cause is determined to be limited bandwidth between CPUs. Under the condition of the second target operating value being main memory bandwidth saturation, the main memory bandwidth saturation is compared with the corresponding first preset bottleneck threshold. If the main memory bandwidth saturation is greater than the first preset percentage of the first preset bottleneck threshold, the bottleneck root cause is determined to be limited memory bandwidth.

[0092] When the bottleneck is caused by memory or cache constraints, embodiments of this application can perform further root cause analysis to address the issue. Sort the data and display it from highest to lowest. The detailed definition is as follows: like and A high value indicates that the bottleneck is at the core because cache resources are limited; like and A high value indicates that the bottleneck is at the core due to limited cross-NUMA resources; furthermore, in When the value reaches more than 90% of the bottleneck threshold, the embodiments of this application can further determine that the root cause of the bottleneck is limited bandwidth between CPUs.

[0093] like A high value, if it reaches more than 70% of the bottleneck threshold, indicates that the bottleneck is limited memory bandwidth.

[0094] This application's embodiments can further subdivide the bottleneck of limited memory or cache into three specific hardware root causes: limited cache resources, limited inconsistent memory access resources, or limited memory bandwidth. By combining conditions for judgment, the risk of misjudgment caused by occasional fluctuations in a single indicator is eliminated, which can be used for subsequent server maintenance guidance.

[0095] Based on this, the embodiments of this application can also optimize the above-mentioned bottleneck threshold according to the evaluation of the bottleneck root cause analysis results based on user feedback, so as to achieve iterative learning optimization and make the bottleneck root cause analysis results more in line with user expectations.

[0096] like Figure 2 As shown, the working principle of the server performance analysis method of this application embodiment is explained in detail with reference to an example.

[0097] like Figure 2 As shown, embodiments of this application may include the following steps: Step S1: Obtain the description information input by the user. This embodiment of the application can receive description information input by the user, that is, the user's description of performance analysis requirements in human natural language.

[0098] Step S2: Analyze user intent. This application embodiment can employ natural language processing technology to extract business scenarios and symptom features from unstructured text input by the user.

[0099] Step S3: Obtain the server's current operating data. This embodiment of the application can obtain the server's current operating data when determining the user's expectation for bottleneck analysis based on the description information.

[0100] Step S4: Perform cross-architecture metric processing on the current running data. This embodiment of the application can map the raw hardware counters of heterogeneous CPUs to a set of standardized performance characteristic values ​​V. std (e.g., front-end limitation rate, back-end limitation rate, instructions per clock cycle, etc.).

[0101] Step S5, correlation reasoning, root cause analysis. Combining the user's analytical intent and performance characteristic values, identify the bottleneck root causes that match the current business symptoms.

[0102] Step S6: Generate a diagnostic report.

[0103] Step S7, Feedback Optimization. Based on user feedback on the diagnostic report, make corresponding optimizations.

[0104] In summary, this application embodiment can unify microarchitecture metrics across different platforms. A single set of universal, multi-dimensional microarchitecture metrics and a unified formula can be used to determine whether the current bottleneck is a kernel consumption bottleneck, a hybrid bottleneck, or a pure hardware bottleneck. By introducing user intent weights, this application embodiment makes root cause analysis more closely aligned with actual customer business scenarios and reduces reliance on user technical experience. Based on the user's final feedback, this application embodiment can build a local historical diagnostic knowledge base, enabling continuous iterative learning of the bottleneck analysis algorithm and achieving convergence of the algorithm over long-term operation.

[0105] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0106] like Figure 3 As shown, embodiments of this application also provide a server performance analysis apparatus, including: Specifically, the first acquisition module 100 is used to acquire the current operating data of the server in response to the description information input by the user.

[0107] The identification module 200 is used to identify the user's actual analysis intent based on descriptive information when the server is determined to be in a business state based on multiple current feature values ​​and the operating frequency of the central processing unit is less than or equal to a preset frequency threshold.

[0108] The analysis module 300 is used to calculate the server's consumption-output ratio by combining the actual analysis intent and multiple current feature values, determine the server's bottleneck type using the consumption-output ratio, and analyze the server's performance bottleneck using the bottleneck type and current running data to obtain the server's performance analysis results.

[0109] Optionally, in one embodiment of this application, the analysis module 300 includes: The first calculation unit is used to calculate the corresponding correction parameters using the loss-output ratio and multiple current feature values.

[0110] The first determining unit is used to determine the bottleneck type by combining the correction parameters and the output-consumption ratio.

[0111] Optionally, in one embodiment of this application, the first determining unit includes: The first determining subunit is used to determine the bottleneck type as a hardware-level bottleneck type when the loss-to-output ratio is greater than a first preset loss threshold and the correction parameter is less than or equal to a first preset correction threshold.

[0112] The second determining subunit is used to determine the bottleneck type as a hybrid bottleneck type when the loss-to-output ratio is greater than the first preset loss threshold, the correction parameter is greater than the first preset correction threshold, and the correction parameter is less than or equal to the second preset correction threshold. The second preset correction threshold is greater than the first preset correction threshold.

[0113] The third determining subunit is used to determine the bottleneck type as an internal friction overload bottleneck type when the loss-to-output ratio is greater than the first preset loss threshold and the correction parameter is greater than the second preset correction threshold.

[0114] Optionally, in one embodiment of this application, when the bottleneck type is an internal friction overload bottleneck type, the analysis module 300 includes: The first acquisition unit is used to acquire the list of currently called functions of the server, thereby obtaining multiple currently called functions.

[0115] The second acquisition unit is used to sort multiple currently called functions based on multiple current feature values ​​and the CPU time corresponding to the multiple currently called functions, so as to obtain the target called function.

[0116] The second determining unit is used to take the target calling function as the bottleneck function, determine the root cause of the bottleneck in the server based on the bottleneck function, and generate performance analysis results based on the root cause of the bottleneck.

[0117] Optionally, in one embodiment of this application, when the bottleneck type is a hardware-level bottleneck type or a hybrid bottleneck type, the analysis module 300 includes: The first extraction unit is used to extract multiple current running values ​​from multiple current feature values ​​that match the hardware-level bottleneck type or the hybrid bottleneck type.

[0118] The second calculation unit is used to calculate the differences between multiple current running values ​​and their corresponding baseline running values, thereby obtaining multiple baseline differences.

[0119] The first sorting unit is used to sort multiple current running values ​​based on the absolute value of multiple benchmark differences to obtain a first sorting result, and to determine the root cause of the server bottleneck based on the first sorting result.

[0120] Optionally, in one embodiment of this application, the first sorting unit includes: The acquisition sub-unit is used to acquire the first target running value at the target position in the sorting result.

[0121] The fourth determination subunit is used to determine the root cause of the bottleneck as a limitation of the central processing unit core, given that the first target running value is the front-end bottleneck value.

[0122] The fifth determination subunit is used to determine the root cause of the bottleneck as either an anomaly in the business code logic or an anomaly in the concurrency logic, given that the first target running value is the estimated bottleneck value.

[0123] The sixth determination subunit is used to determine the root cause of the bottleneck, which is limited by memory or cache, when the first target running value is the backend bottleneck value.

[0124] Optionally, in one embodiment of this application, when the bottleneck root cause is limited by memory or cache, the analysis module 300 includes: The second extraction unit is used to extract the L3 cache miss rate, hyper-threading contention loss value, remote memory bandwidth ratio, cross-physical CPU chip access traffic ratio, and main memory bandwidth saturation from multiple current feature values ​​based on the bottleneck root cause of memory or cache constraints.

[0125] The second sorting unit is used to sort the L3 cache miss rate, hyper-threading contention loss value, remote memory bandwidth ratio, cross-physical CPU chip access traffic ratio, and main memory bandwidth saturation according to a preset order, and obtain the second sorting result.

[0126] The third determining unit is used to determine at least one second target running value that satisfies the preset sorting conditions based on the second sorting result.

[0127] The fourth determining unit is used to determine the root cause of the bottleneck as limited cache resources when the second target running value is the level 3 cache miss rate and the hyper-threading contention overhead value.

[0128] The fifth determining unit is used to determine the bottleneck root cause as limited non-consistent memory access resources when the second target operating value is the proportion of remote memory bandwidth and the proportion of cross-physical CPU chip access traffic.

[0129] The sixth determining unit is used to compare the main memory bandwidth saturation with the corresponding first preset bottleneck threshold when the second target operating value is the main memory bandwidth saturation, and to determine the bottleneck root cause as memory bandwidth limitation when the main memory bandwidth saturation is greater than the first preset percentage of the first preset bottleneck threshold.

[0130] Optionally, in one embodiment of this application, the analysis module 300 further includes: The comparison module is used to compare the proportion of traffic accessed across physical central processing unit chips with the corresponding second preset bottleneck threshold.

[0131] The first determining module is used to determine that the bottleneck root cause is limited bandwidth between central processing units when the proportion of cross-physical central processing unit chip access traffic is greater than a second preset percentage of a second preset bottleneck threshold.

[0132] Optionally, in one embodiment of this application, the server performance analysis device 10 further includes: The calculation module is used to calculate the maximum activity of multiple physical cores of the server based on multiple current feature values.

[0133] The second determination module is used to determine that the server is in a silent, idle state when the maximum activity value is less than the preset activity threshold.

[0134] The third determination module is used to determine whether the server is in a business state when the maximum activity value is greater than or equal to the preset activity threshold.

[0135] Optionally, in one embodiment of this application, the identification module 200 includes: The third extraction unit is used to extract multiple keywords from the description information.

[0136] The mapping unit is used to map multiple keywords to corresponding sensitivity components based on preset tags and a pre-built component mapping table, in order to obtain the user's analytical preferences.

[0137] The seventh determination unit is used to determine the user's actual sensitivity weight based on the analysis tendency, so as to determine the analysis intent using the actual sensitivity weight.

[0138] Optionally, in one embodiment of this application, the analysis module 300 includes: The third calculation unit is used to calculate the server's loss score by combining the actual sensitivity weight corresponding to the analysis intent and multiple current feature values.

[0139] The fourth calculation unit is used to calculate the loss-to-output ratio using the loss score and the server's current instruction output efficiency.

[0140] Optionally, in one embodiment of this application, it further includes: The second acquisition module is used to acquire the actual performance bottleneck of the server as input by the user.

[0141] The optimization module is used to optimize the sensitivity weights in the component mapping table based on the actual performance bottleneck when the preset consistency conditions between the actual performance bottleneck and the performance analysis results are not met.

[0142] Optionally, in one embodiment of this application, the optimization module includes: The generation unit is used to generate multiple sets of candidate sensitivity weights based on actual performance bottlenecks and a preset adjustment step size.

[0143] The third acquisition unit is used to combine multiple sets of sensitivity weights with multiple sets of historical operating data from the server to obtain the predicted bottleneck types corresponding to the multiple sets of historical operating data.

[0144] The fourth acquisition unit is used to compare the predicted bottleneck type with the corresponding actual bottleneck type to obtain the pass rate of multiple sets of candidate sensitivity weights.

[0145] The first processing unit is used to filter out the target sensitivity weight from multiple groups of candidate sensitivity weights based on the pass rate, so as to replace the sensitivity weight with the target sensitivity weight.

[0146] Optionally, in one embodiment of this application, the optimization module further includes: The fifth acquisition unit is used to acquire the historical pass rate corresponding to the sensitivity weight.

[0147] The second processing unit is used to replace the sensitivity weight with the target sensitivity weight when the pass rate is greater than the historical pass rate.

[0148] For a description of the features in the embodiment corresponding to the server performance analysis device, please refer to the relevant description in the embodiment corresponding to the server performance analysis method, which will not be repeated here.

[0149] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described server performance analysis method embodiments.

[0150] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described server performance analysis method embodiments when running.

[0151] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0152] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described server performance analysis method embodiments.

[0153] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described server performance analysis method embodiments.

[0154] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0155] The above provides a detailed description of a server performance analysis method and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for analyzing server performance, characterized in that, include: In response to the description information input by the user, the server's current operating data is obtained, and the current operating data is mapped to multiple current feature values ​​that meet preset standard conditions; If the server is determined to be in a business state based on multiple current feature values, and the operating frequency of the central processing unit is less than or equal to a preset frequency threshold, the user's actual analysis intent is identified based on the description information. Based on the actual analysis intent and multiple current feature values, the server's consumption-output ratio is calculated. The bottleneck type of the server is determined using the consumption-output ratio. The performance bottleneck of the server is analyzed using the bottleneck type and multiple current feature values ​​to obtain the server's performance analysis results.

2. The method according to claim 1, characterized in that, The process of determining the bottleneck type of the server using the loss-to-output ratio includes: Calculate the corresponding correction parameters using the loss-to-output ratio and multiple current feature values; The bottleneck type is determined by combining the correction parameters and the loss-to-output ratio.

3. The method according to claim 2, characterized in that, Determining the bottleneck type by combining the correction parameters and the loss-to-output ratio includes: If the loss-to-output ratio is greater than a first preset loss threshold and the correction parameter is less than or equal to a first preset correction threshold, the bottleneck type is determined to be a hardware-level bottleneck type. If the loss-to-output ratio is greater than a first preset loss threshold, the correction parameter is greater than a first preset correction threshold, and the correction parameter is less than or equal to a second preset correction threshold, then the bottleneck type is determined to be a hybrid bottleneck type, wherein the second preset correction threshold is greater than the first preset correction threshold. If the loss-to-output ratio is greater than a first preset loss threshold and the correction parameter is greater than a second preset correction threshold, the bottleneck type is determined to be an internal friction overload bottleneck type.

4. The method according to claim 3, characterized in that, When the bottleneck type is the internal friction overload bottleneck type, the analysis of the server's performance bottleneck using the bottleneck type and multiple current feature values ​​includes: Obtain the list of currently invoked functions of the server to obtain multiple currently invoked functions; Based on multiple current feature values, the multiple current calling functions are sorted according to the CPU time corresponding to the multiple current calling functions to obtain the target calling function; The target call function is used as the bottleneck function to determine the root cause of the bottleneck in the server, and the performance analysis results are generated based on the root cause of the bottleneck.

5. The method according to claim 3, characterized in that, When the bottleneck type is the hardware-level bottleneck type or the hybrid bottleneck type, the analysis of the server's performance bottleneck using the bottleneck type and multiple current feature values ​​includes: Extract multiple current running values ​​that match the hardware-level bottleneck type or the hybrid bottleneck type from the multiple current feature values; Calculate the differences between the current operating values ​​and the corresponding baseline operating values ​​to obtain multiple baseline differences; The current operating values ​​are sorted based on the absolute values ​​of multiple benchmark differences to obtain a first sorting result, and the bottleneck root cause of the server is determined based on the first sorting result.

6. The method according to claim 5, characterized in that, The process of sorting multiple current operating values ​​based on the absolute values ​​of multiple benchmark differences to obtain a first sorting result, and determining the bottleneck root cause of the server based on the first sorting result, includes: Obtain the first target running value that is at the target position in the sorting results; When the first target operating value is the front-end bottleneck value, it is determined that the root cause of the bottleneck is the limitation of the central processing unit core. If the first target running value is the estimated bottleneck value, the root cause of the bottleneck is determined to be an abnormality in the business code logic or an abnormality in the concurrency logic. If the first target running value is the backend bottleneck value, the root cause of the bottleneck is determined to be limited by memory or cache.

7. The method according to claim 6, characterized in that, When the bottleneck is caused by memory or cache constraints, the analysis of the server's performance bottleneck using the bottleneck type and multiple current feature values ​​includes: Based on the bottleneck root cause of the aforementioned memory or cache limitation, the following are extracted from multiple current feature values: L3 cache miss rate, hyper-threading contention loss value, remote memory bandwidth ratio, cross-physical CPU chip access traffic ratio, and main memory bandwidth saturation. Based on a preset order, the L3 cache miss rate, the hyper-threading contention loss value, the remote memory bandwidth ratio, the cross-physical CPU chip access traffic ratio, and the main memory bandwidth saturation are sorted to obtain a second sorting result; Based on the second sorting result, at least one second target running value that meets the preset sorting conditions is determined; Given that the second target running value is the level 3 cache miss rate and the hyper-threading contention overhead value, the bottleneck root cause is determined to be limited cache resources; Given that the second target operating value is the proportion of remote memory bandwidth and the proportion of cross-physical CPU chip access traffic, the bottleneck root cause is determined to be limited non-consistent memory access resources. When the second target operating value is the main memory bandwidth saturation, the main memory bandwidth saturation is compared with the corresponding first preset bottleneck threshold. If the main memory bandwidth saturation is greater than the first preset bottleneck threshold by a first preset percentage, the root cause of the bottleneck is determined to be limited memory bandwidth.

8. The method according to claim 7, characterized in that, After determining that the bottleneck root cause is limited by inconsistent memory access resources, the following is also included: Compare the percentage of cross-physical CPU chip access traffic with the corresponding second preset bottleneck threshold; If the percentage of cross-physical CPU chip access traffic is greater than a second preset percentage of the second preset bottleneck threshold, the bottleneck root cause is determined to be limited bandwidth between CPUs.

9. The method according to claim 1, characterized in that, After mapping the current running data to multiple current feature values ​​that satisfy preset standard conditions, the method further includes: Based on multiple current feature values, calculate the maximum activity value of multiple physical cores of the server; If the maximum activity level is less than a preset activity threshold, the server is determined to be in a silent, unloaded state. If the maximum activity value is greater than or equal to the preset activity threshold, the server is determined to be in the business state.

10. The method according to claim 1, characterized in that, The step of identifying the user's actual analytical intent based on the descriptive information includes: Extract multiple keywords from the description information; Based on preset tags and a pre-built component mapping table, multiple keywords are mapped to corresponding sensitivity components to obtain the user's analytical tendencies. Based on the analytical tendency, the actual sensitivity weight of the user is determined, and the analytical intent is determined using the actual sensitivity weight.

11. The method according to claim 10, characterized in that, The calculation of the server's cost-benefit ratio, combining the actual analytical intent and multiple current feature values, includes: By combining the actual sensitivity weights corresponding to the analytical intent and multiple current feature values, the server's loss score is calculated; The loss-to-output ratio is calculated using the loss score and the server's current instruction output efficiency.

12. The method according to claim 10, characterized in that, Also includes: Obtain the actual performance bottleneck of the server as input by the user; If the actual performance bottleneck and the performance analysis results do not meet the preset consistency conditions, the sensitivity weights in the component mapping table are optimized based on the actual performance bottleneck.

13. The method according to claim 12, characterized in that, The optimization of the sensitivity weights in the component mapping table based on the actual performance bottleneck includes: Based on the actual performance bottleneck, and based on a preset adjustment step size, multiple sets of candidate sensitivity weights are generated. By combining multiple sets of the aforementioned sensitivity weights with multiple sets of historical operating data of the server, the predicted bottleneck types corresponding to the multiple sets of historical operating data are obtained respectively. By comparing the predicted bottleneck type with the corresponding actual bottleneck type, the pass rate of multiple sets of candidate sensitivity weights is obtained; Based on the pass rate, a target sensitivity weight is selected from multiple sets of candidate sensitivity weights, and the target sensitivity weight is used to replace the sensitivity weight.

14. The method according to claim 13, characterized in that, Before replacing the sensitivity weight with the target sensitivity weight, the method further includes: Obtain the historical pass rate corresponding to the sensitivity weight; If the pass rate is greater than the historical pass rate, the sensitivity weight is replaced with the target sensitivity weight.

15. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the server performance analysis method as described in any one of claims 1 to 14.

Images