Arm micro-service dynamic resource allocation method based on workload prediction

Abstract

The application discloses an ARM micro-service dynamic resource allocation method based on workload prediction, relates to the technical field of computer system resource management, and comprises the following steps: acquiring the mapping relationship between micro-service instances and NUMA nodes and the calling performance data between micro-services, constructing a system topology and a dependency view, and identifying potential candidate micro-service pairs according to the system topology and the dependency view; monitoring abnormal combinations of calling delays and CPU utilization rates, and screening out inhibited micro-service pairs; collecting performance data of the micro-services and the NUMA nodes, generating a resource demand portrait vector through a clustering algorithm with an adaptive determination of the number of clusters, quantifying the sensitivity of the micro-service pairs to resources, accurately positioning interfering instance pairs by judging memory bandwidth utilization rates and the length of the resource demand portrait vector, and performing migration. The ARM micro-service architecture is used to accurately predict and actively resolve the implicit performance bottleneck caused by memory bandwidth competition, and the resource utilization efficiency and service stability are significantly improved.

Description

Technical Field

[0001] This invention relates to the field of computer system resource management technology, and more specifically, this application relates to a dynamic resource allocation method for ARM microservices based on workload prediction. Background Technology

[0002] In ARM-based microservice deployment environments, traditional resource allocation methods often rely on static configuration or dynamic adjustment strategies based on a single dimension. These methods typically focus only on macro-level metrics such as CPU utilization and memory usage, lacking a deep understanding of the complex call relationships between microservices and their competition for underlying hardware resources. As application architectures continue to evolve towards microservices, the dependencies and communication density between service instances increase significantly. Especially in memory-intensive business scenarios, existing resource scheduling mechanisms struggle to effectively identify hidden performance bottlenecks caused by cross-service resource contention. This leads to instability issues such as soaring response latency and decreased throughput during load fluctuations, severely impacting service quality and reliability.

[0003] In existing technologies, resource allocation decisions often lag behind actual load changes, making predictive intervention impossible before performance degradation occurs. This is primarily because traditional methods fail to construct a joint view of microservice deployment topology and call dependencies, thus failing to accurately locate microservice instance pairs coexisting within the same NUMA node and engaging in close calls. More critically, these methods generally overlook the characteristic of memory bandwidth as a critical competitive resource in ARM architectures. When multiple microservice instances concurrently access memory within the same NUMA domain, bandwidth contention issues can easily arise, causing high-latency-sensitive services to experience a sharp performance drop even with sufficient CPU resources due to waiting for memory access. This cascading performance degradation caused by competition for underlying hardware resources is a pain point that existing static or reactive resource management strategies struggle to fundamentally address.

[0004] To address the aforementioned issues, there is an urgent need in this field for a dynamic resource allocation method that can deeply integrate microservice call dependencies, real-time hardware resource status, and workload prediction, aiming to achieve a shift from passive response to proactive prevention in resource scheduling within the complex and ever-changing ARM microservice runtime environment. The core drawback of existing technologies in ARM microservice scenarios with intensive service dependencies and frequent memory access lies in their inability to effectively avoid performance instability caused by memory bandwidth contention. Summary of the Invention

[0005] To address the aforementioned technical issues, this paper provides a dynamic resource allocation method for ARM microservices based on workload prediction. This technical solution resolves the problems mentioned in the background section.

[0006] In a first aspect, embodiments of this application provide a method for dynamic resource allocation of ARM microservices based on workload prediction, comprising the following steps: obtaining the mapping relationship between microservice instances and NUMA nodes, and generating a mapping relationship table; obtaining the call frequency, CPU utilization, and call latency of microservice instances, constructing a service call graph based on the call frequency and call latency, and identifying candidate microservice pairs based on the mapping relationship table and the service call graph; when the call latency of a candidate microservice pair exceeds a first preset threshold and the CPU utilization is lower than a second preset threshold, it is marked as a suppressed microservice pair; collecting the performance data of the microservice instances and the corresponding NUMA nodes of the suppressed microservice pair and generating a resource demand profile vector based on this through a clustering algorithm; if the current memory bandwidth utilization of any of the suppressed microservice pairs exceeds a third preset threshold, determining whether the magnitude of its resource demand profile vector exceeds a fourth preset threshold, and if so, marking it as an interfering instance pair; and performing resource migration operations on the interfering instance pair.

[0007] Secondly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned ARM microservice dynamic resource allocation method based on workload prediction.

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

[0009] 1. By constructing a joint view of the mapping relationship table and the service call graph, it is possible to accurately identify candidate microservice pairs that are located on the same NUMA node and have call dependencies. Then, by using the unique criterion of high call latency and low CPU utilization, suppressed microservice pairs can be marked. This can effectively capture performance bottlenecks caused by non-CPU resource contention such as memory bandwidth, and thus issue early warnings before the overall system performance deteriorates significantly. This achieves accurate location and early warning of hidden resource contention bottlenecks.

[0010] 2. When generating resource demand profile vectors, fixed clustering parameters are not used. Instead, the number of clusters is dynamically determined based on the real-time data characteristics of suppressed microservice pairs. Closed-loop optimization can be performed through feedback adjustment of clustering algorithm parameters and feedback adjustment of clustering effect verification. This allows the resource demand profile vectors to more accurately depict the resource sensitivity of microservices under the current real load, improving the accuracy and adaptability of dynamic identification of microservice resource demand characteristics.

[0011] 3. When migrating interfering instances, instead of simply selecting the node with the lowest load, the migration strategy calculates the resource contention intensity between the node and the existing instances on the target node, and selects the node with the smallest potential conflict value as the optimal migration target node. This migration strategy, based on the complementarity of resource requirements, not only solves the current resource contention problem, but also effectively prevents a new round of resource conflicts that may be caused by migration. This achieves a better resource layout and improved global stability at the system level, realizes global optimization of resource allocation, and avoids introducing new performance bottlenecks through migration decisions. Attached Figure Description

[0012] Figure 1 A schematic diagram of the structure of the ARM microservice dynamic resource allocation method based on workload prediction provided in the embodiments of this application;

[0013] Figure 2 This is a schematic diagram illustrating the logical flow of dynamically determining and optimizing the number of clusters provided in the embodiments of this application. Detailed Implementation

[0014] This application's embodiments address the technical problem in the prior art where, in complex and ever-changing ARM microservice runtime environments, performance instability caused by memory bandwidth contention cannot be effectively avoided through a dynamic resource allocation method for ARM microservices based on workload prediction.

[0015] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0016] like Figure 1 The diagram shown is a structural schematic of the ARM microservice dynamic resource allocation method based on workload prediction provided in this application embodiment. The ARM microservice dynamic resource allocation method based on workload prediction includes the following steps: obtaining the mapping relationship between microservice instances and NUMA nodes, and generating a mapping relationship table; obtaining the call frequency, CPU utilization, and call latency of microservice instances, constructing a service call graph based on the call frequency and call latency, and identifying candidate microservice pairs based on the mapping relationship table and the service call graph; when the call latency of a candidate microservice pair exceeds a first preset threshold and the CPU utilization is lower than a second preset threshold, it is marked as a suppressed microservice pair; collecting the performance data of the microservice instances and the corresponding NUMA nodes of the suppressed microservice pair and generating a resource demand profile vector based on this through a clustering algorithm; if the current memory bandwidth utilization of any of the suppressed microservice pairs exceeds a third preset threshold, determining whether the magnitude of its resource demand profile vector exceeds a fourth preset threshold, and if so, marking it as an interfering instance pair; and performing resource migration operations on the interfering instance pair.

[0017] Obtaining the mapping relationship between microservice instances and NUMA nodes can be understood as establishing the association between microservice instances and the hardware topology in which they run.

[0018] By querying the hardware topology interface provided by the operating system, information about the physical core or memory region where the microservice instance is located can be extracted; or by using monitoring tools to record the resource access paths of the microservice instance during its operation, the correspondence between it and the NUMA node can be determined. The main purpose is to achieve accurate matching between the microservice instance and the underlying hardware resource distribution.

[0019] Microservice pairs with high call frequency can be selected based on the edge weights in the service call graph; or by analyzing the resource access patterns of microservice instances, it can be determined whether there is a situation where the same hardware resources are shared. Its main function is to locate microservice combinations that may be affected by resource contention.

[0020] By combining microservice call dependencies with the underlying hardware resource status, proactive identification and intervention of memory bandwidth contention issues are achieved. Compared to traditional methods that rely solely on macro-level indicators for resource scheduling, this embodiment focuses on the characteristics of memory bandwidth as a critical competitive resource by constructing a joint view of microservice deployment topology and call relationships. This enables predictive intervention before performance degradation occurs, effectively mitigating performance instability caused by resource contention.

[0021] Furthermore, the specific process of obtaining the mapping relationship table is as follows: obtain the real-time running status information of all microservice instances; parse the unique identifier of each microservice instance and its physical identifier on the host machine from the real-time running status information; query the NUMA node topology information of the ARM server corresponding to the physical identifier through the system information query interface of the host machine; and obtain the mapping relationship table between the unique identifier of the microservice instance, the physical identifier of the ARM server, and the NUMA node identifier.

[0022] In this embodiment, real-time running status information refers to a cluster analysis data set that reflects the current running status of microservice instances. It can be implemented using multi-dimensional indicators, including but not limited to CPU utilization, memory usage, and network I / O statistics, to ensure the timeliness and comprehensiveness of the data source, thereby providing dynamically updated input for mapping construction.

[0023] A unique identifier can be understood as a specific code or mark used to distinguish different microservice instances. It can be implemented through UUID, service registration ID, etc., and is used to accurately lock the identity of a microservice instance and associate it with the host physical identifier to establish a direct link between the microservice and hardware resources.

[0024] The system information query interface refers to the functional module provided by the host operating system for obtaining underlying hardware structure information. It can be implemented using the / proc or / sys file system interface of Linux system, the WMI interface of Windows system, etc., to directly obtain the underlying hardware structure using the system's native interface, ensuring the authority and accuracy of NUMA node information.

[0025] It not only solves the problem of inaccurate mapping relationships, but also provides a reliable data foundation for subsequent resource allocation. Especially in the complex and ever-changing ARM microservice operating environment, it can realize the transformation of resource scheduling from passive response to proactive prevention.

[0026] Furthermore, the specific construction process of the service call graph is as follows: collect the call relationships of all microservice instances within a preset time window; construct a graph structure with any microservice instance in a microservice instance pair as a node and the call relationship as a directed edge; for each pair of microservice instances with a call relationship, form a microservice instance pair and calculate its average call frequency and average call latency within the time window; normalize the average call frequency and average call latency respectively, and then perform a weighted sum of the normalized call frequency and normalized call latency to obtain the comprehensive weight value of each directed edge; assign a comprehensive weight value to each directed edge in the graph structure to obtain a weighted directed graph and denote it as the service call graph.

[0027] In this embodiment, the preset time window refers to a fixed time period set according to actual business needs. It can be implemented in minutes or hours. It is used to ensure that the collected data is timely and to avoid data fluctuations that may interfere with the analysis results due to the time window being too short.

[0028] Average call frequency refers to the ratio of the total number of calls between two microservice instances within a preset time window to the length of the time window. It can be achieved through sliding window statistics or cumulative counting, and is used to reflect the call activity between services.

[0029] In addition, average call latency refers to the average time spent on each call between two microservice instances within a preset time window. It can be achieved through a distributed tracing system or log analysis tools and is used to measure the response quality between services.

[0030] Normalization refers to converting indicators with different dimensions to the same numerical range to facilitate subsequent weighted calculations. It can be achieved by using minimum-maximum normalization or Z-score standardization, and is used to eliminate evaluation biases caused by differences in physical dimensions in call frequency and call latency.

[0031] Weighted summation refers to assigning different weight coefficients to the normalized call frequency and call latency according to the needs of the actual business scenario, and generating a comprehensive weight value through linear combination. It can be achieved by dynamically adjusting the weight coefficients or determining fixed weights based on historical data analysis. It is used to balance the contribution ratio of call activity and response quality in dependency strength assessment.

[0032] By assigning comprehensive weights to directed edges to form a weighted directed graph, the service call graph can accurately quantify the true dependency strength between microservices, providing a reliable basis for subsequent identification of high-impact candidate microservice pairs, thereby supporting the accuracy of resource allocation decisions.

[0033] Furthermore, the specific process for identifying and obtaining candidate microservice pairs is as follows: traverse all directed edges in the service call graph, and for each pair of microservice instances connected by a directed edge, query the mapping table to obtain the corresponding NUMA node set; determine whether the NUMA node sets corresponding to the two microservice instances contain the same NUMA node; if so, then identify the pair of microservice instances as candidate microservice pairs.

[0034] In this embodiment, the service call graph refers to a weighted graph structure with microservice instances as nodes and call relationships as directed edges, which can be constructed by collecting call frequency and latency data within a preset time window.

[0035] The service call graph dynamically reflects the interaction intensity between microservices, providing a reliable basis for subsequent analysis. The NUMA node set can be understood as a set of identifiers describing the physical deployment location of microservice instances. It uses precise topology information provided by a mapping table to map logical call relationships to physical locations. This addresses the lack of awareness of the physical deployment location of microservice instances in traditional methods, thereby improving the accuracy of resource contention scenario location.

[0036] The above approach, combined with fundamental steps such as obtaining the mapping relationship between microservice instances and NUMA nodes and constructing service call graphs, forms a joint analysis system from physical topology to logical call relationships. This not only accurately locates instance pairs coexisting within the same NUMA node and having close call relationships, but also provides a reliable foundation for detecting performance degradation issues caused by memory bandwidth contention, thereby significantly mitigating the surge in response latency caused by cross-service resource contention in microservices under the ARM architecture.

[0037] Furthermore, the specific process for obtaining the resource demand profile vector is as follows: For each suppressed microservice pair, its CPU utilization and cache miss rate, as well as the memory bandwidth utilization of the NUMA nodes shared by the microservice pair, are collected, and these three dimensions of data are combined into a data sample; based on the data sample within a preset time period, a cluster analysis dataset is constructed; the sum of variances of all data samples in the cluster analysis dataset in terms of CPU utilization, cache miss rate, and memory bandwidth utilization is calculated, and the sum of variances is multiplied by the ratio of the current total number of suppressed microservice pairs to the reference average total number of microservice pairs, and the result of the multiplication is multiplied by the preset minimum value of the number of clusters to obtain the number of clusters; the clustering algorithm is used to perform cluster analysis on the cluster analysis dataset according to the number of clusters to obtain the clusters of the cluster analysis; for each cluster, the coordinate vector of its cluster center point is calculated and obtained, and the coordinate vector is normalized, and the normalized coordinate vector is defined as the resource demand profile vector of that type of microservice.

[0038] In this embodiment, the data sample refers to a clustering analysis dataset formed by collecting multiple performance metrics of suppressed microservice pairs, which can be implemented using real-time monitoring tools or log analysis systems. It is used to capture the comprehensive behavioral characteristics of microservice instances in resource contention, thereby providing basic data support for subsequent clustering analysis.

[0039] The number of clusters is dynamically generated based on the data distribution characteristics. It can be determined by analyzing the ratio of the sum of the variances of the data samples across multiple dimensions to the system load. This ensures that the number of clusters adapts to changes in data distribution characteristics and system load, avoiding cluster imbalance caused by a fixed number of clusters.

[0040] Resource requirement profile vectors are standardized vectors formed by normalizing the coordinate vectors of cluster centroids. This normalization can be achieved using mathematical normalization methods such as min-max normalization or Z-score normalization. It eliminates the influence of differences in dimensional units on the vector space, enabling the profile vectors to accurately represent the common resource requirements of similar microservices.

[0041] First, CPU utilization, cache miss rate, and memory bandwidth utilization of suppressed microservice pairs on co-located NUMA nodes are collected and combined into a data sample, as these dimensions are directly related to performance bottlenecks caused by memory bandwidth contention in the ARM architecture. A clustering analysis dataset is constructed based on the data samples within a preset time window to ensure that the dataset covers recent workload trends. When calculating the number of clusters, the sum of the variances of the data samples across the three dimensions reflects the dispersion of the data distribution. The sum of variances is multiplied by the ratio of the current total number of suppressed microservice pairs to the reference average total number of microservice pairs, and then multiplied by a preset minimum value for the number of clusters to dynamically generate the number of clusters.

[0042] Combined with the aforementioned steps of obtaining candidate microservice pairs and constructing service call graphs, this approach addresses the issue of distorted resource demand profiles in static clustering methods under dynamic workloads by dynamically optimizing the clustering process. Particularly when facing fluctuations in the number of suppressed microservice pairs and changes in data distribution, it can more accurately depict actual resource demand patterns under memory bandwidth contention, thereby improving the accuracy of identifying interfering instance pairs and enhancing the reliability of resource migration decisions.

[0043] Furthermore, the specific process for obtaining the number of clusters includes: collecting the number of suppressed microservice pairs within multiple consecutive time windows prior to the current moment to form time series data; calculating the difference between values ​​in adjacent time windows within the time series data, using the difference as trend data; when the fluctuation amplitude of adjacent trend data exceeds a fifth preset threshold, calculating the standard deviation and average value of the trend data within the most recent several time windows; calculating the ratio of the standard deviation to the average value to obtain the trend volatility; when the trend volatility exceeds a sixth preset threshold, using the difference between the trend volatility and the sixth preset threshold plus 1 as the first correction value, multiplying the number of clusters by the first correction value to obtain the corrected first cluster number, and updating the number of clusters accordingly; when the trend volatility does not exceed the sixth preset threshold, using 1 minus the difference between the sixth preset threshold and the trend volatility as the second correction value, multiplying the number of clusters by the second correction value to obtain the corrected second cluster number, and updating the number of clusters accordingly; if the updated number of clusters exceeds the preset maximum number of clusters, then performing clustering algorithm parameter feedback adjustment.

[0044] In this embodiment, time series data refers to an ordered cluster analysis data set formed by collecting the number of suppressed microservice pairs within multiple consecutive time windows. It can be implemented using sliding window statistical method or fixed window statistical method to capture the historical variation pattern of load fluctuation.

[0045] Trend data refers to data obtained by quantifying the difference between values ​​in adjacent time windows in time series data. It can be achieved through simple difference operations or weighted difference operations and is used to accurately reflect the rate and direction of load changes.

[0046] Trend volatility is a normalized metric calculated by comparing the standard deviation of trend data with the average of the number of suppressed microservice pairs. It can be achieved through standardization or normalization algorithms and is used to provide a comparable assessment of volatility intensity across different scenarios.

[0047] The first and second correction values ​​are used to dynamically adjust the number of clusters under conditions of drastic fluctuations and steady fluctuations, respectively. They can be implemented using linear or nonlinear correction formulas to ensure that the number of clusters can adapt to the complexity of load changes.

[0048] Clustering algorithm parameter feedback adjustment refers to the process of dynamically adjusting the parameters of the clustering algorithm to prevent the cluster size from getting out of control. This can be achieved by dynamically scaling the search radius parameter or dynamically adjusting the number of iterations, in order to achieve a balance between computational efficiency and image accuracy.

[0049] Combined with the aforementioned technical content on obtaining resource demand profile vectors, the generation process of resource demand profile vectors is further optimized by dynamically adjusting the number of clusters, thereby improving the accuracy of resource migration decisions and the stability of system performance.

[0050] Furthermore, the specific process of clustering algorithm parameter feedback adjustment is as follows: divide the updated number of clusters by the preset maximum number of clusters to obtain a proportional coefficient; multiply the original search radius parameter by an adjustment amount proportional to the proportional coefficient to obtain a new search radius parameter; the new search radius parameter is used to re-execute the clustering analysis; record the number of times the clustering analysis is re-executed in the preset rounds; if the number of times the clustering analysis is re-executed is greater than the preset adjustment threshold, then clustering effect verification feedback adjustment is performed.

[0051] In this embodiment, Figure 2 This is a schematic diagram illustrating the logical flow of dynamically determining and optimizing the number of clusters provided in the embodiments of this application.

[0052] The proportionality coefficient is a quantitative indicator obtained by calculating the ratio between the updated number of clusters and the preset maximum value. It can be achieved by simple mathematical division and is used to reflect the actual extent to which the current cluster size exceeds the preset range, thus providing an accurate basis for subsequent parameter adjustments.

[0053] The process of dynamically adjusting the core parameters of the clustering algorithm is precisely controlled, ensuring the accurate generation of resource demand profile vectors. This provides reliable support for identifying interfering instance pairs and making resource migration decisions. Combined with the aforementioned techniques for obtaining cluster numbers and generating resource demand profile vectors, this process constitutes a complete dynamic resource allocation method, significantly improving the system's performance stability and resource scheduling efficiency in complex and ever-changing operating environments.

[0054] Furthermore, the specific process for clustering effect verification and feedback adjustment is as follows: Obtain all cluster numbers from the preset rounds as the historical cluster number set; after each round of clustering analysis, for each cluster, calculate the sum of Euclidean distances from all resource demand profile vectors within the cluster to the centroid vector of the cluster, then sum the sums of these distances for all clusters to obtain the intra-cluster distance sum; calculate the pairwise Euclidean distances between the centroid vectors of all clusters, find the smallest inter-cluster centroid distance, then divide this smallest inter-cluster centroid distance by the average of the intra-cluster distance sums to obtain the inter-cluster distance ratio; normalize the intra-cluster distance sum and the inter-cluster distance ratio respectively, then sum them by weight to obtain the clustering comprehensive index of the historical cluster number set; select the cluster number corresponding to the maximum value of the clustering comprehensive index as the cluster number for the next round.

[0055] In this embodiment, the historical cluster count set refers to the cluster analysis data set consisting of all cluster counts used in multiple preset rounds. It can be implemented using data structures such as arrays, lists, or databases, and is used to provide historical data support for subsequent clustering effect evaluation, thereby reducing the impact of the randomness of a single evaluation on decision-making.

[0056] Intra-cluster distance sum refers to the sum of the Euclidean distances between all resource demand profile vectors and their centroid vectors within each cluster. It can be obtained by traversing all vectors in each cluster and calculating the Euclidean distance for each vector, and then summing the results. It is used to quantify the density of data points within a cluster and reflect the internal consistency of resource demand profile vectors.

[0057] The inter-class distance ratio is the ratio of the minimum Euclidean distance between all cluster centroid vectors to the sum and average of the intra-class distances. It can be obtained by calculating the Euclidean distance matrix between all centroid vectors, extracting the minimum value, and then taking the ratio. It is used to measure the distinguishability between different resource demand types and ensure clear category boundaries.

[0058] The clustering composite index is a quantitative indicator generated by weighting and summing the intra-cluster distance and the inter-cluster distance ratio after normalization. It can be implemented by linear weighting or other non-linear weighting methods, and is used to integrate the dual dimensions of internal compactness and external separation to form an objective evaluation standard for clustering effect.

[0059] Based on the historical cluster count set, multiple rounds of data support are provided for effect evaluation, enabling cluster optimization to be based on historical performance rather than single results, effectively reducing the interference of evaluation randomness on decision-making.

[0060] For each cluster, the sum of the Euclidean distances from all resource demand profile vectors within that cluster to the centroid vector of that cluster is calculated and accumulated to obtain the intra-class distance sum. This operation directly reflects the internal consistency of the resource demand profile vectors. The smaller the intra-class distance sum, the more similar the resource demand characteristics of microservices of the same type are, providing a basis for identifying resource competition patterns.

[0061] The inter-class distance ratio is obtained by calculating the minimum Euclidean distance between all cluster centroid vectors and dividing it by the average of the sums of intra-class distances. This metric effectively captures the distinguishability between different resource demand types, avoiding the problem of profile confusion caused by memory bandwidth competition. Furthermore, the intra-class distance sum and inter-class distance ratio are normalized and then weighted to generate a comprehensive clustering index. This process integrates the dual dimensions of internal compactness and external separation, forming an objective quantitative standard for clustering effect. This avoids the one-sidedness of a single indicator and ensures that the evaluation results match the actual impact of microservice resource competition.

[0062] The decision-making mechanism selects the number of clusters corresponding to the maximum value of the clustering comprehensive index as the next round parameter. Based on the comprehensive performance of historical data, it automatically selects the optimal cluster size, so that the resource demand profile vector continuously approximates the actual resource demand distribution, thereby ensuring that subsequent resource migration operations can accurately avoid performance bottlenecks caused by memory bandwidth competition.

[0063] The mechanism for dynamically adjusting the number of clusters has been optimized, solving the problem of distortion in resource demand profile vectors caused by the lack of real-time quantitative evaluation and feedback mechanisms, and improving the accuracy of resource migration decisions and system stability.

[0064] Furthermore, the specific operations for performing resource migration on the interfering instance pair are as follows: Based on the mapping table, obtain all NUMA nodes whose current memory bandwidth utilization is lower than the sixth preset threshold, forming a target node set; obtain two resource demand profile vectors corresponding to the interfering instance pair, denoted as the first vector and the second vector respectively; calculate the Euclidean distance between the first and second vectors of the interfering instance pair and the resource demand profile vector of the target node, obtaining the first difference degree and the second difference degree; from the service call graph, obtain two call frequencies corresponding to the interfering instance pair, denoted as the first call frequency and the second call frequency respectively; multiply the first difference degree by the first call frequency to obtain the first resource contention intensity, and multiply the second difference degree by the second call frequency to obtain the second resource contention intensity; take the maximum value of the first resource contention intensity and the second resource contention intensity of the target node as the potential conflict value of the target node; select the target node with the smallest potential conflict value as the optimal migration target node; migrate the resources of the interfering instance pair from the original NUMA node to the optimal migration target node.

[0065] In this embodiment, the target node set refers to the set formed by screening NUMA nodes with low current memory bandwidth utilization, which is used to ensure that candidate nodes have sufficient memory bandwidth resources.

[0066] This is achieved by monitoring the hardware performance metrics of NUMA nodes in real time, such as collecting memory bandwidth utilization data through system interfaces and comparing it with preset thresholds. The resource demand profile vector can be understood as a mathematical expression that comprehensively reflects the resource demand characteristics of microservice instances across key dimensions such as CPU utilization and cache miss rate. It is used to accurately quantify the resource contention sensitivity of microservice instances.

[0067] Resource demand profile vectors can be generated through cluster analysis, and specific implementation methods include, but are not limited to, K-means clustering or hierarchical clustering algorithms.

[0068] The first and second dissimilarity scores are obtained by calculating the Euclidean distance between resource demand profile vectors, which are used to measure the similarity between microservice instances and target nodes in terms of resource demand patterns.

[0069] The smaller the difference, the better the resource demand pattern of the microservice instance matches that of the target node, thus effectively identifying the hidden competition risk caused by overlapping resource demands.

[0070] The first and second call frequencies are key metrics extracted from the service call graph, which are used to reflect the communication strength between microservice instances.

[0071] High-frequency calls can significantly amplify the impact of resource contention, so incorporating call frequency into the evaluation can highlight the migration priority of highly dependent service pairs.

[0072] The first and second resource contention intensities are obtained by multiplying the difference by the call frequency. They are used to quantify the contention pressure on service instances on a specific node, reflecting the non-linear superposition effect of resource demand similarity and communication intensity. The potential conflict value is obtained by taking the maximum of the two resource contention intensities. It is used to focus on the most severe conflict points on the target node, ensuring that migration decisions cover the instances with the highest contention risk in the service pair.

[0073] Migrating interfering instance pairs to the optimal node breaks the chain reaction of latency caused by cross-NUMA memory access, thereby stabilizing microservice performance.

[0074] This is closely linked to the previously constructed service call graph and resource requirement profile vector. The service call graph provides information on the call relationships and communication intensity between microservice instances, while the resource requirement profile vector reflects the resource requirement characteristics of microservice instances. By dynamically integrating these two, it is possible to more accurately locate pairs of microservice instances that are coexisting on the same NUMA node and have close calls, thereby effectively avoiding performance instability issues caused by memory bandwidth contention.

[0075] This application also provides a computer-readable storage medium for storing a computer program, which, when executed by a processor, implements the steps of a dynamic resource allocation method for ARM microservices based on workload prediction.

[0076] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0077] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0078] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0079] These computer program instructions can also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0080] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0081] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A dynamic resource allocation method for ARM microservices based on workload prediction, characterized in that, Includes the following steps: Obtain the mapping relationship between microservice instances and NUMA nodes, and generate a mapping relationship table; Obtain the call frequency, CPU utilization, and call latency of microservice instances; construct a service call graph based on the call frequency and call latency; and identify and obtain candidate microservice pairs based on the mapping table and service call graph. When the call latency of a candidate microservice pair exceeds a first preset threshold and the CPU utilization is lower than a second preset threshold, it is marked as a suppressed microservice pair. Collect performance data of microservice instances and corresponding NUMA nodes of suppressed microservice pairs, and generate resource demand profile vectors based on these data using clustering algorithms. If the current memory bandwidth utilization of any of the suppressed microservice pairs exceeds the third preset threshold, then it is determined whether the magnitude of its resource demand profile vector exceeds the fourth preset threshold. If so, it is marked as an interfering instance pair. Perform resource migration operations on the interfering instances.

2. The method for dynamic resource allocation of ARM microservices based on workload prediction according to claim 1, characterized in that, The specific process for obtaining the mapping relationship table is as follows: Obtain real-time running status information for all microservice instances; From the real-time running status information, the unique identifier of each microservice instance and its physical identifier on the host machine are parsed out; Query the NUMA node topology information of the ARM server corresponding to the physical identifier through the host machine's system information query interface; Based on the mapping table between the obtained microservice instance unique identifier, ARM server physical identifier, and NUMA node identifier.

3. The method for dynamic resource allocation of ARM microservices based on workload prediction according to claim 1, characterized in that, The specific construction process of the service call graph is as follows: Collect the call relationships of all microservice instances within a preset time window; Construct a graph structure with any microservice instance in a microservice instance pair as a node and the call relationship as directed edges; For each pair of microservice instances with a calling relationship, form a microservice instance pair and calculate its average call frequency and average call latency within the time window; The average call frequency and average call latency are normalized respectively. Then, the normalized call frequency and the normalized call latency are weighted and summed to obtain the comprehensive weight value of each directed edge. Assign a comprehensive weight value to each directed edge in the graph structure to obtain a weighted directed graph, which is denoted as the service call graph.

4. The method for dynamic resource allocation of ARM microservices based on workload prediction according to claim 1, characterized in that, The specific process for identifying and obtaining candidate microservice pairs is as follows: Traverse all directed edges in the service call graph. For each directed edge connecting two microservice instances, query the mapping table to obtain the corresponding NUMA node set. Determine whether the NUMA node sets corresponding to two microservice instances contain the same NUMA node; If so, the pair of microservice instances will be identified as a candidate microservice pair.

5. The method for dynamic resource allocation of ARM microservices based on workload prediction according to claim 1, characterized in that, The specific process for obtaining the resource demand profile vector is as follows: For each suppressed microservice pair, its CPU utilization and cache miss rate, as well as the memory bandwidth utilization of the NUMA node where the microservice pair resides, are collected, and the data from these three dimensions are combined into a data sample. Based on data samples within a preset time period, construct a cluster analysis dataset; Calculate the sum of variances of all data samples in the cluster analysis dataset in terms of CPU utilization, cache miss rate, and memory bandwidth utilization. Multiply the sum of variances by the ratio of the current total number of suppressed microservice pairs to the reference average total number of microservice pairs. Multiply the result by the preset minimum value of the number of clusters to obtain the number of clusters. Clustering algorithms are used to perform cluster analysis on the dataset according to the number of clusters to obtain the clusters. For each cluster, the coordinate vector of its cluster center is calculated and normalized. The normalized coordinate vector is then defined as the resource requirement profile vector of that type of microservice.

6. The method for dynamic resource allocation of ARM microservices based on workload prediction according to claim 5, characterized in that, The specific process for obtaining the number of clusters also includes: Collect the number of suppressed microservice pairs within multiple consecutive time windows prior to the current moment to form time series data; Calculate the difference between values ​​in adjacent time windows in the time series data, and use the difference as the trend data; When the fluctuation range of adjacent trend data exceeds the fifth preset threshold, calculate the standard deviation and average value of the trend data within the most recent time windows; The trend volatility is calculated by dividing the standard deviation by the mean. When the trend volatility exceeds the sixth preset threshold, the first correction value is obtained by adding 1 to the difference between the trend volatility and the sixth preset threshold. The number of clusters is then multiplied by the first correction value to obtain the corrected first number of clusters, and the number of clusters is updated accordingly. When the trend volatility does not exceed the sixth preset threshold, the result of subtracting the difference between the sixth preset threshold and the trend volatility from 1 is used as the second correction value. The number of clusters is multiplied by the second correction value to obtain the corrected second number of clusters and the number of clusters is updated accordingly. If the updated number of clusters exceeds the preset maximum number of clusters, then the clustering algorithm parameters will be adjusted based on feedback.

7. The method for dynamic resource allocation of ARM microservices based on workload prediction according to claim 6, characterized in that, The specific process of adjusting the clustering algorithm parameters feedback is as follows: Divide the updated number of clusters by the preset maximum number of clusters to obtain a scaling factor; The original search radius parameter is multiplied by an adjustment amount proportional to the scaling factor to obtain the new search radius parameter; The new search radius parameter is used to re-execute the cluster analysis; Record the number of times cluster analysis is re-executed in the preset rounds. If the number of times cluster analysis is re-executed exceeds the preset adjustment threshold, then perform cluster effect verification feedback adjustment.

8. The method for dynamic resource allocation of ARM microservices based on workload prediction according to claim 7, characterized in that, The specific process for adjusting the clustering effect verification feedback is as follows: Obtain all cluster counts in the preset rounds as a historical cluster count set; After each round of cluster analysis, for each cluster, the sum of Euclidean distances from all resource demand profile vectors within the cluster to the centroid vector of the cluster is calculated. Then, the sum of these distances for all clusters is added together to obtain the intra-cluster distance sum. The Euclidean distances between each pair of centroid vectors of all clusters are calculated, and the minimum inter-cluster centroid distance is found. Then, this minimum inter-cluster centroid distance is divided by the average of the intra-cluster distance sums to obtain the inter-cluster distance ratio. After normalizing the sum of intra-class distances and the ratio of inter-class distances respectively, the weighted sum is obtained to obtain the clustering index of the historical cluster count set; The number of clusters corresponding to the maximum value of the clustering composite index is selected as the number of clusters for the next round.

9. The method for dynamic resource allocation of ARM microservices based on workload prediction according to claim 1, characterized in that, The specific operations for performing resource migration on the interfering instance are as follows: Based on the mapping table, all NUMA nodes whose current memory bandwidth utilization is lower than the sixth preset threshold are obtained from all corresponding NUMA nodes, forming the target node set; Obtain the two resource demand profile vectors corresponding to the interference instance, denoted as the first vector and the second vector, respectively; Calculate the Euclidean distance between the first and second vectors of the interference instance pair and the resource demand profile vector of the target node, respectively, to obtain the first and second dissimilarity scores. From the service call graph, obtain the two call frequencies corresponding to the interference instance pair, and denote them as the first call frequency and the second call frequency, respectively. The first resource contention intensity is obtained by multiplying the first difference degree by the first call frequency, and the second resource contention intensity is obtained by multiplying the second difference degree by the second call frequency. The maximum value between the first resource contention intensity and the second resource contention intensity of the target node is taken as the potential conflict value of the target node; Select the target node with the smallest potential conflict value as the optimal migration target node; Migrate the interfering instances from the resources of the original NUMA node to the optimal migration target node.

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

Images