Uncore frequency control device, uncore frequency control method, and uncore frequency control program

Abstract

An Uncore frequency control device (1) comprises: a monitoring unit (110) that collects HW operation status data from a compute (2) for a prescribed period; an analysis unit that employs data counted up over time as metrics to be analyzed, categorizes the metrics into a metrics A group in which a metrics value progressively increases as a load amount applied to an application increases, a metrics B group in which the metrics value decreases at a timing when degradation in application performance occurs, or a metrics C group in which the metrics value converges at a timing when degradation in application performance occurs, and determines metrics to be monitored; and a frequency control unit (140) that sets the Uncore frequency to the minimum value when the metrics B and C are not below the normalized value of the metrics A.

Description

Uncore frequency control device, Uncore frequency control method, and Uncore frequency control program

[0001] The present invention relates to an uncore frequency control device, an uncore frequency control method, and an uncore frequency control program.

[0002] In server operation and management, power consumption is an important issue, and power-saving technologies are being studied. For example, DVFS (Dynamic Voltage and Frequency Scaling) and virtualization technology can be used to improve resource utilization. DVFS is a technology that controls the voltage and frequency of CPU cores.

[0003] Meanwhile, in recent years, CPUs have been developed that allow different operating frequencies to be set for the core and uncore parts of the CPU package. The core part consists of the CPU core and L1 and L2 caches. The uncore part consists of the last level cache (LLC), memory controller, system bus, etc.

[0004] It is generally said that CPU power consumption is proportional to the product of the square of the voltage and the frequency, and power consumption can be reduced by lowering the voltage or frequency. However, lowering the frequency or voltage leads to a degradation of processing performance. Therefore, in order to minimize the impact of performance degradation depending on the load, technology has been proposed that dynamically lowers the frequency and voltage according to the load on the CPU.

[0005] The basic concept of frequency control in this case is explained below. (1) Lowering the CPU core frequency leads to a decrease in the performance of the calculation process on the core. Based on this, existing research has adopted the following methods of increasing or decreasing frequency: "CPU-intensive processing" → "Increase core frequency" "Memory-intensive processing" → "Decrease core frequency" (2) Lowering the CPU uncore frequency has an impact on the cache line transfer speed and memory bandwidth. Based on this, existing research has adopted the following methods of increasing or decreasing frequency: "CPU-intensive processing" → "Decrease uncore frequency" "Memory-intensive processing" → "Increase uncore frequency"

[0006] For CPUs that can set the operating frequency separately for the core and uncore, Intel (registered trademark, hereinafter the same) has introduced a function called UFS (Uncore Frequency Scaling). This UFS function allows the processor to dynamically change the uncore frequency depending on the load, achieving the same power-saving effect as DVFS for CPU cores (see Non-Patent Document 1). On the other hand, Linux (registered trademark, hereinafter the same) employs a technology that allows the minimum and maximum scaling frequencies to be set via sysfs.

[0007] Furthermore, research into uncore operating frequency control has proposed a control method targeted at HPC (High-Performance Computing) (see Non-Patent Document 2). Non-Patent Document 2 analyzes application (app) performance as a function of uncore frequency changes based on measurements using benchmarks with multiple processing characteristics. As a result, it is difficult for UFS to perform optimal frequency control for all apps, and control must be performed according to app characteristics and user requirements, and a unique uncore frequency control method is proposed.

[0008] Srinivas Pandruvada, “Intel Uncore Frequency Scaling,” Intel Corporation, 2022, [online], [Retrieved June 1, 2023], Internet <URL: https: / / www.kernel.org / doc / html / latest / admin-guide / pm / intel_uncore_frequency_scaling.html Andre, Etienne, et al., “DUF: Dynamic Uncore Frequency scaling to reduce power consumption.” Concurrency and Computation: Practice and Experience 34.3 (2022): e6580.

[0009] However, the applications targeted in existing research such as Non-Patent Document 2 are numerical calculation programs used in natural science research, and no control method for uncore operating frequency in service systems such as web servers has been proposed. Numerical calculation programs and web applications differ in that they are batch processes and real-time processes, and this difference is also reflected in the evaluation criteria for each. In batch processing, performance is evaluated by the processing completion time, and power is evaluated by the amount of power consumed until the processing is completed. On the other hand, in real-time processing, performance is evaluated by response time and throughput, and power is evaluated by power consumption.

[0010] In this real-time processing, performance also varies depending on the load, such as the number of requests processed by the server. For example, even in a simple HTTP request process that returns an HTML file, performance (response time) varies depending on the load (number of requests) when the frequency value is fixed. Therefore, for applications that perform real-time processing, such as web services and network services, it is necessary to perform frequency control in response to fluctuations in the load.

[0011] Furthermore, when performing real-time processing, the performance requirements for web service applications are, for example, a response time of 100 ms, which is less stringent than those for network services. When the optimal frequency described in Non-Patent Document 2 is applied to such web service applications, a state occurs in which there is still room for power reduction during low loads. For example, as shown in FIG. 8, during low loads, there is still room for the response time before violating the SLA. Therefore, even if the frequency is further reduced, it is possible to reduce power consumption within a range that does not violate the SLA. In other words, for web service applications with less stringent performance requirements, it is expected that the power reduction effect will be further increased in low load areas (Problem 1).

[0012] In addition, there are other issues with controlling server frequencies: (Issue 2) When monitoring some kind of index obtained from the server and controlling the frequency in stages according to the amount of fluctuation indicated by that index, if frequency changes occur frequently due to sudden fluctuations in load, overhead occurs due to CPU interrupt control, leading to degradation of application performance. Therefore, it is necessary to suppress the impact of overhead caused by frequency change processing.

[0013] (Problem 3) For server administrators, the contents of some applications are a black box, and server administrators may not be able to obtain values ​​directly related to the application's performance requirements (e.g., response time) or the load on the server (e.g., number of requests). Therefore, a method is needed to determine when performance degradation due to increased load will occur by simply monitoring information obtained from the hardware (e.g., server) on which the application is installed. In addition, the method must be able to handle various load fluctuations, such as fluctuations due to time and noise.

[0014] The present invention has been made in view of the above points, and an object of the present invention is to improve the power saving effect in a low load region in a system equipped with a Web-based application.

[0015] The Uncore frequency control device according to the present invention is an Uncore frequency control device that controls the Uncore frequency of a physical server that is a compute that has a Web service application installed, and includes a monitoring unit that collects data including HW operation status data from the compute for a predetermined period of time, and among the collected data, data that is counted up over time is used as a metric to be analyzed, and the metrics are normalized using a Min-Max method and then classified into a Metrics A group whose values ​​increase as the load on the Web service application increases, a Metrics B group whose values ​​decrease when the load increases and application performance deteriorates, and a Metrics C group whose values ​​converge when the load increases and application performance deteriorates, and at least one of the Metrics B group and the Metrics C group is selected. and a frequency control unit that sets the uncore frequency of the compute to a settable maximum value if either the normalized value of metric B or metric C is lower than the normalized value of metric A, and sets the uncore frequency of the compute to a settable minimum value if the normalized value of metric B or metric C is lower than the normalized value of metric A.

[0016] According to the present invention, it is possible to enhance the power reduction effect in a low load region in a system equipped with a web-based application.

[0017] 1 is a diagram showing the overall configuration of an uncore frequency control system including an uncore frequency control device according to this embodiment. FIG. 2 is a graph showing normalized values ​​of metrics A, B, and C against the amount of load. FIG. 3 is a diagram showing the relationship between an increase in load and deterioration of App performance. FIG. 4 is a diagram showing the transition of metrics A and metrics B over a predetermined period of time in the past. FIG. 5 is a flowchart showing the flow of a metrics determination process performed by an uncore frequency control device according to this embodiment before uncore frequency control. FIG. 6 is a flowchart showing the flow of a process performed by an uncore frequency control device according to this embodiment to perform uncore frequency control using determined metrics. FIG. 7 is a hardware configuration diagram showing an example of a computer that realizes the functions of the uncore frequency control device according to this embodiment. FIG. 8 is a diagram for explaining a state in which power reduction margin is left during low load in conventional technology.

[0018] Next, an embodiment of the present invention (hereinafter referred to as "the present embodiment") will be described.

[0019] The Uncore frequency control device according to this embodiment collects various data from a server on which a Web service application is installed and determines, from that data, data that will serve as an index to be used for control. This index data is data that is counted up over time ("metrics," described below). The Uncore frequency control device checks the trend of the increase rate of each metric relative to the load and determines the metrics to be monitored. The Uncore frequency control device then divides the load into low-load and high-load regions based on the point in time when the metric increase rate changes, and performs frequency control that prioritizes performance guarantee in the high-load region and power consumption reduction in the low-load region (details will be described below).

[0020] 1 is a diagram showing the overall configuration of an uncore frequency control system 1000 including an uncore frequency control device 1 according to this embodiment. As shown in FIG. 1, the uncore frequency control device 1 is communicatively connected to each compute (physical server) 2 that is the target of uncore frequency control.

[0021] Each compute 2 has an application (App) 200 (here, a Web service application) implemented on its hardware (HW). The application 200 may be implemented in a virtual machine (VM) or a container. Each compute 2 also includes data collection software 21 and an intelligent platform management interface (IPMI) 22.

[0022] The data collection software 21 is software that collects performance data of the compute 2 and acquires app performance values ​​and HW operation status data. App performance values ​​include, for example, response time and throughput, but depending on the application specifications, these app performance values ​​may not be acquired. Therefore, the data collection software 21 according to this embodiment acquires at least HW operation status data. The HW operation status data is an index that serves as a reference for the load on the compute 2, and includes performance data obtainable from each compute 2, such as CPU usage, cache misses, and the number of received packets, as well as performance values ​​obtained from logs of apps running on the compute 2. From this HW operation status data, data (metrics) that serve as indices for determining uncore frequency control (described below) are determined (details will be provided later). The data collection software 21 can use existing data collection software such as Perf and dstat, or custom software.

[0023] The IPMI 22 is a standard interface for monitoring and managing the state of hardware, and includes a power consumption measurement unit. The IPMI 22 implements an application (App) 200 to measure the power consumption of the Compute 2 when a load is applied. Note that this power consumption measurement unit is not limited to the IPMI 22. If the Compute 2 includes a power meter, the power consumption may be measured using the power meter.

[0024] The Compute 2 transmits data indicating the HW operation status when a load is applied to the implemented application 200 and information on power consumption to the Uncore frequency control device 1. Then, the Compute 2 acquires the setting information of the Uncore frequency from the Uncore frequency control device 1 and sets the optimal Uncore frequency according to the load.

[0025] <Uncore Frequency Control Device> Next, the uncore frequency control device 1 according to this embodiment will be described. The uncore frequency control device 1 classifies data that can be acquired only by the compute 2 on which the application 200 is installed into those whose values ​​increase relative to the amount of load (metrics group A, described below), those whose values ​​decrease when app performance deteriorates (metrics group B, described below), and those whose values ​​converge when app performance deteriorates (metrics group C, described below). Then, metrics to be monitored are determined from each of metrics group A, group B, and group C. If metrics B and C determined from metrics group B and group C are larger than metric A determined from metrics group A, the uncore frequency control device 1 sets the uncore frequency to the minimum configurable value, and if metrics A and C are smaller, the uncore frequency is set to the maximum configurable value. This enables power reduction, especially in low-load areas, in the server (Compute 2) that provides the web service application, and also enables frequency control based on information from the server (HW) even when necessary information (performance information) cannot be obtained from the web service application. Furthermore, by simplifying control based on load fluctuations, the control processing overhead can be reduced compared to existing methods. As shown in FIG. 1, the uncore frequency control device 1 includes a control unit 10, an input / output unit 11, and a storage unit 12.

[0026] The input / output unit 11 inputs and outputs information between each compute 2, etc. This input / output unit 11 is composed of a communication interface that transmits and receives information via a communication line, and an input / output interface that inputs and outputs information between an input device such as a keyboard and an output device such as a monitor, which are not shown.

[0027] The storage unit 12 is configured by a hard disk, a flash memory, a RAM (Random Access Memory), etc. The storage unit 12 stores a data store 100.

[0028] The data store 100 stores HW operation status data, power consumption, and the like that are collected from each compute 2 by a monitoring unit 110 (described later). The data store 100 also stores information such as normalized values ​​of metrics that are determined as monitoring targets by an analysis unit 120 (described later) and that are acquired by a metrics acquisition unit 130 via the monitoring unit 110.

[0029] The control unit 10 is responsible for all the processes executed by the Uncore frequency control device 1 , and is configured to include a monitoring unit 110 , an analysis unit 120 , a metrics acquisition unit 130 , and a frequency control unit 140 .

[0030] The monitoring unit 110 collects data (HW operation status data) from a server (Compute 2) on which a Web service application is installed. This data collection can be performed using existing data collection software such as Perf or dstat, or custom software. In addition, in the case of Linux, for example, Linux perf stat can be used as a data collection tool.

[0031] The analysis unit 120 analyzes the data collected by the monitoring unit 110, determines an index to be used for controlling the uncore frequency, and determines the logic to be used in the control algorithm based on the analysis results.

[0032] The following describes how the analysis unit 120 determines the index used for uncore frequency control. The analysis unit 120 analyzes data collected by the monitoring unit 110 that is counted up over time. This data is called "metrics." These metrics are counter values ​​that indicate the status of the server (Compute 2) provided by hardware, software, etc., such as the number of instruction executions, context switches, and cache misses.

[0033] When there is no load or a low to medium load, processing proceeds smoothly and the metrics increase. However, if the request queue becomes clogged for some reason, the increase in metrics changes. The analysis unit 120 identifies the monitoring targets required to detect when such a bottleneck occurs as metrics.

[0034] The analysis unit 120 checks the trend of the rate of increase in relation to the load for the multiple metrics collected by the monitoring unit 110 and classifies them into the following three groups. At this time, the analysis unit 120 normalizes the metrics using the Min-Max method because the absolute values ​​of each value are different.

[0035] Figure 2 is a graph showing normalized values ​​of metrics A, B, and C against the amount of load. The metrics are classified into three groups based on their increasing trend. Metrics A: As the amount of load increases, the metric value increases. Metrics B: As the amount of load increases, the metric value decreases when app performance degradation occurs. Metrics C: As the amount of load increases, the metric value converges when app performance degradation occurs.

[0036] The analysis unit 120 selects one metric (metric A) from the classified metrics A group as the monitoring target. The analysis unit 120 also selects at least one metric B or metric C from metrics B group and C group as the monitoring target. Note that it may select one metric from metrics B group and one from metrics C group. Here, with regard to metric A selected from metrics A group, the analysis unit 120 selects one that has a smaller value under low load than metrics B and C, as shown in FIG. 2. The analysis unit 120 then stores the Min / Max values ​​used for normalization during analysis in the data store 100.

[0037] Furthermore, in this embodiment, as shown in Figure 3, the timing at which degradation of App performance occurs and the value of Metric B decreases or the value of Metric C converges (dashed line x in Figures 2 and 3) defines whether the load on the server (Compute 2) is in the low load range or the high load range.

[0038] The analysis unit 120 determines metrics A, B, and C as indices to be used for controlling the uncore frequency based on the analysis results, and then determines the logic to be used in the control algorithm for controlling the uncore frequency. The metrics to be used as indices may be metric A and metric B, metric A and metric C, or metric A, metric B, and metric C.

[0039] As a preprocessing step for data handled by the logic used in the control algorithm, the analysis unit 120 first collects and normalizes the determined metrics (e.g., metrics A, B, and C) at predetermined time intervals. Then, the following logic is used to compare the magnitude of the metrics: The normalized values ​​are compared to determine whether "metric B or C > metric A." Here, it is determined whether either metric B or metric C is greater than metric A. In other words, it is determined whether the load amounts shown in FIGS. 2 and 3 are in the low-load range. If "metric B or C > metric A," the logic sets the uncore frequency to the minimum value that can be set. Meanwhile, the normalized values ​​are compared to determine whether "metric B or C < metric A." Here, it is determined whether either metric B or metric C is less than metric A. In other words, it is determined whether the load amounts shown in FIGS. 2 and 3 are in the high-load range. If "metric B or C<metric A", the logic is to set the uncore frequency to the maximum value that can be set.

[0040] The analysis unit 120 also uses the following logic to determine whether to proceed to a comparison of the magnitudes of the metrics: [1] Determining whether there is a load If the value of any of metrics A, B, or C (normalized using the Min-Max method) is equal to or greater than a predetermined threshold (for example, 0.1), the analysis unit 120 proceeds to a control decision (comparison of the magnitudes of the metrics). This logic is provided to prevent unnecessary processing when there is no load or an extremely low load.

[0041] [2] Judgment based on metric noise Metrics belonging to groups B and C, which are collected at predetermined time intervals by the monitoring unit 110, may become noisy during a transition period from low load to high load. Note that the following explanation will be given using metric B, but the same applies to metric C.

[0042] FIG. 4 shows the trends of Metric A and Metric B over a predetermined period of time. As shown in FIG. 4, during the transition from a low-load region to a high-load region, the magnitude relationship between Metric A and Metric B changes many times due to noise. Therefore, when the difference between the maximum and minimum values ​​of Metric B is equal to or less than a predetermined percentage of the total size (a predetermined first percentage: for example, 20%), a magnitude comparison with Metric A is performed. In other words, when the difference between the maximum and minimum values ​​of Metric B exceeds a predetermined percentage of the total (for example, 20%), a magnitude comparison is not performed. This prevents frequent changes to the uncore frequency setting due to the influence of noise, thereby preventing processing overhead.

[0043] Alternatively, when transitioning from high load to low load, if noise is detected (i.e., the difference between the maximum and minimum values ​​is equal to or greater than a predetermined percentage of the overall size (a predetermined second percentage: for example, 10%)), a control hysteresis is provided and a magnitude comparison (control decision) is made using "metric B+b" and "metric A-a." Note that a (second predetermined value) and b (first predetermined value) are any real numbers with 0<a, b<1. By setting the control hysteresis in this way, even if metric B fluctuates near the threshold, frequent switching due to the influence of that control can be avoided.

[0044] The frequency control unit 140 (described later) controls the uncore frequency using a control algorithm based on these logics determined by the analysis unit 120.

[0045] Returning to Fig. 1, the metrics acquisition unit 130 acquires information on the metrics that serve as indices determined by the analysis unit 120 from the server (Compute 2) via the monitoring unit 110. The metrics acquisition unit 130 then normalizes the acquired metrics A, B, and C using the Min-Max method and stores them in the data store 100.

[0046] The frequency control unit 140 performs uncore frequency control using metrics A, B, and C, which are indices acquired by the metrics acquisition unit 130 via the monitoring unit 110, in accordance with a control algorithm based on the logic generated by the analysis unit 120. Details of the process (control algorithm) executed by the frequency control unit 140 will be described later with reference to the flowchart in FIG.

[0047] <<Processing of Uncore Frequency Control Device>> Next, a description will be given of the processing executed by the Uncore frequency control device 1. Fig. 5 is a diagram showing the flow of a metrics determination processing that the Uncore frequency control device 1 performs before (in advance of) the Uncore frequency control. Fig. 6 is a diagram showing the flow of a processing that the Uncore frequency control device 1 performs the Uncore frequency control using the determined metrics.

[0048] First, the flow of the metrics determination process will be described in Fig. 5. The monitoring unit 110 (Fig. 1) of the Uncoore frequency control device 1 collects data (HW operation status data) for a predetermined period from a server (Compute 2) on which a web service application is installed (step S10).

[0049] Next, the analysis unit 120 of the Uncoore frequency control device 1 normalizes the data acquired by the monitoring unit 110 that is counted up over time (for example, counter values ​​indicating the number of command executions, context switches, cache misses, and other server states) using the Min-Max method (step S11). The Min / Max values ​​used in this normalization are stored in the data store 100.

[0050] Next, the analysis unit 120 checks the trend of the rate of increase in relation to the load amount and classifies the metrics into three groups: "Metrics Group A," whose metric values ​​increase as the load amount increases; "Metrics Group B," whose metric values ​​decrease when the load amount increases and app performance degradation occurs; and "Metrics Group C," whose metric values ​​converge when the load amount increases and app performance degradation occurs (step S12).

[0051] Then, one type from Metrics Group A and at least one type from Metrics Group B and Group C are determined as the indices to be used for controlling the uncore frequency (step S13). Note that one type from Metrics Group A and one type each from Metrics Group B and Group C may be determined as the indices to be used for controlling the uncore frequency. Furthermore, if there are multiple candidates in each metric group, any metric can be selected, but for Metric A selected from Metrics Group A, the metric A with a smaller value under low load than Metrics B and C selected from Metrics Group B and Group C is selected (see FIG. 2).

[0052] Next, the analysis unit 120 determines the logic to be used in the control algorithm (step S14). Specifically, the analysis unit 120 determines the logic for comparing the magnitude of metrics according to the metrics that will be the indices determined in step S13. For example, if metric A selected from the metric A group and metric B selected from the metric B group are determined as the indices in step S13, the analysis unit 120 determines the following logic: - Normalized values ​​are compared during control, and if "metric B > metric A," the uncore frequency is determined to be the minimum configurable value. - Normalized values ​​are compared during control, and if "metric B < metric A," the uncore frequency is determined to be the maximum configurable value. The same applies when metric C is determined as the index.

[0053] Also, for example, if metric A selected from metric group A, metric B selected from metric group B, and metric C selected from metric group C are determined as indices in step S13, the following logic is used to determine the indices: - Normalized values ​​are compared during control, and if either metric B or metric C is greater than metric A, the uncore frequency is determined to be the minimum configurable value. - Normalized values ​​are compared during control, and if either metric B or metric C is less than metric A, the uncore frequency is determined to be the maximum configurable value.

[0054] [Logic for Determining Whether or Not a Load is Applied] Furthermore, the analysis unit 120 determines logic for determining whether or not a load is applied to metrics A, B, and C selected as indicators to determine whether or not to perform a metric magnitude comparison process. The logic determines that if the value of any of metrics A, B, and C (normalized using the Min-Max method) is equal to or greater than a predetermined threshold (e.g., 0.1), the process proceeds to a control decision (metric magnitude comparison). Note that this predetermined threshold is determined in advance, for example, by a system administrator or the like, and stored in the memory unit 12 of the uncore frequency control device 1.

[0055] [Decision Based on Metric Noise] Furthermore, the analysis unit 120 determines whether the metrics are in a transitional period where the load is changing from low to high, and in this case, because the noise is large, determines logic to avoid comparing the magnitude of the metrics. Specifically, for metrics B and C selected as metrics, the analysis unit 120 references data on the transitions over a predetermined period of time (e.g., 5 seconds) stored in the data store 100, and determines logic to move on to a control decision (a magnitude comparison with metric A) if the difference between the maximum and minimum values ​​is less than a predetermined percentage of the overall size (a predetermined first percentage: e.g., 20%).

[0056] Furthermore, the analysis unit 120 references the data stored in the data store 100 showing the transitions over a given period of time (e.g., 5 seconds) for metrics B and C selected as metrics. When a transition from high load to low occurs and the maximum and minimum values ​​exceed a given percentage of the total (a given second percentage: e.g., 10%), the analysis unit 120 determines a logic in which control hysteresis is provided and a control decision (a comparison with metric A) is made as "metric B + b," "metric C + c," and "metric A - a." Here, a (second given value), b (first given value), and c (first given value) are any real numbers in the range 0 < a, b, c < 1. Note that the first given values ​​b and c may be the same or different values.

[0057] As a result, the Uncore frequency control device 1 can prevent frequent setting changes due to the influence of noise, and can prevent processing overhead.

[0058] The frequency control unit 140 of the uncore frequency control device 1 controls the uncore frequency using a control algorithm based on the logic determined by the analysis unit 120. Next, the process flow (control algorithm) of the uncore frequency control will be described.

[0059] 6 is a diagram showing the flow of processing in which the uncore frequency control device 1 performs uncore frequency control using the determined metrics. Here, the explanation is given assuming that the analysis unit 120 has determined the indices used for uncore frequency control to be metrics A and B. Furthermore, the analysis unit 120 has determined the logic for comparing the magnitude of the metrics, and has preset a predetermined threshold for determining whether a load is applied, a predetermined ratio (a predetermined first ratio, a predetermined second ratio) for making a determination based on noise, and so on.

[0060] First, the metrics acquisition unit 130 of the uncore frequency control device 1 acquires information on the metrics (here, metrics A and metrics B) that serve as indices determined by the analysis unit 120 from the server (Compute 2) via the monitoring unit 110 (step S20). Note that, for example, the metrics acquisition unit 130 acquires data at one-second intervals via the monitoring unit 110 using a data collection tool (Linux per stat). Then, for the acquired metrics A and B, the metrics acquisition unit 130 uses the Min / Max values ​​used for normalization during analysis that were stored in the data store 100, and stores the normalized values ​​in the data store 100.

[0061] Next, the frequency control unit 140 of the uncore frequency control device determines whether the metric value (the value of metric A or metric B) is equal to or greater than a predetermined threshold (e.g., 0.1) (step S21). This process is intended to prevent unnecessary processing when there is no load or a very low load. If the metric value is not equal to or greater than the predetermined threshold (step S21 → No), that is, if there is no load or a very low load, the uncore frequency is not controlled and the process proceeds to step S28. On the other hand, if the metric value is equal to or greater than the predetermined threshold (step S21 → Yes), the process proceeds to the next step S22.

[0062] In step S22, the frequency control unit 140 determines whether the difference between the maximum and minimum values ​​of the data of metrics B (normalized values) collected over a predetermined time period in the past (e.g., 5 seconds) is less than a predetermined percentage (a predetermined first percentage: e.g., 20%) of the total. If the difference between the maximum and minimum values ​​is not less than the predetermined percentage (predetermined first percentage) of the total (step S22 → No), the influence of noise is deemed to be large, and the uncore frequency is not controlled, and the process proceeds to step S28. On the other hand, if the difference is less than the predetermined percentage (predetermined first percentage) (step S22 → Yes), the process proceeds to the next step S23.

[0063] In step S23, the frequency control unit 140 determines whether the uncore frequency currently set in Compute 2 is the maximum value and whether the difference between the maximum and minimum values ​​of Metrics B (normalized values) data collected over a predetermined time period in the past (e.g., 5 seconds) is equal to or greater than a predetermined percentage (a predetermined second percentage: e.g., 10%) of the total. If the uncore frequency currently set in Compute 2 is the maximum value, this means that the current load is high and that a transition from high load to low load is occurring. If the difference between the maximum and minimum values ​​is equal to or greater than a predetermined percentage (a predetermined second percentage: e.g., 10%) of the total load, this means that a certain degree of noise influence is present. If the requirements of step S23 are not met (step S23 → No), the process proceeds to step S25. On the other hand, if the requirements of step S23 are met (step S23 → Yes), the process proceeds to step S24.

[0064] In step S24, the frequency control unit 140 sets the control hysteresis. Specifically, the frequency control unit 140 sets the value of metric B to "metric B+b" and the value of metric A to "metric A-a," where a and b are any real numbers such that 0<a, b<1. Then, the process proceeds to step S25.

[0065] In step S25, the frequency control unit 140 determines whether the value of metric B is lower than the value of metric A (metric B < metric A). If the value of metric B is not lower than the value of metric A (step S25 → No), the frequency control unit 140 sets the uncore frequency to the minimum value that can be set (step S26). If the current value is the minimum, the current value is maintained. Then, the process proceeds to step S28. On the other hand, if the value of metric B is lower than the value of metric A (step S25 → Yes), the uncore frequency is set to the maximum value that can be set (step S27). If the current value is the maximum, the current value is maintained. Then, the process proceeds to step S28.

[0066] In step S28, the frequency control unit 140 determines whether the web service in Compute 2 has ended. If the web service has not ended (step S28 → No), the process returns to step S20 and repeats. On the other hand, if the web service has ended (step S28 → Yes), the entire uncore frequency control process ends.

[0067] <Hardware Configuration> The Uncore frequency control device 1 according to this embodiment is realized by a computer 900 having a configuration as shown in Fig. 7, for example. Fig. 7 is a hardware configuration diagram showing an example of the computer 900 that realizes the functions of the Uncore frequency control device 1 according to this embodiment. The computer 900 has a CPU 901, a ROM (Read Only Memory) 902, a RAM 903, a HDD (Hard Disk Drive) 904, an input / output I / F (Interface) 905, a communication I / F 906, and a media I / F 907.

[0068] The CPU 901 operates based on a program (uncore frequency control program) stored in the ROM 902 or the HDD 904, and performs control by the control unit 10 (FIG. 1). The ROM 902 stores a boot program executed by the CPU 901 when the computer 900 starts up, programs related to the hardware of the computer 900, and the like.

[0069] The CPU 901 controls an input device 910 such as a mouse or keyboard, and an output device 911 such as a display or printer, via an input / output I / F 905. The CPU 901 acquires data from the input device 910 via the input / output I / F 905, and outputs generated data to the output device 911. Note that a GPU (Graphics Processing Unit) or the like may be used as a processor together with the CPU 901.

[0070] The HDD 904 stores programs executed by the CPU 901 and data used by the programs. The communication I / F 906 receives data from other devices via a communication network (e.g., NW (Network) 920) and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0071] The media I / F 907 reads a program (uncore frequency control program) or data stored in the recording medium 912 and outputs it to the CPU 901 via the RAM 903. The CPU 901 loads a program related to a target process from the recording medium 912 onto the RAM 903 via the media I / F 907, and executes the loaded program. The recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase Change Rewritable Disc), a magneto-optical recording medium such as an MO (Magneto Optical Disc), a magnetic recording medium, a semiconductor memory, or the like.

[0072] For example, when the computer 900 functions as the uncore frequency control device 1 of the present invention, the CPU 901 of the computer 900 executes a program loaded on the RAM 903 to realize the function of the uncore frequency control program. In addition, the HDD 904 stores data in the RAM 903. The CPU 901 reads and executes a program related to a target process from a recording medium 912. In addition, the CPU 901 may read a program related to a target process from another device via a communication network (NW 920).

[0073] <Effects> The following describes the effects of the Uncore frequency control device etc. according to the present invention. The Uncore frequency control device according to the present invention is an Uncore frequency control device 1 that controls the Uncore frequency of a physical server that is a compute 2 equipped with a Web service application, and includes a monitoring unit 110 that collects data including HW operation status data from the compute 2 for a predetermined period of time, and of the collected data, data that is counted up over time is used as metrics to be analyzed, and the metrics are normalized using the Min-Max method and then classified into a Metrics A group whose values ​​increase as the load on the Web service application increases, a Metrics B group whose values ​​decrease when the load increases and application performance deteriorates, and a Metrics C group whose values ​​converge when the load increases and application performance deteriorates, and at least one of the Metrics B group and the Metrics C group The system is characterized by comprising: an analysis unit (120) that selects one metric A from the group of metrics A that has a smaller normalized value than the selected metric B and / or metric C during low load periods before application performance degradation occurs, and determines the selected metric as the monitoring target; a metrics acquisition unit (130) that acquires data on metric A and metric B and / or metric C to be monitored from compute 2 and normalizes the data using the min-max method; and a frequency control unit (140) that sets the uncore frequency of compute 2 to a configurable maximum value if either the normalized value of metric B or metric C is lower than the normalized value of metric A, and sets the uncore frequency of compute 2 to a configurable minimum value if the normalized value is not lower.

[0074] By doing so, the uncore frequency control device 1 can enhance the power reduction effect in low-load areas in systems equipped with web-based applications. Furthermore, the uncore frequency control device 1 can change the uncore frequency from a configurable minimum value to a configurable maximum value when the state of the compute 2 transitions from a low-load area to a high-load area where performance requirements may be violated. By simplifying the control of the uncore frequency in response to load fluctuations in this way, the overhead caused by frequency setting changes can be reduced compared to conventional techniques. Furthermore, even when values ​​directly related to performance requirements (e.g., response time) cannot be obtained from the application installed in the compute 2, the uncore frequency control device 1 can use HW operation status data obtained from the compute 2 to determine the timing at which performance degradation occurs due to an increase in the load on the application. Therefore, it is possible to reliably determine the timing of a transition to a high-load area and change the uncore frequency setting.

[0075] Furthermore, in the Uncore frequency control device 1, the frequency control unit 140 is characterized in that if any one of the values ​​of each metric to be monitored, acquired and normalized by the metrics acquisition unit 130, is not above a predetermined threshold, it does not perform the Uncore frequency setting process for Compute 2.

[0076] By doing this, the Uncore frequency control device 1 does not perform the process of determining whether to change the uncore frequency setting when the load on the Compute 2 is zero or an extremely low load close to zero. Therefore, the Uncore frequency control device 1 can reduce wasted power due to unnecessary determination processes.

[0077] Furthermore, in the Uncore frequency control device 1, the frequency control unit 140 is characterized in that it does not perform the setting process of the compute Uncore frequency when the difference between the maximum and minimum values ​​of metric B or metric C acquired and normalized by the metrics acquisition unit 130 at a predetermined time exceeds a predetermined first proportion of the overall size of the normalized metrics.

[0078] By doing this, the uncore frequency control device 1 can avoid changing the uncore frequency setting when there is a lot of noise during a transition period from low load to high load in the collected metrics B or metrics C. This allows the uncore frequency control device 1 to suppress an increase in uncore frequency setting changes due to noise, and can reduce the overhead of the compute 2.

[0079] Furthermore, in the Uncore frequency control device 1, when the Uncore frequency of Compute 2 is currently set to the maximum value that can be set, and the difference between the maximum and minimum values ​​of Metric B or Metric C acquired and normalized by the Metric Acquisition Unit 130 at a predetermined time is greater than or equal to a predetermined second percentage of the overall normalized size of the metrics, the frequency control unit 140 sets control hysteresis by adding a first predetermined value to the normalized value of Metric B and / or Metric C determined to be the monitoring target, and subtracting a second predetermined value from the normalized value of Metric A determined to be the monitoring target.

[0080] In this way, the Uncore frequency control device 1 can prevent frequent changes to the Uncore frequency setting by setting the control hysteresis, thereby reducing the overhead of the Compute 2.

[0081] The present invention is not limited to the above-described embodiments, and many modifications can be made by a person having ordinary skill in the art within the technical concept of the present invention.

[0082] DESCRIPTION OF SYMBOLS 1 Uncore frequency control device 2 Compute (physical server) 10 Control unit 11 Input / output unit 12 Storage unit 21 Data collection software 22 IPMI 100 Data store 110 Monitoring unit 120 Analysis unit 130 Metrics acquisition unit 140 Frequency control unit 200 Application (App) 1000 Uncore frequency control system

Claims

1. An uncore frequency control device for controlling an uncore frequency of a physical server that is a compute equipped with a web service application, comprising: a monitoring unit that collects data including HW operation status data from the compute for a predetermined period of time; an analysis unit which uses data that is counted up over time from among the collected data as metrics to be analyzed, normalizes the metrics using a Min-Max method, and then classifies the metrics into a metric A group whose metric values ​​increase as the load on the Web service application increases, a metric B group whose metric values ​​decrease when the load increases and application performance degradation occurs, and a metric C group whose metric values ​​converge when the load increases and application performance degradation occurs, and selects at least one metric B and / or metric C from the metric B group and the metric C group, and selects one metric A from the metric A group whose normalized value is smaller than that of the selected metric B and / or metric C during a low load period before the application performance degradation occurs, and determines the selected metric to be monitored; An uncore frequency control device comprising: a metric acquisition unit that acquires data on metric A, metric B and / or metric C to be monitored from the compute and performs normalization using the Min-Max method; and a frequency control unit that sets the uncore frequency of the compute to a settable maximum value if either the normalized value of metric B or metric C is lower than the normalized value of metric A, and sets the uncore frequency of the compute to a settable minimum value if the normalized value is not lower.

2. The uncore frequency control device according to claim 1, characterized in that the frequency control unit does not perform setting processing of the uncore frequency of the compute if any one of the values ​​of each metric of the monitored object acquired and normalized by the metrics acquisition unit is not equal to or greater than a predetermined threshold.

3. The uncore frequency control device of claim 1, characterized in that the frequency control unit does not perform setting processing of the uncore frequency of the compute when the difference between the maximum and minimum values ​​of the metric B or metric C acquired and normalized by the metrics acquisition unit at a specified time exceeds a specified first percentage of the overall size of the normalized metrics.

4. The uncore frequency control device of claim 1, characterized in that, when the uncore frequency of the compute is currently set to the maximum value that can be set and the difference between the maximum and minimum values ​​of the values ​​of metric B or metric C acquired and normalized by the metrics acquisition unit at a predetermined time is equal to or greater than a predetermined second percentage of the overall normalized size of the metrics, the frequency control unit sets control hysteresis by adding a first predetermined value to the normalized value of metric B and / or metric C determined to be the monitoring target and subtracting a second predetermined value from the normalized value of metric A determined to be the monitoring target.

5. An uncore frequency control method of an uncore frequency control device that controls an uncore frequency of a physical server that is a compute equipped with a Web service application, the uncore frequency control device comprising: a step of collecting data including HW operation status data from the compute for a predetermined period of time; Among the collected data, data that is counted up over time is used as the metrics to be analyzed, the metrics are normalized using the Min-Max method, and then classified into a group of metrics A whose values ​​increase as the load on the Web service application increases, a group of metrics B whose values ​​decrease when the load increases and application performance degradation occurs, and a group of metrics C whose values ​​converge when the load increases and application performance degradation occurs, selecting at least one metric B and / or metric C from the group of metrics B and the group of metrics C, selecting one metric A from the group of metrics A whose normalized value is smaller than that of the selected metric B and / or metric C during a low load period before the application performance degradation occurs, and determining the selected metric as the monitoring target; acquiring the data of metric A and metric B and / or metric C to be monitored from the compute and performing normalization using the Min-Max method; The uncore frequency control method is characterized by executing a step of setting the uncore frequency of the compute to a settable maximum value if either the normalized value of the metric B or the normalized value of the metric C is lower than the normalized value of the metric A, and setting the uncore frequency of the compute to a settable minimum value if the normalized value of either the metric B or the metric C is lower than the normalized value of the metric A.

6. An Uncore frequency control program for causing a computer to function as the Uncore frequency control device according to any one of claims 1 to 4.