A cross-platform numa adaptive optimization method and system in a cloud computing scenario

Abstract

The application relates to the field of data processing, in particular to a cross-platform NUMA adaptive optimization method in a cloud computing scenario. The method obtains a system-level resource capability benchmark by monitoring the resource allocation of server hardware and each NUMA node, and simultaneously monitors the process groups in the server, respectively collects resource usage data of the process groups in two scenarios of service stress testing and daily normality, and constructs a process-level multi-scene resource portrait. Based on the portrait, the memory and CPU ratio in different scenarios are compared, the resource reservation type and reservation amount of the target process are dynamically decided, and combined with the application category divided according to the process life cycle and behavior predictability, the corresponding NUMA resource binding and dynamic adjustment strategy is generated and executed. The application realizes automatic and refined resource scheduling of different types of cloud computing applications under a complex heterogeneous NUMA architecture, can effectively improve the resource utilization efficiency and application running performance, and at the same time, eliminates the manual adaptation cost when crossing different processor platforms.

Description

Technical Field

[0001] This invention relates to the field of data processing, and more specifically, to a cross-platform NUMA adaptive optimization method and system in a cloud computing scenario. Background Technology

[0002] With the widespread adoption of multi-core processor technology, NUMA (Non-Uniform Memory Access) architecture has become the mainstream design for modern servers, including mainstream x86 and emerging domestic chip platforms such as ARM. This architecture effectively alleviates bus contention issues in multi-core systems by organizing the processor and local memory into multiple nodes, significantly improving memory access efficiency and system scalability. In the cloud computing field, deploying various computing, storage, and middleware applications on NUMA architecture has become an important trend in the pursuit of higher performance and resource utilization.

[0003] However, the application ecosystem in cloud computing environments is complex and diverse. Many traditional applications were initially developed based on SMP (Symmetric Multiprocessing) architectures, whose operating models do not take into account the heterogeneous memory access characteristics of NUMA. Directly deploying these applications in a NUMA environment may lead to frequent remote memory accesses, not only failing to leverage the performance advantages of NUMA but also potentially causing severe performance degradation and resource waste. Current technologies typically address this challenge by requiring in-depth performance profiling and manual tuning for specific software and hardware platforms, such as manually binding processes to NUMA nodes to optimize resource locality. This approach is highly dependent on expert experience, cumbersome, and difficult to scale.

[0004] Furthermore, cloud computing platforms typically need to manage hardware resources from different vendors using different instruction set architectures (such as x86, ARM, MIPS, etc.). This heterogeneous environment means that NUMA configuration strategies optimized for one platform may completely fail or even have negative effects on another platform, resulting in high and repetitive cross-platform adaptation costs. Therefore, there is an urgent need in the field for a generalized NUMA optimization scheme that can automatically perceive the underlying hardware architecture and adapt to the characteristics of different types of application workloads, in order to achieve stable and optimized application performance in cross-platform NUMA environments. Summary of the Invention

[0005] The purpose of this invention is to provide a generalized NUMA optimization scheme for cloud computing scenarios.

[0006] According to a first aspect of the present invention, a cross-platform NUMA adaptive optimization method for cloud computing scenarios is proposed, comprising the following steps: S1. Monitor and collect resource allocation data of server hardware and each NUMA node to obtain a system-level resource capability benchmark; S2. Monitor a process group on the server, calculate the first resource usage data of the process group in the business stress test scenario and the second resource usage data in the daily normal scenario, so as to build a process-level multi-scenario resource profile for decision-making. S3. For any target process in the process group, based on the corresponding multi-scenario resource profile, by comparing the first resource usage data and the second resource usage data, dynamically decide the type and amount of resource reservation for the target process; S4. Determine the lifecycle and behavioral predictability of the target process based on the process-level multi-scenario resource profile, and further classify the target process into different application categories; S5. Utilize system-level resource capacity benchmarks, resource reservation types and amounts determined for the target process, and application categories to generate and execute corresponding NUMA resource binding and dynamic adjustment strategies to ensure that resource reservations are satisfied on the bound NUMA nodes.

[0007] According to some embodiments, in the method of the first aspect of the present invention, the type and amount of dynamic decision-making resource reservation in step S3 specifically include: S31. From the process-level multi-scenario resource profile, obtain the first memory to CPU ratio of the target process in the stress test scenario and the second memory to CPU ratio in the normal scenario; S32. Compare the first ratio and the second ratio, and determine the larger ratio as the decision-making basis ratio; S33. Based on the resource demand characteristics represented by the decision-making basis ratio, determine the resource demand tendency of the target process: If the decision-making basis ratio is the second ratio, then memory is determined as the resource reservation type, and the memory reservation amount is calculated based on memory usage data under normal scenarios. If the decision-making basis ratio is the first ratio, then CPU is determined as the resource reservation type, and the CPU reservation amount is calculated based on CPU usage data under normal scenarios.

[0008] According to some embodiments, in the method of the first aspect of the present invention, in step S33, the memory reservation amount is calculated as follows: the larger of the product of the average memory usage value under normal scenarios and a first preset multiple, and the product of the peak memory usage value under stress testing scenarios and a second preset multiple is taken. The CPU reserve is calculated as follows: take the larger of the product of the average CPU usage under normal scenarios and the first preset multiple, and the product of the peak CPU usage under stress testing scenarios and the second preset multiple.

[0009] According to some embodiments, in the method of the first aspect of the present invention, the lifecycle characteristics include continuous operation and short-term operation, and the behavioral predictability characteristics include stability, planned triggering, and random uncertainty; step S4 specifically includes: Given that the target process's lifecycle characteristics are continuous operation and its behavior predictability characteristics are stable, the application category is determined to be an ordered-resident process. Given that the target process has a short lifecycle and predictable behavior (triggered according to a schedule), the application is classified as an ordered-non-resident process. When the predictability of the target process's behavior is random and unpredictable, the application category is determined to be an unordered process.

[0010] According to some embodiments, in the method of the first aspect of the present invention, in step S5, for the target process whose application category is determined to be an unordered process, a corresponding NUMA resource binding and dynamic adjustment strategy is generated and executed, specifically including: Set a resource utilization threshold for the target process; When the resource utilization rate of the target process exceeds the resource utilization rate threshold, based on the resource reservation type and reservation amount dynamically determined for the target process in step S3, it is included in the management scope of NUMA resource binding and bound to the core. Monitor the target processes that have been managed in this way, and when the resource usage reaches a certain percentage of the reserved resources decided for the target process, trigger the resource expansion operation.

[0011] According to some embodiments, in the method of the first aspect of the present invention, in step S5, for the target process whose application category is determined to be an ordered-resident process, a corresponding NUMA resource binding and dynamic adjustment strategy is generated and executed, specifically including: Resource consumption assessment and unpacking / binding steps: Based on the resource reservation amount decided for the target process in step S3, determine its resource consumption level; for target processes with high resource consumption levels, prioritize unpacking and binding them to different NUMA nodes to achieve load balancing among nodes; Intra-node resource reservation and binding steps: Based on the resource reservation type and reservation amount determined for the target process in step S3, resources are reserved for it on the specified NUMA node, and the process is bound to the NUMA node with the reserved corresponding resources to avoid inter-process resource conflicts within the node.

[0012] According to some embodiments, the resource reservation and binding step within a node in the method of the first aspect of the present invention specifically includes: If the resource reservation type determined for the target process is CPU, then bind the target process to a NUMA node and ensure that the node reserves computing resources corresponding to the CPU reservation amount for the process; If the resource reservation type determined for the target process is memory, then perform the following operations: Based on the server's total memory to CPU ratio in the system-level resource capability benchmark obtained in step S1, calculate the corresponding amount of CPU required to guarantee the memory reserve. Bind the target process to a NUMA node that can simultaneously meet its memory reservation and CPU requirements.

[0013] According to a second aspect of the present invention, a cross-platform NUMA adaptive optimization system for implementing the method of the first aspect of the present invention is proposed, comprising: The resource monitoring module is configured to execute steps S1 and S2, namely: collecting resource allocation data of server hardware and each NUMA node to obtain system-level resource capability benchmarks; and monitoring process groups in the server to build process-level multi-scenario resource profiles. The decision analysis module, connected to the resource monitoring module, is configured to execute steps S3 and S4, namely: for the target process in the process group, dynamically decide the resource reservation type and reservation amount based on its multi-scenario resource profile; and determine the life cycle and behavioral predictability of the target process based on the resource profile, and classify it into different application categories. The strategy execution engine connects to the decision analysis module and accesses the system-level resource capability benchmark obtained by the resource monitoring module. It is configured to execute step S5, which is to comprehensively utilize the resource capability benchmark, the resource reservation type and reservation amount determined for the target process, and its application category to generate and execute the corresponding NUMA resource binding and dynamic adjustment strategy.

[0014] According to some embodiments, in the system of the second aspect of the present invention, the decision analysis module is further configured to: when dynamically deciding the type and amount of resource reservation. Obtain the first memory to CPU ratio of the target process under stress testing and the second memory to CPU ratio under normal scenarios from the process-level multi-scenario resource profile; Compare the first ratio and the second ratio, and determine the larger ratio as the decision-making basis ratio; Based on the decision-making criteria ratio, the resource demand tendency is determined to identify the type of resource reservation, and the resource reservation amount is calculated based on the resource usage data under normal scenarios.

[0015] According to some embodiments, in the system of the second aspect of the present invention, the policy execution engine includes: The resident process management unit is configured to perform resource consumption assessment and unbinding operations, as well as resource reservation binding operations within nodes, on target processes whose application category is ordered-resident process. The non-resident process scheduling unit is configured to dynamically allocate and release NUMA resources for target processes whose application category is ordered-non-resident process. The unordered process management unit is configured to perform resource utilization threshold determination, core binding, and monitoring and expansion operations on target processes whose application category is unordered process.

[0016] The technical advantages of the solution proposed in this invention are reflected in the following aspects: 1. To address the issue of static and rigid resource scheduling strategies under NUMA architecture, which cannot adapt to the actual load characteristics of applications, this invention constructs process resource profiles based on dual scenarios of "business stress testing" and "normal daily operations," and dynamically decides on the type and amount of resource reservation. This enables accurate identification and resource reservation of the application's essential needs (CPU-intensive or memory-intensive), ensuring that resource allocation is more in line with the actual operating rules of the application, thereby improving the accuracy of resource configuration and system performance.

[0017] 2. To address the issue that a single NUMA scheduling strategy cannot accommodate all process behavior patterns in a cloud computing environment due to the diverse application types, this invention introduces a process classification system based on "lifecycle" and "behavioral predictability" (ordered-resident, ordered-non-resident, unordered). This enables a divide-and-conquer approach for differentiated applications, allowing for the formulation and execution of the most targeted NUMA binding and adjustment strategies for each type of process, thereby achieving refined scheduling and improved overall system efficiency.

[0018] 3. To address the issue of resource contention and "hot spots" caused by high-consumption resident processes clustering on a single NUMA node, this invention prioritizes distributing high-consumption resident processes to different NUMA nodes and reserves dedicated resources for them within each node. This achieves load balancing between NUMA nodes and resource isolation within each node, effectively avoiding inter-process interference and ensuring the performance stability of critical applications.

[0019] 4. To address the issue that when binding cores to memory-intensive processes, the required CPU resources are easily overlooked, thus affecting memory access efficiency, this invention calculates the amount of CPU required to ensure memory bandwidth based on the system-level memory / CPU ratio when binding memory resources, and binds it to a NUMA node that can simultaneously satisfy both. This achieves coordinated allocation of memory and computing resources, fundamentally ensuring the locality of memory access and fully leveraging the performance advantages of the NUMA architecture.

[0020] 5. To address the problem that disordered or temporary processes are difficult to manage effectively and that their resource requirements fluctuate greatly, which can easily lead to performance instability, this invention sets a resource utilization threshold for disordered processes to trigger management, monitors their resource consumption, and dynamically expands capacity according to preset rules. This achieves automated and elastic resource supply for random loads, ensuring performance while avoiding excessive management overhead. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without exceeding the scope of protection claimed by the present invention.

[0022] Figure 1 This is a flowchart illustrating an embodiment 1000 of a cross-platform NUMA adaptive optimization method in a cloud computing scenario according to the present invention.

[0023] Figure 2 for Figure 1 A flowchart illustrating step S3 in embodiment 1000; Figure 3 for Figure 1 A flowchart illustrating step S4 in embodiment 1000; Figure 4 for Figure 1 A flowchart illustrating step S5A of step S5 in embodiment 1000; Figure 5 for Figure 1 A flowchart illustrating step S5B of embodiment S5 in embodiment 1000. Figure 6 This is a schematic diagram of an embodiment 2000 of a cross-platform NUMA adaptive optimization system in a cloud computing scenario according to the present invention; Figure 7 for Figure 1 A schematic diagram of the strategy execution engine 203 in the Chinese embodiment 2000. Detailed Implementation

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

[0025] Figure 1This is a flowchart illustrating an embodiment 1000 of the cross-platform NUMA adaptive optimization method in a cloud computing scenario according to the present invention. Figure 1 As shown, Example 1000 includes steps S1-S5.

[0026] In step S1, the resource allocation data of the server hardware and each NUMA node are monitored and collected to obtain a system-level resource capability benchmark. Optionally, step S1 aims to quantify the inherent resource endowment of the entire server and its internal NUMA nodes from a macroscopic perspective, laying the foundation for subsequent precise matching of process requirements with node capabilities. The core is the resource density ratio of the computing system, that is, the ratio of memory to CPU.

[0027] Optionally, the implementation process of step S1 specifically includes: (1) Monitoring and acquisition process: Collect static configuration data of physical hardware through system tools (such as lscpu, numactl) or kernel interface.

[0028] Key data includes: Total server memory capacity; Total number of logical CPU cores in the server; Local memory capacity of each NUMA node; The number of logical CPU cores owned by each NUMA node.

[0029] (2) Calculate resource allocation: Formula 1: Server hardware configuration memory / CPU ratio M / C = a(m(n)) / ∑u(o(n)) Parameter description: a(m(n)): Represents the total memory capacity of the server.

[0030] ∑u(o(n)): Represents the total number of CPU cores in the server.

[0031] This formula calculates the average amount of memory allocated to each CPU core at the server level, reflecting the overall resource allocation of the system.

[0032] Formula 2: Memory / CPU ratio of a single NUMA node numa_mem(n) / numa_cpu(n) Parameter description: numa_mem(n): Represents the local memory capacity of the nth NUMA node.

[0033] numa_cpu(n): Represents the number of CPU cores in the nth NUMA node.

[0034] This formula calculates the ratio of memory to CPU cores within each NUMA node, revealing the heterogeneity of resources between different nodes and serving as a key basis for precise binding.

[0035] In step S2, a process group on the server is monitored, and the first resource usage data of the process group under business stress testing scenarios and the second resource usage data under normal daily scenarios are calculated to construct a process-level multi-scenario resource profile for decision-making. Optionally, step S2, by long-term monitoring of processes under scenarios with the highest business volume (such as stress testing) and normal scenarios (i.e., daily operation), avoids the drawback of making decisions based solely on instantaneous states and constructs a dynamic profile that reflects the true resource status of the process. This solves the problem that traditional schedulers cannot distinguish the behavior patterns of processes under different pressures.

[0036] Specifically, step S2 is achieved through the following process: (1) Scene monitoring and data acquisition: Within a preset time period, monitor the resource usage of a target process group in both the stress testing environment and the normal production environment. Collect the instantaneous CPU utilization and instantaneous memory usage of each process.

[0037] (2) Calculate the average utilization rate: The collected instantaneous data is averaged to smooth out fluctuations and obtain a representative level of resource utilization.

[0038] Formula 3: Average CPU utilization of a single process CPU(util) = ∑CPU(avg) / n(time) This formula calculates the average CPU utilization of a process within a specific time window n, ∑CPU(avg), thus obtaining its average CPU utilization CPU(util).

[0039] Formula 4: Average memory usage statistics for a single process MEM(util) = ∑MEM(avg) / n (time) This formula calculates the average memory usage of a process within a specific time window n, ∑MEM(avg), thus obtaining its average memory usage MEM(util).

[0040] (3) Calculate the key ratio: Formula 5: Average memory / CPU ratio of a single process Process_M_C = MEM(util) / CPU(util) The critical ratio is an indicator of a process's resource requirements. A high ratio indicates that the process requires a large amount of memory for every unit of CPU consumed, suggesting a memory-intensive nature; a low ratio suggests a CPU-intensive nature.

[0041] (4) Construct a profile, and construct a multi-scenario resource profile for each process that includes the following data: Load testing scenario data: process_cpu_max, process_mem_max, Process_M_C_max; Normal scenario data: process_cpu_normal, process_mem_normal, Process_M_C_normal In step S3, for any target process in the process group, based on the corresponding multi-scenario resource profile, the resource reservation type and amount for the target process are dynamically determined by comparing the first resource usage data and the second resource usage data. Optionally, step S3 is the core decision engine of the solution. By comparing the differences in process behavior under pressure and normal conditions, it intelligently determines the type of resource (CPU or memory) that needs to be guaranteed the most, and adopts a strategy that takes into account both stable operation and peak performance to calculate the specific reservation amount.

[0042] Optionally, step S3 specifically includes: comparing the first memory to CPU ratio with the second memory to CPU ratio, and determining the larger ratio as the decision-making basis ratio; based on the resource demand characteristics represented by the decision-making basis ratio, determining the resource demand tendency of the target process: If the decision-making basis ratio is the second memory to CPU ratio, then memory is determined as the resource reservation type, and the memory reservation amount is calculated based on memory usage data under normal scenarios; if the decision-making basis ratio is the first memory to CPU ratio, then CPU is determined as the resource reservation type, and the CPU reservation amount is calculated based on CPU usage data under normal scenarios.

[0043] Optionally, in step S3: the memory reservation amount is calculated as the larger of the product of the average memory usage value under normal scenarios and a first preset multiple, and the product of the peak memory usage value under stress testing scenarios and a second preset multiple; the CPU reservation amount is calculated as the larger of the product of the average CPU usage value under normal scenarios and a first preset multiple, and the product of the peak CPU usage value under stress testing scenarios and a second preset multiple.

[0044] In step S4, the lifecycle and predictability of the target process are determined based on the process-level multi-scenario resource profile, and the target process is further divided into different application categories.

[0045] Optionally, in step S4, the lifecycle and behavioral predictability of the target process are determined based on the process-level multi-scenario resource profile, including: (1) Life cycle characteristics: mainly based on the proportion of time a process exists within a sufficiently long statistical period T. The data is based on the existence of the PID of the target process collected at fixed time intervals within the statistical period T.

[0046] The key indicators for judgment are: Process survival rate = (Number of times the process PID was detected / Total number of times it was detected) * 100% Once started, a persistent process will remain in the system for an extended period (days, weeks, or longer), continuously providing services. Examples of persistent processes include persistent services for database services (such as MySQL), web servers (Nginx), and big data processing frameworks (Spark). Specifically, a process is considered "persistently running" if its survival rate exceeds a preset threshold. This means that the process is active for almost the entire statistical period and is a persistent service of the system.

[0047] Short-lived processes are created to complete a specific task and exit once the task is finished. Their existence time varies from a few seconds to a few hours. Examples include scheduled task scripts, data processing jobs, command-line tools, and instance creation operations in cloud platforms. Specifically, if the process survival rate is less than or equal to a preset threshold, it is considered a "short-lived process." This indicates that the process exists intermittently and exits after completing its task.

[0048] Optionally, the preset threshold for determining life cycle characteristics in step S4 is set to 98%.

[0049] (2) Behavioral predictability characteristics are analyzed by combining the process's persistence pattern and resource consumption pattern. The data used include: persistence time series, the persistence record of process PID within period T; resource consumption time series, the monitoring data of process CPU utilization (CPU(util)) and memory usage (MEM(util)) within period T.

[0050] Optionally, the classification and typical characteristics of life cycle features in step S4 include: Stability: The process's resource consumption is relatively stable, or its variation pattern is highly consistent and reproducible under stress testing and normal scenarios. Its startup, operation, and termination all follow a fixed pattern. Triggered on schedule: The startup and runtime of the process are predictable, following a preset schedule or explicit triggering conditions. Although it is a short-lived process, its behavior is orderly on a macroscopic level. Random and unpredictable: The startup, termination, and resource consumption patterns of processes have no fixed rules and are highly uncertain. This typically occurs in resource-sharing or multi-tenant environments and is dynamically scheduled by an external scheduler based on the global state.

[0051] Specifically, the process of determining life cycle characteristics includes: A. Determine whether it is "triggered on schedule" by performing pattern recognition on the process's startup time sequence.

[0052] Specific implementation: Extract all the start times of the process from the time series and analyze whether these time points show obvious periodicity, such as every 24 hours, every hour, or follow a Cron expression.

[0053] Judgment logic: If the sequence of startup times can match one or more defined periodic patterns with a high confidence level, then its behavior is judged to be "triggering as planned". For example, a process always starts at 02:00 every day and exits after running for 1 hour.

[0054] B. To determine whether a process is "stable", perform a stability analysis on the resource consumption sequence of the process during its lifetime.

[0055] Specific implementation: First, the process must have been determined to be "continuously running".

[0056] Calculate the coefficient of variation (CV) of its resource use sequence, which is the ratio of the standard deviation to the mean (CV = σ / μ). The smaller the CV, the more stable the sequence.

[0057] CPU_CV = σ(CPU_usage_series) / μ(CPU_usage_series) MEM_CV = σ(MEM_usage_series) / μ(MEM_usage_series) Judgment logic: If both CPU_CV and MEM_CV are below a preset stability threshold, it indicates that the process's resource requirements fluctuate very little and its behavior pattern is fixed, and it is judged as "stable". For example, the stability threshold can be set to 0.5.

[0058] C. Determine whether it is "random and uncertain", which is the default or specific case after the process of elimination.

[0059] Judgment logic: A system is judged as "random and uncertain" if any of the following conditions are met: The process's startup mode does not conform to the periodic pattern of "triggering on schedule".

[0060] Although the process is "running continuously", its coefficient of variation (CV) for resource consumption is higher than the stability threshold, indicating that its load fluctuates wildly and is unpredictable.

[0061] Processes are dynamically scheduled by an external orchestration system (such as Kubernetes), and their creation and destruction are driven by the cluster state, appearing random from a single-machine perspective.

[0062] Optionally, in step S4, the process of classifying the target process into different application categories includes: if the target process's lifecycle characteristic is continuous operation and its behavior predictability characteristic is stable, determining the application category as an ordered-resident process; if the target process's lifecycle characteristic is short-lived operation and its behavior predictability characteristic is scheduled triggering, determining the application category as an ordered-non-resident process; and if the target process's behavior predictability characteristic is random and unpredictable, determining the application category as an unordered process.

[0063] In step S5, the corresponding NUMA resource binding and dynamic adjustment strategy is generated and executed using the system-level resource capability benchmark, the resource reservation type and reservation amount determined for the target process, and the application category, to ensure that the resource reservation is satisfied on the bound NUMA node.

[0064] Optionally, for a target process whose application category is determined to be an unordered process, step S5 specifically includes: setting a resource utilization threshold for the target process; when the resource utilization of the target process exceeds the resource utilization threshold, then based on the resource reservation type and reservation amount dynamically decided for the target process in step S3, including it in the management scope of NUMA resource binding and binding it to the core; monitoring the target process that has been managed in this way, and when it is detected that its resource usage reaches a certain proportion of the reserved resource amount decided for the target process, triggering a resource expansion operation.

[0065] Optionally, for the target process whose application category is determined to be an ordered-resident process, step S5 specifically includes: resource consumption assessment and unpacking binding step: based on the resource reservation amount decided for the target process in step S3, its resource consumption level is determined; for target processes with high resource consumption levels, they are preferentially unpacked and bound to different NUMA nodes to achieve load balancing between nodes; intra-node resource reservation binding step: according to the resource reservation type and reservation amount decided for the target process in step S3, resources are reserved for it on the specified NUMA node, and the process is bound to the NUMA node that has reserved the corresponding resources to avoid resource conflicts between processes within the node.

[0066] Optionally, for the target process whose application category is determined to be an ordered-non-resident process, step S5 specifically includes: (1) Dynamic sensing and resource allocation: When a process starts, the policy execution engine dynamically captures its PID.

[0067] Based on the resource reservation type and reservation amount determined by S3 for this type of process, resources are allocated to it.

[0068] (2) Serial NUMA-bound core: Data processing: The system maintains resource usage queues for one or more NUMA nodes. During allocation, it will prioritize fully allocating the resources of a NUMA node to a single process.

[0069] Execution strategy: A "serial" rather than "parallel" allocation method is adopted. That is, process A is given priority to exclusively run on Node 0; after A finishes, process B is then given exclusive access to Node 0. This approach maximizes the use of memory locality and avoids cache pollution and context switching overhead caused by multiple short-lived processes running concurrently on the same node.

[0070] Allocation ratio reference: When allocating, ensure that the memory / CPU ratio within the NUMA node allocated to the process is as close as possible to the decision basis ratio (Process_M_C) calculated in S3 for that process, so as to achieve the best matching of resources.

[0071] (3) Resource release: After the process finishes running, it immediately releases all NUMA resources (CPU cores and memory) it occupies and returns them to the resource pool for use by subsequent processes.

[0072] According to such Figure 1 The implementation shown in this invention achieves automated and refined resource scheduling for various cloud computing applications under a complex and heterogeneous NUMA architecture by constructing a fully adaptive closed loop of "monitoring-profiling-decision-classification-execution". The ultimate effect is a significant improvement in application performance, fully leveraging the advantages of the NUMA architecture while eliminating the tedious and expensive manual tuning costs associated with different hardware platforms, thus achieving a dual improvement in resource utilization efficiency and system operation and maintenance efficiency.

[0073] Figure 2 for Figure 1 A flowchart illustrating step S3 in embodiment 1000. (See attached diagram.) Figure 2 As shown, step S3 includes steps S31-S33.

[0074] In step S31, the first memory-to-CPU ratio of the target process under stress testing and the second memory-to-CPU ratio under normal conditions are obtained from the process-level multi-scenario resource profile. Optionally, in step S31, the following are obtained from the process-level multi-scenario resource profile determined in step S2: the first memory-to-CPU ratio Process_M_C_max under stress testing and the second memory-to-CPU ratio Process_M_C_normal under normal conditions.

[0075] In step S32, the first memory to CPU ratio and the second memory to CPU ratio are compared, and the larger ratio is determined as the decision-making ratio.

[0076] Specifically, in step S32, if Process_M_C_max >= Process_M_C_normal, then Process_M_C = Process_M_C_max; otherwise, Process_M_C = Process_M_C_normal.

[0077] In step S33, based on the resource demand characteristics represented by the decision basis ratio, the resource demand tendency of the target process is determined, specifically including: if the decision basis ratio is the second memory to CPU ratio, then memory is determined as the resource reservation type, and the memory reservation amount is calculated based on the memory usage data under normal scenarios; if the decision basis ratio is the first memory to CPU ratio, then CPU is determined as the resource reservation type, and the CPU reservation amount is calculated based on the CPU usage data under normal scenarios.

[0078] Optionally, in step S33, when Process_M_C = Process_M_C_normal, it indicates that the process exhibits a higher tendency to demand memory under normal conditions, so memory is determined as the resource reservation type; when Process_M_C = Process_M_C_max, it indicates that the process exhibits stronger CPU contention under high pressure, so CPU is determined as the resource reservation type.

[0079] Optionally, in step S33, the calculation of memory reservation aims to ensure both scenarios: it needs to meet the resource requirements for stable daily operation, which requires reference to the normal average value; and it needs to absorb the impact of peak business, which requires reference to the peak value of stress test, and to achieve a balance between the two.

[0080] Optionally, in step S33, the memory reservation amount is calculated as follows: the larger of the product of the average memory usage value under normal scenarios and a first preset multiple, and the product of the peak memory usage value under stress testing scenarios and a second preset multiple.

[0081] In some specific embodiments, in step S33, when the reservation type is memory: P_reserve_mem = MAX(process_mem_normal*1.5, process_mem_max*0.8) Between the guaranteed requirement of 50% higher than normal memory usage and the economic requirement of 20% lower than peak memory usage during stress testing, the larger value should be chosen. This prevents both insufficient memory and excessive reservation.

[0082] Optionally, in step S33, the CPU reserve is calculated as follows: the larger of the product of the average CPU usage value under normal scenarios and the first preset multiple, and the product of the peak CPU usage value under stress testing scenarios and the second preset multiple.

[0083] In some specific embodiments, in step S33, when the reservation type is CPU: P_reserve_cpu = MAX(process_cpu_normal * 1.5, process_cpu_max * 0.8) The larger value between 50% increase in normal CPU usage and 20% reduction in peak CPU usage during stress testing should be used as the CPU computing resources that need to be reserved.

[0084] According to such Figure 2 The implementation shown in this invention intelligently and dynamically determines the type and amount of resource reservation by comparing the memory / CPU ratio of a process under stress testing and normal scenarios. The effect of this mechanism is that it can accurately identify whether a process's inherent needs are memory-intensive or CPU-intensive, thus avoiding the limitations of traditional methods that use CPU as a single benchmark. This makes resource reservation more aligned with the actual load characteristics of the application, ensuring the accuracy and efficiency of resource allocation from the source.

[0085] Figure 3 for Figure 1 A flowchart illustrating step S4 in embodiment 1000. (See attached diagram.) Figure 3 As shown, step S4 includes steps S41-S43.

[0086] Step S41: If the target process's lifecycle characteristic is continuous operation and its behavior predictability characteristic is stable, determine the application category as an ordered-persistent process. Step S42: If the target process's lifecycle characteristic is short-lived operation and its behavior predictability characteristic is scheduled triggering, determine the application category as an ordered-non-persistent process. Step S43: If the target process's behavior predictability characteristic is random and unpredictable, determine the application category as an unordered process.

[0087] Specifically, in step S4, the decision-making process may include: Analyze the startup mode: First, determine if the process is "triggered on schedule". If so, classify it as an ordered-non-resident process.

[0088] Analyze sustainability and stability: If it is not triggered as planned, calculate its "survival rate".

[0089] If the survival rate is high (continuous operation), then further analysis of the "stability" of its resource consumption is needed.

[0090] If stable, it is classified as an ordered-resident process.

[0091] If it is unstable, it is classified as an unordered process.

[0092] Default classification: If none of the above conditions are met (i.e., unplanned, non-continuous), it is directly classified as an unordered process.

[0093] According to such Figure 3 In the implementation shown, step S4 of this invention introduces two dimensions: "lifecycle" and "behavioral predictability," finely dividing processes into three categories: ordered-resident, ordered-non-resident, and unordered. The technical effect of this approach is to achieve precise scheduling through divide and conquer, providing a clear basis for subsequent execution of differentiated optimization strategies. This solves the problem that a single, general NUMA strategy cannot accommodate diverse application behaviors, thus optimizing the overall system scheduling efficiency.

[0094] Figure 4 for Figure 1 A flowchart illustrating step S5A of step S5 in embodiment 1000. Figure 4 As shown, step S5A represents the specific implementation process of generating and executing the corresponding NUMA resource binding and dynamic adjustment strategy for the target process whose application category is determined to be an out-of-order process. Step S5A includes steps S5A1-S5A3. Out-of-order processes in step S5A are characterized by unpredictable behavior, and the strategy aims for low-overhead management, elastic scaling, and avoiding performance runaway.

[0095] In step S5A1, a resource utilization threshold is set for the target process. For example, a sustained CPU utilization exceeding 70% or memory usage exceeding 8GB. In step S5A2, when the resource utilization rate of the target process exceeds the resource utilization rate threshold, the target process is included in the management scope of NUMA resource binding and bound to the core based on the resource reservation type and reservation amount dynamically determined for the target process in step S3.

[0096] Optionally, in step S5A2, the resource utilization rate of the process is continuously monitored, and the management process is triggered only when its utilization rate exceeds a set threshold.

[0097] In step S5A3, the target process that has been managed in this way is monitored. When the resource usage reaches a certain proportion of the reserved resources decided for the target process, the resource expansion operation is triggered.

[0098] Optionally, in step S5A3: For unordered processes that have been included in the management, continuously monitor their resource usage and calculate the ratio of their usage to the reserved resource amount determined by S3. When resource usage reaches 90% of the reserved resources, the "1.5x expansion rule" is triggered. This means that the reserved CPU and memory resources are immediately increased to 1.5 times the current amount, and the NUMA binding is dynamically adjusted, migrating or expanding to a NUMA configuration that can meet the new resource volume. This provides effective elasticity protection for sudden traffic surges.

[0099] According to such Figure 4 The implementation method shown in this invention addresses unordered processes by setting resource thresholds for triggered management and implementing a monitoring and scaling mechanism, thereby achieving intelligent and elastic management of unpredictable loads. Its effectiveness lies in automatically handling random loads with low management overhead while ensuring the performance of critical processes remains unaffected, and rapidly scaling up elastically during traffic surges. This ensures both system stability and resource supply agility in complex and ever-changing cloud environments.

[0100] Figure 5 for Figure 1 A flowchart illustrating step S5B of embodiment S5 in embodiment 1000. (See attached flowchart.) Figure 5 As shown, step S5B represents the specific implementation process of generating and executing the corresponding NUMA resource binding and dynamic adjustment strategy for the target process whose application category is determined to be an ordered-resident process. Step S5B includes steps S5B1 and S5B2.

[0101] Resource consumption assessment and unbinding step S5B1: Based on the resource reservation amount decided for the target process in step S3, determine its resource consumption level; for target processes with high resource consumption levels, preferentially unbind them to different NUMA nodes to achieve load balancing among nodes.

[0102] Specifically, in step S5B1, the reserved amount of the process determined in step S3 is compared with a system-level benchmark. For example, P_reserve_cpu is compared with 50% of the total number of CPU cores on a single NUMA node, or P_reserve_mem is compared with 50% of the total memory. If the reserved amount of the process exceeds a preset threshold, it is determined to be a "high-consumption resident process".

[0103] In step S5B1, all these high-consumption processes are preferentially distributed and bound to different NUMA nodes. For example, process A is bound to Node 0, and process B is bound to Node 1. This proactively achieves load balancing among NUMA nodes, preventing multiple resource-intensive processes from competing for resources on the same node.

[0104] Intra-node resource reservation and binding step S5B2: Based on the resource reservation type and reservation amount determined for the target process in step S3, reserve resources for it on the specified NUMA node, and bind the process to the NUMA node that has reserved the corresponding resources to avoid inter-process resource conflicts within the node.

[0105] Optionally, in some specific embodiments, in step S5B2, if the resource reservation type determined for the target process is CPU, then the target process is bound to a NUMA node, and it is ensured that the node reserves computing resources corresponding to the CPU reservation amount for the process. Specifically, this includes: Based on P_reserve_cpu, CPU cores with corresponding computing power are allocated from the CPU core list (cpuset) of the NUMA node to which it is assigned. Use cgroups or numactl commands to strictly bind the CPU affinity (cpuset) of the target process to this batch of reserved cores.

[0106] Optionally, in some specific embodiments, in step S5B2, if the resource reservation type determined for the target process is memory, the following operations are performed: Based on the total server memory to CPU ratio in the system-level resource capability benchmark obtained in step S1, calculate the required CPU quantity to guarantee the memory reservation; bind the target process to a NUMA node that can simultaneously meet its memory reservation and CPU quantity requirements. Specifically, this includes: (1) Calculate the required CPU resources: This is a key innovation. To ensure that memory bandwidth can be used efficiently, it is necessary to calculate the required CPU resources to guarantee P_reserve_mem based on the total memory / CPU ratio of the server in step S1: Required CPU resources = P_reserve_mem / (M / C).

[0107] (2) Select the target NUMA node: Traverse all NUMA nodes and find a node that can simultaneously satisfy the conditions of available memory ≥ P_reserve_mem and available CPU ≥ the matching amount of CPU.

[0108] (3) At this node, the specified amount of memory and the calculated amount of CPU are reserved for the process and then bound together.

[0109] According to such Figure 5 The implementation scheme presented in this invention effectively achieves load balancing between NUMA nodes and resource isolation within nodes by implementing strategies such as "dispersing and binding high-consumption processes" and "reserving resources within nodes" for ordered resident processes. This not only prevents performance hotspots and fluctuations caused by multiple high-resource-consuming processes competing for resources, but also ensures stable and predictable performance for critical resident services, thus providing a solid guarantee for the performance foundation of the entire cloud platform.

[0110] Figure 6 This is a schematic diagram of an embodiment 2000 of a cross-platform NUMA adaptive optimization system in a cloud computing scenario according to the present invention. Figure 6 As shown, embodiment 2000 includes a resource monitoring module 201, a decision analysis module 202, and a strategy execution engine 203.

[0111] Optionally, the resource monitoring module 201 is configured to perform steps S1 and S2, namely: collecting resource allocation data of server hardware and each NUMA node to obtain a system-level resource capability benchmark; and monitoring process groups in the server to build process-level multi-scenario resource profiles.

[0112] In some specific embodiments, the resource monitoring module 201 is typically deployed on each computing node of the cluster in the form of a distributed monitoring agent, and performs low-overhead data collection through operating system kernel interfaces (such as the / proc file system, numactl library, performance counters).

[0113] Optionally, the decision analysis module 202 is connected to the resource monitoring module 201 and configured to execute steps S3 and S4, namely: for the target process in the process group, dynamically decide the resource reservation type and reservation amount based on its multi-scenario resource profile; and determine the life cycle and behavioral predictability of the target process according to the resource profile, and classify it into different application categories.

[0114] Specifically, the decision analysis module 202 is the core analysis and decision center, which usually runs as an independent service, and pulls or receives monitoring data pushed by the resource monitoring module through a predefined API interface.

[0115] Optionally, the decision analysis module 202 internally encapsulates a patented decision logic algorithm. To achieve efficient classification, the decision analysis module 202 maintains a process feature database and automatically executes quantitative indicators such as process survival rate, resource sequence variation coefficient, and startup cycle pattern. Figure 1 The classification logic in step S4 of the illustrated embodiment 1000 is performed without human intervention.

[0116] Optionally, the strategy execution engine 203 is connected to the decision analysis module 202 and accesses the system-level resource capability benchmark obtained by the resource monitoring module 201. It is configured to execute step S5, namely: comprehensively utilize the resource capability benchmark, the resource reservation type and reservation amount determined for the target process, and its application category to generate and execute the corresponding NUMA resource binding and dynamic adjustment strategy.

[0117] Optionally, when dynamically deciding the type and amount of resource reservation, the decision analysis module 202 further configures the following for: The first memory to CPU ratio and the second memory to CPU ratio in the normal scenario are obtained from the multi-scenario resource profile of the process. The first ratio and the second ratio are compared and the larger ratio is determined as the decision basis ratio. The resource demand tendency is determined based on the decision basis ratio to determine the resource reservation type, and the resource reservation amount is calculated based on the resource usage data in the normal scenario.

[0118] Figure 7 for Figure 1 A schematic diagram of the strategy execution engine 203 in embodiment 2000. (See attached diagram.) Figure 7 As shown, the policy execution engine 203 includes a resident process management unit 2031, a non-resident process scheduling unit 2032, and an unordered process management unit 2033.

[0119] Optionally, the policy execution engine 203 is the final executor of the policy, and its design emphasizes modularity and policy isolation. The overall architecture is that the engine implements core binding and memory policies by calling underlying system interfaces, such as the Linux cgroups ccpuset controller, numactl commands, and sched_setaffinity system calls.

[0120] The resident process management unit 2031 is configured to perform resource consumption assessment and unbinding operations, as well as resource reservation binding operations within the node, on target processes whose application category is ordered-resident process.

[0121] Optionally, the resident process management unit 2031 maintains a global resource topology map, tracking the amount of resources reserved on each NUMA node in real time. When performing unbalanced binding, its internal algorithm calculates the current load of each node and prioritizes the node with the lowest load for binding new processes, thereby achieving true load balancing.

[0122] The non-resident process scheduling unit 2032 is configured to perform dynamic allocation and release of NUMA resources for target processes whose application category is ordered-non-resident process.

[0123] Optionally, the core of the non-resident process scheduling unit 2032 is to manage one or more NUMA node resource pools. It employs a serial scheduling algorithm, using the entire NUMA node as the smallest unit for resource allocation, ensuring that a single ephemeral task can exclusively occupy all local resources of the node, maximizing performance. The non-resident process scheduling unit 2032 is responsible for managing the entire lifecycle, including dynamic resource allocation at process startup and immediate resource reclamation and pooling after process termination.

[0124] The disordered process management unit 2033 is configured to perform resource utilization threshold determination, management and core binding, and monitoring and expansion operations on target processes whose application category is disordered process.

[0125] Optionally, the unordered process management unit 2033 implements an event-driven monitoring loop that continuously listens for resource usage events of all unmanaged processes. When it detects that the resource usage of a process exceeds a preset threshold, it immediately triggers a management workflow. The elastic scaling controller of the unordered process management unit 2033 periodically checks the resource usage of managed processes and compares it with the reserved amount. When the scaling trigger condition is met, it automatically calls the interface of the policy execution engine to complete the online adjustment of resources.

[0126] The embodiments of the present invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, any changes or modifications made by those skilled in the art based on the ideas of the present invention, its specific implementation methods, and its application scope, are all within the scope of protection of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A cross-platform NUMA adaptive optimization method in a cloud computing scenario, characterized in that, Includes the following steps: S1. Monitor and collect resource allocation data of server hardware and each NUMA node to obtain a system-level resource capability benchmark; S2. Monitor a process group in the server, calculate the first resource usage data of the process group in the business stress test scenario and the second resource usage data in the daily normal scenario, so as to construct a process-level multi-scenario resource profile for decision-making. S3. For any target process in the process group, based on the corresponding multi-scenario resource profile, by comparing the first resource usage data and the second resource usage data, dynamically decide the type and amount of resource reservation for the target process; S4. Based on the process-level multi-scenario resource profile, determine the lifecycle characteristics and behavioral predictability characteristics of the target process, and further classify the target process into different application categories. The lifecycle characteristics include continuous operation and short-term operation, and the behavioral predictability characteristics include stability, scheduled triggering, and randomness. Specifically, classifying the target process into different application categories includes: if the lifecycle characteristic of the target process is continuous operation and the behavioral predictability characteristic is stable, determining the application category as an ordered-persistent process; if the lifecycle characteristic of the target process is short-term operation and the behavioral predictability characteristic is scheduled triggering, determining the application category as an ordered-non-persistent process; and if the behavioral predictability characteristic of the target process is randomness, determining the application category as an unordered process. S5. Using the system-level resource capability benchmark, the resource reservation type and reservation amount determined for the target process, and the application category, generate and execute the corresponding NUMA resource binding and dynamic adjustment strategy to ensure that the resource reservation is satisfied on the bound NUMA node.

2. The method according to claim 1, characterized in that, The specific types and amounts of dynamic decision-making resource reservations in step S3 include: S31. From the process-level multi-scenario resource profile, obtain the first memory to CPU ratio of the target process under the stress test scenario and the second memory to CPU ratio under the normal scenario; S32. Compare the first memory to CPU ratio with the second memory to CPU ratio, and determine the larger ratio as the decision-making basis ratio; S33. Based on the resource demand characteristics represented by the decision-making criteria ratio, determine the resource demand tendency of the target process: If the decision-based ratio is the second memory to CPU ratio, then memory is determined as the resource reservation type, and the memory reservation amount is calculated based on the memory usage data under the normal scenario. If the decision-making basis ratio is the first memory to CPU ratio, then CPU is determined as the resource reservation type, and the CPU reservation amount is calculated based on the CPU usage data under the normal scenario.

3. The method according to claim 2, characterized in that, In step S33, the memory reservation amount is calculated as follows: the larger of the product of the average memory usage value under normal scenarios and a first preset multiple, and the product of the peak memory usage value under stress testing scenarios and a second preset multiple. The CPU reserve is calculated as follows: the larger of the product of the average CPU usage under normal scenarios and the first preset multiple, and the product of the peak CPU usage under stress testing scenarios and the second preset multiple.

4. The method according to claim 2, characterized in that, In step S5, for the target process whose application category is determined to be an out-of-order process, the generation and execution of the corresponding NUMA resource binding and dynamic adjustment strategy specifically includes: Set a resource utilization threshold for the target process; When the resource utilization rate of the target process exceeds the resource utilization rate threshold, the target process is included in the management scope of NUMA resource binding and bound to the core based on the resource reservation type and reservation amount dynamically determined for the target process in step S3. The target process that has been managed in this manner is monitored, and when its resource usage reaches a certain percentage of the reserved resources determined for the target process, a resource expansion operation is triggered.

5. The method according to claim 2, characterized in that, In step S5, for the target process whose application category is determined to be an ordered-resident process, the generation and execution of the corresponding NUMA resource binding and dynamic adjustment strategy specifically includes: Resource consumption assessment and unpacking / binding steps: Based on the resource reservation amount decided for the target process in step S3, its resource consumption level is determined; for target processes with high resource consumption levels, they are preferentially unpacked and bound to different NUMA nodes to achieve load balancing among nodes; Intra-node resource reservation and binding steps: Based on the resource reservation type and reservation amount determined for the target process in step S3, resources are reserved for it on the designated NUMA node, and the process is bound to the NUMA node with the reserved corresponding resources to avoid inter-process resource conflicts within the node.

6. The method according to claim 5, characterized in that, The resource reservation and binding steps within the node specifically include: If the resource reservation type determined for the target process is CPU, then the target process is bound to a NUMA node, and the node is ensured to reserve computing resources for the process corresponding to the amount of CPU reserved. If the resource reservation type determined for the target process is memory, then perform the following operations: Based on the server's total memory to CPU ratio in the system-level resource capability benchmark obtained in step S1, calculate the corresponding CPU quantity required to guarantee the memory reservation amount. The target process is bound to a NUMA node that can simultaneously meet the memory reservation and CPU requirements.

7. A cross-platform NUMA adaptive optimization system for cloud computing scenarios to implement the method as described in any one of claims 1-6, characterized in that, include: The resource monitoring module is configured to execute steps S1 and S2, namely: collecting resource allocation data of server hardware and each NUMA node to obtain system-level resource capability benchmarks; and monitoring process groups in the server to build process-level multi-scenario resource profiles. The decision analysis module, connected to the resource monitoring module, is configured to execute steps S3 and S4, namely: for the target process in the process group, dynamically decides the resource reservation type and reservation amount based on its multi-scenario resource profile; and determines the lifecycle characteristics and behavioral predictability characteristics of the target process according to the resource profile, classifying it into different application categories. The lifecycle characteristics include continuous operation and short-term operation, and the behavioral predictability characteristics include stable, scheduled triggering, and random unpredictability. Specifically, classifying into different application categories includes: when the lifecycle characteristic of the target process is continuous operation and the behavioral predictability characteristic is stable, determining the application category as an ordered-resident process; when the lifecycle characteristic of the target process is short-term operation and the behavioral predictability characteristic is scheduled triggering, determining the application category as an ordered-non-resident process; and when the behavioral predictability characteristic of the target process is random unpredictability, determining the application category as an unordered process. The strategy execution engine is connected to the decision analysis module and accesses the system-level resource capability benchmark obtained by the resource monitoring module. It is configured to execute step S5, namely: by comprehensively utilizing the resource capability benchmark, the resource reservation type and reservation amount determined for the target process, and its application category, to generate and execute the corresponding NUMA resource binding and dynamic adjustment strategy.

8. The system according to claim 7, characterized in that, When dynamically deciding on the type and amount of resource reservation, the decision analysis module is further configured to: The first memory to CPU ratio of the target process under stress testing and the second memory to CPU ratio under normal scenarios are obtained from the process-level multi-scenario resource profile. Compare the first memory to CPU ratio with the second memory to CPU ratio, and determine the larger ratio as the decision-making basis ratio; Based on the aforementioned decision criteria ratio, the resource demand tendency is determined to identify the resource reservation type, and the resource reservation amount is calculated based on resource usage data under normal scenarios.

9. The system according to claim 8, characterized in that, The strategy execution engine includes: The resident process management unit is configured to perform resource consumption assessment and unbinding operations, as well as resource reservation binding operations within nodes, on target processes whose application category is ordered-resident process. The non-resident process scheduling unit is configured to dynamically allocate and release NUMA resources for target processes whose application category is ordered-non-resident process. The unordered process management unit is configured to perform resource utilization threshold determination, core binding, and monitoring and expansion operations on target processes whose application category is unordered process.

Images