Server control method, device and equipment and readable storage medium

Abstract

The invention provides a server control method, device and equipment and a readable storage medium, and the method comprises the steps: deploying a decision engine at a firmware layer of a system stack, and carrying out the data driving based on the current operation state of a server and a historical performance adjustment scheme to automatically generate a plurality of candidate performance adjustment schemes; the performance expression and the security risk of the server under the candidate performance adjustment scheme are further evaluated, and the decision engine combines the estimated performance and the security risk of the candidate performance adjustment scheme to select a target performance adjustment scheme considering both the performance and the operation security; the control parameters of the server component are directly written through the specified interface of the firmware layer, operation system scheduling and software stack transfer links are bypassed, full-process autonomous closed-loop control from performance optimization to safety protection is realized on the premise of ensuring safe operation of the system, the performance adjustment efficiency and the response speed of the server are improved, and the service life of the server component is prolonged. And the performance adjustment cost is reduced.

Description

Technical Field

[0001] This application relates to the field of computer network technology, and in particular to a server control method, apparatus, device, and readable storage medium. Background Technology

[0002] Traditional server performance tuning primarily relies on operating system-level scheduling and manual intervention, adjusting numerous parameters to optimize server performance. However, this approach has significant limitations: firstly, tuning commands must be relayed through the operating system, resulting in substantial response latency and difficulty in handling sudden load spikes in real time; secondly, for newly deployed servers or servers with significantly different configurations, hundreds of manual trial-and-error samplings are required to determine a performance solution suitable for the current load requirements, consuming significant manpower, time, and hardware resources, leading to long tuning cycles. In summary, existing performance tuning solutions have clear limitations in terms of real-time response, tuning efficiency, and automation, making it difficult to meet the dynamic optimization needs of high-performance computing scenarios. Summary of the Invention

[0003] In view of this, in order to solve the above-mentioned technical problems, this application provides a server control method, apparatus, device and readable storage medium.

[0004] Specifically, this application is implemented through the following technical solution:

[0005] According to a first aspect of the embodiments of this application, a server control method is provided, the method being applied to a decision engine deployed on the firmware layer of a server's system stack, the method comprising:

[0006] When it is determined that the server needs to be performance tuned, based on the current values ​​of N performance metrics of the server during operation and the historical performance tuning schemes used by the server, at least one candidate performance tuning scheme is decided and the estimated performance that the server can achieve when running with the candidate performance tuning scheme is evaluated.

[0007] For each candidate performance tuning scheme, evaluate the probability that the predicted value of each constraint metric does not exceed its set constraint threshold when the server is running with that candidate performance tuning scheme; the constraint metric represents the boundary condition parameter whose value is limited to the engineering allowable threshold range when the server is running safely.

[0008] Based on the estimated performance corresponding to each candidate performance tuning scheme and the probability corresponding to each constraint indicator under the candidate performance tuning scheme, a target performance tuning scheme is selected.

[0009] Based on the control parameters of the components in the target performance tuning scheme, the server is adjusted through a specified interface in the firmware layer so that the server continues to run based on the control parameters of the components in the target performance tuning scheme.

[0010] Optionally, the N performance metrics include the binding metrics; determining that performance tuning of the server is required includes:

[0011] Check whether the current value of each constraint metric during server operation does not exceed its set constraint threshold;

[0012] If so, it is determined that the server needs to be adjusted for performance; otherwise, the performance adjustment of the server is stopped, and the operation protection mechanism corresponding to the constraint indicator is triggered based on the constraint indicator whose current value exceeds its set constraint threshold.

[0013] Optionally, the constraint metric includes at least the temperature of the core computing components in the server; triggering the operational protection mechanism corresponding to the constraint metric includes:

[0014] If the temperature of the core computing component exceeds its set constraint threshold, it triggers the voltage regulation module (VRM) to send an indication signal directly to the server, causing the voltage regulation module to adjust the power supply to the core computing component to achieve hardware-level thermal fuse protection.

[0015] Optionally, a set of target performance tuning schemes may be selected, including:

[0016] For each candidate performance tuning scheme, based on the probability that the predicted value of each constraint indicator under the candidate performance tuning scheme does not exceed its set constraint threshold, the safe probability of the server running with the candidate performance tuning scheme is obtained by combining the probabilities.

[0017] Based on the estimated performance and safety probability corresponding to the candidate performance adjustment scheme, the feasibility parameters of the candidate performance adjustment scheme are determined, and the target performance adjustment scheme is selected according to the feasibility parameters of each candidate performance adjustment scheme.

[0018] Optionally, the server can be adjusted through a specified interface in the firmware layer, including:

[0019] The specified interface of the firmware layer in the server is invoked to directly write the control parameters of each component in the target performance tuning scheme into the hardware register unit to which the control parameters belong; wherein, the specified interface includes at least the Unified Extensible Firmware Interface (UEFI).

[0020] Optionally, the control parameters of each component in the target performance tuning scheme are directly written into the hardware register unit to which the control parameters belong, including:

[0021] When the target performance tuning scheme includes a first parameter indicating the CPU performance state P-state of the server, the specified interface of the firmware layer is called to directly write the first parameter into the CPU internal register MSR register;

[0022] When the target performance tuning scheme includes a second parameter indicating the memory operation control of the server, the server's PCIe configuration space is accessed through a specified interface of the firmware layer, and the second parameter is written to the control register of the memory controller mapped to the extended area of ​​the PCIe configuration space.

[0023] Optionally, as the server continues to run based on the control parameters of the components in the target performance tuning scheme, the method further includes:

[0024] Obtain the actual measured performance achieved by the server when running with the target performance tuning scheme; the measured performance is used to reflect the measured gain of the target performance index that the server's performance tuning target is concerned with;

[0025] If the measured performance indicates that the server's performance has not improved, then performance tuning of the server is stopped, and the most recent historical performance tuning scheme used before adopting the target performance tuning scheme is obtained. Based on the control parameters of the components in the most recent historical performance tuning scheme, the server is controlled through the specified interface of the firmware layer.

[0026] Optionally, the probability that the predicted value of each constraint metric does not exceed its set constraint threshold when the server uses the candidate performance tuning scheme is evaluated, including:

[0027] The current values ​​of the N performance indicators and the control parameters of the components in the candidate performance adjustment scheme are used as input features and input into the probabilistic prediction model trained for the constraint indicator.

[0028] Obtain the probability distribution of the constraint index in future control cycles, output by the probability prediction model, when the server adopts the candidate performance adjustment scheme; the probability distribution includes the prediction mean and the prediction variance.

[0029] The probability that the constraint index does not exceed its set constraint threshold is calculated based on the probability distribution.

[0030] Optionally, deciding on at least one candidate performance tuning scheme and evaluating the estimated performance that the server can achieve by running with the candidate performance tuning scheme includes:

[0031] Based on the current values ​​of the N performance indicators and the performance adjustment target, identify the current performance bottleneck of the server, and set a local search space for the control parameters related to the current performance bottleneck.

[0032] The proxy model is constructed by using the historical performance tuning scheme adopted by the server as the input sample and the actual performance of the server under the historical performance tuning scheme as the output label.

[0033] Within the local search space, based on the mean and uncertainty of the predicted performance output by the surrogate model, the search direction is guided by the acquisition function, multiple candidate performance adjustment schemes are generated iteratively, and the predicted performance given by the surrogate model for each candidate performance adjustment scheme is obtained.

[0034] According to a second aspect of the embodiments of this application, a server control device is provided, the device being applied to a decision engine deployed on the firmware layer of a server's system stack, the device comprising:

[0035] The candidate scheme acquisition and evaluation module is used to determine at least one candidate performance adjustment scheme and evaluate the estimated performance that the server can achieve when it is determined that the server needs to be adjusted for performance. This is based on the current values ​​of N performance indicators of the server during operation and the historical performance adjustment schemes adopted by the server.

[0036] The constraint metric prediction module is used to evaluate, for each candidate performance tuning scheme, the probability that the predicted value of each constraint metric will not exceed its set constraint threshold when the server is running with that candidate performance tuning scheme; the constraint metric represents a boundary condition parameter whose value is limited to the engineering allowable threshold range when the server is running safely.

[0037] The target scheme selection module is used to select a target performance adjustment scheme based on the estimated performance corresponding to each candidate performance adjustment scheme and the probability corresponding to each constraint index under the candidate performance adjustment scheme.

[0038] The control module is used to adjust the server through a specified interface in the firmware layer based on the control parameters of the components in the target performance tuning scheme, so that the server continues to run based on the control parameters of the components in the target performance tuning scheme.

[0039] Optionally, the N performance metrics include the binding metrics; the apparatus includes a performance tuning determination module, used to determine if performance tuning of the server is required.

[0040] Check whether the current value of each constraint metric during server operation does not exceed its set constraint threshold;

[0041] If so, it is determined that the server needs to be adjusted for performance; otherwise, the performance adjustment of the server is stopped, and the operation protection mechanism corresponding to the constraint indicator is triggered based on the constraint indicator whose current value exceeds its set constraint threshold.

[0042] Optionally, the constraint metric includes at least the temperature of the core computing components in the server; when the performance adjustment determination module triggers the operational protection mechanism corresponding to the constraint metric:

[0043] If the temperature of the core computing component exceeds its set constraint threshold, it triggers the voltage regulation module (VRM) to send an indication signal directly to the server, causing the voltage regulation module to adjust the power supply to the core computing component to achieve hardware-level thermal fuse protection.

[0044] Optionally, when the target scheme selection module selects a target performance tuning scheme from among them:

[0045] For each candidate performance tuning scheme, based on the probability that the predicted value of each constraint indicator under the candidate performance tuning scheme does not exceed its set constraint threshold, the safe probability of the server running with the candidate performance tuning scheme is obtained by combining the probabilities.

[0046] Based on the estimated performance and safety probability corresponding to the candidate performance adjustment scheme, the feasibility parameters of the candidate performance adjustment scheme are determined, and the target performance adjustment scheme is selected according to the feasibility parameters of each candidate performance adjustment scheme.

[0047] Optionally, when the control module is used to adjust the server through a specified interface in the firmware layer:

[0048] The specified interface of the firmware layer in the server is invoked to directly write the control parameters of each component in the target performance tuning scheme into the hardware register unit to which the control parameters belong; wherein, the specified interface includes at least the Unified Extensible Firmware Interface (UEFI).

[0049] Optionally, the control module directly writes the control parameters of each component in the target performance adjustment scheme into the hardware register unit to which the control parameters belong, including:

[0050] When the target performance tuning scheme includes a first parameter indicating the CPU performance state P-state of the server, the specified interface of the firmware layer is called to directly write the first parameter into the CPU internal register MSR register;

[0051] When the target performance tuning scheme includes a second parameter indicating the memory operation control of the server, the server's PCIe configuration space is accessed through a specified interface of the firmware layer, and the second parameter is written to the control register of the memory controller mapped to the extended area of ​​the PCIe configuration space.

[0052] Optionally, while the server continues to run based on the control parameters of the components in the target performance tuning scheme, the device further includes an automatic recovery module for:

[0053] Obtain the actual measured performance achieved by the server when running with the target performance tuning scheme; the measured performance is used to reflect the measured gain of the target performance index that the server's performance tuning target is concerned with;

[0054] If the measured performance indicates that the server's performance has not improved, then performance tuning of the server is stopped, and the most recent historical performance tuning scheme used before adopting the target performance tuning scheme is obtained. Based on the control parameters of the components in the most recent historical performance tuning scheme, the server is controlled through the specified interface of the firmware layer.

[0055] Optionally, the constraint indicator prediction module is specifically used for:

[0056] The current values ​​of the N performance indicators and the control parameters of the components in the candidate performance adjustment scheme are used as input features and input into the probabilistic prediction model trained for the constraint indicator.

[0057] Obtain the probability distribution of the constraint index in future control cycles, output by the probability prediction model, when the server adopts the candidate performance adjustment scheme; the probability distribution includes the prediction mean and the prediction variance.

[0058] The probability that the constraint index does not exceed its set constraint threshold is calculated based on the probability distribution.

[0059] Optionally, the candidate solution acquisition and evaluation module is specifically used for:

[0060] Based on the current values ​​of the N performance indicators and the performance adjustment target, identify the current performance bottleneck of the server, and set a local search space for the control parameters related to the current performance bottleneck.

[0061] The proxy model is constructed by using the historical performance tuning scheme adopted by the server as the input sample and the actual performance of the server under the historical performance tuning scheme as the output label.

[0062] Within the local search space, based on the mean and uncertainty of the predicted performance output by the surrogate model, the search direction is guided by the acquisition function, multiple candidate performance adjustment schemes are generated iteratively, and the predicted performance given by the surrogate model for each candidate performance adjustment scheme is obtained.

[0063] According to a third aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a memory and a processor; the memory being used to store a computer program; the processor being used to execute the above-described server control method by invoking the computer program.

[0064] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein the program, when executed by a processor, implements the above-described server control method.

[0065] The technical solutions provided in this application embodiment may include the following beneficial effects:

[0066] In the technical solution provided in this application, a decision engine is deployed at the firmware layer of the system stack. Based on the current operating status of the server and historical performance tuning schemes, multiple candidate performance tuning schemes are automatically generated using data-driven methods. The performance and security risks of the server under the candidate performance tuning schemes are further evaluated. The decision engine comprehensively considers the estimated performance and security risks of the candidate performance tuning schemes, selects the target performance tuning scheme that balances performance gains and operational reliability, and writes the control parameters of the server components directly through the specified interface of the firmware layer. This bypasses the operating system scheduling and software stack relay links, significantly reduces the response latency of tuning commands, and can respond to sudden load changes in real time. Under the premise of ensuring the safe operation of the system, it realizes the autonomous closed-loop control of the entire process from performance tuning to security protection, improves the efficiency and response speed of server performance tuning, and reduces tuning costs.

[0067] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Furthermore, no embodiment in this application needs to achieve all the effects described above. Attached Figure Description

[0068] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0069] Figure 1A This is a schematic diagram of the system stack architecture of a server according to an exemplary embodiment of this application;

[0070] Figure 1B This is a schematic flowchart illustrating a server control method according to an exemplary embodiment of this application;

[0071] Figure 1C This is a flowchart illustrating the probability prediction of any constraint indicator not exceeding its set constraint threshold, as shown in an exemplary embodiment of this application.

[0072] Figure 1D This is a flowchart illustrating an exemplary embodiment of this application for determining a target performance tuning scheme;

[0073] Figure 2 This is an exemplary embodiment of the present application illustrating a process for determining whether a server is operating within a safe range;

[0074] Figure 3 This is a schematic diagram illustrating an exemplary embodiment of the present application of an automatic generation of candidate performance tuning schemes and acquisition of predicted performance.

[0075] Figure 4A This is a schematic diagram illustrating the interaction between modules in a server when a server control method is used, as shown in an exemplary embodiment of this application.

[0076] Figure 4B This is an execution flowchart of a server control method illustrated in an exemplary embodiment of this application;

[0077] Figure 5 This is a schematic diagram of the structure of a server control device shown in an exemplary embodiment of this application;

[0078] Figure 6 This is a hardware schematic diagram of an electronic device illustrated in an exemplary embodiment of this application. Detailed Implementation

[0079] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

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

[0081] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, a first classification threshold may also be referred to as a second classification threshold, and similarly, a second classification threshold may also be referred to as a first classification threshold. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0082] Before describing the method provided in this application, a brief explanation of some of the terms / concepts that may be involved in this application will be provided:

[0083] PMU (Performance Monitoring Unit): A hardware module integrated into modern CPUs to collect low-level performance data during processor operation. It can monitor events such as CPU instruction execution, cache hits / misses, branch prediction errors, and bus cycles, providing performance analysis support to help developers optimize program performance. It also supports performance event counters, which can be read by the operating system or tools (such as perf on Linux).

[0084] RAPL (Running Average Power Limit): A power capping technology introduced by Intel that allows for precise monitoring and limiting of the power consumption of the CPU and its components. The monitored and limited domains include: Package (the entire CPU package), Core, Uncore (such as the memory controller), GPU (integrated graphics card), etc. It can read power usage in real time (in joules or watts) and set power limits to prevent system overheating or exceeding the power budget. It supports configuration in the BIOS, operating system, or management tools (such as through the MSR register or the powercap interface in Linux).

[0085] DTS (Digital Temperature Sensor): A high-precision temperature sensor integrated into the CPU core, used to monitor processor temperature in real time to prevent overheating and hardware damage. Typically, each core has an independent DTS, providing more accurate and faster-responding temperature readings than traditional thermistors. Temperature values ​​can be read through a specific MSR (Model Specific Register).

[0086] UEFI is a firmware interface standard that runs between the operating system and hardware. Developed by the UEFI Forum (including manufacturers such as Intel, AMD, Microsoft, Dell, and HP), it addresses the limitations of traditional BIOS, providing more secure, flexible, and efficient system boot and management capabilities. UEFI runs before the operating system is loaded, belonging to the pre-boot environment.

[0087] Performance event counters: A set of hardware registers inside the CPU used to automatically accumulate the number of occurrences of specific types of hardware events. The counters are controlled by the operating system or performance analysis tools (such as perf): they can be started, stopped, read, and cleared.

[0088] Traditional server performance tuning solutions primarily rely on operating system-level scheduling mechanisms, manually adjusting numerous parameters that may impact system performance to optimize server operation. However, on one hand, traditional performance tuning solutions, based on operating system-level scheduling and control (such as Linux cpufreq), result in latency exceeding 100 milliseconds during the transfer of performance tuning commands between hardware and the operating system, making it difficult to respond in real-time to sudden load changes. On the other hand, for newly deployed servers or servers with significantly different configurations, without historical performance tuning data, hundreds or even more manual trial-and-error samplings are required to find a performance solution suitable for the current load requirements. Each performance tuning process consumes significant human resources and requires substantial investment in machinery, materials, and time, resulting in low efficiency.

[0089] In addition, existing technologies typically rely on software layers to implement safety measures such as high-temperature protection during service performance adjustments. That is, when the temperature of the core computing component exceeds a set threshold, the sensor needs to send an interrupt signal to the CPU, which then jumps to the preset interrupt handler in the operating system kernel to read the temperature value and determine the severity. The driver then issues protection instructions to the hardware, which involves multiple context switches and complex software processes. This results in a high-temperature protection response time that also exceeds 100 milliseconds, posing a high risk of hardware burnout.

[0090] To address the limitations of the aforementioned server performance tuning methods, this application proposes a server control method for server performance tuning. This method employs an end-to-end autonomous closed-loop performance tuning mechanism, introducing a decision engine at the server's firmware layer. This engine can quickly bypass human intervention, enabling the machine to automatically perform optimizations. Furthermore, it allows performance tuning parameters under sudden loads to interact directly with the underlying hardware register unit by bypassing the operating system's scheduling path, thereby achieving rapid parameter writing and improving server response speed.

[0091] like Figure 1AThis example illustrates a schematic diagram of a server system stack architecture. The system stack, from top to bottom, includes an application layer, an operating system (OS) layer, a firmware layer, and a hardware layer, forming a typical computer hierarchical structure. This application adds a decision engine to the firmware layer. This decision engine is a cross-layer, hardware-software collaborative control module in the system architecture. It is neither entirely subordinate to the operating system layer nor limited to the hardware control unit, but is deeply integrated into the firmware layer and tightly coupled with the underlying hardware characteristics. The firmware layer includes UEFI (Unified Extensible Firmware Interface) and its runtime services. It has a higher system privilege level than the operating system kernel, possessing unconditional access to all server hardware resources. It can bypass the operating system's scheduling mechanism and latency control, directly reading and writing key hardware registers such as the CPU, GPU, memory controller, and power management unit through methods such as MSR (Model Specific Register) and MMIO (Memory Mapped I / O). It does not depend on any specific operating system (Windows / Linux) and is loaded and resides in memory during the later stages of server startup as part of the server firmware.

[0092] This decision engine is deployed at the firmware layer as a UEFI Runtime Service. Drivers in the operating system kernel can provide the decision engine with high-level, application-related load information, such as process priority, virtual machine scheduling status, and task latency sensitivity. The decision engine does not rely on the operating system's scheduling. Even when the server is in an abnormal state such as operating system lag, crash, or kernel debugging, the decision engine can still run independently, continuously monitoring hardware status and executing critical performance and security policies, thereby ensuring the stability and security of the server at the underlying hardware level.

[0093] The server control method provided in this application is applied to Figure 1A The decision engine shown is described in the image. Figure 1B An exemplary server control method is shown, which may include at least the following steps:

[0094] S101, when it is determined that the server needs to be adjusted for performance, based on the current values ​​of N performance indicators of the server during operation and the historical performance adjustment schemes adopted by the server, at least one candidate performance adjustment scheme is decided and the estimated performance that the server can achieve when running with the candidate performance adjustment scheme is evaluated.

[0095] Server performance tuning refers to the process of improving a server's performance metrics, such as operating efficiency, response time, and throughput, by modifying server hardware and software configuration parameters, such as CPU scheduling policies, memory allocation, I / O scheduling, network buffer size, and database connection pool size. This aims to increase system resource utilization, reduce latency, improve service stability, or meet higher load demands. The goal of server performance tuning is to maximize system performance while ensuring the server's safe operation. The performance tuning objectives are determined based on the server's actual application scenario. For example, for scenarios where the server needs to process more requests or transactions per unit of time, the performance tuning objective is to increase throughput; for high-speed query scenarios, the performance tuning objective is to reduce response latency; and for data center energy-saving scenarios, the performance tuning objective is to optimize energy efficiency (improving performance while controlling power consumption).

[0096] The N performance metrics are parameters that reflect the server's operating status and performance, set based on the server's performance tuning goals and the requirements for the server's secure and stable operation. These may include, but are not limited to, parameters such as CPU temperature, CPU utilization, CPU power consumption, memory utilization, disk I / O latency / throughput, network bandwidth utilization / packet loss rate, request response time (Latency), transactions per second (TPS), or throughput.

[0097] The current values ​​of these N performance metrics reflect the server's performance at the current moment. They can be obtained in real time during server operation through hardware modules such as the PMU (Performance Monitoring Unit), RAPL (Running Average Power Limit), and temperature sensors configured within the server.

[0098] Historical performance tuning schemes refer to the performance tuning schemes used by the server prior to this performance tuning. These can include the initial default parameter configuration scheme when the server was manufactured, as well as a series of performance tuning schemes used to adjust performance based on the initial default parameter configuration scheme under the current performance tuning target. These historical performance schemes constitute the server's performance tuning history trajectory and serve as training data for machine learning / optimization algorithms, guiding the generation of new candidate performance tuning schemes. For example, if the server's initial configuration scheme is M0, and performance tuning schemes M1, M2, and M3 are used sequentially, where M3 is the performance tuning scheme used when collecting the current values ​​of the N performance indicators, then M0, M1, M2, and M3 can all be considered historical performance tuning schemes.

[0099] The candidate performance tuning schemes are automatically generated based on historical performance tuning schemes, representing a set of suggested combinations of control parameters for server components. These schemes have not yet been deployed. The decision engine selects one of the candidate schemes as the target performance tuning scheme for this adjustment to control server operation. It is understood that the control parameters of the components included in the historical and candidate performance tuning schemes have the same parameter types, and the parameter types of these control parameters are determined by the server's performance tuning objective. For example, if the server's performance tuning objective is to improve the throughput of GPU-intensive tasks, then the control parameters of this component may include, but are not limited to, CPU frequency, memory bandwidth, PCIe bandwidth, and GPU frequency / power consumption.

[0100] The estimated performance is a predicted value. The server is not actually operating according to the control parameters of the components in the candidate performance tuning scheme. It represents the performance gain relative to the baseline performance value obtained by predicting the target performance index for the server's performance tuning objective, assuming the server is running using the candidate performance tuning scheme. It is typically expressed as a performance gain multiple or a relative improvement ratio. The baseline performance value can be the value of the target performance index for the server's performance tuning objective under the initial default parameter configuration or without performance tuning.

[0101] For example, if the performance tuning goal is to increase throughput, then the target performance metric is the throughput of the server during runtime. If the server throughput is 1000 requests / second under the initial default parameter configuration, and the predicted throughput of the server under the candidate performance tuning scheme is 1400 requests / second, then the estimated performance is 1.4 times (i.e., a performance gain of 40%).

[0102] Based on the above, the performance evaluation can be used to reflect the predicted gain of the target performance metric that the server's performance tuning objectives are concerned with. In contrast to this evaluated performance is the measured performance, which represents the performance gain of the target performance metric relative to the baseline performance value when the server actually runs using the performance tuning scheme. This measured performance and the predicted performance are determined using the same baseline performance value.

[0103] The determination of server performance tuning in this step is based on a safety prerequisite: the server is currently operating within a safe range. This safe range means that the current value of any constraint indicator does not exceed its set constraint threshold. The constraint indicators are boundary condition parameters whose values ​​are limited to engineering-allowed thresholds during safe server operation. They can be understood as key physical or engineering parameters used to measure whether the server is operating within a safe range. These can include temperature, power consumption, electrical, mechanical, and storage health indicators, etc., and their values ​​must be limited to preset safety thresholds to ensure hardware and system stability and prevent equipment damage, service interruption, or shortened lifespan due to resource overruns. The constraint indicators can include various physical and electrical critical limits affecting hardware safety, such as CPU core temperature, GPU junction temperature, total board power, CPU package power, memory voltage, power supply current load, fan speed lower / upper limits, cooling system airflow temperature, and hard drive SMART health status parameters. When any constraint indicator exceeds the preset safety threshold, the system will determine that the operating state is abnormal and will prioritize the execution of safety protection mechanisms rather than performance tuning operations.

[0104] Under this security premise, a judgment can be made based on the current and historical values ​​of N performance indicators during server operation. This multi-dimensional analysis can determine whether the server requires performance adjustments, and can include at least the following judgment dimensions:

[0105] (1) Based on the comparison of the current and historical values ​​of N performance indicators during server operation, a performance bottleneck in the server is identified;

[0106] (2) Based on the current values ​​of N performance indicators during server operation, and combined with the server's performance adjustment goals, identify areas where there is no obvious performance bottleneck but there is room for further performance adjustment.

[0107] (3) If the measured performance of the server during its current operation is improved compared to the measured performance during the most recent historical operation, meaning that the measured performance of the performance adjustment scheme currently used by the server has a positive gain compared to the measured performance of the most recent historical performance adjustment scheme, then the current performance adjustment is effective. In this case, new candidate performance adjustment schemes should be generated based on the updated historical data to enter the next round of optimization iterations to explore further performance improvement potential. The ratio of the measured performance of the most recent historical performance adjustment scheme to the measured performance during the most recent historical operation can be understood as the measured performance of the historical performance adjustment scheme used before the current performance adjustment scheme was adopted. For example, if the server is currently using performance adjustment scheme M4 with a measured performance of 1.45, and the server's most recent performance adjustment scheme before M4 was M3 with a measured performance of 1.49, then the current performance of the server is considered not to have been effectively improved compared to M3. However, if the measured performance of M3 is 1.4, then the current performance of the server is considered to have been effectively improved compared to M3.

[0108] If at least one of the above conditions is met, it is determined that server performance tuning is required, triggering the subsequent process of generating and selecting candidate performance tuning solutions. By determining whether server performance testing is necessary, the risk of erroneous performance tuning in insecure conditions is effectively avoided. Simultaneously, it addresses performance bottlenecks and uncovers potential performance issues, improving the intelligence and reliability of the performance tuning system.

[0109] Regarding the decision on at least one candidate performance tuning scheme described in this step, historical performance tuning schemes and the measured performance of the server running with those schemes can be used as learning bases. Through machine learning, Bayesian optimization, reinforcement learning, or evolutionary algorithms, combined with the current server operating status (such as the current values ​​of N performance indicators like CPU utilization, memory bandwidth, I / O latency, and network throughput), the nonlinear mapping relationship between the control parameters of configuration components and server performance is automatically modeled. Based on this, a high-dimensional parameter space is explored to generate multiple candidate performance tuning schemes with potential performance improvement effects. These candidate schemes not only cover parameter adjustments for individual components (such as CPU frequency adjustment strategies, memory reclamation thresholds, disk I / O schedulers, network buffer sizes, and database connection pool capacity), but also include collaborative optimization combinations between multiple components. Simultaneously, constraints (such as hardware safety boundaries, power consumption limits, and compatibility rules) can be introduced during the generation process to ensure the feasibility and safety of the candidate schemes, thereby providing high-quality input for subsequent performance estimation and scheme selection.

[0110] S102, For each candidate performance tuning scheme, evaluate the probability that the predicted value of each constraint metric does not exceed its set constraint threshold when the server uses the candidate performance tuning scheme to run.

[0111] A constraint threshold represents the upper (or lower) limit allowed by the engineering specifications for each constraint indicator. These thresholds are typically defined by hardware manufacturers, system design standards, or data center operation and maintenance strategies. They can be flexibly adjusted based on the server's current operating environment and load scenario. For example, setting a constraint threshold of 95°C for the CPU temperature and 300W for the CPU package power consumption of a server requires that the CPU temperature not exceed 95°C and the CPU package power consumption not exceed 300W during safe and stable operation.

[0112] The predicted value of each constraint metric represents the future value of each constraint metric when the server operates according to a candidate performance tuning scheme, using modeling and simulation methods, before the server has actually implemented the candidate performance tuning scheme. The predicted value of this constraint metric can be obtained by training a mapping relationship between "performance tuning scheme → constraint metric value" based on historical data using machine learning models (such as random forests or neural networks). This means that the current operating state of the server + candidate performance tuning scheme → predicted value of each constraint metric is output. The predicted value has uncertainty, represented by a probability distribution such as the mean and variance of a Gaussian distribution.

[0113] The probability that the predicted value of a constraint metric does not exceed its set constraint threshold represents the likelihood that, considering prediction uncertainty, the predicted value of the constraint metric is less than or equal to its constraint threshold, usually represented by a probability value P∈[0,1]. For example, predicting CPU temperature follows the pattern N(90℃,3). 2 If the threshold is 95℃, then the probability that the predicted CPU temperature does not exceed its set constraint threshold is P(T≤95)≈95.2%. The higher the probability, the stronger the safety of the candidate performance adjustment scheme under this constraint.

[0114] When evaluating the probability that the predicted value of each constraint metric does not exceed its set constraint threshold when the server is running with this candidate performance tuning scheme, see [reference needed]. Figure 1C The illustrative flowchart illustrates a probability prediction process where the predicted value of any constraint indicator does not exceed its set constraint threshold. This probability prediction for a single constraint indicator can be achieved through the following steps:

[0115] S1021, the current values ​​of the N performance indicators and the control parameters of the components in the candidate performance adjustment scheme are used as input features and input to the probability prediction model trained for the constraint indicator.

[0116] A probabilistic prediction model is a machine model that estimates the probability distribution of constraint metrics when a server runs according to candidate performance tuning schemes. Its output is a probability distribution. This probabilistic prediction model can be implemented using Gaussian regression, Bayesian neural networks, quantile regression forests, Monte Carlo Dropou-based deep learning models, etc. In this embodiment, a dedicated probabilistic prediction model is trained for each constraint metric.

[0117] The training of this probabilistic prediction model relies on high-quality time-series data, which can include at least the following features:

[0118] Real-time metrics: Current CPU temperature, power consumption, core voltage, core utilization, L3 cache hit rate, instruction retirement count, memory bandwidth utilization, etc., are monitored by hardware modules such as DTS, RAPL, and PMU configured in the server.

[0119] Environmental parameters: server operating environment parameters collected by BMC and external sensors, such as fan speed, server room ambient temperature, and radiator efficiency;

[0120] Control category: The server's historical performance tuning schemes, including the control parameters of the components to be tuned.

[0121] In this embodiment, when training a probabilistic prediction model based on historical data for any constraint metric, the training input features include the historical performance tuning scheme used plus the values ​​of N performance metrics during server operation before adopting the historical performance tuning scheme. The values ​​of the constraint metric during server operation after adopting the historical performance tuning scheme are used as the training output labels. The training model learns the complex mapping relationship from input features to output labels. Optionally, the probabilistic prediction model in this embodiment can be trained using a Gaussian process regression algorithm. The Gaussian process regression algorithm can not only predict the mean (the most likely value) but also naturally provide the confidence interval (variance) of the prediction. After the model is trained, for any new set of inputs, the model can provide a prediction distribution represented by the mean and variance.

[0122] S1022, Obtain the probability distribution of the constraint index in future control cycles, output by the probability prediction model, when the server adopts the candidate performance adjustment scheme; the probability distribution includes the prediction mean and the prediction variance;

[0123] The future control period represents a fixed time window (e.g., 10 seconds, 30 seconds, or 1 minute) that the server will enter after applying a candidate performance tuning scheme. It is used to evaluate the scheme's short-term effectiveness, avoiding the influence of momentary fluctuations on judgment and ensuring that the prediction covers typical response times. This future control period can be set based on system response latency, monitoring sampling period, or load change frequency.

[0124] A probability distribution is a mathematical function that describes the possible values ​​of a random variable and their probabilities of occurrence. In this step, it represents the distribution of predicted values ​​of the constraint index over future control periods. Its common form is a normal distribution N(μ,σ). 2 μ represents the predicted mean, σ 2 This represents the prediction variance; the larger the variance, the more uncertain the prediction. If the model is a Gaussian process regression (GPR), it directly outputs the predicted mean and predicted variance. If it is a Bayesian neural network, the mean and variance can be estimated through multiple forward propagations (Monte Carlo Dropout). If it is a quantile regression model, the distribution parameters can be inferred from the upper and lower quantiles.

[0125] S1023, calculate the probability that the constraint index does not exceed its set constraint threshold based on the probability distribution.

[0126] Obtain the predicted mean and predicted variance output in step S1022, and obtain the set constraint threshold T for the constraint index. Calculate the standardized variable z = (T - predicted mean) / predicted variance using the standard normal cumulative distribution function. The probability can be determined by calling a mathematical library or using a lookup table to obtain the probability that the constraint indicator will not exceed its set constraint threshold. For example, P = 0.885 means that there is an 88.5% chance that the server will not exceed its set constraint threshold when running with this candidate performance scheme.

[0127] For each constraint indicator, the technical approach described in steps S1021-S1023 above can be repeated to obtain the probability that the constraint indicator does not exceed its set constraint threshold.

[0128] For example, in the scenario where the server's current state is [temperature = 80℃, power consumption = 200W, load = high], the decision engine plans to increase the CPU frequency from 3.0GHz to 3.8GHz, and the temperature constraint threshold T_max = 85℃:

[0129] Step 1: Model Predicts Distribution

[0130] Input the current state of the server and the parameters to be adjusted (i.e. the control parameters of the components in the candidate performance adjustment scheme) into the trained temperature prediction model to obtain the model output: the future temperature follows a normal distribution T ~ N (μ = 83.5, σ = 1.5), where the mean μ = 83.5℃ represents the most likely temperature value, and the standard deviation σ = 1.5℃ reflects the uncertainty of the prediction.

[0131] Step 2: Calculate the safety probability P (T≤85)

[0132] To calculate the probability that the temperature is less than or equal to 85℃, we calculate the cumulative area to the left of 85℃ in the normal distribution. Calculate the Z-value (which measures how many standard deviations 85℃ deviates from the mean): Z = (85 - 83.5) / 1.5 = 1.0. Looking up the standard normal distribution table: P(Z≤1.0) ≈ 0.8413. Therefore, P(T≤85) = 0.8413. This means there is approximately an 84.1% chance that the temperature will not exceed 85℃, and correspondingly, there is a 15.9% risk of exceeding 85℃.

[0133] Step 3: Similarly, calculate the power consumption safety probability.

[0134] Power consumption model prediction: P ~ N (μ = 245, σ = 10), P_max = 250W.

[0135] Z = (250 - 245) / 10 = 0.5

[0136] P(P≤250)=P(Z≤0.5)≈0.6915 (that is, there is a 30.9% risk of over-power consumption).

[0137] S103, based on the estimated performance corresponding to each candidate performance adjustment scheme and the probability corresponding to each constraint index under the candidate performance adjustment scheme, select a target performance adjustment scheme.

[0138] The target performance tuning scheme is the final performance tuning scheme selected from all candidate performance tuning schemes after evaluation and decision-making, and will be actually applied to the server operation. The selection principle is to maximize the overall system performance benefits while meeting security constraints.

[0139] Since the estimated performance reflects the degree of improvement in server performance by the candidate performance tuning scheme, and the probability corresponding to each constraint indicator under the candidate performance tuning scheme reflects the security impact of the candidate performance tuning scheme on the server, based on the estimated performance and the probability corresponding to the constraint indicator for each candidate performance tuning scheme, a performance tuning scheme that takes into account both the server's performance tuning goals and operational security can be selected from multiple candidate performance tuning schemes, so as to achieve performance tuning while ensuring the safe operation of the server.

[0140] like Figure 1D An exemplary flowchart illustrating the determination of a target performance tuning scheme is shown. When selecting the target performance tuning scheme, it can be quickly determined in the following manner:

[0141] S1031, for each candidate performance adjustment scheme, based on the probability that the predicted value of each constraint indicator under the candidate performance adjustment scheme does not exceed its set constraint threshold, the safe probability of the server running with the candidate performance adjustment scheme is obtained by combining probabilities.

[0142] The security probability represents the joint prediction probability that all constraint indicators will not exceed their respective set constraint thresholds when the server is running using the candidate performance tuning scheme, reflecting the overall security of the candidate performance tuning scheme.

[0143] When the various constraints are approximately independent, the safety probability can be expressed as the product of the probabilities that each constraint does not exceed its set constraint threshold. For example, if the probability of meeting the CPU temperature requirement is 0.95 and the probability of meeting the power consumption requirement is 0.98, then the safety probability P = 0.95 × 0.98 = 0.931. When the correlation between the constraints is known (e.g., increased power consumption → increased temperature), more complex methods such as Bayesian networks and Copula models can be used to model the joint distribution to accurately give the joint prediction probability.

[0144] S1032, Based on the estimated performance corresponding to the candidate performance adjustment scheme and the security probability, the target performance adjustment scheme is selected from them.

[0145] For example, the feasibility parameters of the candidate performance adjustment scheme can be determined based on the estimated performance and safety probability corresponding to the candidate performance adjustment scheme, and the target performance adjustment scheme can be selected according to the feasibility parameters of each candidate performance adjustment scheme. The feasibility parameters are used to comprehensively measure the balance between the performance improvement potential and the operational safety of the candidate performance adjustment scheme, and can be expressed as a weighted result or product of the estimated performance and safety probability corresponding to the candidate performance adjustment scheme.

[0146] Alternatively, a two-stage screening method can be used, which sets a safety threshold and screens out candidate performance adjustment schemes with a safety probability greater than or equal to the safety threshold. Then, the scheme with the highest estimated performance is selected from the screened candidate performance adjustment schemes as the target performance adjustment scheme.

[0147] Alternatively, the top k1 performance adjustment schemes with the highest estimated performance corresponding to the candidate performance adjustment scheme can be selected, and the top k2 performance adjustment schemes with the highest safety probability corresponding to the candidate performance adjustment scheme can be selected. The performance adjustment scheme that appears simultaneously in the top k1 and top k2 performance adjustment schemes can be taken as the target performance adjustment scheme. If there is no performance adjustment scheme that appears simultaneously in the top k1 and top k2 performance adjustment schemes, the feasibility parameters of the top k1 and top k2 performance adjustment schemes can be calculated, and the target performance adjustment scheme can be selected based on the feasibility parameters.

[0148] S104, Based on the control parameters of the components in the target performance tuning scheme, the server is adjusted through a specified interface in the firmware layer so that the server continues to run based on the control parameters of the components in the target performance tuning scheme.

[0149] The target performance tuning scheme includes a set of hardware resource configuration instructions determined to achieve the server's performance tuning goals. This scheme is not limited to adjusting the performance of a single component but encompasses the collaborative configuration parameters of multiple hardware components, aiming to achieve cross-level, hardware-software collaborative system-level performance improvements. The control parameters of the components included in this target performance tuning scheme represent specific configurable variables that can be used to dynamically adjust the operating state of various server hardware modules. These parameters typically correspond to writable fields in the underlying hardware registers; modifying their values ​​directly affects the hardware's behavior, such as frequency, voltage, power consumption limits, memory timings, and I / O scheduling policies. For example, component control parameters may include CPU multiplier, memory timing parameters, memory operating frequency, GPU frequency, and voltage adjustment.

[0150] The designated interfaces at the firmware layer refer to a set of standardized or custom programming interfaces with high privileges and low latency exposed by the server firmware to the operating system or internal management modules. These interfaces enable direct access to and control of underlying hardware resources during system runtime. Independent of the operating system scheduling mechanism, these interfaces have the ability to bypass the kernel driver stack and are a key technical channel for achieving cross-layer performance regulation. It is important to clarify that the designated interfaces at the firmware layer are not ordinary device drivers or system calls, but rather predefined and exposed functional entry points by the firmware for specific control purposes. These entry points allow trusted modules (such as the decision engine in this application) to directly read and write critical hardware registers without relying on the operating system.

[0151] The specified interface of this firmware layer can include the following types: UEFI runtime service interface, ACPI control method interface, SMBIOS extension interface, OEM custom runtime hook interface, etc. In the server control process of this application, the specified interface used refers to the UEFI runtime service interface. It can be understood that the interface type used can be flexibly adjusted according to the actual parameter writing requirements.

[0152] Leveraging the firmware layer's higher privilege level than the operating system kernel, it can bypass the operating system's task scheduling mechanism and device driver latency paths through designated interfaces provided by the firmware layer, directly interacting with the server's underlying hardware to achieve direct, low-latency access to underlying hardware resources. Specifically, the decision engine calls the designated interface of the firmware layer in the server to directly write the control parameters of each component in the target performance tuning scheme into the hardware register unit to which the control parameters belong, without needing to go through the forwarding processing of the operating system kernel or device driver, achieving low-overhead, high-response real-time control.

[0153] For example, when the target performance adjustment scheme includes a first parameter indicating the CPU performance state P-state of the server, the specified interface of the firmware layer is called to directly write the first parameter into the CPU's internal MSR register. That is, the UEFI Runtime Service is called to access the MSR register and write the first parameter into the CPU's internal MSR registers such as IA32_PERF_CTL, thereby dynamically adjusting the processor's operating frequency and voltage.

[0154] For example, when the target performance tuning scheme includes a second parameter that indicates the memory operation control of the server, the server's PCIe configuration space is accessed through a specified interface of the firmware layer, the dedicated control register of the memory controller mapped to the extended area of ​​the PCIe configuration space is located, and the second parameter is written to the control register of the memory controller mapped to the extended area of ​​the PCIe configuration space to optimize memory timing, bandwidth allocation, or power consumption mode.

[0155] The parameter writing method provided in this embodiment enables the control commands for the operation of components in the server to be issued in milliseconds or even microseconds, and is not affected by operating system lag, high load or abnormal state, which significantly improves the system response speed and operational reliability.

[0156] While the server continues to run based on the control parameters of the components in the target performance tuning scheme, the actual measured performance achieved by the server when running under the target performance tuning scheme can also be obtained. This measured performance reflects the measured gain of the target performance metric that the server's performance tuning objective focuses on, and is expressed as the performance gain of the actual performance value of the target performance metric relative to the baseline performance value when the server runs according to the target performance tuning scheme. It can be understood that when the server obtains measured performance after each performance tuning, a unified baseline performance value is used as a reference standard. This baseline performance value can be set as the performance of the target performance metric under the initial default configuration scheme. Using a unified baseline performance value facilitates a consistent comparison of the performance gain effects of different performance tuning schemes within the same dimension.

[0157] Furthermore, if it is detected that the server's current performance has not improved compared to the performance after the most recent performance adjustment, that is, the server's measured performance under the target adjustment scheme has not increased positively compared to the measured performance obtained from the previous performance adjustment before this performance adjustment, and the server's performance has not improved (the server's measured performance under the target adjustment scheme is lower than the measured performance obtained from the previous performance adjustment before this performance adjustment), then the performance adjustment of the server is stopped, the most recent historical performance adjustment scheme used before adopting the target performance adjustment scheme is obtained (that is, the performance adjustment scheme used in the previous performance adjustment before this performance adjustment), and the server is controlled through the specified interface of the firmware layer based on the control parameters of the components in the most recent historical performance adjustment scheme.

[0158] In other words, if the actual performance values ​​of the server's target performance metrics measured after this performance adjustment do not show a positive improvement compared to the actual performance values ​​obtained from the previous performance adjustment, then the current performance adjustment is deemed to have failed to achieve the expected results, and the subsequent performance adjustment process is stopped. At this point, the system rolls back to the most recent effective historical performance adjustment scheme. Specifically, it retrieves the component control parameters included in the last successfully applied historical performance adjustment scheme before the current target performance adjustment scheme was applied, and restores the server configuration to the parameter state corresponding to that historical performance adjustment scheme through a specified interface in the firmware layer, thereby ensuring the stability and reliability of system operation.

[0159] For example, if the current performance adjustment uses the target performance adjustment scheme M6, and its measured performance is 1.41, while the previous performance adjustment using the historical performance adjustment scheme M5 yielded a measured performance of 1.43, then it is considered that the server's current performance has not been improved. Therefore, performance adjustment of the server is stopped, and the server is controlled through the specified interface of the firmware layer. The server configuration is modified to the control parameters of the components in the historical performance adjustment scheme M5 used in the previous performance adjustment, causing the server to roll back to the parameter state of the historical performance adjustment scheme M5 and continue to run. This allows for a rapid recovery to a known stable operating state when the performance adjustment does not meet the requirements, improving the reliability and practicality of the automated performance adjustment process.

[0160] It is understood that the above embodiment only provides the process steps for one performance adjustment. In this embodiment, the server can repeat the above steps each time it is determined that the server needs to be adjusted for performance in order to complete the performance adjustment.

[0161] In this embodiment of the disclosure, by deploying a decision engine at the firmware layer of the system stack, autonomous closed-loop control of the entire process from performance tuning to security protection is realized, which significantly improves the efficiency and response speed of server performance tuning and reduces performance tuning latency compared to the prior art.

[0162] This embodiment intelligently determines multiple candidate performance adjustment schemes based on the server's current operating status and historical performance adjustment schemes, and evaluates their corresponding estimated performance. This overcomes the shortcomings of traditional manual tuning, which relies on experience and has high trial-and-error costs. It achieves data-driven automated tuning, significantly shortening the tuning cycle and reducing manpower, material, and time investment. For each candidate performance adjustment scheme, the probability that the predicted values ​​of each constraint indicator of the server under that scheme will not exceed its set threshold is further evaluated, avoiding security risks caused by improper parameter combinations and achieving a controllable quantitative assessment of risk. The decision engine integrates the estimated performance and security probability of candidate schemes, selecting a target performance adjustment scheme that balances performance gain and operational reliability. This scheme directly writes the control parameters of the server components through a specified interface in the firmware layer, bypassing the operating system scheduling and software stack relay links. This reduces the response latency of tuning commands from >100ms in traditional schemes to microseconds, enabling real-time response to sudden load changes and achieving dynamic elastic adjustment. This ensures performance adjustment while guaranteeing system safety and effectively prevents performance degradation or hardware damage caused by blind optimization.

[0163] This application improves the server's performance adaptability, operational reliability, and deployment efficiency in complex and dynamic environments through the collaborative design of firmware layer decision engine, probabilistic security assessment, performance-security joint optimization mechanism, and hardware direct connection control path. It provides an efficient, secure, and scalable automated performance optimization solution for high-performance computing scenarios such as large-scale data centers and intelligent computing centers.

[0164] In some embodiments, the process of determining the need for performance tuning of the server as described in the foregoing embodiments is essentially a condition for initiating autonomous performance tuning while ensuring system operational security. Based on this, this embodiment proposes a security-based admission-based performance tuning triggering mechanism based on constraint indicators. (See [link to relevant documentation]). Figure 2 An exemplary procedure for determining whether a server is operating within a safe range can be implemented through the following steps to determine whether performance tuning of the server is necessary, ensuring that performance tuning is performed only when the system is stable, the hardware is healthy, and resources are not exceeded:

[0165] S201, Detect whether the current value of each constraint indicator during the operation of the server does not exceed its set constraint threshold.

[0166] During the server's current operation, the current value of each set constraint indicator is monitored in real time. This constraint indicator may be a subset of the N performance indicators described in the preceding embodiments; alternatively, the constraint indicator may be collected individually, and the changes in the current value of each constraint indicator are continuously monitored in real time. The constraint indicators may include at least boundary condition parameters affecting hardware security, such as, but not limited to: CPU temperature, CPU power consumption, memory voltage, total power consumption, cooling fan speed, CPU core voltage (Vcore), and other key parameters directly affecting hardware reliability and system stability.

[0167] S202, if so, that is, if the current value of each constraint indicator does not exceed its set constraint threshold, then it is determined that the server needs to be adjusted for performance.

[0168] For example, constraint indicators include CPU temperature and CPU power consumption. When the CPU temperature is less than or equal to its temperature threshold such as TMAX and the CPU power consumption is less than or equal to its power consumption threshold TDP, it is determined that the server is currently operating within a safe range and performance adjustments can be made to the server.

[0169] S203, if no, that is, if the current value of at least one constraint indicator exceeds its set constraint threshold, then stop the performance tuning of the server, and trigger the operation protection mechanism corresponding to the constraint indicator whose current value exceeds its set constraint threshold.

[0170] For example, constraint indicators include CPU temperature and CPU power consumption. If at least one of the following conditions is met, the CPU temperature is greater than its temperature threshold such as TMAX, or the CPU power consumption is greater than its power consumption threshold TDP, it is determined that the server is currently operating outside the safe range. At this time, the security protection mechanism for the server operation is automatically triggered to prevent server hardware damage.

[0171] When the constraint indicators include the temperature of the core computing components in the server, if the temperature of the core computing component exceeds its set constraint threshold, an indication signal is directly sent to the server's voltage regulation module (VRM). This triggers the VRM to adjust the power supply to the core computing component to achieve hardware-level thermal protection. The core computing component may be, for example, a CPU or GPU. The VRM's power supply adjustment may include dynamically reducing the supply voltage, voltage-frequency reduction control, limiting the maximum output current or power via the VRM, and temporarily cutting off the power supply to force the core computing component into a sleep state.

[0172] In other words, in this embodiment, if the temperature of the core computing component in the server exceeds its set constraint threshold (e.g., a temperature threshold of 85°C), an alarm signal indicating that the temperature of the core computing component exceeds its set constraint threshold will be directly sent to the server's voltage regulation module (VRM), thereby triggering a hardware-level fuse protection mechanism. Unlike the existing technology where the alarm signal is reported to the operating system kernel and then the kernel calls a software program for response, this solution bypasses the software stack, achieving direct hardware connection and rapid response for the alarm signal. It can cut off or reduce the power supply voltage within a microsecond timescale, quickly suppressing temperature rise.

[0173] When the power consumption of the core computing components in the server is included in the constraint indicators, if the power consumption of the core computing components exceeds its set constraint threshold, the indication signal can be sent directly to the server's voltage regulation module (VRM) to force the voltage regulation module to reduce the voltage and frequency of the core computing components. At the same time, emergency intervention can be performed using the software layer, such as frequency and voltage reduction, restarting, or restoring to a performance adjustment scheme that allows the system to run stably.

[0174] This mechanism avoids operating system scheduling delays, interrupt handling overhead, and software execution uncertainty, significantly improving the response speed and reliability of thermal protection, effectively preventing chip damage or system failure caused by high temperatures, and better ensuring the operational safety and lifespan of core computing components.

[0175] In some embodiments, for the decision-making of at least one candidate performance tuning scheme as described in the foregoing embodiments, and the estimated performance that the server can achieve by running the server using the candidate performance tuning scheme, see [link to documentation]. Figure 3 An exemplary flowchart illustrates the process of automatically generating candidate performance tuning schemes and obtaining predicted performance:

[0176] S301, based on the current values ​​of the N performance indicators and the performance adjustment target, identify the current performance bottleneck of the server, and set a local search space for the control parameters related to the current performance bottleneck;

[0177] The current performance bottleneck represents the critical resource constraint that hinders the overall system performance from improving towards the performance adjustment target under the current load. Common bottleneck types include CPU bottlenecks (e.g., CPU utilization consistently >90%), memory bottlenecks (e.g., frequent swap usage, high page faults), and I / O bottlenecks (e.g., high iowait, large disk queue depth). These can be analyzed using existing tools such as top, iotop, vmstat, and sar, based on the current values ​​of the N performance metrics and the performance adjustment target. For example, if the target is "reducing latency" and iowait >30%, it is identified as an I / O bottleneck; if the target is "increasing throughput" and cpu_util >90%, it is identified as a CPU bottleneck. This can be automatically determined using machine learning classifiers or rule engines.

[0178] The control parameters related to the current performance bottleneck can be understood as key parameters that are sensitive to or easily affect the bottleneck. These control parameters can be determined based on a pre-defined "bottleneck-parameter mapping table." The local search space represents a subset of parameters within a reasonable range for the control parameters involved in the current performance bottleneck, used for efficient searching by subsequent optimization algorithms. Compared to the global search space, which represents all possible parameter combinations and suffers from combinatorial explosion and convergence difficulties, the local search space includes parameters related to the current bottleneck, narrowing the search range and improving efficiency. For each control parameter related to the current performance bottleneck, a search range is defined as the search domain for subsequent algorithms such as Bayesian optimization.

[0179] The current performance bottleneck can be used to guide the search direction of Bayesian optimization. If it is a CPU bottleneck, prioritize searching for solutions with higher frequency and higher voltage. If it is a memory bottleneck, search for memory scheduling strategies and prefetch configurations. If it is a heat dissipation bottleneck, explore ways to limit high temperature and favor energy saving and frequency reduction. It can also be used to construct conditional surrogate models or weighted objective functions.

[0180] S302: The proxy model is constructed by using the historical performance tuning scheme adopted by the server as the input sample and the actual performance of the server under the historical performance tuning scheme as the output label.

[0181] A surrogate model is a machine learning model used to approximate the performance response function of a real system. It can predict the performance of a given configuration combination without actually running the server. This surrogate model can be implemented using models such as Gaussian process regression (supporting uncertainty estimation), random forests, neural networks, and XGBoost / LightGBM.

[0182] The input sample (X) of the surrogate model consists of the control parameters of the components in the historical performance tuning scheme. The output label (Y) is the actual performance value of the target performance index of the server's performance tuning objective, measured when the server is actually running under the historical performance tuning scheme, and / or the measured performance determined based on the actual performance value and the same benchmark performance value. The model is trained using this input sample to learn the nonlinear mapping relationship from X to Y. If uncertainty estimation is required, Gaussian process regression can be preferred for constructing the surrogate model.

[0183] The trained proxy model can be encapsulated as a service interface, supporting input of candidate performance tuning schemes and providing a predicted performance value for the target performance index of the server when the server adopts the input candidate performance tuning scheme, or providing the corresponding predicted performance (depending on the output label settings of the proxy model), and providing the prediction uncertainty (variance). For example, if the output label during training is the actual performance value of the target performance index of the server when the server actually adopts the historical performance tuning scheme, then each prediction by the proxy model will provide a predicted performance value of the target performance index of the server when the server adopts the input candidate performance tuning scheme. This predicted performance value can then be processed with a set baseline performance value to obtain the corresponding predicted performance.

[0184] S303, within the local search space, based on the mean and uncertainty of the predicted performance output by the surrogate model, the search direction is guided by the acquisition function, multiple candidate performance adjustment schemes are iteratively generated, and the predicted performance given by the surrogate model for each candidate performance adjustment scheme is obtained.

[0185] The mean of the predicted performance represents the expected performance value predicted by the surrogate model, reflecting the potential performance improvement brought about by the performance adjustment scheme determined by the acquisition function; uncertainty represents the model's confidence in the prediction, usually expressed as variance, reflecting the value of exploration. For example, the acquisition function gives scheme A: predicted performance = 1.40, variance = 0.01 → high confidence, high performance; scheme B: predicted performance = 1.35, variance = 0.10 → may be underestimated, worth exploring.

[0186] In Bayesian optimization, the sampling function is a mathematical function used to balance development and exploration, guiding the selection of the next sampling point. Common types of sampling functions include EI (Expected Improvement, prioritizing points that are likely better than the current best), UCB (Upper Confidence Bound, μ+κσ, balancing the mean and uncertainty), and probabilistic improvement (selecting the point with the highest probability of improvement). Under the guidance of the surrogate model, the sampling function efficiently searches the control parameters of the components to form a performance tuning scheme.

[0187] In this embodiment, potential high-performance configurations are gradually discovered in the local search space by calling the acquisition function multiple times. Each iteration of the search uses the predicted performance given by the surrogate model to update the search direction, avoiding random search. The performance adjustment scheme formed by the combination of control parameters recommended by the acquisition function will be sent to the surrogate model to re-evaluate its estimated performance, forming a closed-loop optimization.

[0188] Multiple candidate performance tuning schemes are generated iteratively, i.e., after setting the acquisition function, the following steps are executed repeatedly: a. Call the acquisition function: Calculate the acquisition score of each point in the search space based on the current surrogate model; b. Recommend new candidate schemes: Select the parameter combination with the highest acquisition score to form a performance tuning scheme; c. Query the surrogate model: Input the performance tuning scheme formed by the parameter combination with the highest score, and obtain its estimated mean μ and variance σ. 2 d. Record candidate solutions and predicted values: Save the solution and its performance prediction for subsequent decision-making; e. Update the surrogate model: Add the point to the training set and refit the model (optional online learning). After multiple rounds of iteration, collect all generated performance adjustment solutions and their estimated performance output by the surrogate model, and select the top M performance adjustment solutions with the highest total or estimated performance as candidate performance adjustment solutions.

[0189] For example, given the performance tuning scheme Xcandidate from the acquisition function, the proxy model outputs: Estimated performance: Predicted mean μ(X), representing the most likely performance achieved by the scheme (e.g., throughput = 4700 req / s); Predicted variance σ²(X), representing the confidence level of the prediction. Assuming a baseline performance value of 4000:

[0190] Option A: The throughput is predicted to be 4700±50req / s, and the estimated performance is 4700 / 4000=1.175. The prediction variance is small, indicating that the model has high confidence in its prediction and stable performance. It is a low-risk and reliable optimization option.

[0191] Option B: The throughput is predicted to be 4900±200req / s, and the estimated performance is 4900 / 4000=1.1225. The theoretical performance is better than Option A, but the prediction variance is large, indicating that there is a high degree of uncertainty. In actual operation, it may be as low as 4700req / s (4900-200) or even lower. It is a high-risk and highly volatile exploratory option.

[0192] Regarding the identification of the current performance bottleneck of the server described in the above embodiments, if there is no obvious performance bottleneck in the server at present, steps S302 and S303 can be executed directly so that the acquisition function can explore and provide candidate performance adjustment schemes in the global space based on historical performance adjustment schemes.

[0193] In this embodiment, compared to traditional parameter tuning methods that rely on manual experience or global exhaustive search, this embodiment constructs a local search space by identifying performance bottlenecks in the current operating state of the server. This avoids the combinatorial explosion problem caused by blindly searching the entire parameter space. Furthermore, it utilizes performance tuning schemes implemented in the server's historical operation and their corresponding measured performance to construct a proxy model. This enables efficient evaluation of the performance potential of candidate solutions without actual deployment and load testing. By using a collection function, a dynamic balance is achieved between "developing high-confidence high-quality solutions" and "exploring high-uncertainty potential solutions," thereby efficiently converging to a globally optimal solution within a limited number of iterations. This achieves automated performance tuning and reduces the time overhead and resource consumption of the performance tuning process.

[0194] To enable those skilled in the art to better understand the server control method provided in this application, the following will describe this application from the perspective of system architecture interaction for server performance adjustment and performance adjustment examples in specific scenarios.

[0195] See Figure 4A This diagram illustrates the interaction between modules within a server when using a server control method. The module names used in the diagram are user-defined concepts for ease of explanation.

[0196] Sensing module 4a: Used to monitor the current operating status of the server and collect data, including hardware modules such as PMU, RAPL, and DTS, and collects server operating indicators in real time through hardware sensors.

[0197] Decision Engine 4b: Based on the current values ​​of performance metrics provided by the perception module and combined with historical performance tuning schemes used by the server, it automatically generates multiple candidate performance tuning schemes. Then, based on the estimated performance and safety probability of each candidate scheme, it decides on a target performance tuning scheme. The process of automatically generating multiple candidate performance tuning schemes can utilize algorithms such as Bayesian optimization and reinforcement learning to construct an incremental learning and updating generation method.

[0198] Hardware control 4c: The control parameters of the components in the target performance adjustment scheme are directly written into the underlying hardware register unit of the server through the UEFI interface, and the parameter adjustment is performed.

[0199] Server Hardware 4D: Receives control parameters written from the hardware control, enabling the server to operate according to the control parameters of the components in the target performance tuning scheme, so that the sensing module can continue to monitor the new operating status of the server.

[0200] Security Protection Module 4e: Detects whether the server is operating within a safe range, i.e. whether the constraint indicators exceed the constraint threshold. If so, it triggers a hardware-level operation protection mechanism to prevent hardware damage.

[0201] The performance tuning method provided in this application is a server-side autonomous closed-loop performance tuning method, in which the server can repeatedly execute the above process each time it is determined that performance needs to be adjusted.

[0202] See Figure 4B An exemplary flowchart of a server control method is shown, which illustrates a closed-loop processing flow for server autonomous performance tuning after the server starts running:

[0203] S401, Sensing Data Acquisition:

[0204] Hardware sensors include PMU, RAPL, DTS, etc., which collect server operating indicators in real time. These indicators include at least CPU temperature, power consumption, and performance event counters, and may also include CPU utilization / frequency, memory bandwidth / latency, I / O throughput / queue depth, etc.

[0205] S402, Check if the server is operating within safe limits:

[0206] For each collected constraint indicator's current value, it is checked whether the current value of the constraint indicator exceeds the constraint threshold set for that constraint indicator. If at least one constraint indicator exceeds its set constraint threshold, it is considered that the server's operation is out of the safe range, and the process proceeds to step S403 to implement the operation protection mechanism; otherwise, if all constraint indicators do not exceed their set constraint thresholds, it is considered that the server is operating within the safe range, and the process proceeds to step S404 to adjust the server's performance.

[0207] This binding indicator may include, but is not limited to, the following types of indicators:

[0208]

[0209] S403, Operational protection mechanism when constraint indicators exceed thresholds.

[0210] Includes a temperature-triggered hardware fuse mechanism with a response time of ≤10μs, effectively preventing risks.

[0211] Hardware fuse: If the safety threshold is exceeded, such as when the temperature is >85℃, the signal is directly connected to the VRM (voltage regulation module) and the frequency is reduced within 10μs;

[0212] Configuration rollback: When performance fluctuations exceed 10%, automatically restore the component control parameter configuration to the most recently used historical performance tuning scheme.

[0213] S404, the decision engine determines the target performance tuning plan.

[0214] For each candidate performance tuning scheme, based on the estimated performance and safety probability of the evaluated server running with that scheme, the decision engine selects the target performance tuning scheme from multiple candidates that balances performance improvement and operational safety. For example, the decision engine can directly make a decision based on the product of the estimated performance and safety probability of the candidate performance tuning scheme. Under this decision-making method, based on the multiplication property (if any term in the product operation is close to zero, the total score is zero, which can achieve a safety veto for the candidate performance tuning scheme), performance can be adjusted while ensuring server operational safety.

[0215] S405, Hardware control layer performs parameter writing:

[0216] By bypassing the operating system's scheduling path, it directly writes to the underlying register unit of the hardware through the UEFI interface, achieving nanosecond-level response.

[0217] S406, Performance Verification

[0218] Obtain the actual performance of the server under the target performance tuning scheme. This actual performance is used to compare with the actual performance obtained in the most recent performance tuning before this performance tuning to determine whether the server's current performance has been improved.

[0219] S407, Check if the server's current performance has improved.

[0220] If the server's current performance is improved, the target performance tuning scheme currently in use and its measured performance will be used as the basis for automatically generating candidate performance tuning schemes. Conversely, if the server's current performance is not improved, it will automatically roll back to a safe state in S408, that is, roll back to the control parameter state of the historical performance tuning scheme used in the most recent performance tuning before this performance tuning.

[0221] In the above embodiments, hardware indicators are collected in real time by PMU and RAPL sensors. The decision engine determines the target performance adjustment scheme from multiple candidate performance adjustment schemes based on the predictable performance × safety probability (the probability that each constraint indicator does not exceed its set constraint threshold). By bypassing the OS through the UEFI interface, CPU registers and memory allocation parameters are directly modified to achieve CPU frequency switching and adjust channel allocation through PCIe configuration space. This enables adaptive server performance adjustment, significantly improving the efficiency of service performance adjustment, reducing repetitive manpower investment, including R&D performance adjustment manpower and operation and maintenance manpower, and reducing material costs. In addition, the fuse signal for constraint indicators exceeding the constraint threshold is directly connected to VRM. When the temperature is >85℃, hardware-level fuse frequency reduction is triggered, achieving a hardware fuse response of 10μs, reducing the risk of hardware damage, improving temperature control accuracy, and extending the service life.

[0222] This embodiment provides a GPU server performance tuning scenario. The GPU performance tuning goal is to improve the throughput (Tokens / Second) of GPU-intensive tasks (such as LLM training). The core bottleneck is usually that the GPU cannot obtain data in time, resulting in "starvation" and idle computing units.

[0223] For this GPU performance tuning target, the control parameters of the components included in the performance tuning scheme can include at least the following types:

[0224] CPU frequency: Increasing the CPU frequency can speed up data preprocessing.

[0225] Memory bandwidth: Allocate more bandwidth to the CPU to speed up the movement of data from memory to the CPU.

[0226] PCIe bandwidth: Adjust the allocation of PCIe channels to accelerate data transfer from the CPU to the GPU.

[0227] GPU frequency / power limit: Overclock the GPU itself to a moderate degree.

[0228] Based on this, the performance autonomous adjustment process using the server control method provided in this application is as follows:

[0229] (1) Step 1: Sensing module - real-time data acquisition

[0230] The decision engine collects the current state through hardware sensors:

[0231] GPU: Use the NVML library to obtain GPU utilization, memory bandwidth utilization, GPU core temperature, and power consumption.

[0232] CPU: Monitor CPU cache hit rate and instruction retirement count via PMU.

[0233] Memory: Monitor memory controller utilization and DRAM bandwidth via PMU.

[0234] PCIe: Monitor PCIe link layer traffic and transmission latency through the PCIe PMU.

[0235] Power consumption: The power consumption of the entire socket is obtained through RAPL.

[0236] Based on the current values ​​of the collected performance metrics, the perception module found that the GPU utilization was only 70%, while the PCIe bandwidth utilization was as high as 90%, thus identifying that the current performance bottleneck might be in data transmission.

[0237] (2) Step 2: Decision Engine - Decision Target Performance Tuning Scheme

[0238] The decision engine evaluates various parameter combinations based on a safety scoring function (Score = Estimated Performance × Safety Probability), where safety probability = P(Temperature ≤ 85℃) × P(Power Consumption ≤ TDP).

[0239] ①Option A (aggressive): Significantly increase CPU frequency + reallocate memory bandwidth to CPU + accelerate PCIe Gen4

[0240] Perf_pred = 1.30 (30% improvement in prediction performance compared to the baseline)

[0241] P(T≤85)=0.75 (Due to the high-speed operation of PCIe and CPU, the risk of high temperature is relatively high)

[0242] P (P≤350W)=0.80 (Power consumption may exceed limits)

[0243] Score=1.30×0.75×0.80=0.78

[0244] Option B (Conservative): Slightly increase CPU frequency + optimize PCIe link width

[0245] Perf_pred = 1.10

[0246] P(T≤85)=0.99

[0247] P(P≤350W)=0.99

[0248] Score=1.10×0.99×0.99≈1.08

[0249] ③ Option C (Balanced): Moderately increase CPU frequency + reallocate memory bandwidth + PCIe Gen4 speedup

[0250] Perf_pred = 1.22

[0251] P(T≤85)=0.90

[0252] P(P≤350W)=0.95

[0253] Score=1.22×0.90×0.95≈1.04

[0254] The decision engine selects option C: Option A has the highest absolute performance prediction, but its safety score is too low. Option B is the safest, but its performance improvement is limited. Option C achieves the best balance between performance and safety. Option B has the highest score, but Option C, by sacrificing a minimal safety score, gains a considerable performance improvement and is the optimal solution.

[0255] (3) Step 3: Hardware control layer - Execution parameter adjustment

[0256] The engine writes directly to the hardware registers via the UEFI interface:

[0257] Increase CPU frequency: Write to the MSR_IA32_PERF_CTL register to switch the CPU P-State from P1 to P0 (highest performance state).

[0258] Memory bandwidth reallocation: By writing to the MMIO register of the memory controller, channel priorities are adjusted to allocate more bandwidth to the CPU cores that process data.

[0259] Optimize PCIe links: Through the configuration space of the PCIe Root Port, force the x16 link where the GPU is located to switch from power-saving state (L1) to active state (L0) and ensure that it runs in Gen4 full-speed mode.

[0260] (4) Step 4: Security Protection Layer - Real-time Monitoring and Circuit Breaker

[0261] Continuous monitoring: Throughout the server performance tuning process, the sensing module continuously monitors the temperature and power consumption of the GPU and CPU.

[0262] Triggering the circuit breaker: If a partial failure occurs in the data center's air conditioning, causing a sudden rise in ambient temperature and resulting in the GPU temperature reaching 85°C within a very short time, the operational protection mechanism will be triggered.

[0263] ① Hardware response: The hardware fuse mechanism (entirely implemented by circuitry) is triggered immediately, bypassing all software layers within ≤10μs, directly forcing the GPU to downclock to the base frequency, ensuring absolute hardware safety.

[0264] ② Engine Response: After the decision engine detects a circuit breaker event, it will record the anomaly and generate a more conservative parameter configuration scheme with a higher score in the next control cycle to avoid triggering the circuit breaker again.

[0265] Corresponding to the embodiments of the aforementioned server control method, see [link to relevant documentation]. Figure 5 As shown, this application also provides an embodiment of a server control device, which is applied to a decision engine deployed on the firmware layer of a server's system stack. The device includes:

[0266] The candidate scheme acquisition and evaluation module 501 is used to, when it is determined that the server needs to be adjusted for performance, decide on at least one candidate performance adjustment scheme based on the current values ​​of N performance indicators of the server during operation and the historical performance adjustment schemes adopted by the server, and evaluate the estimated performance that the server can achieve when running with the candidate performance adjustment scheme.

[0267] The constraint metric prediction module 502 is used to evaluate, for each candidate performance tuning scheme, the probability that the predicted value of each constraint metric does not exceed its set constraint threshold when the server adopts the candidate performance tuning scheme; the constraint metric represents the boundary condition parameter whose value is limited to the engineering allowable threshold range when the server is running safely.

[0268] The target scheme selection module 503 is used to select a target performance adjustment scheme based on the estimated performance corresponding to each candidate performance adjustment scheme and the probability corresponding to each constraint index under the candidate performance adjustment scheme.

[0269] The control module 504 is used to adjust the server through a specified interface of the firmware layer based on the control parameters of the components in the target performance adjustment scheme, so that the server continues to operate based on the control parameters of the components in the target performance adjustment scheme.

[0270] In some embodiments, the N performance metrics include the constraint metrics; the apparatus includes a performance tuning determination module, configured to determine if performance tuning of the server is required:

[0271] Check whether the current value of each constraint metric during server operation does not exceed its set constraint threshold;

[0272] If so, it is determined that the server needs to be adjusted for performance; otherwise, the performance adjustment of the server is stopped, and the operation protection mechanism corresponding to the constraint indicator is triggered based on the constraint indicator whose current value exceeds its set constraint threshold.

[0273] In some embodiments, the constraint metric includes at least the temperature of the core computing components in the server; when the performance adjustment determination module triggers the runtime protection mechanism corresponding to the constraint metric:

[0274] If the temperature of the core computing component exceeds its set constraint threshold, it triggers the voltage regulation module (VRM) to send an indication signal directly to the server, causing the voltage regulation module to adjust the power supply to the core computing component to achieve hardware-level thermal fuse protection.

[0275] In some embodiments, when the target scheme selection module selects a target performance tuning scheme from among them:

[0276] For each candidate performance tuning scheme, based on the probability that the predicted value of each constraint indicator under the candidate performance tuning scheme does not exceed its set constraint threshold, the safe probability of the server running with the candidate performance tuning scheme is obtained by combining the probabilities.

[0277] Based on the estimated performance and safety probability corresponding to the candidate performance adjustment scheme, the feasibility parameters of the candidate performance adjustment scheme are determined, and the target performance adjustment scheme is selected according to the feasibility parameters of each candidate performance adjustment scheme.

[0278] In some embodiments, when the control module is used to adjust the server through a specified interface of the firmware layer:

[0279] The specified interface of the firmware layer in the server is invoked to directly write the control parameters of each component in the target performance tuning scheme into the hardware register unit to which the control parameters belong; wherein, the specified interface includes at least the Unified Extensible Firmware Interface (UEFI).

[0280] In some embodiments, the control module directly writes the control parameters of each component in the target performance tuning scheme into the hardware register to which the control parameters belong, including:

[0281] When the target performance tuning scheme includes a first parameter indicating the CPU performance state P-state of the server, the specified interface of the firmware layer is called to directly write the first parameter into the CPU internal register MSR register;

[0282] When the target performance tuning scheme includes a second parameter indicating the memory operation control of the server, the server's PCIe configuration space is accessed through a specified interface of the firmware layer, and the second parameter is written to the control register of the memory controller mapped to the extended area of ​​the PCIe configuration space.

[0283] In some embodiments, while the server continues to run based on the control parameters of the components in the target performance tuning scheme, the apparatus further includes an automatic recovery module for:

[0284] Obtain the actual measured performance achieved by the server when running with the target performance tuning scheme; the measured performance is used to reflect the measured gain of the target performance index that the server's performance tuning target is concerned with;

[0285] If the measured performance indicates that the server's performance has not improved, then performance tuning of the server is stopped, and the most recent historical performance tuning scheme used before adopting the target performance tuning scheme is obtained. Based on the control parameters of the components in the most recent historical performance tuning scheme, the server is controlled through the specified interface of the firmware layer.

[0286] In some embodiments, the constraint indicator prediction module is specifically used for:

[0287] The current values ​​of the N performance indicators and the control parameters of the components in the candidate performance adjustment scheme are used as input features and input into the probabilistic prediction model trained for the constraint indicator.

[0288] Obtain the probability distribution of the constraint index in future control cycles, output by the probability prediction model, when the server adopts the candidate performance adjustment scheme; the probability distribution includes the prediction mean and the prediction variance.

[0289] The probability that the constraint index does not exceed its set constraint threshold is calculated based on the probability distribution.

[0290] In some embodiments, the candidate solution acquisition and evaluation module is specifically used for:

[0291] Based on the current values ​​of the N performance indicators and the performance adjustment target, identify the current performance bottleneck of the server, and set a local search space for the control parameters related to the current performance bottleneck.

[0292] The proxy model is constructed by using the historical performance tuning scheme adopted by the server as the input sample and the actual performance of the server under the historical performance tuning scheme as the output label.

[0293] Within the local search space, based on the mean and uncertainty of the predicted performance output by the surrogate model, the search direction is guided by the acquisition function, multiple candidate performance adjustment schemes are generated iteratively, and the predicted performance given by the surrogate model for each candidate performance adjustment scheme is obtained.

[0294] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0295] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without any inventive effort.

[0296] This application also provides an electronic device, the structural schematic diagram of which is shown below. Figure 6As shown, the electronic device 600 includes at least one processor 601, a memory 602, and a bus 603. At least one processor 601 is electrically connected to the memory 602. The memory 602 is configured to store at least one computer-executable instruction, and the processor 601 is configured to execute the at least one computer-executable instruction to perform the steps of any server control method provided in any embodiment or optional implementation of this application.

[0297] Furthermore, the processor 601 can be an FPGA (Field-Programmable Gate Array) or other devices with logic processing capabilities, such as an MCU (Microcontroller Unit) or a CPU (Central Processing Unit).

[0298] This application also provides another readable storage medium storing a computer program that, when executed by a processor, implements the steps of any server control method provided in any embodiment or optional implementation of this application.

[0299] The readable storage media provided in this application include, but are not limited to, any type of disk (including floppy disk, hard disk, optical disk, CD-ROM, and magneto-optical disk), ROM (Read-Only Memory), RAM (Random Access Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory, magnetic cards, or optical cards. In other words, the readable storage media includes any medium by which a device (e.g., a computer) stores or transmits information in a readable form.

[0300] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0301] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A server control method characterized by comprising: The method is applied to a decision engine deployed on a firmware layer of a system stack of a server, and the method comprises: Upon determining that performance adjustment of the server is required, based on current values of N performance indicators of the server in runtime, and a historical performance adjustment scheme adopted by the server, determining at least one candidate performance adjustment scheme, and evaluating an estimated performance that the server can achieve when running with the candidate performance adjustment scheme; For each candidate performance adjustment scheme, evaluating a probability that a predicted value of each constraint indicator does not exceed a constraint threshold set for the constraint indicator, the constraint indicator representing a boundary condition parameter whose value is limited within an engineering-allowed threshold range when the server is running safely; Based on the estimated performance corresponding to each candidate performance adjustment scheme, and the probability corresponding to each constraint indicator under the candidate performance adjustment scheme, selecting a target performance adjustment scheme therefrom; Based on a control parameter of a component in the target performance adjustment scheme, adjusting the server through a specified interface of the firmware layer, so that the server continues to run based on the control parameter of the component in the target performance adjustment scheme.

2. The method of claim 1, wherein, The N performance indicators include the constraint indicators; determining that performance adjustment of the server is required comprises: Detecting whether the current value of each constraint indicator of the server in runtime does not exceed the constraint threshold set for the constraint indicator; If yes, determining that performance adjustment of the server is required, otherwise, stopping performance adjustment of the server, and triggering a running protection mechanism corresponding to the constraint indicator whose current value exceeds the constraint threshold set therefor.

3. The method of claim 2, wherein, The constraint indicators at least include a temperature of a core computing component in the server; triggering the running protection mechanism corresponding to the constraint indicator comprises: If the temperature of the core computing component exceeds the constraint threshold set therefor, triggering a voltage regulation module VRM of the server to send an indication signal directly to the voltage regulation module, so that the voltage regulation module performs power supply adjustment on the core computing component to achieve hardware-level thermal fuse protection.

4. The method of claim 1, wherein, Selecting a group of target performance adjustment schemes comprises: For each candidate performance adjustment scheme, based on the probability that the predicted value of each constraint indicator does not exceed the constraint threshold set therefor under the candidate performance adjustment scheme, obtaining a safety probability of the server running with the candidate performance adjustment scheme through joint probability; Based on the estimated performance corresponding to the candidate performance adjustment scheme and the safety probability, determining a feasibility parameter of the candidate performance adjustment scheme, and selecting the target performance adjustment scheme according to the feasibility parameter of each candidate performance adjustment scheme.

5. The method of claim 1, wherein, Adjusting the server through the specified interface of the firmware layer comprises: Calling the specified interface of the firmware layer of the server, and directly writing the control parameter of each component in the target performance adjustment scheme into a hardware register unit to which the control parameter belongs; wherein the specified interface at least includes a unified extensible firmware interface UEFI.

6. The method of claim 5, wherein, Directly writing the control parameter of each component in the target performance adjustment scheme into a hardware register unit to which the control parameter belongs comprises: When the target performance adjustment scheme includes a first parameter indicating a performance state P-state of a CPU of the server, a specified interface of the firmware layer is invoked to directly write the first parameter into a CPU internal register MSR register; When the target performance adjustment scheme includes a second parameter indicating a memory operation control of the server, a specified interface of the firmware layer is invoked to access a PCIe configuration space of the server, and the second parameter is written into a control register mapped in an extension region of the PCIe configuration space by a memory controller.

7. The method of claim 1, wherein, When the server continues to run based on the control parameters of the components in the target performance adjustment scheme, the method further includes: obtaining an actual measured performance actually achieved when the server runs based on the target performance adjustment scheme; the actual measured performance is used to reflect an actual measured gain of a target performance indicator of the performance adjustment target of the server; if it is determined based on the actual measured performance that the performance of the server is not improved, stopping the performance adjustment of the server, and obtaining a historical performance adjustment scheme last used before the target performance adjustment scheme is used, and controlling the server based on the control parameters of the components in the historical performance adjustment scheme.

8. The method of claim 1, wherein, evaluating a probability that a predicted value of each constraint indicator when the server runs based on the candidate performance adjustment scheme does not exceed a constraint threshold set for the constraint indicator, including: inputting current values of the N performance indicators and the control parameters of the components in the candidate performance adjustment scheme as input features into a probability prediction model trained for the constraint indicator; obtaining a probability distribution of the constraint indicator in a future control period when the server runs based on the candidate performance adjustment scheme output by the probability prediction model; the probability distribution includes a predicted mean and a predicted variance; calculating a probability that the constraint indicator does not exceed the constraint threshold set for the constraint indicator based on the probability distribution.

9. The method of claim 1, wherein, deciding at least one candidate performance adjustment scheme and evaluating an estimated performance that can be achieved when the server runs based on the candidate performance adjustment scheme, including: based on the current values of the N performance indicators and the performance adjustment target, identifying a current performance bottleneck of the server, and setting a local search space for control parameters related to the current performance bottleneck; using a historical performance adjustment scheme adopted by the server as an input sample and using an actual measured performance of the server under the historical performance adjustment scheme as an output label to construct a proxy model; based on a mean value and uncertainty of the estimated performance output by the proxy model, guiding a search direction by a sampling function in the local search space, iteratively generating a plurality of candidate performance adjustment schemes, and obtaining an estimated performance given by the proxy model for each candidate performance adjustment scheme.

10. A server control device characterized by comprising: The device is applied to a decision engine deployed on a firmware layer in a system stack of a server, and the device includes: The candidate scheme obtaining and evaluating module is configured to, when it is determined that performance adjustment of the server is needed, decide at least one candidate performance adjustment scheme based on current values of N performance indexes of the server at runtime and historical performance adjustment schemes adopted by the server, and evaluate estimated performance that the server can achieve when the candidate performance adjustment scheme is adopted to run; The constraint index prediction module is configured to, for each candidate performance adjustment scheme, evaluate a probability that a predicted value of each constraint index does not exceed a constraint threshold set for the constraint index when the candidate performance adjustment scheme is adopted to run the server; the constraint index represents a boundary condition parameter whose value is limited in an engineering allowable threshold range when the server is safely running; The target scheme selection module is configured to select a target performance adjustment scheme from each candidate performance adjustment scheme based on corresponding estimated performance of each candidate performance adjustment scheme and corresponding probabilities of each constraint index under the candidate performance adjustment scheme; The control module is configured to adjust the server through a specified interface of the firmware layer based on a control parameter of a component in the target performance adjustment scheme, so that the server continues to run based on the control parameter of the component in the target performance adjustment scheme.

11. An electronic device, comprising: Comprise: a memory and a processor; the memory is configured to store a computer program; the processor is configured to call the computer program to implement the method of any one of claims 1-9.

12. A readable storage medium, having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method of any one of claims 1-9. The program is executed by the processor to implement the method of any one of claims 1-9.

Images