Method, device and equipment for limiting CPU (Central Processing Unit) utilization rate of process and storage medium

Abstract

The invention discloses a method, device and equipment for limiting the CPU utilization rate of a process and a storage medium, and the method comprises the steps: distributing a target number of tokens for a target process at the beginning of an Nth time period; wherein the target number is calculated based on the CPU utilization rate limited for the target process; at the end of the Nth time period, the token balance owned by the target process is calculated; determining an expected state of the target process in the (N + 1) th time period based on the token balance; wherein the expected state is a running state or a pause state; when the expected state is different from the actual state of the target process in the Nth time period, sending a state switching signal to the target process so as to switch the state of the target process into the expected state; and when the expected state is the same as the actual state of the target process in the Nth time period, forbidding sending a state switching signal to the target process, and controlling the target process to maintain the actual state in the (N + 1) th time period.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for limiting the CPU usage of a process. Background Technology

[0002] There are two common methods used in existing technologies to limit the CPU (Central Processing Unit) utilization of processes.

[0003] One option is to use cgroups technology, but the deployment of cgroups technology is relatively complex.

[0004] Another approach uses a signal mechanism based on the `cpulimit` tool to control process execution and pause time allocation. Specifically, it sends two signals within 100-millisecond intervals to control process execution and pause respectively, thus controlling CPU usage by managing the timing of these signal transmissions. However, the inventors discovered that when a process has a large number of threads, sending two signals within a 100-millisecond interval to control execution and pause may not effectively limit CPU usage. For example, when a process has many threads and is running, sending a `SIGSTOP` signal will pause all threads, but the scheduling operation itself consumes CPU time and introduces a delay. When the number of threads is large, this delay and the time consumed by the operation can cause the process to exceed the set CPU usage threshold. Furthermore, in cloud environments, when the host machine's CPU load is high, limiting the CPU usage of a process with a large number of threads within a virtual machine becomes even more difficult.

[0005] There is currently no effective solution to the aforementioned technical problems. Summary of the Invention

[0006] The purpose of this invention is to provide a method, apparatus, device, and storage medium for limiting the CPU usage of a process, which can accurately limit the CPU usage of a process and the solution is easy to deploy.

[0007] According to one aspect of the present invention, a method for limiting process CPU utilization is provided, the method comprising: At the start of the Nth time period, a target number of tokens is allocated to the target process; wherein, the target number is calculated based on the CPU utilization limit imposed on the target process; At the end of the Nth time period, calculate the token balance held by the target process; Based on the token balance, the expected state of the target process in the N+1th time period is determined; wherein, the expected state is a running state or a paused state, the running state indicates that the target process is using CPU resources, and the paused state indicates that the target process is not using CPU resources; When the desired state differs from the actual state of the target process in the Nth time period, a state switching signal is sent to the target process to switch the state of the target process to the desired state. When the desired state is the same as the actual state of the target process in the Nth time period, the sending of the state switching signal to the target process is prohibited, and the target process is controlled to maintain the actual state in the N+1th time period.

[0008] Optionally, the target number is calculated based on the CPU utilization limit imposed on the target process, including: Set a preset fixed duration as the unit duration; Determine the number of unit durations contained within any given time period, and use this as the unit duration quantity; The target quantity is calculated by multiplying the number of unit durations by the CPU utilization limit imposed on the target process, with the constraint that the target process consumes one token per unit of time to maintain its running state.

[0009] Optionally, calculating the token balance held by the target process at the end of the Nth time period includes: At the end of the Nth time period, calculate the number of tokens actually consumed by the target process during the Nth time period; Obtain the token balance held by the target process at the end of the N-1th time period; Calculate the sum of the target quantity and the token balance of the target process at the end of the N-1 time period, and calculate the difference between the sum and the number of tokens actually consumed by the target process in the Nth time period, as the token balance of the target process at the end of the Nth time period.

[0010] Optionally, calculating the number of tokens actually consumed by the target process in the Nth time period includes: Calculate the total time spent by the target process in maintaining the running state during the Nth time period; Calculate the number of unit durations included in the total duration, which is taken as the number of tokens actually consumed by the target process in the Nth time period.

[0011] Optionally, determining the desired state of the target process in the (N+1)th time period based on the token balance includes: Determine whether the token balance held by the target process is greater than or equal to the number of units of time at the end of the Nth time period; If so, then the desired state of the target process in the (N+1)th time period is determined as the running state; If not, then the desired state of the target process in the (N+1)th time period is determined to be the paused state.

[0012] Optionally, the method further includes: After the target process remains in the paused state for M time periods, a SIGCONT signal is sent to the target process to switch the target process from the paused state to the running state; From the moment the SIGCONT signal is sent, after a preset runtime, a SIGSTOP signal is sent to the target process to switch the target process from the running state back to the paused state.

[0013] Optionally, after a preset runtime has elapsed since the SIGCONT signal was sent, and a SIGSTOP signal is sent to the target process to switch the target process from the running state back to the suspended state, the method further includes: Determine the total number of time periods required to cover the preset runtime; Calculate the product of the target quantity and the total number of time periods, and use it as the number of tokens allocated to the target process within the preset runtime; Calculate the number of tokens actually consumed by the target process in the most recent time to maintain the running state; Obtain the token balance held by the target process at the end of the last time period of the M time periods; Calculate the sum of the token balance and the number of tokens allocated to the target process within the preset runtime, and calculate the difference between the sum and the number of tokens actually consumed by the target process to maintain the running state most recently, which is taken as the token balance currently held by the target process; The desired state of the target process in the next time period is determined based on the current token balance of the target process.

[0014] To achieve the above objectives, the present invention further provides a device for limiting process CPU usage, the device comprising: A token allocation module is used to allocate a target number of tokens to a target process at the beginning of the Nth time period; wherein the target number is calculated based on the CPU utilization limit imposed on the target process; The token calculation module is used to calculate the token balance of the target process at the end of the Nth time period; A state determination module is used to determine the expected state of the target process in the N+1th time period based on the token balance; wherein the expected state is a running state or a paused state, the running state indicates that the target process is using CPU resources, and the paused state indicates that the target process is not using CPU resources; A state switching module is used to send a state switching signal to the target process when the desired state is different from the actual state of the target process in the Nth time period, so as to switch the state of the target process to the desired state. The state maintenance module is used to prevent the sending of state switching signals to the target process when the desired state is the same as the actual state of the target process in the Nth time period, and to control the target process to maintain the actual state in the N+1th time period.

[0015] To achieve the above objectives, the present invention also provides a computer device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method for limiting process CPU utilization described above.

[0016] To achieve the above objectives, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is used to implement the steps of the method for limiting process CPU utilization described above.

[0017] The present invention provides a method, apparatus, device, and storage medium for limiting process CPU utilization, which minimizes the frequency of signal transmission and reduces the impact of scheduling operations triggered by high-frequency signals on CPU utilization, thereby achieving the goal of accurately controlling the CPU utilization of a process even if it contains a large number of threads. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart of the method for limiting process CPU usage provided in Embodiment 1; Figure 2 A block diagram of the device for limiting process CPU usage provided in Embodiment 2; Figure 3A block diagram of a computer device suitable for implementing a method for limiting process CPU utilization, as provided in Embodiment 3. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0020] Example 1 Embodiment 1 of the present invention provides a method for limiting process CPU usage, such as... Figure 1 As shown, the method includes steps S1 to S5, wherein: Step S1: At the beginning of the Nth time period, allocate a target number of tokens to the target process; wherein the target number is calculated based on the CPU usage limit for the target process.

[0021] CPU utilization, also known as CPU resource utilization, refers to the ratio of CPU time consumed by a process within a certain time period to the length of that time period. Limiting CPU utilization for a target process can be represented as restricting the ratio of CPU time consumed by the target process within a certain time period to a certain percentage, such as 40%. This embodiment pre-limits the CPU utilization of the target process within a future time period, divides that time period into multiple time cycles, applies the CPU utilization limit for the target process within each time period to a token bucket strategy, and calculates how many tokens should be allocated to the target process in each time cycle. The goal is that after a sufficient number of time cycles, the proportion of CPU time actually consumed by the target process to the total CPU time will approach the preset value of the CPU utilization limit for the target process.

[0022] This application uses a fixed duration as a time cycle for cyclical control. The control judgment logic for the target process is the same in each time cycle; this application uses the Nth time cycle as an example for illustration. Specifically, at the beginning of each time cycle, a target number of tokens is allocated to the target process. This target number is calculated based on a pre-set CPU utilization limit for the target process, and is the number of tokens added to the target process's token bucket in each time cycle. One token represents the allowed CPU time of one unit; that is, one token is consumed for every unit of CPU time. This essentially transforms the percentage-based resource allocation into a discrete time budget. For example, if the duration of each time cycle is 100 milliseconds and the CPU utilization limit for the target process is 40%, then the target number is 40, and 40 tokens are allocated to the target process in each time cycle. As another example, if the duration of each time cycle is 50 milliseconds and the CPU utilization limit for the target process is 40%, then the target number is 20, and 20 tokens are allocated to the target process in each time cycle.

[0023] Optionally, the target number is calculated based on the CPU utilization limit imposed on the target process, including: Set a preset fixed duration as the unit duration; Determine the number of unit durations contained within any given time period, and use this as the unit duration quantity; The target quantity is calculated by multiplying the number of unit durations by the CPU utilization limit imposed on the target process, with the constraint that the target process consumes one token per unit of time to maintain its running state.

[0024] Specifically, the unit duration is a pre-defined, fixed time length, such as 1 millisecond or 2 milliseconds. The unit duration setting is the foundation for the time accuracy of the entire control scheme. The choice of unit duration requires a trade-off between control accuracy and system overhead. For example, a smaller unit duration (such as 1 microsecond) allows for finer control but increases the frequency of token calculation and status checks; a larger unit duration (such as 10 milliseconds) has the opposite effect. One unit duration corresponds to one token, signifying that the target process needs to pay one token for every unit duration of CPU time consumed.

[0025] A time period is the basic time window for resource allocation and state decisions. By calculating how many units of time are contained within a time period, we can determine the basic number of units of time resources available for allocation within that time period, i.e., the number of units of time. For example, if the unit of time is 1 millisecond and the time period is 100 milliseconds, then the number of units of time is 100. The number of units of time essentially represents the total number of tokens corresponding to 100% of the CPU time resources within that time period. By transforming the abstract percentage limit into a concrete resource quota, the proportional allocation of CPU time resources is achieved. The target quantity is the CPU time budget that the target process is allowed to occupy in each time period.

[0026] This embodiment establishes a stable and predictable resource allocation mechanism. By introducing the concepts of unit duration and time period, it clearly converts the easily understandable and configurable percentage parameter of CPU utilization into a discrete token budget used by the internal control logic. This not only ensures the precise mathematical correspondence of the control target of CPU utilization but also provides a clear benchmark for subsequent token balance calculation and state decisions.

[0027] Step S2: At the end of the Nth time period, calculate the token balance held by the target process.

[0028] At the end of the time period, the actual CPU time consumed by the target process during this period is obtained and converted into the number of tokens consumed. Then, a token settlement operation is performed: Token balance for this time period = Token balance for the previous time period + Target tokens allocated for this time period - Tokens actually consumed for this time period. This settlement result may be positive, zero, or negative. A negative balance indicates that the target process over-consumed CPU time during this time period, which will be deducted from the new tokens allocated in subsequent time periods. This mechanism ensures the accuracy of utilization in long-term statistical terms.

[0029] It's important to note that a SIGSTOP signal is sent to a target process when it needs to be switched from a running state to a suspended state. However, there is an unavoidable slight response delay between the signal being sent and the target process being actually suspended. During this period, the target process remains runnable and may continue to be scheduled for execution, consuming additional CPU time. This CPU consumption, which shouldn't occur after the control instruction takes effect but actually happens, and the CPU consumption that occurs when calculating the decision result and issuing the state switch instruction at the end of a time cycle, may cause the number of tokens deducted during settlement to exceed the number of tokens currently held by the target process, resulting in a negative balance. In high-load host environments, the scheduling delay within the virtual machine may be more pronounced, exacerbating this phenomenon. Furthermore, the situation becomes more complex when the target process contains multiple threads. The SIGSTOP signal is typically sent to the entire process group, intended to suspend all threads. However, in practice, a suspended multi-threaded process may still generate unexpected CPU consumption at a microscopic level, resulting in overdraft and a negative balance during settlement. Allowing negative token balances is a key design feature of this scheme for its flexibility and robustness, not a flaw. It is equivalent to giving the target process a limited, short-term CPU time credit.

[0030] Optionally, calculating the token balance held by the target process at the end of the Nth time period includes: At the end of the Nth time period, calculate the number of tokens actually consumed by the target process during the Nth time period; Obtain the token balance held by the target process at the end of the N-1th time period; Calculate the sum of the target quantity and the token balance of the target process at the end of the N-1 time period, and calculate the difference between the sum and the number of tokens actually consumed by the target process in the Nth time period, as the token balance of the target process at the end of the Nth time period.

[0031] Specifically, this application does not start from scratch in each time period, but uses the token balance after the settlement of the previous time period as the initial state for the calculation of the current time period. The actual behavior of the target process is quantified and incorporated into the calculation to determine the actual number of tokens consumed by the target process, ensuring that control decisions are always based on actual resource consumption, rather than assumptions or predictions. If the target process's consumption is consistently lower than the allocated amount, the token balance will increase positively, eventually prompting the target process to enter the running state; conversely, if consumption exceeds the limit, the token balance will decrease or even become negative, subsequently causing the target process to enter a paused state.

[0032] This embodiment avoids frequent process state switching due to minor consumption fluctuations within a single time period by using a balance accumulation strategy, thereby achieving low-frequency, highly deterministic signal control and significantly reducing system overhead. Executing a token settlement formula at the end of each time period ensures that after a sufficient number of time periods, the difference between the total number of tokens allocated and the total number of tokens consumed will be limited to a finite range, thus strictly constraining the long-term average CPU utilization.

[0033] Optionally, calculating the number of tokens actually consumed by the target process in the Nth time period includes: Calculate the total time spent by the target process in maintaining the running state during the Nth time period; Calculate the number of unit durations included in the total duration, which is taken as the number of tokens actually consumed by the target process in the Nth time period.

[0034] Specifically, maintaining a running state indicates that the target process is continuously using CPU resources. The total CPU time actually spent by the target process within the Nth time period is obtained; this total duration objectively represents the actual amount of CPU resources used by the target process, unaffected by system load or other processes. This total duration is divided by a predefined unit duration to calculate the number of units of time contained within that time period. Since a token is defined as representing one unit of CPU usage right, this calculated number of units of time is directly considered the actual number of tokens consumed.

[0035] This embodiment directly measures the actual execution time, rather than the waiting time before the target process enters the running state. Even if the target process is temporarily deprived of CPU during the running state due to host scheduling, time slice exhaustion, or other reasons, this will not be included in the consumption. This accurately reflects the computing resources actually acquired and used by the target process, making the control fairer and more accurate.

[0036] Step S3: Determine the expected state of the target process in the N+1th time period based on the token balance; wherein the expected state is a running state or a paused state, the running state indicates that the target process is using CPU resources, and the paused state indicates that the target process is not using CPU resources.

[0037] The desired state characterizes the expected state of the target process in the next time cycle. The current token balance is compared to a preset state transition threshold. If the token balance is greater than or equal to the threshold, it indicates that the target process has sufficient budget to cover the CPU time for the next full time cycle, thus its desired state in the next cycle is determined to be the running state; if the token balance is less than the threshold, it indicates insufficient budget, thus the desired state of the target process in the next time cycle is determined to be the paused state. Through this threshold comparison, the token bucket mechanism maps continuous budget balances to discrete run or pause control instructions.

[0038] Optionally, determining the desired state of the target process in the (N+1)th time period based on the token balance includes: Determine whether the token balance held by the target process is greater than or equal to the number of units of time at the end of the Nth time period; If so, then the desired state of the target process in the (N+1)th time period is determined as the running state; If not, then the desired state of the target process in the (N+1)th time period is determined to be the paused state.

[0039] Using the number of tokens per unit of time as the benchmark for the target process's state transition threshold, a process is only authorized to enter the running state if its accumulated token budget is sufficient to cover the CPU time cost of the next full time cycle. This ensures that once a process starts running, it can continuously occupy the CPU until the end of the cycle, thus avoiding frequent state transitions within a single cycle due to budget fragmentation. This is a robust and efficient design that ensures sufficient runtime performance. Allowing a target process to enter the running state when its budget reserve is insufficient may cause it to quickly exhaust its budget before the end of a cycle, resulting in frequent state transitions and increasing uncertainty. Therefore, once it is determined that the current token balance is less than the number of tokens per unit of time, the target process's expected state for the next time cycle is determined to be the paused state, forcing it to stop occupying the CPU in the next time cycle. During this period, the budget is accumulated through periodic token allocation, avoiding the risk of frequent instruction sending.

[0040] Step S4: When the desired state is different from the actual state of the target process in the Nth time period, a state switching signal is sent to the target process to switch the state of the target process to the desired state.

[0041] Step S5: When the desired state is the same as the actual state of the target process in the Nth time period, the state switching signal is prohibited from being sent to the target process, and the target process is controlled to maintain the actual state in the N+1th time period.

[0042] When the desired state differs from the actual state in the previous time period, it indicates a need to change the current behavior of the target process. A state transition signal is sent to the target process: a SIGCONT signal is sent if the process needs to transition from paused to running; a SIGSTOP signal is sent if the process needs to transition from running to paused. That is, when the desired state is running, the state transition signal is SIGCONT; when the desired state is paused, the state transition signal is SIGSTOP.

[0043] When the desired state is the same as the actual state in the previous time period, it indicates that the current behavior of the target process meets the budget control requirements and no changes are needed. At this time, it is explicitly prohibited to send any state transition signals to the target process, and the target process will maintain its current state in the next time period.

[0044] This application triggers a costly inter-process signal communication and state switching operation only when the accumulation of token balance necessitates a change in the target process's behavior state. During the steady-state phase where the target process needs to run for a long time or be paused for a long time, the system incurs no control overhead. The principle of lazy signaling in this application is fundamentally different from the traditional fixed-time-slice round-robin method (which forces a switch every cycle), greatly reducing unnecessary context switching and kernel trap overhead. Even in virtualized environments with high host loads, fine-grained CPU limiting can be implemented.

[0045] Optionally, the method further includes: After the target process remains in the paused state for M time periods, a SIGCONT signal is sent to the target process to switch the target process from the paused state to the running state; From the moment the SIGCONT signal is sent, after a preset runtime, a SIGSTOP signal is sent to the target process to switch the target process from the running state back to the paused state.

[0046] Specifically, when using this embodiment to address the technical problem of poor CPU utilization of processes in existing technologies, the inventors discovered that, to avoid network connection failures caused by processes requiring network connectivity being unable to run for extended periods, a short period of runtime is allowed after a prolonged pause. M is dynamically determined by the token balance. The underlying logic is: while the target process is paused, it still receives the target number of tokens each time period, and the token balance continuously accumulates; the desired running state is determined only when the token balance accumulates to a value greater than or equal to the unit duration value; however, when the token balance is less than the unit duration value for M time periods, the target process is given a short period of runtime. This helps to avoid network connection failures caused by processes requiring network connectivity being unable to run for extended periods.

[0047] After sending the SIGCONT signal, the target process is set to a runnable state, but its actual acquisition of the CPU and commencement of execution depends on the operating system's scheduling decisions, resulting in unpredictable and minor scheduling delays. This application sets the timing start point to the moment the controller sends the signal, rather than the moment the process actually begins execution, ensuring the determinism of the control duration. The preset runtime is the maximum available time window actively planned and guaranteed by the controller, unaffected by random scheduling delays.

[0048] Optionally, after a preset runtime has elapsed since the SIGCONT signal was sent, and a SIGSTOP signal is sent to the target process to switch the target process from the running state back to the suspended state, the method further includes: Determine the total number of time periods required to cover the preset runtime; Calculate the product of the target quantity and the total number of time periods, and use it as the number of tokens allocated to the target process within the preset runtime; Calculate the number of tokens actually consumed by the target process in the most recent time to maintain the running state; Obtain the token balance held by the target process at the end of the last time period of the M time periods; Calculate the sum of the token balance and the number of tokens allocated to the target process within the preset runtime, and calculate the difference between the sum and the number of tokens actually consumed by the target process to maintain the running state most recently, which is taken as the token balance currently held by the target process; The desired state of the target process in the next time period is determined based on the current token balance of the target process.

[0049] Specifically, when the target process undergoes a brief, controlled running phase triggered by the budget and returns to a paused state, the expected state of the target process in the next time period needs to be calculated. The preset runtime may fully cover several time periods, or it may only cover a portion of a certain time period, or it may fully cover several time periods and then only cover a portion of the next time period. For example, if each time period is 100 milliseconds, the preset runtime may be 100 milliseconds, 20 milliseconds, or 110 milliseconds, etc. By dividing the preset runtime by the length of a single time period and rounding the result up to obtain the total number of time periods, it is ensured that the budget reserved for this running phase is complete and sufficient in the period dimension. Preferably, to avoid excessive token consumption by multi-threaded processes after running in one time unit, resulting in prolonged periods of unavailability for subsequent runs, the preset runtime is less than the duration of one time unit. For example, if each time period is 100 milliseconds, the preset runtime is 10 milliseconds.

[0050] The calculation of the actual number of tokens consumed by the target process during its most recent run is essentially the calculation of the actual number of tokens consumed by the target process during that brief run phase. Specifically, this involves: calculating the total duration of the target process's most recent run; and calculating the number of unit durations included in this total duration, which is taken as the actual number of tokens consumed by the target process during its most recent run. Any calculation result that is not an integer is rounded up to the nearest integer to facilitate the calculation of the token count.

[0051] After completing the above comprehensive settlement, the system obtains a token balance reflecting the latest resource status. Based on this new balance, the desired state of the target process in the next time period can be determined, thus seamlessly resuming the normal cycle control loop.

[0052] Existing technologies lack a method for accurately controlling process CPU utilization at low signal frequencies. Traditional solutions suffer from frequent signaling and high scheduling overhead. Specifically, traditional solutions switch process states by sending SIGSTOP and SIGCONT signals at a fixed frequency (e.g., every 100 milliseconds) to control CPU utilization. However, this method triggers signals frequently regardless of whether the process state needs to be changed, leading to significant scheduling overhead and control bias. To address the shortcomings of existing technologies, this solution innovatively combines a signaling mechanism with a token bucket strategy to limit process CPU utilization. CPU time is quantified into tokens. Tokens are allocated each time period based on a preset CPU utilization rate, and tokens are deducted based on the actual process running time. A process state switch is only determined when the accumulated tokens reach or fall below the running threshold. Simultaneously, a state preservation mechanism ensures that no signals are sent when the desired state remains unchanged within consecutive periods, thereby significantly reducing the signal triggering frequency and system scheduling load. This achieves more precise and efficient CPU utilization control and avoids network interruptions that may be caused by prolonged process pauses.

[0053] Optionally, to dynamically adjust the control rhythm according to the system load, achieving fine-grained control during periods of high load and coarse-grained release during periods of idleness, this application also designs a state machine adjustment algorithm: when external pressure is high and internal demand fluctuates greatly, the time period is shortened to more sensitively preempt the CPU and reduce the probability of processes running during scheduling gaps; when the system is idle and process demand is stable, the time period is linearly extended to further reduce signal and switching overhead. Taking the Nth time period as an example, the specific implementation is as follows: monitoring system load indicators during the Nth time period; where the system load indicators include: external pressure indicators representing the CPU resource stress and internal demand fluctuation indicators representing the stability of the target process's CPU usage pattern; based on the external pressure indicators and internal demand fluctuation indicators, determining the control state to be adopted for the N+1th time period; and adjusting the duration of the N+1th time period according to the determined control state.

[0054] External stress metrics can include scheduling latency monitoring metrics and overall system CPU utilization. Scheduling latency monitoring metrics are scheduling statistics provided by the kernel, such as the waiting time of a target process in the ready queue. A sustained increase in average latency indicates that the system scheduler is busy, and the determinism of the system obtaining CPU time slices decreases. Overall system CPU utilization is the percentage of time all CPU cores spend in a non-idle state out of the total statistical time.

[0055] The internal demand fluctuation index is obtained by collecting the actual number of tokens consumed by the target process in each of the most recent P consecutive time periods, forming a consumption sequence; and calculating the statistical variance of this consumption sequence. A high variance value indicates that the CPU consumption behavior of the target process fluctuates wildly and lacks regularity, possibly belonging to interactive or bursty tasks; a lower variance value indicates that the consumption behavior is stable and predictable, possibly belonging to batch processing or computationally intensive tasks.

[0056] The regulatory status includes: tightening, easing, and baseline. When external pressure indicators consistently exceed preset external thresholds and internal demand fluctuation indicators exceed preset internal thresholds, the regulatory status is determined to be tightening. When external pressure indicators consistently fall below preset external thresholds and internal demand fluctuation indicators fall below preset internal thresholds, the regulatory status is determined to be easing. Otherwise, the regulatory status is determined to be baseline.

[0057] When the control state is tightened, the duration of the (N+1)th time period is shortened to half the duration of the time period under the baseline state; when the control state is tightened, the duration of the (N+1)th time period is widened to three-half the duration of the time period under the baseline state; when the control state is the baseline state, the duration of the (N+1)th time period remains unchanged.

[0058] Once it's determined that the duration of the (N+1)th time period needs to be changed, the target quantity must be redefined within the Nth time period. The newly determined target quantity is calculated as follows: the number of unit durations contained within the (N+1)th time period is determined as the new unit duration quantity; the product of the new unit duration quantity and the CPU utilization limit imposed on the target process is calculated as the new target quantity. Furthermore, at the beginning of the (N+1)th time period, tokens representing the new target quantity are allocated to the target process.

[0059] By introducing a dynamic adaptive mechanism based on both internal and external load indicators, the control system is upgraded from a static budget executor to an intelligent resource coordinator. It can perceive the host CPU contention pressure (through scheduling latency and overall utilization) and the volatility of the target process's behavior in real time, and dynamically adjust the control cycle accordingly: automatically shortening the cycle to improve control accuracy and prevent process overruns when both internal and external pressures are high; and automatically extending the cycle to significantly reduce the overhead of signal transmission and context switching when the system is idle and stable. This adaptive optimization achieves a dynamic optimal balance between control accuracy and system overhead, and significantly improves the robustness, responsiveness, and overall efficiency of CPU limiting strategies in complex virtualized or physical machine environments with high host loads.

[0060] Example 2 This invention provides a device for limiting the CPU usage of a process, such as... Figure 2 As shown, the device 20 for limiting process CPU usage specifically includes the following components: The token allocation module 201 is used to allocate a target number of tokens to the target process at the beginning of the Nth time period; wherein the target number is calculated based on the CPU utilization limit for the target process; The token calculation module 202 is used to calculate the token balance of the target process at the end of the Nth time period; The state determination module 203 is used to determine the expected state of the target process in the N+1th time period based on the token balance; wherein the expected state is a running state or a paused state, the running state indicates that the target process is using CPU resources, and the paused state indicates that the target process is not using CPU resources. The state switching module 204 is used to send a state switching signal to the target process when the desired state is different from the actual state of the target process in the Nth time period, so as to switch the state of the target process to the desired state. The state maintenance module 205 is used to prevent sending a state switching signal to the target process when the desired state is the same as the actual state of the target process in the Nth time period, and to control the target process to maintain the actual state in the N+1th time period.

[0061] Optionally, the apparatus further includes a token determination module, configured to calculate the target quantity based on the CPU usage limit imposed on the target process; specifically configured to: Set a preset fixed duration as the unit duration; Determine the number of unit durations contained within any given time period, and use this as the unit duration quantity; The target quantity is calculated by multiplying the number of unit durations by the CPU utilization limit imposed on the target process, with the constraint that the target process consumes one token per unit of time to maintain its running state.

[0062] Optionally, the token calculation module is specifically used for: At the end of the Nth time period, calculate the number of tokens actually consumed by the target process during the Nth time period; Obtain the token balance held by the target process at the end of the N-1th time period; Calculate the sum of the target quantity and the token balance of the target process at the end of the N-1 time period, and calculate the difference between the sum and the number of tokens actually consumed by the target process in the Nth time period, as the token balance of the target process at the end of the Nth time period.

[0063] Optionally, when the token calculation module performs the calculation of the actual number of tokens consumed by the target process in the Nth time period, it is specifically used to: Calculate the total time spent by the target process in maintaining the running state during the Nth time period; Calculate the number of unit durations included in the total duration, which is taken as the number of tokens actually consumed by the target process in the Nth time period.

[0064] Optionally, the state determination module is specifically used for: Determine whether the token balance held by the target process is greater than or equal to the number of units of time at the end of the Nth time period; If so, then the desired state of the target process in the (N+1)th time period is determined as the running state; If not, then the desired state of the target process in the (N+1)th time period is determined to be the paused state.

[0065] Optionally, the device further includes: The temporary state control module is used to send a SIGCONT signal to the target process after the target process has been in the paused state for M time periods, so as to switch the target process from the paused state to the running state. The state recovery module is used to send a SIGSTOP signal to the target process after a preset runtime period from the time the SIGCONT signal is sent, so as to switch the target process from the running state back to the paused state.

[0066] Optionally, the device further includes a state prediction module for: After a preset runtime has elapsed since the SIGCONT signal was sent, a SIGSTOP signal is sent to the target process to switch the target process from the running state back to the paused state, and then the total number of time periods required to cover the preset runtime is determined. Calculate the product of the target quantity and the total number of time periods, and use it as the number of tokens allocated to the target process within the preset runtime; Calculate the number of tokens actually consumed by the target process in the most recent time to maintain the running state; Obtain the token balance held by the target process at the end of the last time period of the M time periods; Calculate the sum of the token balance and the number of tokens allocated to the target process within the preset runtime, and calculate the difference between the sum and the number of tokens actually consumed by the target process to maintain the running state most recently, which is taken as the token balance currently held by the target process; The desired state of the target process in the next time period is determined based on the current token balance of the target process.

[0067] Example 3 This embodiment also provides a computer device, such as a smartphone, tablet computer, laptop computer, desktop computer, rack server, blade server, tower server, or cabinet server (including a standalone server or a server cluster composed of multiple servers), etc., capable of executing programs. Figure 3 As shown, the computer device 30 in this embodiment includes, but is not limited to, a memory 301 and a processor 302 that are communicatively connected to each other via a system bus. It should be noted that... Figure 3 Only a computer device 30 with components 301-302 is shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0068] In this embodiment, the memory 301 (i.e., the readable storage medium) includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 301 may be an internal storage unit of the computer device 30, such as the hard disk or memory of the computer device 30. In other embodiments, the memory 301 may also be an external storage device of the computer device 30, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 30. Of course, the memory 301 may include both the internal storage unit and the external storage device of the computer device 30. In this embodiment, the memory 301 is typically used to store the operating system and various application software installed on the computer device 30. In addition, the memory 301 may also be used to temporarily store various types of data that have been output or will be output.

[0069] In some embodiments, processor 302 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. This processor 302 is typically used to control the overall operation of the computer device 30.

[0070] Specifically, in this embodiment, the processor 302 is used to execute a program stored in the memory 301 for a method of limiting the CPU usage of a process.

[0071] For a detailed description of the above method steps, please refer to Example 1. This example will not be repeated here.

[0072] Example 4 This embodiment also provides a computer-readable storage medium, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, server, App application store, etc., which stores a computer program. When the computer program is executed by a processor, it is used to implement the steps of a method for limiting the CPU usage of a process.

[0073] For a detailed description of the above method steps, please refer to Example 1. This example will not be repeated here.

[0074] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0075] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0076] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0077] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for limiting process CPU utilization, characterized in that, The method includes: At the start of the Nth time period, a target number of tokens is allocated to the target process; wherein, the target number is calculated based on the CPU utilization limit imposed on the target process; At the end of the Nth time period, calculate the token balance held by the target process; Based on the token balance, the expected state of the target process in the N+1th time period is determined; wherein, the expected state is a running state or a paused state, the running state indicates that the target process is using CPU resources, and the paused state indicates that the target process is not using CPU resources; When the desired state differs from the actual state of the target process in the Nth time period, a state switching signal is sent to the target process to switch the state of the target process to the desired state. When the desired state is the same as the actual state of the target process in the Nth time period, the sending of the state switching signal to the target process is prohibited, and the target process is controlled to maintain the actual state in the N+1th time period.

2. The method for limiting process CPU usage according to claim 1, characterized in that, The target number is calculated based on the CPU utilization limit imposed on the target process, including: Set a preset fixed duration as the unit duration; Determine the number of unit durations contained within any given time period, and use this as the unit duration quantity; The target quantity is calculated by multiplying the number of unit durations by the CPU utilization limit imposed on the target process, with the constraint that the target process consumes one token per unit of time to maintain its running state.

3. The method for limiting process CPU usage according to claim 2, characterized in that, At the end of the Nth time period, the token balance of the target process is calculated, including: At the end of the Nth time period, calculate the number of tokens actually consumed by the target process during the Nth time period; Obtain the token balance held by the target process at the end of the N-1th time period; Calculate the sum of the target quantity and the token balance of the target process at the end of the N-1 time period, and calculate the difference between the sum and the number of tokens actually consumed by the target process in the Nth time period, as the token balance of the target process at the end of the Nth time period.

4. The method for limiting process CPU usage according to claim 3, characterized in that, The calculation of the number of tokens actually consumed by the target process in the Nth time period includes: Calculate the total time spent by the target process in maintaining the running state during the Nth time period; Calculate the number of unit durations included in the total duration, which is taken as the number of tokens actually consumed by the target process in the Nth time period.

5. The method for limiting process CPU usage according to claim 2, characterized in that, Determining the desired state of the target process in the (N+1)th time period based on the token balance includes: Determine whether the token balance held by the target process is greater than or equal to the number of units of time at the end of the Nth time period; If so, then the desired state of the target process in the (N+1)th time period is determined as the running state; If not, then the desired state of the target process in the (N+1)th time period is determined to be the paused state.

6. The method for limiting process CPU usage according to claim 1, characterized in that, The method further includes: After the target process remains in the paused state for M time periods, a SIGCONT signal is sent to the target process to switch the target process from the paused state to the running state; From the moment the SIGCONT signal is sent, after a preset runtime, a SIGSTOP signal is sent to the target process to switch the target process from the running state back to the paused state.

7. The method for limiting process CPU usage according to claim 6, characterized in that, After a preset runtime period elapsed from the moment the SIGCONT signal is sent, and a SIGSTOP signal is sent to the target process to switch the target process from the running state back to the suspended state, the method further includes: Determine the total number of time periods required to cover the preset runtime; Calculate the product of the target quantity and the total number of time periods, and use it as the number of tokens allocated to the target process within the preset runtime; Calculate the number of tokens actually consumed by the target process in the most recent time to maintain the running state; Obtain the token balance held by the target process at the end of the last time period of the M time periods; Calculate the sum of the token balance and the number of tokens allocated to the target process within the preset runtime, and calculate the difference between the sum and the number of tokens actually consumed by the target process to maintain the running state most recently, which is taken as the token balance currently held by the target process; The desired state of the target process in the next time period is determined based on the current token balance of the target process.

8. A device for limiting the CPU usage of a process, characterized in that, The device includes: A token allocation module is used to allocate a target number of tokens to a target process at the beginning of the Nth time period; wherein the target number is calculated based on the CPU utilization limit imposed on the target process; The token calculation module is used to calculate the token balance of the target process at the end of the Nth time period; A state determination module is used to determine the expected state of the target process in the N+1th time period based on the token balance; wherein the expected state is a running state or a paused state, the running state indicates that the target process is using CPU resources, and the paused state indicates that the target process is not using CPU resources; A state switching module is used to send a state switching signal to the target process when the desired state is different from the actual state of the target process in the Nth time period, so as to switch the state of the target process to the desired state. The state maintenance module is used to prevent the sending of state switching signals to the target process when the desired state is the same as the actual state of the target process in the Nth time period, and to control the target process to maintain the actual state in the N+1th time period.

9. A computer device, the computer device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, is configured to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it is used to implement the steps of the method according to any one of claims 1 to 7.

Images