A data center resource regulation method, system, program product and storage medium

Abstract

A data center resource regulation method, system, program product and storage medium. The method comprises: when a high-priority first application is found to have a resource bottleneck due to waiting for an input / output operation, locating a second application that is positively correlated with the first application IO load change trend and has a lower priority; generating a response feature containing expected information entropy, data structure and size according to the request content of the first application through a pre-trained business logic model; comparing the actual response feature of the second application with the expected feature to calculate a content correlation score; when the score is lower than a trust threshold, it is proved that the response content is irrelevant to the business logic, and the upper limit of the IO resource quota of the second application is reduced, and the quota is increased again after the waiting problem of the first application is alleviated. The technical scheme provided by the application improves the accuracy of resource regulation of the data center under complex application relationship.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing, and in particular to a data center resource regulation method, system, program product, and storage medium. Background Technology

[0002] With the rapid development of cloud computing, big data, and artificial intelligence technologies, data centers have become the core infrastructure supporting the operation of the digital economy. To maximize return on investment and reduce operating costs, the high-density deployment of various types of applications on the same physical cluster has become the mainstream model for data center resource management.

[0003] In related technologies, to address resource conflicts arising from hybrid deployments, one approach is to utilize hardware performance monitoring units (such as Intel RDT) to monitor the real-time usage of shared resources such as last-level cache and memory bandwidth by various applications. When performance metrics (such as latency) of core applications are detected to be deteriorating, the system will associate this with the application with the highest resource usage during the same period and invoke operating system-level resource isolation technologies (such as cgroups) to suppress it, thereby ensuring the performance of core applications.

[0004] However, in related technologies, because control decisions rely on quantitative indicators of resource consumption, inaccurate control behavior can have detrimental effects when there is business collaboration between high-priority and low-priority applications. When a low-priority application is responding to data requests from a core high-priority application, the legitimate high load generated by the low-priority application may show a high resource utilization rate, thus being misjudged as malicious contention. In this case, the suppression of the low-priority application by related technologies may actually prolong the waiting time for the high-priority application to obtain the required data, thereby exacerbating the performance degradation problem of the high-priority application. Summary of the Invention

[0005] This application provides a data center resource control method, system, program product, and storage medium, which improves the accuracy of resource control in data centers under complex application relationships.

[0006] The first aspect of this application provides a data center resource regulation method, the method comprising:

[0007] Monitor the resource waiting index of the first application running in the data center; when the resource waiting index exceeds the preset resource waiting index threshold, identify the application that is positively correlated with the change trend of the real-time input / output operation load and the change trend of the resource waiting index, and whose business priority is lower than the first business priority corresponding to the first application, as the second application; calculate the information entropy of the actual response data generated by the second application in response to the request of the first application, and extract the data structure and data size of the actual response data to obtain the actual response features; based on the request content sent by the first application to the second application through a pre-trained business logic model, generate expected response features including the expected information entropy range, expected data structure, and expected data size; compare the actual response features with the expected response features to obtain the information entropy deviation value, structural similarity score, and size matching score, and perform weighted summation according to preset weights to obtain the content relevance score; when the content relevance score does not exceed the preset trust threshold, reduce the upper limit of the resource quota for the input / output operation of the second application by a preset first adjustment ratio; when the resource waiting index is lower than the preset first resource waiting index threshold, increase the upper limit of the resource quota for the input / output operation of the second application by a preset second adjustment ratio.

[0008] In the above embodiments, after identifying low-priority applications related to the performance degradation of high-priority applications, this solution does not directly suppress them based on resource utilization like existing technologies. Instead, it introduces a content relevance scoring mechanism. This scoring compares the actual response of the application with the expected response generated based on business logic to determine whether the high resource consumption of low-priority applications is providing legitimate and valuable services to high-priority applications. This avoids misjudging legitimate business collaboration as malicious resource contention, thus preventing the exacerbation of core application performance degradation due to erroneous suppression. Ultimately, it improves the accuracy of resource allocation in data centers under complex application relationships.

[0009] In conjunction with some embodiments of the first aspect, in some embodiments, after calculating the information entropy of the actual response data generated by the second application responding to the request of the first application, and extracting the data structure and data size of the actual response data to obtain the actual response characteristics, the method further includes:

[0010] Obtain a sample set of other response data from other applications with different business priorities for the second application; calculate the other data information entropy, other data structure, and other data size of the other response data in the sample set to obtain other response feature data groups; calculate the mean variance of the feature data among the means of multiple other response feature data corresponding to each business priority in the other response feature data group; when the mean variance of any feature data exceeds the corresponding preset variance threshold, read the service quality configuration parameters corresponding to different business priorities from the configuration file of the second application; normalize the actual response features based on the service quality configuration parameters to obtain the corrected actual response features.

[0011] In the above embodiments, by calculating the mean and variance of the characteristic data of the second application's responses to clients of different priorities, it is possible to identify whether the response differences originate from random anomalies or from a preset legitimate Quality of Service (QoS) policy. After identifying the legitimate QoS policy, the original observation data is normalized using configuration parameters. This restores a corrected response characteristic that excludes the impact of legitimate service degradation and is fair enough for comparison. This avoids misjudging normal differentiated service behavior of applications as faults, ensuring the fairness of subsequent evaluations, and thus improving the accuracy of resource allocation in data centers under complex application relationships.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, after reading the service quality configuration parameters corresponding to different service priorities from the configuration file of the second application, the method further includes:

[0013] Obtain the service call chain diagram of the second application and identify the set of downstream applications of the second application; for each downstream application in the set of downstream applications, calculate the mean and variance of downstream feature data when responding to requests of different priorities; obtain the downstream service quality configuration parameters of each downstream application in the set of downstream applications; calculate the business priority difference coefficient corresponding to each downstream application in the set of downstream applications; weight the service quality configuration parameters based on the business priority difference coefficient to obtain the combined configuration parameters that take into account the impact of downstream services; normalize the actual response characteristics based on the combined configuration parameters to obtain the corrected actual response characteristics.

[0014] In the above embodiments, by analyzing the service call chain graph, the diagnostic perspective for performance issues is extended from isolated applications to the complete downstream service dependency chain. After identifying downstream applications, the legitimate performance fluctuations introduced by the QoS policies of each downstream application are quantified by calculating the business priority difference coefficient of each downstream application. Subsequently, by weighting and combining these impacts, a combined configuration parameter that comprehensively reflects the overall impact of downstream applications is constructed. Finally, this parameter is used to normalize the original observation data. This is equivalent to subtracting all legitimate performance jitter caused by downstream dependencies when evaluating the second application, avoiding the incorrect attribution of downstream problems to upstream applications, thus improving the accuracy of resource allocation in data centers under complex application relationships.

[0015] In conjunction with some embodiments of the first aspect, in some embodiments, when the resource waiting index exceeds a preset resource waiting index threshold, after determining the potential impact application that is positively correlated with the change trend of the real-time input / output operation load and the change trend of the resource waiting index, and whose business priority is lower than the first business priority corresponding to the first application, as the second application, the method further includes:

[0016] Obtain network connection information of the second application; when the ratio of the number of outbound connections to the number of inbound connections of the second application exceeds a preset proxy feature threshold, track the outbound data flow of the second application and identify the target application of the outbound data flow; determine the target application as the second application.

[0017] In the above embodiments, by analyzing the ratio of outbound connections to inbound connections, it is possible to identify whether the observed application is acting as a service gateway or proxy. Once proxy characteristics are identified, the outbound data flow is further tracked until the backend target application that actually processes the business logic is located. This solves the problem of incorrect attribution of analysis targets caused by the presence of middleware, ensuring that subsequent analysis and control always target the root cause of the problem, rather than innocent messenger applications, thus improving the accuracy of resource control in data centers under complex application relationships.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after reducing the resource quota limit for the input / output operations of the second application by a preset first adjustment ratio, the method further includes:

[0019] The system counts the number of small data responses (smaller than expected) from the second application's response to the first application. When the number of small data responses exceeds a preset threshold within a preset time window, the system extracts the field type distribution characteristics from each response. The system calculates the similarity between the field type distribution characteristics and the field type distribution characteristics of historical normal response data. When the number of similarities below a preset similarity threshold exceeds a preset low similarity threshold, the system reduces the upper limit of the resource quota for the second application according to a preset penalty ratio.

[0020] In the above embodiments, when a potentially impactful application frequently returns small data responses, it is not classified as a fault. Instead, a deep validation of the distribution characteristics of the response data field types is performed. This penetrates the superficial appearance of data size and, by comparing the response content structure, distinguishes between a legitimate empty response with no query results and an error message indicating service anomaly. This method of identification, from size to structure to persistence, avoids incorrectly penalizing applications returning legitimate empty data, locates abnormal applications trapped in persistent faults and wasting resources, and thus improves the accuracy of resource allocation in data centers under complex application relationships.

[0021] In conjunction with some embodiments of the first aspect, in some embodiments, after reducing the resource quota limit of the second application according to a preset penalty ratio when the number of times the similarity is lower than a preset similarity threshold exceeds a preset low similarity number threshold, the method further includes:

[0022] Record the number of times the second application responds to the first application within a preset detection period. When the number of responses exceeds the preset upper limit of the number of responses, calculate the variance of the data size of each response within the detection period. If the variance of the data size is less than the preset variance threshold, and the ratio of the total size of the response data within the detection period to the size of the historical single response data is greater than the preset segmentation ratio threshold, then limit the maximum number of concurrent responses of the second application to the preset concurrent threshold.

[0023] In the above embodiment, after an abnormal increase in the number of responses is detected, the variance of the data size is calculated to first identify whether the response stream has a highly consistent small packet characteristic; then, by verifying whether the total size of the response is comparable to a historical single large response, it is further confirmed that this is a specific inefficient behavior of splitting a single large response into a large number of small data packets for transmission; this dual verification mechanism distinguishes response fragmentation from normal business burst traffic, avoids misjudgment, and allows the system to take targeted measures to limit concurrency, thus improving the accuracy of resource control in data centers under complex application relationships.

[0024] In conjunction with some embodiments of the first aspect, in some embodiments, after increasing the resource quota limit for the input / output operations of the second application by a preset second adjustment ratio, the method further includes:

[0025] At the end of each preset sampling period, the number of requests sent from the first application to the second application is obtained; the request number growth rate within two adjacent sampling periods is calculated; when the request number growth rate exceeds a preset growth rate threshold, the request processing queue length of the second application is calculated; if the request processing queue length exceeds a preset queue length threshold, and the number of consecutive times the content relevance score exceeds a preset trust threshold exceeds a preset consecutive number threshold, then the resource quota restriction on the second application is lifted, and the lifting time is proportional to the request number growth rate.

[0026] In the above embodiments, when a surge in the number of requests (request growth rate) is detected and a processing bottleneck (request processing queue length) has formed at the second application, the consistently positive content relevance score is verified to prove that the current resource shortage stems from a legitimate, high-value business surge. This removes resource restrictions on the second application, proactively ensuring the smooth operation of the core business chain and avoiding the problem of impairing the performance of high-priority applications due to untimely regulation. It also allows the regulation strategy to dynamically adapt to changes in business traffic, thus improving the accuracy of resource regulation in data centers under complex application relationships.

[0027] In a second aspect, embodiments of this application provide a data center resource control system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the data center resource control system to perform the method described in the first aspect and any possible implementation thereof.

[0028] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a data center resource control system, cause the data center resource control system to execute the method described in the first aspect and any possible implementation thereof.

[0029] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a data center resource control system, cause the data center resource control system to perform the method described in the first aspect and any possible implementation thereof.

[0030] Understandably, the data center resource control system provided in the second aspect, the computer program product provided in the third aspect, and the computer storage medium provided in the fourth aspect are all used to execute the data center resource control method provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0031] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0032] After identifying low-priority applications related to the performance degradation of high-priority applications, this application does not rely on resource utilization as in existing technologies for suppression. Instead, it introduces a content relevance scoring mechanism. This scoring compares the actual response of the application with the expected response generated based on business logic to determine whether the high resource consumption of low-priority applications is providing legitimate and valuable services to high-priority applications. This avoids misjudging legitimate business collaborations as malicious resource contention, thus preventing the exacerbation of core application performance degradation due to erroneous suppression. Ultimately, it improves the accuracy of resource allocation in data centers under complex application relationships.

[0033] 2. This application calculates the mean and variance of characteristic data of the second application's responses to clients of different priorities, thereby identifying whether the response differences stem from random anomalies or preset legitimate Quality of Service (QoS) policies. After identifying legitimate QoS policies, the original observation data is normalized using configuration parameters. This restores a fair and comparable corrected response characteristic that excludes the impact of legitimate service degradation. This avoids misjudging normal differentiated service behavior of applications as faults, ensuring the fairness of subsequent evaluations, and thus improving the accuracy of resource allocation in data centers under complex application relationships.

[0034] 3. This application extends the diagnostic perspective for performance issues from isolated applications to the complete downstream service dependency chain by analyzing the service call chain diagram. After identifying downstream applications, the legitimate performance fluctuations introduced by the QoS policies of each downstream application are quantified by calculating the business priority difference coefficient of each downstream application. Subsequently, a weighted combination of these impacts is constructed to construct a combined configuration parameter that comprehensively reflects the overall impact of downstream applications. Finally, this parameter is used to normalize the original observation data. This is equivalent to subtracting all legitimate performance jitter caused by downstream dependencies when evaluating the second application, avoiding the incorrect attribution of downstream problems to upstream applications, thus improving the accuracy of resource allocation in data centers under complex application relationships. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating a data center resource regulation method in an embodiment of this application;

[0036] Figure 2 This is another flowchart illustrating the data center resource regulation method in this application embodiment;

[0037] Figure 3 This is a schematic diagram of an exemplary hardware structure of the data center resource control system in this application embodiment. Detailed Implementation

[0038] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0039] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0040] In related technologies, a common approach to address resource conflicts within data centers is to monitor application resource usage metrics. When a high-priority primary application's resource wait time exceeds a threshold, the system identifies a lower-priority application with high concurrent input / output (I / O) load and classifies it as an interfering factor in resource contention. The logic behind this approach is that high I / O load and high resource wait time occurring simultaneously imply that the former is the cause of the latter. However, if a low-priority secondary application's high I / O load is precisely responding to a legitimate data request from the primary application, then this high load is necessary and beneficial. In this case, limiting resources solely based on high I / O load might actually block the primary application's path to the required data, further extending wait times and creating a negative effect, thus degrading the performance of core applications.

[0041] In this embodiment, after initially locating the second application related to the resource waiting of the first application, a content relevance scoring mechanism based on business logic is introduced. This mechanism, through a pre-trained business logic model, generates an expected response profile containing expected information entropy, data structure, and size based on the request content issued by the first application. Subsequently, the actual response characteristics of the second application are compared with the expected response. Only when the actual response significantly deviates from the expected response (i.e., a low content relevance score) is the high I / O load of the second application considered invalid or abnormal, and its resource quota is adjusted accordingly. This method, by verifying the business legality of the data content, distinguishes between normal business collaboration and abnormal resource contention, avoiding the problem of exacerbating the performance degradation of core applications due to error suppression.

[0042] Figure 1 This is a flowchart illustrating the data center resource regulation method used in the embodiments of this application, including the following steps:

[0043] S101. Monitor the resource wait metrics of the primary application running within the data center.

[0044] Among them, a data center refers to a physical or virtualized infrastructure used for the centralized deployment, operation, and management of computing, storage, and network resources, such as an enterprise private cloud, public cloud platform, or hybrid cloud environment; the first application refers to the core business application that is given priority protection within the data center, which usually has the characteristics of high business priority and sensitivity to response latency, such as online transaction systems, real-time recommendation engines, or core API gateways; the resource wait metric is a key performance indicator for measuring application performance bottlenecks, specifically referring to the percentage of the total CPU time that the central processing unit (CPU) is idle, and the reason for the idleness is waiting for input / output operations to complete.

[0045] Specifically, in a high-density, hybrid data center environment, multiple applications share underlying physical I / O resources (such as solid-state drives and network interface cards). Abnormal I / O behavior in one application can easily impact other applications. This method does not use indirect performance metrics (such as application latency), but instead directly monitors the root cause metric, "I / O wait time percentage," which directly reflects whether an application's processor cycles are wasted due to the inability to acquire or send data in a timely manner. A monitoring agent is deployed that periodically collects CPU status data for the process or container designated as the primary application. By analyzing the time distribution of CPU in different states per unit time—user mode, system mode, idle mode, and I / O wait mode—the I / O wait time percentage is calculated, thus forming real-time time-series data reflecting the severity of the I / O bottleneck.

[0046] In some embodiments, resource wait time metrics can be monitored in several ways: Optionally, monitoring can be based on Extended Berkeley Packet Filter (eBPF) technology, which includes the following steps: writing and mounting an eBPF program to the kernel, which can track process scheduling events related to a first application; when a process enters a non-runnable sleep state due to an I / O request, the eBPF program records the current timestamp; when the process is awakened, the timestamp is recorded again, resulting in timestamp pairs; a user-space monitoring agent aggregates these timestamp pairs, calculates the total I / O wait time, and compares it with the total monitoring duration to obtain the I / O wait time percentage. It is understood that other performance monitoring tools or technologies can also be used to monitor this metric, and this is not limited here.

[0047] S102. When the resource waiting index exceeds the preset resource waiting index threshold, the application that is positively correlated with the change trend of the real-time input / output operation load and the change trend of the resource waiting index, and whose business priority is lower than the first business priority corresponding to the first application, is identified as the second application.

[0048] Among them, the preset resource waiting indicator threshold is a pre-configured critical value used to determine whether the I / O performance of the first application has significantly deteriorated; real-time input / output operation load represents the intensity of I / O activity of potentially impactful applications per unit time, which can be quantified by read / write operations per second (IOPS) or read / write bytes per second (throughput); change trend refers to the direction and rate of change of an indicator within a specific time window, usually obtained by calculating the first derivative or slope of time series data; positive correlation indicates that the two variables change in the same direction, that is, when one variable increases, the other variable also increases; business priority refers to the labels or values ​​assigned to different applications to represent their importance level, used for decision-making during resource competition; potentially impactful applications refer to server applications that logically provide services to the first application, and are the direct suspects causing the first application's I / O waiting.

[0049] Specifically, the system is triggered when the resource waiting metrics of the first application exceed a preset threshold, avoiding unnecessary calculations during normal system operation. Upon triggering, a list of applications with service call relationships to the first application is first retrieved as a candidate pool of potentially affected applications. Next, three key checks are performed on each application in the candidate pool: First, correlation analysis: retrieving the time series of the resource waiting metrics of the first application within the problem occurrence time window (e.g., the past 5 minutes), and the I / O load time series of each potentially affected application. By calculating the Pearson correlation coefficient or other correlation measures between the two, applications with correlation coefficients greater than a preset correlation threshold are selected, indicating that their I / O behavior is highly synchronized with the waiting phenomenon of the first application. Second, priority check: from the applications that pass the correlation analysis, applications with a clearly lower business priority than the first application are further selected, ensuring that control measures do not mistakenly suppress applications more important than core business. Third, one or more applications that simultaneously meet all the above conditions are identified as the second application, serving as the object of subsequent analysis and control.

[0050] In some embodiments, after identifying the second application, proxy identification and root cause tracing can be further performed to address the presence of intermediate forwarding layers in the service call chain, thereby ensuring that control measures can be applied to the backend services that actually consume resources and avoiding erroneous suppression of innocent proxy applications.

[0051] First, obtain all network connection information of the preliminarily identified second application, including the identifiers of all peer applications that have established TCP / IP connections with the second application (such as IP address, port or service name) and the data flow direction of each connection (whether it is an outbound connection initiated by the client or an inbound connection received by the server), and construct a local network topology map centered on the second application.

[0052] Next, the inbound / outbound connection ratio is calculated, which is the ratio of the number of outbound connections to the number of inbound connections. A typical proxy or API gateway operates by receiving requests from upstream (such as the first application) (inbound connections) and then forwarding the requests to one or more downstream backend services (outbound connections). Therefore, the number of outbound connections is usually much greater than or significantly more than the number of inbound connections. When this ratio exceeds a preset proxy characteristic threshold, the initially identified second application is suspected of being a proxy. A root cause tracing mechanism is then initiated to actively track all outbound data flows of the proxy application. By analyzing the destination address of the data packets or the routing information in the service mesh, the target application into which these data flows ultimately converge is identified. The target application is the root cause of processing business logic and generating high I / O load.

[0053] The target application that was traced will be corrected to the final second application, and all subsequent analysis and control will be carried out for this corrected second application.

[0054] In modern microservice architectures, proxy patterns such as API gateways and message queues are very common. Indiscriminately restricting resources on the proxy itself not only fails to solve the problem but also degrades the performance of services that rely on it due to blocked forwarding capabilities, resulting in a worsening effect with each attempt at regulation. This proxy identification and root cause tracing step distinguishes proxy applications from backend service applications by quantifying the inbound and outbound connection ratios of applications. After identifying the proxy, data flow tracing corrects the regulation target from the superficial proxy responsible only for forwarding to the backend service that actually generates the load, avoiding erroneous attacks on innocent middleware. This makes the entire regulation decision more precise and ultimately improves the overall accuracy of resource regulation in data centers under complex application relationships.

[0055] S103. Calculate the information entropy of the actual response data generated by the second application in response to the request of the first application, and extract the data structure and data size of the actual response data to obtain the actual response characteristics.

[0056] Among them, actual response data refers to the real data payload output by the second application after processing the request of the first application; information entropy is used to quantify the uncertainty or randomness of the response data content. The higher the information entropy, the more complex and irregular the data content; data structure refers to the organization form and pattern of the response data, such as the key name set of a JSON object, the tag tree structure of XML, or the field definition of Protobuf; data size is the number of bytes of the response data; the actual response feature is a multi-dimensional feature vector composed of the above information entropy, data structure, and data size.

[0057] Specifically, after identifying the second application, a traffic capture module is deployed to intercept and parse response data packets flowing from the second application to the first application. For each captured response data packet, a series of calculations are performed to extract its characteristics: First, the information entropy is calculated. The response data is treated as a byte sequence, and the frequency of each byte value from 0 to 255 is counted. Then, the Shannon entropy formula is applied to calculate the overall information entropy value. Second, the data structure is extracted. The data is parsed according to a pre-configured protocol type (such as HTTP / JSON, gRPC / Protobuf). For JSON, all keys are extracted and formed into a set or tree; for Protobuf, the filled field labels are decoded and identified. Finally, the data size is recorded by directly obtaining the byte length of the response packet payload. Information entropy, data structure, and data size together constitute the actual response characteristics of the corresponding actual response data.

[0058] In some embodiments, the extraction of actual response characteristics can be achieved in several ways: Optionally, based on application-layer traffic proxy. This method includes the following steps: deploying a transparent Layer 7 proxy (such as Envoy) at the network egress of the second application; configuring proxy rules to copy or perform deep packet inspection (DPI) on response traffic flowing to the first application; after receiving the response data, the analysis module built into the proxy or attached to it performs information entropy calculation, JSON / XML structure parsing, and size statistics, and sends the results (actual response characteristics) to the control center. Optionally, based on application code instrumentation. This method includes the following steps: using dynamic bytecode injection technology (such as JavaAgent) or aspect-oriented programming (AOP) frameworks to intercept the function returning the response in the code of the second application; in the interception logic, obtaining the response object to be sent, analyzing it directly in memory, calculating information entropy, extracting its field structure through reflection, and serializing it to obtain its size; sending the extracted characteristics to the control center through an asynchronous message queue to reduce the performance impact on the main business process. It is understandable that other network packet capture or application monitoring technologies can also be used to achieve feature extraction, and this is not limited here.

[0059] S104. Based on the request content sent from the first application to the second application, generate expected response features containing the expected information entropy range, expected data structure, and expected data size using a pre-trained business logic model.

[0060] Among them, the pre-trained business logic model refers to a model that has been learned and trained through historical normal interaction data, and can understand the business relationship logic between the first application and the second application; the request content refers to the request data sent by the first application to the second application; the expected response characteristics are the characteristics that the business logic model predicts based on the request content, and which a legal or normal response should have. It is not an exact value, but a composite structure that includes a range, template and expected value. For example, the information entropy should be between [2.5, 3.5], the data structure should include key fields such as "user_id" and "items", and the data size should be between 1KB and 2KB.

[0061] Specifically, a machine learning model is used to dynamically generate an expected response profile. This business logic model is trained by learning from massive amounts of request-response data pairs, aiming to find the mapping relationship between specific requests and normal response characteristics (information entropy, structure, size). When the control process runs, the captured request content issued by the first application is input into this pre-trained business logic model. The model, based on the business semantics of the request (e.g., whether it requests a single user's information or a batch of product lists) and knowledge learned from historical data, outputs a corresponding expected response feature. This expected feature provides a dynamic, business logic-dependent gold standard for subsequent comparisons and scoring.

[0062] In some embodiments, a pre-trained business logic model can be constructed in several ways: Optionally, a model based on request classification and statistical profiling. This approach includes the following steps: During the training phase, historical request data is first clustered or classified using regular expressions to divide requests into different business types; for each business type, the statistical distribution (such as mean, variance, common structural templates) of the entropy, structure, and size of all corresponding normal response data is calculated; when a new request arrives, it is first classified into a certain business type, and then the statistical profiling corresponding to that type is directly called as the expected response feature. Optionally, an end-to-end generative model based on deep learning. This approach includes the following steps: During the training phase, a model with an architecture such as Seq2Seq (sequence-to-sequence) or Transformer is used, with the input being the text or structured data of the request and the output being the feature vector of the response; the model learns a large number of request-response pairs and autonomously masters the complex mapping relationship from request to response features; new request content is input into the trained model, and the model directly generates an expected response feature vector (containing the expected entropy, structure, and size). It is understood that other machine learning or statistical modeling methods can also be used to construct this model, and this is not limited here.

[0063] S105. Compare the actual response features with the expected response features to obtain the information entropy deviation value, structural similarity score and size matching score, and then perform a weighted sum according to the preset weights to obtain the content relevance score.

[0064] Among them, the information entropy deviation value is used to quantify the degree of deviation between the actual information entropy and the expected range; the structural similarity score is used to quantify the degree of conformity between the actual data structure and the expected structure; the size matching score is used to quantify the degree of closeness between the actual data size and the expected size; the preset weight refers to the importance coefficients assigned to the above three sub-scores, and these coefficients can be adjusted according to business characteristics; the content relevance score is the final comprehensive score, which represents the degree of correlation between the response content of the second application and the business intent of the request of the first application. The higher the score, the more relevant and credible it is.

[0065] Specifically, the actual response features obtained in S103 are compared item by item with the expected response features generated in S104, and three sub-scores are calculated: First, the information entropy deviation value is calculated. If the actual information entropy is within the expected range, the score is 1 (or full marks); if it deviates, a penalty score is calculated based on the distance of the deviation, with lower scores for larger deviations. Second, the structural similarity score is calculated by comparing the actual data structure (such as a JSON key set) with the expected data structure. Algorithms such as Jaccard Similarity or tree edit distance can be used to calculate their similarity, resulting in a score between 0 and 1. Third, the size matching score is calculated, similar to information entropy, based on the matching between the actual data size and the expected size range, giving a score between 0 and 1. Finally, the three sub-scores are weighted and summed according to preset weights to obtain the content relevance score.

[0066] In some embodiments, the comparison and scoring process can be implemented in several ways: Optionally, a scoring method based on normalized distance: For information entropy and data size, calculate the normalized bias and then convert it to a 0-1 score using a Gaussian function; for data structure, extract the actual and expected JSON key path sets, calculate their Jaccard similarity coefficients as scores; multiply the three scores by their corresponding weights and sum them to obtain the final score. Optionally, a scoring method based on fuzzy logic: Define multiple fuzzy linguistic variables (e.g., "too low," "normal," "too high") for each feature (entropy, structure, size); compare the actual feature values ​​with the expected features to determine the membership degree on each fuzzy variable; perform fuzzy inference using a pre-defined fuzzy rule base to finally obtain the content relevance score. It is understood that other multi-criteria decision-making or vector space models can also be used for scoring, and this is not limited here.

[0067] S106. When the content relevance score does not exceed the preset trust threshold, reduce the upper limit of the resource quota for the input and output operations of the second application by the preset first adjustment ratio.

[0068] Among them, the preset trust threshold is a critical score used to judge whether the response is trustworthy. If it is below this threshold, it means that the response content is not very relevant to the business request and may be an abnormal or malicious response; the first adjustment ratio refers to the reduction ratio used when resource limits are first implemented; the upper limit of the resource quota for input and output operations refers to the upper limit of I / O resource usage allocated by the operating system or virtualization layer to the application (container or process), such as the disk IOPS limit or network bandwidth limit.

[0069] Specifically, when the content relevance score calculated by S105 is lower than a preset trust threshold, it is determined that although the second application has generated high I / O load, its response content does not match the request of the first application. This is a typical abnormal response pattern; for example, a large amount of irrelevant logs or error messages are returned instead of a small amount of user data. At this point, the high load of the second application is no longer considered a legitimate business activity, but rather a form of resource abuse. Therefore, the control system will call the underlying resource management interface to reduce the upper limit of the second application's I / O resource quota according to a preset first adjustment ratio. For example, the upper limit of the second application's disk write rate may be reduced from unlimited to 50MB / s, aiming to suppress its abnormal I / O behavior, thereby releasing the occupied shared I / O resources, allowing the first application to perform its own I / O operations normally, and thus reducing its resource wait index.

[0070] In some embodiments, resource quota adjustments can be implemented in several ways: Optionally, using the Linux control group's blkio subsystem: Locate the cgroup path where the second application resides; read its current read / write rate limit file; calculate a new rate cap value according to a first adjustment ratio, and write the new value to the file; the kernel will immediately enforce the new I / O quota. Optionally, through the storage system's Quality of Service (QoS) policy. This method includes the following steps: 1) If the data center uses a centralized storage system that supports QoS (such as Ceph, SAN), the storage volume of the second application will have a corresponding QoS policy; the control system finds the storage volume ID associated with the second application by calling the storage system's API; modifies the QoS policy of the storage volume, reducing its IOPS cap or bandwidth cap according to the first adjustment ratio. It is understood that resource limits can also be implemented through virtualization management platforms (such as vSphere) or network switch QoS policies, etc., which are not limited here.

[0071] In some embodiments, in addition to general regulation based on content relevance scoring, fine-grained identification and punishment mechanisms for specific attack patterns can be integrated to more accurately respond to invalid small packet attacks and data segmentation attacks.

[0072] The first method is used to identify invalid small packet attacks. First, within a preset time window, the number of small data responses (smaller than the expected data size) occurring in the second application's responses to the first application is continuously counted. When this count exceeds a preset threshold for the number of small data responses within an evaluation period, an anomaly is initially identified. The content of each small data response is then structurally parsed to extract field type distribution features. This feature is a quantified vector describing the proportion of different data types (such as strings, integers, floating-point numbers, booleans, nested objects, etc.) in the response data. For example, for a JSON response, all key-value pairs are iterated, the number of each value type is counted, and a distribution histogram is generated. Subsequently, this real-time extracted feature vector is compared with a pre-established standard field type distribution feature built by learning from a large amount of historical normal response data. This calculation can use algorithms such as cosine similarity or Jaccard similarity coefficient to obtain a quantified similarity score. This similarity score is continuously tracked. When the cumulative number of times the score is below a preset similarity threshold exceeds a preset low similarity threshold, it is confirmed that this is a persistent, non-accidental invalid small packet attack. Once confirmed, the upper limit of I / O resource quota for the second application will be reduced according to a preset penalty ratio that is significantly greater than the first adjustment ratio.

[0073] The second method is used to identify data segmentation attacks. First, within a very short detection period, the total number of responses from the second application to the first application is recorded frequently. When this number of responses spikes abnormally in a short period, exceeding a preset response limit, a high-frequency attack is suspected. The data size of all responses within this detection period is collected, and the statistical variance of this data set is calculated. A very small variance value means that all response packets are of highly consistent size, which is an unnatural pattern and highly likely that the attacker has mass-copied the same data template. For final confirmation, aggregation verification is performed: the data sizes of all responses within this period are summed to obtain a total data volume, and then the ratio of this total data volume to the average data size of historical normal business responses is calculated. If this ratio is significantly greater than a preset segmentation ratio threshold, a complete chain of evidence can be formed, proving that the attacker maliciously segmented a large amount of data that should have been returned all at once into a large number of small data packets with highly consistent content and size, using high-frequency responses to overwhelm the first application. For this attack pattern that uses frequency rather than single-transaction traffic as its attack method, simple I / O rate limiting is ineffective. Therefore, once confirmed, the maximum number of concurrent responses for the second application can be directly limited. By modifying the configuration of the runtime environment (such as the thread pool size of the application server or the concurrent connection limit of the service mesh), the concurrent processing capacity can be restricted to an extremely low level, thereby dismantling the ability to launch high-frequency attacks at the root.

[0074] By executing detection and control steps for these specific attack patterns, the system's response speed and control accuracy in the face of advanced threats are significantly improved. It no longer relies on a single, universal content relevance indicator, but instead constructs profiles of two typical attack patterns—invalid small packets and data segmentation—through combined analysis of multiple fine-grained features such as response size, field type distribution, response frequency, and data size variance. From general low-relevance responses, it identifies behaviors with clear attack intentions and matches them with more targeted and powerful control strategies. This avoids using a one-size-fits-all approach to handle all anomalies, thereby improving the accuracy and timeliness of resource control in complex attack scenarios.

[0075] S107. When the resource waiting index is lower than the preset first resource waiting index threshold, increase the upper limit of the resource quota for the input and output operations of the second application by the preset second adjustment ratio.

[0076] The first resource waiting index threshold can be the same as the trigger threshold in S102, or it can be a lower recovery threshold to prevent the system from oscillating frequently near the critical point; the second adjustment ratio refers to the boost ratio used to restore resources for the second application after the system recovers.

[0077] Specifically, after implementing the resource limiting measures in S106, the resource waiting index of the first application is continuously monitored. If this index drops below the preset recovery threshold, it indicates that the control measures have taken effect and the I / O bottleneck has been alleviated. At this point, to avoid permanently suppressing the performance of the second application (whose abnormal behavior may only be temporary) and affecting its ability to handle other normal business, the control system will gradually and in stages increase the resource quota limit that was reduced in S106 according to the preset second adjustment ratio. This gradual recovery method, rather than completely removing the restrictions all at once, is a protective strategy that can restore the resource quota of the second application, provided that the performance of the first application is stable, until it is restored to the original level or a new level that is adapted to the current system load.

[0078] In the above embodiments, after identifying low-priority applications related to the performance degradation of high-priority applications, this solution does not suppress them based solely on resource utilization as in existing technologies. Instead, it introduces a content relevance scoring mechanism. This scoring compares the actual response of the application with the expected response generated based on business logic to determine whether the high resource consumption of low-priority applications is providing legitimate and valuable services to high-priority applications. This avoids misjudging legitimate business collaboration as malicious resource contention, thus preventing the exacerbation of core application performance degradation due to erroneous suppression. Ultimately, it improves the accuracy of resource allocation in data centers under complex application relationships.

[0079] In other embodiments of this application, when the second application acts as a service gateway or a complex application that relies on multiple downstream services, legitimate service degradation behaviors of downstream services may be incorrectly attributed to the failure of the currently observed application itself. The data center resource control method provided in this application can identify that differentiated behaviors are due to preset, legitimate service quality policies, rather than the application's own failure, thereby avoiding erroneous resource control decisions.

[0080] like Figure 2 The diagram shown is another flowchart illustrating the data center resource regulation method provided in this application, which includes the following steps:

[0081] S201. Monitor the resource wait metrics of the primary application running within the data center.

[0082] S202. When the resource waiting index exceeds the preset resource waiting index threshold, the application that is positively correlated with the change trend of the real-time input / output operation load and the change trend of the resource waiting index, and whose business priority is lower than the first business priority corresponding to the first application, is identified as the second application.

[0083] S203. Calculate the information entropy of the actual response data generated by the second application in response to the request of the first application, and extract the data structure and data size of the actual response data to obtain the actual response characteristics.

[0084] Steps S201-S203 and Figure 1 Steps S101-S103 in the illustrated embodiment are similar and can be found in the descriptions of steps S101-S103, which will not be repeated here.

[0085] S204. Obtain a sample set of other response data from the second application to other applications with different business priorities.

[0086] Among them, "other applications" refers to all client applications that have service call relationships with the second application, excluding the first application; "other response data" refers to the data payload returned by the second application when responding to requests from other applications.

[0087] Specifically, the high I / O load generated by the second application and its unusual responses to the first application (e.g., small data volumes) may not be malicious or faulty, but rather normal business logic built in to provide differentiated services to clients with different priorities. To verify this possibility, evidence of the second application's interactions with all other known clients is actively collected. Through service discovery mechanisms or network traffic monitoring, all client applications that initiate requests to the second application are identified, and the business priorities of these applications are queried. Subsequently, a series of response data from the second application to these applications with different priorities are captured and stored, forming a sample set containing rich response instances categorized by business priority.

[0088] In some embodiments, the acquisition of the response data sample set can be achieved in several ways: Optionally, based on service mesh telemetry data collection: A request is sent to the control plane of the service mesh (such as Istio) to obtain a list of all downstream services that use the second application as an upstream service; the service priority tags of these downstream services are obtained through the service mesh's metadata; the service mesh's traffic mirroring rules are configured to copy all response traffic sent by the second application to these services with different priorities, and send them to a dedicated data acquisition service, thereby constructing the sample set. It is understood that other network monitoring or log analysis techniques can also be used to acquire the sample set, and this is not limited here.

[0089] S205. Calculate the other data information entropy, other data structure and other data size of the other response data in the other response data sample set to obtain the other response feature data group.

[0090] Among them, other data information entropy, other data structure and other data size refer to the fact that for each response sample collected in S204, the same feature extraction calculation as in S103 is performed; other response feature data group represents a structured dataset that stores the feature vectors of all samples (composed of information entropy, structure and size), and retains the original client application business priority label corresponding to each feature vector.

[0091] Specifically, each response data point in the sample set is iterated through. For each data point, the information entropy is calculated using the Shannon entropy formula to quantify the complexity of the content; the data format (such as JSON, XML) is parsed and structural patterns are extracted to understand the organizational paradigm; and the byte length is obtained to measure the physical size. After processing, the original response data sample set is transformed into a response feature data set.

[0092] S206. Calculate the variance of the mean values ​​of multiple other response feature data corresponding to each service priority in the other response feature data group. When the variance of any feature data exceeds the corresponding preset variance threshold, read the service quality configuration parameters corresponding to different service priorities from the configuration file of the second application.

[0093] Among them, the mean of feature data refers to the average value calculated from all response feature data within the same business priority group; the variance of the mean of feature data is used to represent the degree of dispersion between the mean of feature data of different business priority groups. The larger the variance, the more significant the difference in service quality obtained by different priorities; the service quality configuration parameters refer to the rules that are explicitly defined in the configuration file of the second application and are used to guide how to provide different responses (such as different size limits and content descriptiveness) for different priority requests.

[0094] Specifically, firstly, statistical analysis is performed on the feature data sets generated by S205. All feature vectors are grouped according to business priority, and the mean of the feature vectors within each group is calculated to obtain multiple average response features. Next, the variance between these average response features is calculated. For example, the variance of the average data size of all groups is calculated separately. If this variance value exceeds a preset threshold, it indicates that the second application implements a differentiated service strategy based on client priority. Once this hypothesis is confirmed, the deployment environment of the second application is accessed, and its configuration files (such as YAML, properties, or XML files) are directly located and parsed to extract the explicitly defined Quality of Service (QoS) parameters.

[0095] In some embodiments, variance calculation and configuration retrieval can be implemented in several ways: Optionally, it can be achieved through linkage with a configuration center: application configurations within the data center are managed by a centralized configuration center (such as Nacos or Consul); after the variance calculation exceeds a threshold, an API request is initiated to the configuration center based on the identity of the second application; the request queries the configuration set that is effective for the application in the current environment, and the service quality-related parameters are parsed from the returned configuration data. It is understood that configuration files can also be read through other automated operation and maintenance tools or by directly executing commands remotely; this is not limited here.

[0096] In some embodiments, after identifying that the second application itself has a differentiated service strategy, the complete service call chain can be traced further. By quantitatively analyzing the differentiated service behavior of each downstream dependent service, a combined configuration parameter that can reflect the comprehensive impact of downstream services can be constructed, thereby achieving deep correction of the actual response characteristics and avoiding misjudgment due to the QoS transmission effect on the service dependency chain.

[0097] Specifically, this deep correction process is initiated after S206 confirms that the second application has QoS behavior. The core logic is that the response characteristics of the second application are not only determined by itself, but may also be profoundly affected by the downstream services it depends on.

[0098] Obtain the complete service call chain graph of the second application to identify the set of downstream applications that it directly depends on. This can be done by querying the backend storage of a distributed tracing system (such as OpenTelemetry or Jaeger) to extract all child spans with the second application as the parent span and identifying the services corresponding to these child spans as downstream applications; or by querying the control plane of a service mesh (such as Istio) to obtain the service topology graph and parse out the destination services of all outbound traffic originating from the second application.

[0099] For the set of downstream applications identified in the previous step, perform the analysis process from S204 to S206 independently for each downstream application. Collect response sample sets of each downstream application to requests of different priorities, calculate response characteristics (information entropy, structure, size), and finally calculate the mean and variance of downstream feature data representing the strength of its own QoS policy. At the same time, attempt to obtain the downstream service quality configuration parameters of each downstream application.

[0100] The business priority difference coefficient for each downstream application is calculated to measure the contribution of each downstream service to the final response characteristics of the second application. First, the mean and variance values ​​of the feature data for all downstream applications obtained in the previous step are collected. Then, for the i-th application in the downstream application set, the difference coefficient is calculated as the ratio of the mean and variance of the application's own feature data to the sum of the mean and variance of the feature data of all applications in the set. This normalized coefficient ensures that downstream applications with more significant QoS policies (larger variance) have higher weights, and vice versa.

[0101] Based on the calculated business priority difference coefficient, the service quality configuration parameters of all downstream applications are weighted and combined. The downstream application set is iterated through, and the service quality configuration parameters of each downstream application (e.g., response size scaling ratio, content field deletion list, etc.) are multiplied by the corresponding difference coefficient. Then, all products are summed or combined in other preset ways. This yields the combined configuration parameters. These combined parameters are no longer the configuration of any single application, but rather an equivalent representation of the QoS effect of the entire downstream service ecosystem on the second application.

[0102] The actual response characteristics are normalized using combined configuration parameters. The process is similar to S207. For example, if the combined parameters indicate that, given the priority of the current request, the response size is expected to shrink to 35% of normal due to the combined impact of downstream services, the system will divide the actually observed response size by 0.35 to restore the theoretical value under no QoS influence. This results in a corrected actual response characteristic.

[0103] This downstream impact analysis and combination correction step acknowledges that in complex call chains, the response characteristics of an upstream application are often an aggregation and reflection of the response characteristics of all its downstream services. By calculating the business priority difference coefficient, the influence weight of each downstream service's QoS policy is quantified, and equivalent combination configuration parameters are constructed. This ensures that normalization processing is no longer based solely on the QoS declaration of the second application itself, but on the actual behavior of the entire service dependency system behind it. It effectively distinguishes between a failure of the second application itself and a legitimate degradation response transmitted by it to downstream services, thereby ensuring the accuracy of control decisions and improving the overall precision of resource control in data centers under complex application relationships.

[0104] S207. Normalize the actual response characteristics based on the service quality configuration parameters to obtain the corrected actual response characteristics.

[0105] Normalization refers to performing mathematical transformations on the actual response characteristics based on QoS parameters to eliminate the impact of priority-differentiated services and convert them to a standard, priority-independent baseline.

[0106] Specifically, first, the service priority of the first application is determined, and then the rules applicable to that priority are found in the read QoS configuration parameters. For example, the rule might be "For low-priority applications, the response size is reduced to 20% of normal." Then, the data size value in the actual response feature is divided by 20% to obtain a theoretically appropriate size without a QoS policy. Similarly, if the QoS policy affects the data structure (e.g., omitting certain non-core fields for low-priority users), the expected structure is adjusted accordingly before comparing structural similarity. After this reverse calculation, a corrected actual response feature is obtained. This corrected feature is compared with the expected feature generated by the model, thus ensuring the fairness of the comparison.

[0107] In some embodiments, the normalization of actual response characteristics can be achieved in several ways: Optionally, inverse adjustment based on scaling factors: The QoS configuration file defines scaling factors for various characteristics with different priorities; the priority of the first application is obtained, and the corresponding scaling factor is found; the obtained actual characteristic values ​​are divided one by one by the corresponding scaling factor to obtain the corrected characteristic values. It is understood that other mathematical transformations or calibration models can also be used to achieve normalization, which is not limited here.

[0108] S208. Based on the request content sent from the first application to the second application, generate expected response features containing the expected information entropy range, expected data structure, and expected data size using a pre-trained business logic model.

[0109] S209. Compare the actual response features with the expected response features to obtain the information entropy deviation value, structural similarity score and size matching score, and then perform a weighted sum according to the preset weights to obtain the content relevance score.

[0110] S210. When the content relevance score does not exceed the preset trust threshold, reduce the upper limit of the resource quota for the input and output operations of the second application by the preset first adjustment ratio.

[0111] S211. When the resource waiting index is lower than the preset first resource waiting index threshold, increase the upper limit of the resource quota for the input and output operations of the second application by a preset second adjustment ratio.

[0112] Steps S208-S211 and Figure 1 Steps S104-S107 in the illustrated embodiment are similar and can be found in the descriptions of steps S104-S107, which will not be repeated here.

[0113] In some embodiments of this application, after the application performance is restored to stability through continuous resource regulation, a forward-looking dynamic resource quota enhancement mechanism can be introduced to proactively identify and adapt to legitimate business surges, thereby maximizing application performance and responsiveness under high load scenarios while ensuring system stability.

[0114] Specifically, at the end of each preset sampling period, the total number of requests sent from the first application to the second application during this period is obtained through monitoring components (such as APM probes or service mesh telemetry data). Then, the number of requests in the current period and the previous period are calculated, and the request growth rate is obtained using the formula (current period request count - previous period request count) / previous period request count. When this growth rate exceeds a preset growth rate threshold used to filter out daily fluctuations, a preliminary judgment is made that a sudden business peak may have occurred, and the real-time operating status of the second application is probed, especially the request processing queue length. This metric can be obtained by querying the application's runtime environment (such as JMX MBeans for Java applications) or from an infrastructure monitoring system (such as Prometheus), reflecting the degree of request backlog. Next, firstly, it is confirmed whether the request processing queue length has exceeded the preset queue length threshold. This indicates that the resources currently allocated to the second application are insufficient to handle the request pressure, resulting in a processing bottleneck. Secondly, historical records are queried to verify whether the content relevance score calculated by step S210 has continuously exceeded the preset trust threshold over a period of time. This is crucial for distinguishing between benevolent and malicious requests, ensuring that the application to be supported is one with a long-term track record of good performance and consistently provides high-quality service. This effectively prevents incorrect resource support for continuously increasing spam requests or slow attacks. Only when all three conditions are met simultaneously—rapid request growth, processing queue backlog, and reliable historical service quality—is it finally confirmed as a legitimate business surge. At this point, the I / O resource quota limit for the second application is temporarily lifted, or increased to a higher level. Furthermore, to achieve dynamic response, the duration of the lifted limit is designed to be proportional to the request volume growth rate. For example, the lifting duration = base duration × (1 + growth rate). This means that the more rapid the business growth, the longer the resource support window will be.

[0115] By correlating load metrics such as request growth rate and queue length with the service quality metric of content relevance score, it is possible to distinguish between malicious traffic attacks and benign business surges, avoiding the erroneous triggering of resource limits due to legitimate high-concurrency requests. This ensures the service performance and user experience of critical businesses during peak periods, thereby improving the intelligence and accuracy of data center resource allocation under complex application relationships.

[0116] In the above embodiments, by calculating the mean and variance of the characteristic data of the second application's responses to clients of different priorities, it is possible to identify whether the response differences originate from random anomalies or from a preset legitimate Quality of Service (QoS) policy. After identifying the legitimate QoS policy, the original observation data is normalized using its configuration parameters. This restores a corrected response characteristic that excludes the impact of legitimate service degradation and allows for fair comparison, avoiding misjudging normal differentiated service behavior of the application as a fault, improving the fairness of subsequent evaluations, and thus improving the accuracy of resource allocation in data centers under complex application relationships.

[0117] The following describes an exemplary data center resource control system 300 provided in an embodiment of this application. Figure 3 This is an exemplary hardware structure diagram of the data center resource control system 300 provided in this application embodiment.

[0118] In some embodiments, the data center resource control system 300 is a computer device or includes a computer device. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores data. The network interface of the computer device is used to communicate with other external terminals or servers via a network connection. In some embodiments, the network interface can be a wired network interface; in some embodiments, the network interface can also be a wireless network interface. When the computer program is executed by the processor, it implements the methods in the embodiments of this application.

[0119] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0120] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0121] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0122] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0123] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A data center resource regulation method, characterized in that, include: Monitor the resource waiting index of the first application running in the data center, wherein the resource waiting index is the percentage of time that the processor of the first application is idle due to waiting for input / output operations; When the resource waiting index exceeds the preset resource waiting index threshold, the application that is positively correlated with the change trend of the real-time input / output operation load and the change trend of the resource waiting index, and whose business priority is lower than the first business priority corresponding to the first application, is identified as the second application. The potential application is the server application that receives and processes the request of the first application. Calculate the information entropy of the actual response data generated by the second application in response to the request of the first application, and extract the data structure and data size of the actual response data to obtain the actual response characteristics; Based on the request content sent by the first application to the second application using a pre-trained business logic model, expected response features including expected information entropy range, expected data structure, and expected data size are generated. The actual response features are compared with the expected response features to obtain the information entropy deviation value, structural similarity score and size matching score, and then weighted and summed according to preset weights to obtain the content relevance score. When the content relevance score does not exceed the preset trust threshold, the upper limit of the resource quota for the input and output operations of the second application is reduced by a preset first adjustment ratio. When the resource waiting index is lower than the preset first resource waiting index threshold, the upper limit of the resource quota for the input and output operations of the second application is increased by a preset second adjustment ratio.

2. The method according to claim 1, characterized in that, After calculating the information entropy of the actual response data generated by the second application in response to the request of the first application, and extracting the data structure and data size of the actual response data to obtain the actual response characteristics, the method further includes: Obtain a sample set of other response data from the second application to other applications with different business priorities; Calculate the other data information entropy, other data structure, and other data size of the other response data in the other response data sample set to obtain the other response feature data group; Calculate the variance of the mean of multiple other response feature data corresponding to each service priority in the other response feature data group. When the variance of any of the feature data exceeds the corresponding preset variance threshold, read the service quality configuration parameters corresponding to different service priorities from the configuration file of the second application. The actual response characteristics are normalized based on the service quality configuration parameters to obtain the corrected actual response characteristics.

3. The method according to claim 2, characterized in that, After reading the service quality configuration parameters corresponding to different service priorities from the configuration file of the second application, the method further includes: Obtain the service call chain diagram of the second application and identify the set of downstream applications of the second application; For each downstream application in the aforementioned downstream application set, calculate the mean and variance of downstream feature data when responding to requests of different priorities. Obtain the downstream service quality configuration parameters for each downstream application in the downstream application set; Calculate the business priority difference coefficient for each downstream application in the downstream application set. The business priority difference coefficient is the ratio of the variance of the response data features when each downstream application processes requests of different priorities to the variance of the mean of the downstream feature data. The service quality configuration parameters are weighted and combined based on the business priority difference coefficient to obtain combined configuration parameters that take into account the impact of downstream services. The actual response features are normalized based on the combined configuration parameters to obtain the corrected actual response features.

4. The method according to claim 1, characterized in that, When the resource waiting index exceeds a preset resource waiting index threshold, after determining a potential application that is positively correlated with the change trend of the real-time input / output operation load and the change trend of the resource waiting index, and whose business priority is lower than the first business priority corresponding to the first application, as the second application, the following is also included: Obtain the network connection information of the second application, the network connection information including the identifiers of other applications that have established connections with the second application and the data transmission direction of each connection; When the ratio of the number of outbound connections to the number of inbound connections of the second application exceeds a preset proxy feature threshold, the outbound data flow of the second application is tracked, and the target application of the outbound data flow is identified. The target application is identified as the second application.

5. The method according to claim 1, characterized in that, After reducing the resource quota limit for the input / output operations of the second application by a preset first adjustment ratio, the method further includes: The number of responses from the second application to the first application that were smaller than the expected data size was counted. When the number of small data responses exceeds a preset threshold for the number of small data responses within a preset time window, the field type distribution characteristics of each response data are extracted. Calculate the similarity between the field type distribution characteristics and the field type distribution characteristics of historical normal response data; When the number of times the similarity is lower than the preset similarity threshold exceeds the preset low similarity number threshold, the upper limit of the resource quota of the second application is reduced according to the preset penalty ratio, and the penalty ratio is greater than the first adjustment ratio.

6. The method according to claim 5, characterized in that, After reducing the resource quota limit of the second application according to a preset penalty ratio when the number of times the similarity is lower than a preset similarity threshold exceeds a preset low similarity number threshold, the method further includes: Record the number of times the second application responds to the first application within a preset detection time period; When the number of responses exceeds the preset upper limit of the number of responses, the variance of the data size of each response data within the detection time period is calculated; If the variance of the data size is less than a preset variance threshold, and the ratio of the total size of the response data within the detection time period to the size of the historical single response data is greater than a preset segmentation ratio threshold, then the maximum number of concurrent responses of the second application will be limited to a preset concurrent threshold.

7. The method according to claim 1, characterized in that, After increasing the resource quota limit for the input / output operations of the second application by a preset second adjustment ratio, the method further includes: At the end of each preset sampling period, the number of requests sent from the first application to the second application is obtained; Calculate the request growth rate within two adjacent sampling periods; When the growth rate of the number of requests exceeds a preset growth rate threshold, the length of the request processing queue of the second application is calculated. If the length of the request processing queue exceeds a preset queue length threshold, and the number of consecutive times the content relevance score exceeds the preset trust threshold exceeds a preset consecutive number threshold, then the resource quota restriction on the second application is lifted, and the lifting time is proportional to the growth rate of the number of requests.

8. A data center resource control system, characterized in that, The data center resource control system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the data center resource control system to perform the method as described in any one of claims 1-7.

9. A computer program product containing instructions, characterized in that, When the computer program product is run on the data center resource control system, the data center resource control system performs the method as described in any one of claims 1-7.

10. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the data center resource control system, the data center resource control system performs the method as described in any one of claims 1-7.

Images