Method and system for adjusting computing power of container, electronic device, computer-readable storage medium, and computer program product

Abstract

Embodiments of the present disclosure relate to the technical field of cloud computing, and provide a method and system for adjusting a computing power of a container, an electronic device, a computer-readable storage medium, and a computer program product. The method comprises: acquiring a computing power satisfaction rate of a container, the computing power satisfaction rate being used for characterizing a ratio of computing power allocated to the container to computing power required by the container; in response to the computing power satisfaction rate not satisfying a preset condition, invoking a hyper-thread resource allocation sensing interface of a kernel on which the container depends, to adjust the computing power satisfaction rate of the container. The present disclosure uses a computing power satisfaction rate to measure a computing power level actually obtained by a container, and on the basis of dynamic adjustment of the computing power satisfaction rate of the container by the hyper-thread resource quota sensing interface, controls the performance fluctuation of the application in the container within a particular range, such that the computing power obtained by the container on a node at any load level falls within a stable interval, thereby reducing the difference in performance of containers on host nodes at different load levels, and increasing container performance consistency.

Description

A method, system, electronic device, computer-readable storage medium, and computer program product for regulating the computing power of a container. Technical Field

[0001] This disclosure relates to the field of cloud computing technology, and in particular to the adjustment of computing power in containers. Background Technology

[0002] Containers provide users with an independent runtime space for their applications. The processes running inside a container are isolated from other processes on the host node, but containers share kernel computing resources with other processes. On host nodes with different loads, the varying degrees of performance interference caused by system resource contention result in inconsistent computing power allocated to containers on different host nodes, leading to significant differences in container performance across different host nodes.

[0003] In related technologies, to improve the consistency of container performance, latency-sensitive tasks are used to model the CPI (Clock cycles per instruction, the number of clock cycles required to execute each computer instruction) for the target scenario. Because the CPI of latency-sensitive tasks is generally relatively stable, outlier containers can be easily identified based on CPI, and these outlier containers can be identified as having abnormal performance, thus allowing for the management of the identified abnormal containers.

[0004] However, the aforementioned technologies are only effective for tasks with stable CPI indicators. When the task being run is not latency-sensitive, the performance of containers on host nodes with different loads still varies greatly. Summary of the Invention

[0005] This disclosure provides a method, system, electronic device, computer-readable storage medium, and computer program product for adjusting the computing power of a container, in order to alleviate or solve one or more technical problems existing in the related art.

[0006] In a first aspect, embodiments of this disclosure provide a method for adjusting the computing power of a container, comprising: obtaining a computing power satisfaction rate of the container, the computing power satisfaction rate being used to characterize the ratio between the computing power allocated to the container and the computing power required by the container; and, in response to the computing power satisfaction rate not meeting a preset condition, invoking the hyper-threaded resource quota awareness interface of the kernel on which the container depends to adjust the computing power satisfaction rate.

[0007] Secondly, embodiments of this disclosure provide a method for adjusting the computing power of a container, comprising: sending configuration information to each computing node in a cluster, the configuration information including a preset performance consistency model; the preset performance consistency model being used to characterize the mapping relationship between node computing power utilization and hyper-threaded computing power ratio; receiving a container creation request sent by a client, the creation request carrying the configuration file of the container; sending the configuration file to a target computing node, the target computing node being any computing node in the cluster, so that the target computing node starts the container based on the configuration file and calls the hyper-threaded resource quota awareness interface of the kernel on which the container depends based on the configuration information to adjust the computing power satisfaction rate of the container.

[0008] Thirdly, embodiments of this disclosure provide a container computing power adjustment system, including: a management node and a computing node; the management node is configured to send configuration information to the computing node and send a container creation request to the computing node; the configuration information includes a preset performance consistency model; the preset performance consistency model is used to characterize the mapping relationship between node computing power utilization and hyper-threaded computing power ratio; the computing node is configured to start the container based on the configuration file included in the container creation request; obtain the computing power satisfaction rate of the container; and, based on the computing power satisfaction rate and the configuration information, call the hyper-threaded resource quota awareness interface of the kernel on which the container depends to adjust the computing power satisfaction rate of the container; the computing power satisfaction rate is used to characterize the ratio between the computing power allocated to the container and the computing power required by the container.

[0009] Fourthly, embodiments of this disclosure provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor implements the method of any one of the embodiments of this disclosure when executing the computer program.

[0010] Fifthly, embodiments of this disclosure provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method of any one of the embodiments of this disclosure.

[0011] Sixthly, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the embodiments of this disclosure.

[0012] Based on the container computing power adjustment method described in the first aspect above, this disclosure has at least the following beneficial effects or advantages: The embodiments of this disclosure use computing power satisfaction rate to measure the actual computing power level obtained by the container. When the container's computing power satisfaction rate does not meet preset conditions, the container's computing power satisfaction rate is adjusted by calling the kernel's hyper-threaded resource quota awareness interface. This achieves dynamic adjustment of the container's computing power satisfaction rate, thereby helping to control the performance fluctuations of applications within the container within a certain range. It allows for dynamic adjustment of the computing power that the container can obtain on a host node with any load level, thus helping to adjust the actual computing power obtained by the container to a stable range. This reduces the performance differences of containers on host nodes with different load levels, reduces the impact of host node load on container performance, and improves the consistency of container performance.

[0013] The above description is only an overview of the technical solution of this disclosure. In order to better understand the technical means of this disclosure, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this disclosure more obvious and understandable, specific embodiments of this disclosure are given below. Attached Figure Description

[0014] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments according to this disclosure and should not be construed as limiting the scope of this disclosure.

[0015] Figure 1 shows a flowchart of a container computing power adjustment method provided in an embodiment of this disclosure;

[0016] Figure 2 shows another flowchart of a container computing power adjustment method provided in an embodiment of this disclosure;

[0017] Figure 3 shows a flowchart of another container computing power adjustment method provided in an embodiment of this disclosure;

[0018] Figure 4 shows a schematic diagram of a container computing power adjustment system provided in an embodiment of this disclosure;

[0019] Figure 5 shows a schematic diagram of the structure of a container computing power adjustment device provided in an embodiment of this disclosure;

[0020] Figure 6 shows a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0021] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of this disclosure. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0022] To facilitate understanding of the technical solutions of the embodiments of this disclosure, the related technologies of the embodiments of this disclosure are described below. The following related technologies are optional solutions and can be combined with the technical solutions of the embodiments of this disclosure in any way, and all of them fall within the protection scope of the embodiments of this disclosure.

[0023] The containers mentioned in this disclosure can be single containers running on physical machines or virtual machines, or they can be container groups (Pods) running in a Kubernetes cluster, where a container group can contain one or more containers. In this disclosure, the nodes on which the containers depend for operation are referred to as host nodes. These host nodes can be physical servers, cloud servers, virtual machines, etc. In the application scenario of container groups, the host node can be a management node, compute node, or edge node in the Kubernetes cluster.

[0024] The processes running inside a container are isolated from other processes on the host node, but the container shares kernel computing resources with other processes. Because different containers and applications on the host node compete for system resources, different containers or applications run on different host nodes with varying load levels. If the same container is run on nodes with different load levels, the computing power it receives will differ, resulting in varying performance of the same container on nodes with different load levels. This performance variation can cause instability in user applications.

[0025] Based on this, this disclosure provides a method for adjusting the computing power of a container, which obtains the computing power satisfaction rate of the container, and when the computing power satisfaction rate of the container does not meet the preset conditions, calls the kernel's hyper-threaded resource quota awareness interface to adjust the computing power satisfaction rate of the container.

[0026] The aforementioned computing power sufficiency rate accurately measures the actual computing power obtained by the container. Dynamic adjustment of the container's computing power sufficiency rate is achieved by calling the hyper-threading resource quota awareness interface. The method of this embodiment can be used to adjust the computing power sufficiency rate of containers running on any host node. This ensures that regardless of the load level of the host node, the container can obtain approximately the same computing power, solving the problem of performance differences caused by resource contention on nodes with different load levels. It achieves dynamic performance balancing of containers based on the computing power sufficiency rate, making the container's running performance unaffected by the host node's load, improving the consistency of container running performance, and reducing performance fluctuations of user applications within the container.

[0027] It should be noted that the application scenarios or examples provided in this disclosure are for ease of understanding, and the application of the technical solutions in the embodiments of this disclosure is not specifically limited. Furthermore, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0028] The technical solutions of this disclosure and how they solve the aforementioned technical problems are described in detail below with specific embodiments. The listed specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of this disclosure will be described in detail below with reference to the accompanying drawings.

[0029] Refer to the flowchart of the container computing power adjustment method shown in Figure 1. The adjustment method specifically includes steps 101 and 102.

[0030] Step 101: Obtain the computing power satisfaction rate of the container. The computing power satisfaction rate is used to characterize the ratio between the computing power allocated to the container and the computing power required by the container.

[0031] Step 102: In response to the fact that the computing power satisfaction rate does not meet the preset conditions, call the hyper-threaded resource quota awareness interface of the kernel on which the container depends to adjust the computing power satisfaction rate of the container.

[0032] The execution entity in this embodiment is the host node where the container resides. This host node can be a physical server, a cloud server, or any node in a Kubernetes cluster. The aforementioned container computing power fulfillment rate is an indicator that quantifies the container's computing power achievement rate and reflects the actual computing power level obtained by the container.

[0033] The aforementioned preset conditions may include situations where the container's computing power satisfaction rate is not within a preset satisfaction rate range, or where the container's computing power satisfaction rate is not a preset satisfaction rate. The preset satisfaction rate range can be manually pre-configured in the host node. Alternatively, it can be sent to the host node by other nodes, received, and stored by the host node. For example, in a Kubernetes cluster, the management node can distribute the preset satisfaction rate range to each compute node in the cluster. The preset satisfaction rate range is a pre-set range of baseline computing power satisfaction rates that containers on host nodes with different load levels are required to achieve. The preset satisfaction rate range can be [25%, 35%], [35%, 40%], etc. This embodiment does not limit the specific value of the preset satisfaction rate range; it can be set according to requirements in practical applications.

[0034] The aforementioned preset satisfaction rate can also be sent to the host node by other nodes, or pre-configured on the host node. The preset satisfaction rate can be 30%, 35%, etc. This disclosure does not limit the specific value of the preset satisfaction rate; it can be set according to requirements in practical applications.

[0035] The kernel has a hyper-threading quota awareness (HT-Aware Quota) mechanism, and the aforementioned HT-Aware Quota interface is used to call this mechanism. The HT-Aware Quota mechanism is a scheduling technique in the kernel that uses CPU computing power to calibrate virtual runtime, enabling adjustments to process runtime resources.

[0036] This embodiment uses a computing power sufficiency rate to measure the actual computing power level obtained by the container. When the container's computing power sufficiency rate does not meet a preset condition, the container's computing power sufficiency rate is adjusted by calling the kernel's hyper-threading resource quota awareness interface. Calling the kernel's hyper-threading resource quota awareness interface uses the hyper-threading resource quota awareness mechanism, which can adjust the virtual runtime of the container's processes. The scheduler schedules the process's computing power usage based on the process's virtual runtime. After adjusting the virtual runtime of the container's processes by calling the hyper-threading resource quota awareness interface, the scheduler can schedule the CPU time occupied by the container's processes based on the adjusted virtual runtime, thereby adjusting the container's computing power sufficiency rate. This method enables dynamic adjustment of the container's computing power sufficiency rate on the host node. It can control the container's computing power sufficiency rate to be within a preset range, or adjust the container's computing power sufficiency rate to a specific value. This allows the performance fluctuation of the application in the container to be controlled within a certain range, ensuring that the computing power that the container can obtain on the host node at any load level is within a stable range. This reduces the performance difference of containers on host nodes with different load levels, realizes dynamic performance balancing of containers based on computing power sufficiency rate, reduces the impact of host node load on container running performance, and improves the consistency of container running performance.

[0037] In some embodiments of this disclosure, the computing power satisfaction rate of a container can be obtained through the following process: obtaining first duration information of the container's process in the run queue; obtaining second duration information of the hyperthread corresponding to the container during process execution; and calculating the container's computing power satisfaction rate based on the first and second duration information.

[0038] The run queue described above manages processes in a runnable state, scheduling all processes to ensure they are executed in a specific order. Processes within a container wait in the run queue when not in execution, and the initial duration information of that process reflects its CPU usage. A container can contain one or more processes. In the case of multiple processes within a container, the initial duration information can be determined based on the CPU usage of each process within the container.

[0039] Containers rely on the kernel to run. When the kernel supports hyper-threading, a kernel is divided into two logical cores, each capable of running a hyper-thread. The other hyper-thread on the kernel besides the one currently hosting the container is the peer hyper-thread. The aforementioned second duration information reflects the CPU usage of the peer hyper-thread while the container's process is using the CPU, thus indicating whether the container's process exclusively uses the CPU or shares it with the peer hyper-thread.

[0040] The container's computing power satisfaction rate is calculated based on the first duration information of the container process and the second duration information of the peer's hyper-thread. This fully considers the resource contention between the peer's hyper-thread and the container process, a hardware-level interference factor. The first duration information of the container process and the second duration information of the peer's hyper-thread are affected by the kernel scheduler's software scheduling; therefore, the calculation of the computing power satisfaction rate also incorporates factors at the system software scheduling level. Because the calculation of the computing power satisfaction rate fully considers the influence of both the hyper-thread hardware level and the system scheduling software level, the calculated computing power satisfaction rate is highly accurate and can accurately measure the actual computing power level obtained by the container under the condition of resource contention by the peer's hyper-thread.

[0041] In some embodiments, the first duration information may include the waiting time of the container's process in the run queue and the first actual runtime of the process; the second duration information may include the idle time of the peer hyperthread and the second actual runtime during the execution of the container process. The specific calculation process of the container's computing power satisfaction rate may include: calculating a first sum of the waiting time and the first actual runtime of the container's process; calculating the product of a preset ratio and the second actual runtime, where the preset ratio characterizes the proportion of the kernel usage time of the process in the container within the total kernel usage time shared by the process and the peer hyperthread; calculating a second sum of the product and the idle time of the peer hyperthread; and calculating the ratio of the second sum to the first sum, using this ratio as the container's computing power satisfaction rate.

[0042] The waiting time is the duration from when a process in the container enters the run queue to when it is dequeued. The first actual runtime is the cumulative execution time of the processes in the container. A container can contain one or more processes. When there are multiple processes in a container, the aforementioned waiting time can be the sum of the waiting times of all processes in the container while they are in the run queue, and the aforementioned first actual runtime can be the sum of the cumulative execution time of all processes in the container.

[0043] The idle time of the peer hyperthread is the time during which the container's process is executing while the peer hyperthread has no tasks to execute. The second actual runtime of the peer hyperthread is the time during which the container's process is executing and the peer hyperthread also has tasks to execute.

[0044] The waiting time of a process within a container is the time the process waits for runtime resources. The first actual runtime is equivalent to the time the process in the container actually takes to acquire runtime resources and execute. The first sum is the total time the process in the container spends waiting for resources and acquiring and executing them.

[0045] In some embodiments, the aforementioned preset ratio can be a pre-configured ratio, which can be pre-set in the host node or pre-set in the management node and then distributed to the host node by the management node. In this embodiment, the preset ratio can be 0.65, 0.7, 0.75, etc. The embodiments of this disclosure do not limit the specific value of the preset ratio, and it can be set according to the needs in actual applications.

[0046] In other embodiments, the preset ratio may also be determined by the host node based on relevant information about the container. This relevant information may include, but is not limited to, the container's priority, the user level of the user owning the container, the application level of the application within the container, and the number of processes within the container. As an example, the host node may perform a weighted percentage calculation on multiple relevant information about the container and use the resulting value as the aforementioned preset ratio.

[0047] The preset ratio is determined based on relevant information about the container, which dynamically determines the preset ratio in combination with the actual situation of the container. This improves the accuracy of the preset ratio in representing the proportion of the time the container process uses the kernel in the total time that the process and the peer hyperthread use the kernel together, and thus helps to improve the accuracy of the final calculated computing power satisfaction rate of the container.

[0048] The second actual runtime of the peer hyperthread is the time during which the peer hyperthread performs tasks while the container's process is executing. Therefore, during this second actual runtime, the container's process and the peer hyperthread share the kernel's computing resources. In other words, the second actual runtime is equivalent to the total time that the container's process and the peer hyperthread use the kernel together. Therefore, calculating the product of the preset ratio and the second actual runtime gives us the equivalent of the actual time the container's process uses the kernel, or the effective usage time of the container's process using the kernel's computing resources.

[0049] The idle time of the peer hyperthread is the period during which the peer hyperthread has no tasks to execute while the container's process is running. Therefore, during this idle time, the container's process exclusively enjoys kernel computing resources. Thus, the second sum of the above product and this idle time is calculated. This second sum is equivalent to the sum of the time the container's process exclusively enjoys kernel computing resources and the effective usage time of the container's process using kernel computing resources. Alternatively, the second sum can be understood as the total effective usage time of the container's process using kernel computing resources.

[0050] The ratio of the second sum to the first sum yields the container's computing power satisfaction rate. This rate is equivalent to the ratio between the total time the container effectively uses kernel computing resources and the total time a process within the container waits for resources and acquires and executes them. Therefore, the computing power satisfaction rate accurately represents the ratio between the actual computing power obtained by the container and the computing power required by the container, and accurately reflects the actual computing power level obtained by the container.

[0051] During the aforementioned idle time of the peer hyperthread, the peer hyperthread is idle while the container process is executing, allowing the container to exclusively utilize kernel resources. However, during the second actual runtime of the peer hyperthread, the peer hyperthread is executing a task while the container process is also executing. Therefore, the container process and the peer hyperthread share kernel resources, resulting in resource contention. The container's compute fulfillment rate is calculated based on the container process's waiting time and first actual runtime, as well as the peer hyperthread's idle time and second actual runtime. This fully considers the resource contention factor between the peer hyperthread and the container process, a hardware-level interference factor. Furthermore, the container process's waiting time and first actual runtime, along with the peer hyperthread's idle time and second actual runtime, are affected by the kernel scheduler's software scheduling; therefore, the compute fulfillment rate calculation also incorporates system software scheduling factors. The calculation of computing power sufficiency rate fully considers the influence factors of hyper-threading hardware and system scheduling software, so the calculated computing power sufficiency rate is highly accurate and can accurately measure the actual computing power level obtained by the container in the presence of resource competition from other hyper-threading.

[0052] The method described above for calculating container computing power sufficiency is simple, computationally inexpensive, and highly efficient. Furthermore, it fully considers the hardware impact of hyper-threading on the peer end, as well as the system software scheduling impact of the container's local and peer hyper-threading. This covers the software and hardware-level effects on the computing power available to the container on host nodes at various load levels, enabling accurate detection of the container's computing power. Moreover, using this accurate metric for subsequent computing power adjustment improves the accuracy of this adjustment, helping to regulate the container's computing power level on host nodes at different load levels to a smaller fluctuation range and enhancing the consistency of computing power obtained by the container across different load levels.

[0053] After a container is started on the host node, its computing power satisfaction rate is detected using the methods described in the above embodiments, and then it is determined whether the container's computing power satisfaction rate meets preset conditions. In some implementations, the relationship between the container's computing power satisfaction rate and a preset satisfaction rate range can be determined. If the container's computing power satisfaction rate is within the preset satisfaction rate range, it is determined that the computing power level obtained by the container is already at the required baseline level, and therefore no computing power adjustment is performed on the container. If it is determined that the container's computing power satisfaction rate is not within the preset satisfaction rate range, it is determined that the computing power level obtained by the container does not meet the required baseline level, and therefore computing power adjustment is required to bring the container's computing power level to the baseline level. In other implementations, it is determined whether the container's computing power satisfaction rate is equal to the preset satisfaction rate. If yes, no computing power adjustment is performed on the container. If no, computing power adjustment is required for the container.

[0054] Specifically, if the computing power sufficiency rate of the container does not meet the preset conditions, the hyper-threading resource quota awareness interface of the kernel on which the container depends is called to modify the hyper-threading computing power ratio of the container so that the computing power sufficiency rate of the container changes to meet the preset conditions; the hyper-threading computing power ratio is used to characterize the proportion of the container's runtime when calculating the kernel's runtime.

[0055] The hyper-threading hashrate ratio is a kernel parameter. By adjusting the hyper-threading hashrate ratio, the kernel's resource scheduler can adjust the core weight ratio of hyper-threads. A higher hyper-threading hashrate ratio results in a lower core weight ratio for hyper-threads. The core weight ratio represents the weight of kernel runtime required for hyper-thread execution. A higher core weight ratio indicates that the hyper-thread requires more kernel runtime, thus requiring a relatively smaller virtual runtime for the hyper-thread in the kernel's resource scheduler, allowing it to be selected for execution more frequently. Therefore, to give the hyper-thread containing the container more runtime, the hyper-threading hashrate ratio can be lowered. Conversely, to give the hyper-thread containing the container less runtime, the hyper-threading hashrate ratio can be increased.

[0056] In other words, there is a certain correlation between the hyper-threaded computing power ratio and the actual computing power obtained by the container. The computing power satisfaction rate of the container will change with the change of the hyper-threaded computing power ratio. Specifically, the higher the hyper-threaded computing power ratio, the lower the computing power satisfaction rate, and the lower the hyper-threaded computing power ratio, the higher the computing power satisfaction rate.

[0057] When the container's computing power fulfillment rate does not meet preset conditions, the kernel's hyper-threading resource quota awareness mechanism is used to modify the hyper-threading computing power ratio. This causes the core weight ratio of hyper-threading to change with the hyper-threading computing power ratio, thereby altering the virtual runtime of hyper-threading in the resource scheduler. This changes the resource scheduler's scheduling operations for hyper-threading, ultimately altering the hyper-threading runtime. Consequently, the runtime of the container running via hyper-threading, as well as the idle and runtime of the peer hyper-threading, will also change. The computing power fulfillment rate of the container, calculated based on the container's runtime and the idle and runtime of the peer hyper-threading, will also change. By using the kernel's hyper-threading resource quota awareness interface to achieve real-time and accurate adjustment of container computing power allocation, the performance fluctuations of applications within the container can be controlled within a certain range, resulting in better application performance consistency.

[0058] In some embodiments of this disclosure, the process of changing the computing power satisfaction rate of a container to meet a preset condition may include: modifying the hyper-threaded computing power ratio corresponding to the container according to a preset adjustment step size; obtaining the computing power satisfaction rate of the container after modifying the hyper-threaded computing power ratio; and, if the computing power satisfaction rate after modifying the hyper-threaded computing power ratio still does not meet the preset condition, returning to the step of modifying the hyper-threaded computing power ratio corresponding to the container according to a preset adjustment step size and repeating the process until the computing power of the container meets the preset condition.

[0059] In this embodiment, a range of values ​​for the hyper-threaded computing power ratio is pre-configured in the host node. This range can be [100, 200], [100, 250], [100, 300], etc., and the preset adjustment step size can be 10, 15, or 20, etc. This embodiment does not limit the specific values ​​of the above-mentioned range and the preset adjustment step size.

[0060] The system invokes the hyper-threading resource quota awareness interface of the kernel upon which the container depends for adjustment, employing a corresponding adjustment algorithm to adjust according to a preset adjustment step size. This adjustment algorithm may include, but is not limited to, AIAD (Addictive-Increase / Adaptive-Decrease), AIMD (Addictive-Increase / Multiplicative-Decrease), and PID (Proportional-Integral-Derivative) algorithms. The choice of adjustment algorithm and the required preset adjustment step size can be uniformly distributed from the management node to each compute node, or it can be pre-configured on the compute nodes.

[0061] After the hyper-threading hashrate ratio changes, the core weight ratio of hyper-threading in the kernel's resource regulator will change accordingly. This will then alter the scheduling of the container's local and remote hyper-threads by the resource regulator. The resulting container hashrate satisfaction rate after modifying the hyper-threading hashrate ratio will differ from the previously obtained rate. Based on this new hashrate satisfaction rate, the container's hashrate satisfaction rate is again checked to see if it meets the preset conditions. If it does, it indicates that the container's hashrate level has been adjusted to the baseline level. If the modified container hashrate satisfaction rate still does not meet the preset conditions, the hyper-threading hashrate ratio continues to be modified according to the preset adjustment step size until the container's hashrate satisfaction rate meets the preset conditions.

[0062] According to a preset adjustment step size, the hyper-threaded computing power ratio is gradually adjusted, thereby progressively bringing the container's computing power satisfaction rate closer to the value that meets the preset conditions, ultimately achieving the desired result. This achieves dynamic adjustment of the container's computing power satisfaction rate with a high degree of fine-grainedness. It can accurately adjust the container's computing power satisfaction rate to a preset satisfaction rate range with a small interval length, or to a specific preset satisfaction rate. The interval length refers to the difference between the upper and lower limits of the preset satisfaction rate range. In other words, this embodiment can maintain the actual computing power level obtained by the container within a small fluctuation range, or even adjust the container's computing power level to a fixed level, thereby ensuring relatively stable application performance for users within the container.

[0063] This disclosure utilizes the kernel's hyper-threading resource quota awareness mechanism to adjust the hyper-threading computing power ratio, thereby regulating the container's computing power fulfillment rate. In this mechanism, a resource limiting operation is triggered when the actual time the container's hyper-thread uses kernel runtime resources is greater than or equal to the hyper-threading quota threshold. The sum of the idle time of the peer hyper-thread and its second actual runtime, as mentioned earlier, represents the actual time the container's hyper-thread uses kernel runtime resources. The resource limiting operation allows the kernel's resource scheduler to schedule the peer hyper-thread to use kernel runtime resources, while the container's local hyper-thread suspends execution and releases resources.

[0064] To make it easier to understand, the formula is used to represent the actual time that the hyperthread containing the container in the relevant technology uses kernel computing resources: OnCpu = SibIdle + SibBusy. (1)

[0065] Where SibIdle is the idle time of the peer hyperthread, and SibBusy is the second actual runtime of the peer hyperthread. In fact, the formula should be: OnCpu = SibIdle * ht_ratio / 100 + SibBusy. (2)

[0066] Where ht_ratio is the hyper-threading computing power ratio. In related technologies, the hyper-threading computing power ratio is set to 100, indicating that when the hyper-thread on the other end is idle, the hyper-thread on the local end where the container resides exclusively occupies the kernel's computing power resources. Therefore, the above formula can be simplified to the above formula (1).

[0067] This embodiment adjusts the hyper-threading computing power ratio through a hyper-threading resource quota awareness mechanism. The lower limit of the hyper-threading computing power ratio is 100, for example, its value range can be [100, 200]. Therefore, in formula (2), ht_ratio / 100≥1. Thus, the hyper-threading computing power ratio ht_ratio will amplify the cumulative speed of the SibIdle part, so that the actual time OnCpu used by the hyper-thread where the container is located reaches the quota threshold more quickly, thereby triggering the resource limit operation of the resource regulator more quickly.

[0068] On host nodes with low load levels, the actual computing power obtained by containers is significantly higher than that obtained by the same containers on host nodes with high load levels. This results in significantly lower performance for containers on host nodes with high load levels compared to those on host nodes with low load levels, leading to substantial performance differences due to varying load levels. This embodiment addresses this by increasing the hyper-threading computing power ratio (ht_ratio) on host nodes with low load levels through a hyper-threading resource quota awareness mechanism. Increasing ht_ratio according to the formula allows OnCpu to more quickly meet the condition of being greater than or equal to the quota threshold, triggering resource limiting operations by the resource scheduler and reducing the computing power obtained by containers on host nodes with low load levels. By reducing the gap between the computing power obtained by containers on host nodes with low and high load levels, the performance differences of containers running on host nodes with different load levels are minimized. Furthermore, when the resource scheduler's resource limitation operation is triggered, the computing resources released by the local hyperthread where the resource scheduler schedules the container can be used by other applications, and there is no loss of resources for the host node as a whole.

[0069] In some embodiments of this disclosure, if the computing power satisfaction rate of the container is less than the minimum satisfaction rate corresponding to the condition, then the hyper-threaded computing power ratio corresponding to the container is reduced by a preset adjustment step size. If the computing power satisfaction rate of the container is greater than the maximum satisfaction rate corresponding to the preset condition, then the hyper-threaded computing power ratio corresponding to the container is increased by a preset adjustment step size.

[0070] When the preset conditions include a preset satisfaction rate range, the minimum satisfaction rate is the lower limit of the preset satisfaction rate range, and the maximum satisfaction rate is the upper limit of the preset satisfaction rate range. When the preset conditions include a specific preset satisfaction rate, both the minimum and maximum satisfaction rates refer to that preset satisfaction rate.

[0071] When the container's computing power satisfaction rate is less than the minimum satisfaction rate mentioned above, the container's computing power satisfaction rate needs to be increased. At this time, the hyper-threaded computing power ratio corresponding to the container is reduced by the preset adjustment step size. As can be seen from the above formula (2), after modification, the hyper-threaded computing power ratio ht_ratio decreases, and the value of OnCpu will decrease, making it more difficult to reach the condition of being greater than or equal to the quota threshold, that is, it is more difficult to trigger resource limit operations. In this way, the local hyper-thread where the container is located can have a longer kernel computing power resource usage time, and the container's computing power satisfaction rate will increase. By gradually reducing the hyper-threaded computing power ratio according to the preset adjustment step size, the container's computing power satisfaction rate can be adjusted to be greater than or equal to the minimum satisfaction rate.

[0072] When the container's computing power satisfaction rate exceeds the maximum satisfaction rate mentioned above, the container's computing power satisfaction rate needs to be lowered. At this time, the container's hyper-threaded computing power ratio is increased by a preset adjustment step size. As can be seen from formula (2) above, after modification, the hyper-threaded computing power ratio ht_ratio increases, thus increasing the value of OnCpu, making it easier to reach the condition of being greater than or equal to the quota threshold, meaning it's easier to trigger resource limitation operations. This shortens the time the container's local hyper-thread uses kernel computing power resources, reducing the container's computing power satisfaction rate. By gradually increasing the hyper-threaded computing power ratio according to the preset adjustment step size, the container's computing power satisfaction rate can be adjusted to be less than or equal to the maximum satisfaction rate mentioned above.

[0073] When the load level of the host node is low, the hyperthreads on the container's counterpart are more likely to be idle. Therefore, the container actually obtains more computing power, and the computing power quality of the container is better than that of the same specification container on a host node with a higher load level. At this time, the container's computing power satisfaction rate is usually greater than the maximum satisfaction rate mentioned above. This embodiment of the disclosure gradually increases the hyperthread computing power ratio, so that the duration of the container's use of kernel computing power resources can reach the quota threshold more quickly, thereby triggering the resource scheduler's resource limiting operation more quickly, shortening the duration of the container's use of kernel computing power resources, thereby reducing the container's computing power satisfaction rate, and thus adjusting the container's computing power satisfaction rate to meet the preset conditions.

[0074] When the load level of the host node increases, the hardware and software interference experienced by the container itself may be close to or exceed the interference experienced by the same type of container on other host nodes. At this time, the computing power satisfaction rate of the container is low, usually less than the minimum satisfaction rate mentioned above. This embodiment of the present disclosure gradually reduces the hyper-threaded computing power ratio, so that the duration of the container's use of kernel computing power resources can reach the quota threshold more slowly, making it more difficult to trigger the resource scheduler's resource limit operation, thereby extending the duration of the container's use of kernel computing power resources, thereby improving the computing power satisfaction rate of the container, and thus adjusting the container's computing power satisfaction rate to meet the preset conditions.

[0075] Based on the relationship between the container's computing power fulfillment rate and the minimum and maximum fulfillment rates corresponding to preset conditions, the hyper-threaded computing power ratio is adjusted in a targeted manner. Regardless of whether the host node's load level is high or low, the container's computing power fulfillment rate can be adjusted to meet the preset conditions. Moreover, the adjustment is done step-by-step according to preset adjustment steps, making the adjustment operation very precise. This prevents the container's computing power from changing too much instantaneously during the adjustment process, so that users do not noticeably experience performance changes in the application. It can adjust the container's computing power level to a baseline level without affecting user experience, reducing the impact of the host node's load level on the stability of container operation performance and improving the consistency of container operation performance.

[0076] In some embodiments of this disclosure, a pre-constructed performance consistency model is also provided to characterize the mapping relationship between node computing power utilization and the hyper-threaded computing power ratio. As an example, the pre-constructed performance consistency model can be in tabular form, which may include node computing power utilization and the corresponding hyper-threaded computing power ratio, or it may include a range of node computing power utilization and the corresponding hyper-threaded computing power ratio. In another example, the pre-constructed performance consistency model can also be in the form of a function formula, where the dependent variable is node computing power utilization and the independent variable is the hyper-threaded computing power ratio, or the dependent variable is the hyper-threaded computing power ratio and the independent variable is node computing power utilization. Yet another example is that the pre-constructed performance consistency model can also be a curve showing the relationship between node computing power utilization and the hyper-threaded computing power ratio, reflecting the relationship between the hyper-threaded computing power ratio and the node computing power utilization.

[0077] The aforementioned preset performance consistency model can be implemented on host nodes with different load levels by adjusting the hyper-threading ratio to adjust the container's computing power sufficiency to meet preset conditions. For each host node, the node computing power utilization rate and the hyper-threading ratio when the container's computing power sufficiency is adjusted to meet the preset conditions are obtained. The node computing power utilization rate characterizes the load level of the computing node; a higher node computing power utilization rate indicates a higher node load level, and a lower node computing power utilization rate indicates a lower node load level.

[0078] By adjusting container computing power across a large number of host nodes with varying load levels, multiple sets of data can be obtained, each including node utilization and the corresponding hyper-threaded computing power ratio. Based on these multiple sets of data, a pre-defined performance consistency model is derived. The modeling process can involve constructing a mapping table between node utilization and the hyper-threaded computing power ratio, a functional relationship between the two, or a curve illustrating their relationship.

[0079] After obtaining the preset performance consistency model using the above methods, it can be pre-configured on the host node. Alternatively, it can be configured on the management node in the cluster, and then uniformly distributed to all compute nodes in the cluster by the management node.

[0080] In some embodiments of this disclosure, before the host node adjusts the container's computing power through steps 101 and 102, it can first initialize the container's computing power configuration based on a preset performance consistency model. Specifically, this may include: obtaining the current node computing power utilization rate of the computing node to which the container belongs; determining the target hyper-threaded computing power ratio corresponding to the current node computing power utilization rate through the preset performance consistency model; and calling the hyper-threaded resource quota awareness interface of the kernel on which the container depends to set the hyper-threaded computing power ratio corresponding to the container to the target hyper-threaded computing power ratio.

[0081] The aforementioned preset performance consistency model can be a pre-configured preset performance consistency model obtained locally from the host node, or it can be a preset performance consistency model sent by the management node or other computing nodes.

[0082] The above node computing power utilization rate is the overall node computing power utilization rate of the compute node to which the container belongs. You can first obtain the CPU utilization rate of each core on the compute node, and then calculate the average or median of the CPU utilization rate of each core. Use this average or median as the node computing power utilization rate of the compute node to which the container belongs.

[0083] After obtaining the node computing power utilization rate of the compute node to which the container belongs, the target hyper-threaded computing power ratio corresponding to the current node computing power utilization rate is determined based on this node computing power utilization rate and a preset performance consistency model. As an example, if the preset performance consistency model is a mapping table between node computing power utilization rate and hyper-threaded computing power ratio, the corresponding target hyper-threaded computing power ratio is obtained by looking up the table based on the node computing power utilization rate of this compute node. In another example, if the preset performance consistency model is a functional relationship between node computing power utilization rate and hyper-threaded computing power ratio, the node computing power utilization rate of this compute node is substituted into this functional relationship to calculate the corresponding target hyper-threaded computing power ratio. In yet another example, the preset performance consistency model can be a relationship curve between node computing power utilization rate and hyper-threaded computing power ratio. The coordinates of the node computing power utilization rate of this compute node are located on this relationship curve, and the hyper-threaded computing power ratio at these coordinates is used as the corresponding target hyper-threaded computing power ratio.

[0084] After obtaining the target hyper-threaded computing power ratio using the above method, the kernel's hyper-threaded resource quota awareness interface is called to set the hyper-threaded computing power ratio corresponding to the container to the target hyper-threaded computing power ratio.

[0085] The above process is equivalent to initializing the hyper-threaded computing power ratio of the container using a preset performance consistency model. After this configuration, the container's computing power satisfaction rate will change depending on the target hyper-threaded computing power ratio. Since the preset performance consistency model is modeled by adjusting the container's computing power satisfaction rate to meet preset conditions on host nodes with different load levels, initializing the container's hyper-threaded computing power ratio based on the preset performance consistency model can make the container's computing power satisfaction rate approach the preset conditions, or even directly adjust the container's computing power satisfaction rate to meet the preset conditions. Even if the container's computing power satisfaction rate does not meet the preset conditions after initialization, the difference between the container's computing power satisfaction rate and meeting the preset conditions will be very small. Thus, by adjusting the hyper-threaded computing power ratio through steps 101 and 102 above, the container's computing power satisfaction rate can be easily adjusted to meet the preset conditions. Therefore, initializing the container's hyper-threaded computing power ratio using a preset performance consistency model can reduce the time spent adjusting the container's computing power satisfaction rate to meet the preset conditions, greatly improving the efficiency of container computing power adjustment.

[0086] In some embodiments of this disclosure, containers run within a service cluster, such as a Kubernetes cluster. In this scenario, the cluster may contain management nodes and compute nodes, and containers may run on compute nodes. The management node is responsible for managing each compute node. Configuration information can be pre-uploaded to the management node, including at least one of the aforementioned preset performance consistency model and preset conditions. The management node then distributes this configuration information to each compute node.

[0087] The compute node receives the configuration information sent by the management node and stores it. For preset performance consistency models and conditions not included in this configuration information, they can also be pre-configured in the compute node.

[0088] By having the management node uniformly distribute the above configuration information to the compute nodes, consistency in container computing power adjustment configuration can be achieved across compute nodes in the cluster. This ensures that containers running on any compute node in the cluster can obtain relatively consistent computing power adjustment capabilities, thereby improving the performance consistency of containers running on different compute nodes in the cluster.

[0089] In some embodiments of this disclosure, the client sends a container creation request to the management node. This creation request includes the container's configuration file. The client can send the creation request directly to the management node, or it can first send the request to the edge node closest to the client, which then forwards it to the management node. The container's configuration file includes configuration data defining the container image, storage volume, environment variables, ports, services, etc. After receiving the creation request, the management node can select a compute node from the compute nodes in the cluster using a load balancing strategy, and then forward the creation request to that compute node.

[0090] The compute node receives the container creation request sent by the management node. Using the method described in the previous embodiment, it sets the hyper-threaded computing power ratio corresponding to the container to the target hyper-threaded computing power ratio based on the preset performance consistency model. Then, it starts the container based on the container's configuration file and performs step 101 to obtain the container's computing power satisfaction rate, thereby adjusting the container's computing power satisfaction rate to within the preset satisfaction rate range.

[0091] To facilitate understanding of the scheme for adjusting computing power by combining a preset performance consistency model with the kernel's hyper-threading resource quota awareness mechanism, the following explanation is provided with reference to the accompanying diagram. Figure 2 shows a flowchart of the container's computing power adjustment method.

[0092] S1: The management node sends a preset performance consistency model to the compute node.

[0093] S2: The management node receives a container creation request from the client and sends the creation request to the compute node.

[0094] Steps S1 and S2 can be performed simultaneously or in any order.

[0095] S3: The compute node receives and stores the preset performance consistency model, and receives the creation request of the above container.

[0096] S4: The compute node obtains the current compute node's compute power utilization rate, determines the target hyper-threaded compute power ratio corresponding to the compute power utilization rate of the node through a preset performance consistency model, and modifies the hyper-threaded compute power ratio corresponding to the current kernel hyper-thread to the target hyper-threaded compute power ratio.

[0097] S5: The compute node starts the container based on the container's creation request, which includes the container's configuration file.

[0098] S6: The compute node obtains the computing power satisfaction rate of the container.

[0099] S7: The computing node determines whether the computing power satisfaction rate of the container meets the preset conditions. If yes, the operation ends; otherwise, the operation of step S8 is executed.

[0100] S8: The compute node calls the hyper-threading resource quota awareness interface of the kernel on which the container depends, modifies the hyper-threading computing power ratio corresponding to the container according to the preset adjustment step size, and then returns to execute step S6.

[0101] The process shown in Figure 2 is only an example. In practical applications, the solutions of the various embodiments of this disclosure can be reasonably combined to obtain a variety of different computing power adjustment processes.

[0102] Before starting the container, the hyper-threading ratio is initialized based on a preset performance consistency model. Then, the container is started. Once started, the scheduling between the container's local hyper-thread and its corresponding peer hyper-thread is influenced by the initialized hyper-threading ratio. Therefore, within a short time after the container starts, its computing power sufficiency will reach the sufficiency rate corresponding to the initialized hyper-threading ratio. This sufficiency rate will be very close to meeting the preset conditions, and may even meet them. Therefore, initializing the hyper-threading ratio based on the preset performance consistency model before starting the container can further shorten the time spent adjusting the container's computing power and improve adjustment efficiency.

[0103] In some embodiments of this disclosure, the container's configuration file from the client may include indication information for enabling the computing power adjustment function; alternatively, the container's configuration file may not include this indication information. This indication information can be a preset string, such as 0011, 0101, etc. After receiving the container's configuration file, the compute node first checks whether the configuration file contains the indication information. If it does not contain the indication information, the computing power of the container is not adjusted using the method provided in the embodiments of this disclosure. If it is determined that the container's configuration file contains the indication information, the computing power of the container is adjusted using the method provided in the embodiments of this disclosure.

[0104] The container configuration file carries instructions to enable the computing power adjustment function, providing users with a service to decide whether to adjust the computing power of the container. This can meet users' personalized needs for the computing power of the container and better provide containerized services for users' applications.

[0105] In some embodiments of this disclosure, considering that the load level of the host node is dynamically changing, the computing power sufficiency rate of the container can be periodically checked to see if it meets preset conditions. If the preset conditions are not met, the computing power adjustment method provided in this disclosure is used to adjust the computing power of the container, including adjustment through a preset performance consistency model and adjustment by calling the kernel's hyper-threading resource quota awareness interface. This enables continuous detection and dynamic adjustment of the container's computing power sufficiency rate, effectively maintaining the container's computing power sufficiency rate at the preset conditions for a long time, thereby improving the stability of the actual computing power obtained by the container and improving the consistency of application performance in the container.

[0106] The method provided in this disclosure for adjusting the computing power of containers enables users' applications to achieve relatively stable application performance on any host node at any time. Testing has shown that the method can keep the performance of containers of the same specifications running on host nodes with different load levels within 10% of the baseline performance fluctuation. This disclosure is suitable for performance consistency adjustment of any type of computing task, and is particularly suitable for performance consistency adjustment of compute-intensive tasks.

[0107] Containers of the same specifications can refer to containers with identical specifications in terms of CPU and memory resources, storage, network, environmental variables, ports, etc. The performance of the containers mentioned in the embodiments of this disclosure may include, but is not limited to, the container's CPU utilization and response time.

[0108] In this embodiment, the computing power satisfaction rate is used to measure the actual computing power level obtained by the container. When the container's computing power satisfaction rate does not meet the preset conditions, the kernel's hyper-threading resource quota awareness interface is called to adjust the container's computing power satisfaction rate to meet the preset conditions. This achieves dynamic adjustment of the container's computing power satisfaction rate, thereby controlling the performance fluctuations of the application in the container within a certain range. This ensures that the computing power obtained by the container on any host node with a load level is within a stable range, reducing the performance differences of containers on host nodes with different load levels, reducing the impact of host node load on container performance, and improving the consistency of container performance. Furthermore, the container's computing power satisfaction rate can be initially adjusted using a preset performance consistency model. Combined with the kernel's hyper-threading resource quota awareness mechanism to adjust the container's computing power, the container's computing power satisfaction rate can be adjusted to the preset satisfaction rate range more quickly, improving the efficiency of computing power adjustment.

[0109] Some embodiments of this disclosure also provide a container computing power adjustment algorithm. The execution subject of this method can be a management node in a service cluster, which can be a cluster composed of multiple physical servers and / or multiple virtual machines, or the service cluster can be a Kubernetes cluster. Figure 3 shows a flowchart of the container computing power adjustment method according to an embodiment of this disclosure. As shown in Figure 3, the method can include steps 201-203.

[0110] Step 201: Send configuration information to each computing node in the cluster. The configuration information includes at least one of a preset performance consistency model and preset conditions. The preset performance consistency model is used to characterize the mapping relationship between the node's computing power utilization rate and the hyper-threaded computing power ratio.

[0111] Step 202: Receive a container creation request sent by the client, which carries the container's configuration file.

[0112] Step 203: Send the configuration file to the target compute node, which can be any compute node in the cluster, so that the target compute node can start the container based on the configuration file and, if the container's computing power satisfaction rate does not meet the preset conditions, call the hyper-threaded resource quota awareness interface of the kernel on which the container depends to adjust the container's computing power satisfaction rate based on the configuration information.

[0113] For preset performance consistency models and preset conditions not included in the configuration information, they can be pre-configured in each computing node. The meaning and purpose of the aforementioned preset performance consistency models and preset conditions have been introduced in the previous embodiments and will not be repeated in this embodiment.

[0114] The management node distributes configuration information to each compute node in the cluster, enabling the compute nodes to use the configuration information to meet preset conditions for the computing power of the containers.

[0115] By having the management node uniformly distribute the aforementioned configuration information to the compute nodes, consistency in container computing power adjustment configurations across all compute nodes in the cluster can be achieved. This ensures that containers running on any compute node in the cluster can obtain relatively consistent computing power adjustment capabilities, thereby improving the performance consistency of containers running on different compute nodes within the cluster. Furthermore, using computing power fulfillment rate to measure the actual computing power level obtained by the container, if the container's computing power fulfillment rate does not meet preset conditions, it will be adjusted to meet those conditions. This dynamic adjustment of the container's computing power fulfillment rate allows performance fluctuations of the application within the container to be controlled within a certain range. This ensures that the computing power obtained by the container on any host node with a certain load level remains within a stable range, thereby reducing the performance differences of containers on host nodes with different load levels, minimizing the impact of host node load on container performance, and improving the consistency of container performance.

[0116] Some embodiments of this disclosure also provide a container computing power adjustment system. Referring to Figure 4, which shows a schematic diagram of a container computing power adjustment system, the system includes: a management node and a compute node; the management node is used to send configuration information to the compute node and to send a container creation request to the compute node; the configuration information includes at least one of a preset performance consistency model and preset conditions; the preset performance consistency model is used to characterize the mapping relationship between the node's computing power utilization rate and the hyper-threaded computing power ratio; the compute node is used to start the container based on the configuration file included in the container creation request; obtain the container's computing power satisfaction rate; if the container's computing power satisfaction rate does not meet the preset conditions, based on the computing power satisfaction rate and the configuration information, call the hyper-threaded resource quota awareness interface of the kernel on which the container depends to adjust the container's computing power satisfaction rate; the computing power satisfaction rate is used to characterize the ratio between the computing power allocated to the container and the computing power required by the container.

[0117] A cluster can have multiple compute nodes; Figure 4 schematically illustrates one compute node. Each compute node can run one or more containers; Figure 4 schematically illustrates three containers within a compute node.

[0118] The specific operational details of the management node and the compute node have been described in the previous embodiments and will not be repeated here.

[0119] In this embodiment, the management node uniformly distributes the aforementioned configuration information to the compute nodes, achieving consistency in container computing power adjustment configuration across all compute nodes in the cluster. This ensures that containers running on any compute node in the cluster can obtain relatively consistent computing power adjustment capabilities, thereby improving the performance consistency of containers running on different compute nodes within the cluster. Furthermore, a computing power fulfillment rate is used to measure the actual computing power level obtained by the container. When the container's computing power fulfillment rate does not meet a preset condition, it is adjusted to meet that condition. This achieves dynamic adjustment of the container's computing power fulfillment rate, thereby controlling the performance fluctuations of the application within the container within a certain range. This ensures that the computing power obtained by the container on any host node with a certain load level remains within a stable range, reducing the performance differences of containers on host nodes with different load levels, minimizing the impact of host node load on container performance, and improving the consistency of container performance.

[0120] Corresponding to the application scenarios and methods provided in the embodiments of this disclosure, the embodiments of this disclosure also provide a container computing power adjustment device. Referring to FIG5, the device includes: an acquisition module 301, used to acquire the computing power satisfaction rate of the container, wherein the computing power satisfaction rate is used to characterize the ratio between the computing power allocated to the container and the computing power required by the container; and a computing power adjustment module 302, used to adjust the computing power satisfaction rate of the container by calling the hyper-threaded resource quota awareness interface of the kernel on which the container depends when the computing power satisfaction rate does not meet the preset conditions.

[0121] The acquisition module 301 is used to acquire the first duration information of the container's process in the run queue; acquire the second duration information of the hyperthread of the counterpart of the container during the process execution; and determine the computing power satisfaction rate of the container based on the first duration information and the second duration information.

[0122] The first duration information includes the waiting time of the process in the run queue and the first actual runtime of the process; the second duration information includes the idle time and the second actual runtime of the peer hyperthread during the process's operation; the acquisition module 301 is used to calculate the first sum of the process's waiting time and the first actual runtime; calculate the product of a preset ratio and the second actual runtime, where the preset ratio is used to characterize the proportion of the process's kernel usage time in the total kernel usage time shared by the process and the peer hyperthread; calculate the second sum of the product and the idle time of the peer hyperthread; calculate the ratio of the second sum to the first sum, and use the ratio as the container's computing power satisfaction rate.

[0123] The computing power adjustment module 302 is used to call the hyper-threading resource quota awareness interface of the kernel on which the container depends, modify the hyper-threading computing power ratio corresponding to the container, and change the computing power satisfaction rate of the container to meet the preset conditions; the hyper-threading computing power ratio is used to characterize the proportion of the container's runtime when calculating the kernel's runtime.

[0124] The computing power adjustment module 302 is used to modify the hyper-threaded computing power ratio corresponding to the container according to a preset adjustment step size; obtain the computing power satisfaction rate of the container after modifying the hyper-threaded computing power ratio; and, if the computing power satisfaction rate after modifying the hyper-threaded computing power ratio still does not meet the preset conditions, return to the step of modifying the hyper-threaded computing power ratio corresponding to the container according to the preset adjustment step size and execute it in a loop until the computing power satisfaction rate of the container meets the preset conditions.

[0125] The computing power adjustment module 302 is used to subtract a preset adjustment step size from the hyper-threaded computing power ratio of the container if the computing power satisfaction rate of the container is less than the minimum satisfaction rate corresponding to the preset condition; or, if the computing power satisfaction rate of the container is greater than the maximum satisfaction rate corresponding to the preset condition, to add a preset adjustment step size to the hyper-threaded computing power ratio of the container.

[0126] Before obtaining the container's computing power utilization rate, the process also includes: an initialization adjustment module, used to obtain the current node computing power utilization rate of the computing node to which the container belongs; determining the target hyper-threaded computing power ratio corresponding to the current node computing power utilization rate through a preset performance consistency model; wherein, the preset performance consistency model is used to characterize the mapping relationship between the node computing power utilization rate and the hyper-threaded computing power ratio; the node computing power utilization rate is used to characterize the load level of the computing node; and calling the hyper-threaded resource quota awareness interface of the kernel on which the container depends, setting the hyper-threaded computing power ratio corresponding to the container to the target hyper-threaded computing power ratio.

[0127] Before determining the target hyper-threaded computing power ratio corresponding to the current node computing power utilization rate through the preset performance consistency model, the device further includes: a receiving module, used to receive configuration information sent by the management node, the configuration information including at least one of the preset performance consistency model and preset conditions.

[0128] Before obtaining the container's computing power utilization rate, the aforementioned receiving module is further configured to receive a container creation request sent by the management node, the creation request including the container's configuration file; after determining that the hyper-threaded computing power ratio corresponding to the container is set as the target hyper-threaded computing power ratio, it further includes: a container startup module, configured to start the container based on the configuration file and execute the operation of the obtaining module 301. The target hyper-threaded computing power ratio is used to characterize the hyper-threaded computing power ratio corresponding to the current node computing power utilization rate of the computing node to which the container belongs.

[0129] Before obtaining the computing power satisfaction rate of the container, the device further includes: a determination module, used to determine that the container's configuration file includes indication information for indicating the activation of the computing power adjustment function; and to execute the computing power adjustment process of the container according to the indication information.

[0130] The functions of each module in the apparatus of this embodiment can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.

[0131] Corresponding to the application scenarios and methods provided in the embodiments of this disclosure, the embodiments of this disclosure also provide a container computing power adjustment device, which includes: a sending module, used to send configuration information to each computing node in the cluster, the configuration information including at least one of a preset performance consistency model and preset conditions; the preset performance consistency model is used to characterize the mapping relationship between node computing power utilization and hyper-threaded computing power ratio; a receiving module, used to receive a container creation request sent by a client, the creation request carrying the configuration file of the container; the sending module is used to send the configuration file to a target computing node, the target computing node being any computing node in the cluster, so that the target computing node starts the container based on the configuration file, and if the computing power satisfaction rate of the container does not meet the preset conditions, it calls the hyper-threaded resource quota awareness interface of the kernel on which the container depends based on the configuration information to adjust the computing power satisfaction rate of the container.

[0132] The functions of each module in the apparatus of this embodiment can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.

[0133] Figure 6 is a block diagram of an electronic device used to implement embodiments of the present disclosure. As shown in Figure 6, the electronic device includes a memory 601 and a processor 602. The memory 601 stores a computer program that can run on the processor 602. When the processor 602 executes the computer program, it implements the methods in the above embodiments. The number of memories 601 and processors 602 can be one or more. In a specific implementation, the electronic device may also include a communication interface 603 for communicating with external devices and performing data exchange and transmission.

[0134] In practical implementation, if the memory 601, processor 602, and communication interface 603 are implemented independently, they can be interconnected via a bus to complete communication. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in Figure 6, but this does not indicate that there is only one bus or one type of bus.

[0135] Optionally, in a specific implementation, if the memory 601, processor 602 and communication interface 603 are integrated on a single chip, the memory 601, processor 602 and communication interface 603 can communicate with each other through an internal interface.

[0136] This disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods provided in this disclosure.

[0137] This disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the methods provided in this disclosure.

[0138] This disclosure also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device on which the chip is installed to perform the methods provided in this disclosure.

[0139] This disclosure also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0140] It should be understood that the aforementioned processor can be a CPU (Central Processing Unit), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0141] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0142] In the above embodiments, implementation can be achieved, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this disclosure are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0143] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this disclosure. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0144] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means two or more, unless otherwise explicitly specified.

[0145] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this disclosure includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0146] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0147] It should be understood that various parts of this disclosure can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0148] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0149] The above description is merely an exemplary embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this disclosure, and these should all be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for adjusting the computing power of a container, comprising: Obtain the computing power satisfaction rate of the container, which is used to characterize the ratio between the computing power allocated to the container and the computing power required by the container; In response to the computing power satisfaction rate not meeting the preset conditions, the hyper-threaded resource quota awareness interface of the kernel on which the container depends is invoked to adjust the computing power satisfaction rate.

2. The method according to claim 1, wherein, The acquisition of the container's computing power satisfaction rate includes: Get the first duration information of the container's process in the run queue; Obtain the second duration information of the peer hyperthread corresponding to the container during the process execution; Based on the first duration information and the second duration information, the computing power satisfaction rate of the container is determined.

3. The method according to claim 2, wherein, The first duration information includes the waiting time of the process in the run queue and the first actual runtime of the process; the second duration information includes the idle time and the second actual runtime of the peer hyperthread during the process's execution. Determining the computing power satisfaction rate of the container based on the first duration information and the second duration information includes: Calculate the first sum of the waiting time and the first actual runtime of the process; Calculate the product of the preset ratio and the second actual runtime, whereby the preset ratio is used to characterize the proportion of the time the process uses the kernel in the total time the process and the peer hyperthread jointly use the kernel. Calculate a second sum of the product and the idle time of the peer hyperthread; Calculate the ratio of the second sum to the first sum, and use the ratio as the computing power satisfaction rate of the container.

4. The method according to claim 1, wherein, The step of invoking the hyper-threaded resource quota awareness interface of the kernel on which the container depends to adjust the computing power satisfaction rate includes: The hyper-threading resource quota awareness interface of the kernel on which the container depends is invoked to modify the hyper-threading computing power ratio corresponding to the container, so that the computing power satisfaction rate of the container changes to meet the preset condition; the hyper-threading computing power ratio is used to characterize the proportion of the container's runtime when calculating the kernel's runtime.

5. The method according to claim 4, wherein, Modifying the hyper-threaded computing power ratio corresponding to the container to change the computing power satisfaction rate of the container to meet the preset condition includes: Modify the hyper-threading computing power ratio corresponding to the container according to the preset adjustment step size; Obtain the computing power satisfaction rate of the container after modifying the hyper-threading computing power ratio; If the computing power satisfaction rate after modifying the hyper-threaded computing power ratio still does not meet the preset condition, the step of modifying the hyper-threaded computing power ratio corresponding to the container according to the preset adjustment step size is returned and executed repeatedly until the computing power satisfaction rate of the container meets the preset condition.

6. The method according to claim 5, wherein, The step of modifying the hyper-threading computing power ratio corresponding to the container according to a preset adjustment step size includes: Based on the fact that the computing power satisfaction rate of the container is less than the minimum satisfaction rate corresponding to the preset condition, the hyper-threaded computing power ratio corresponding to the container is reduced by the preset adjustment step size. Based on the fact that the computing power satisfaction rate of the container is greater than the maximum satisfaction rate corresponding to the preset condition, the hyper-threaded computing power ratio corresponding to the container is increased by the preset adjustment step size.

7. The method according to any one of claims 1-6, wherein, Before obtaining the computing power satisfaction rate of the container, the method further includes: Obtain the current node computing power utilization rate of the computing node to which the container belongs; By using a preset performance consistency model, the target hyper-threaded computing power ratio corresponding to the current node computing power utilization rate is determined; wherein, the preset performance consistency model is used to characterize the mapping relationship between the node computing power utilization rate and the hyper-threaded computing power ratio; the node computing power utilization rate is used to characterize the load level of the computing node; Call the hyper-threading resource quota awareness interface of the kernel on which the container depends, and set the hyper-threading computing power ratio corresponding to the container to the target hyper-threading computing power ratio.

8. The method according to claim 7, wherein, Before determining the target hyper-threaded computing power ratio corresponding to the current node computing power utilization rate through the preset performance consistency model, the method further includes: The system receives configuration information sent by the management node, the configuration information including at least one of the preset performance consistency model and the preset conditions.

9. The method according to any one of claims 1-6, wherein, Before obtaining the computing power satisfaction rate of the container, the method further includes: Receive the container creation request sent by the management node, the creation request including the container's configuration file; After determining the target hyper-threaded computing power ratio for the container, the container is started based on the configuration file, and the operation of obtaining the container's computing power satisfaction rate is performed; wherein, the target hyper-threaded computing power ratio is used to characterize the hyper-threaded computing power ratio corresponding to the current node computing power utilization rate of the computing node to which the container belongs.

10. The method according to any one of claims 1-6, wherein, Before obtaining the computing power satisfaction rate of the container, the method further includes: It is determined that the container's configuration file includes indication information for enabling the computing power adjustment function; The computing power adjustment process of the container is executed according to the indicated information.

11. A method for adjusting the computing power of a container, comprising: Send configuration information to each computing node in the cluster, the configuration information including at least one of a preset performance consistency model and preset conditions; The preset performance consistency model is used to characterize the mapping relationship between node computing power utilization and hyper-threaded computing power ratio; Receive a container creation request sent by the client, the creation request carrying the container's configuration file; The configuration file is sent to the target computing node, which is any computing node in the cluster, so that the target computing node starts the container based on the configuration file. If the computing power satisfaction rate of the container does not meet the preset condition, the hyper-threaded resource quota awareness interface of the kernel on which the container depends is called based on the configuration information to adjust the computing power satisfaction rate of the container.

12. A computing power adjustment system for a container, comprising: Management nodes and compute nodes; The management node is used to send configuration information to the computing node and to send container creation requests to the computing node; The configuration information includes at least one of a preset performance consistency model and preset conditions; the preset performance consistency model is used to characterize the mapping relationship between node computing power utilization and hyper-threaded computing power ratio; The computing node is configured to start the container based on the configuration file included in the container creation request; obtain the computing power satisfaction rate of the container; and, if the computing power satisfaction rate of the container does not meet the preset conditions, adjust the computing power satisfaction rate of the container by calling the hyper-threaded resource quota awareness interface of the kernel on which the container depends, based on the computing power satisfaction rate and the configuration information; the computing power satisfaction rate is used to characterize the ratio between the computing power allocated to the container and the computing power required by the container.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements: Obtain the computing power satisfaction rate of the container, which is used to characterize the ratio between the computing power allocated to the container and the computing power required by the container; In response to the computing power satisfaction rate not meeting the preset conditions, the hyper-threaded resource quota awareness interface of the kernel on which the container depends is invoked to adjust the computing power satisfaction rate.

14. The electronic device according to claim 13, wherein, The acquisition of the container's computing power satisfaction rate includes: Get the first duration information of the container's process in the run queue; Obtain the second duration information of the peer hyperthread corresponding to the container during the process execution; Based on the first duration information and the second duration information, the computing power satisfaction rate of the container is determined.

15. The electronic device according to claim 14, wherein, The first duration information includes the waiting time of the process in the run queue and the first actual runtime of the process; the second duration information includes the idle time and the second actual runtime of the peer hyperthread during the process's execution. Determining the computing power satisfaction rate of the container based on the first duration information and the second duration information includes: Calculate the first sum of the waiting time and the first actual runtime of the process; Calculate the product of the preset ratio and the second actual runtime, whereby the preset ratio is used to characterize the proportion of the time the process uses the kernel in the total time the process and the peer hyperthread jointly use the kernel. Calculate a second sum of the product and the idle time of the peer hyperthread; Calculate the ratio of the second sum to the first sum, and use the ratio as the computing power satisfaction rate of the container.

16. The electronic device according to claim 13, wherein, The step of invoking the hyper-threaded resource quota awareness interface of the kernel on which the container depends to adjust the computing power satisfaction rate includes: The hyper-threading resource quota awareness interface of the kernel on which the container depends is invoked to modify the hyper-threading computing power ratio corresponding to the container, so that the computing power satisfaction rate of the container changes to meet the preset condition; the hyper-threading computing power ratio is used to characterize the proportion of the container's runtime when calculating the kernel's runtime.

17. The electronic device according to claim 16, wherein, Modifying the hyper-threaded computing power ratio corresponding to the container to change the computing power satisfaction rate of the container to meet the preset condition includes: Modify the hyper-threading computing power ratio corresponding to the container according to the preset adjustment step size; Obtain the computing power satisfaction rate of the container after modifying the hyper-threading computing power ratio; If the computing power satisfaction rate after modifying the hyper-threaded computing power ratio still does not meet the preset condition, the step of modifying the hyper-threaded computing power ratio corresponding to the container according to the preset adjustment step size is returned and executed repeatedly until the computing power satisfaction rate of the container meets the preset condition.

18. The electronic device according to claim 17, wherein, The step of modifying the hyper-threading computing power ratio corresponding to the container according to a preset adjustment step size includes: Based on the fact that the computing power satisfaction rate of the container is less than the minimum satisfaction rate corresponding to the preset condition, the hyper-threaded computing power ratio corresponding to the container is reduced by the preset adjustment step size. Based on the fact that the computing power satisfaction rate of the container is greater than the maximum satisfaction rate corresponding to the preset condition, the hyper-threaded computing power ratio corresponding to the container is increased by the preset adjustment step size.

19. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method of any one of claims 1 to 11.

20. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 11.

Images