CPU (Central Processing Unit) congestion control method for processing overload of service volume
By introducing a packet loss frequency feedback loop with sampling period granularity into the 5G communication system, the instability of CPU utilization under heavy traffic was solved, smooth control of CPU utilization was achieved, and the stability and service continuity of the system were improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NANJING TICOM TECH
- Filing Date
- 2026-02-04
- Publication Date
- 2026-05-15
AI Technical Summary
When handling heavy workloads, existing technologies struggle to keep CPU utilization levels stable near the expected threshold, causing sudden spikes and drops in call volume, which impacts system stability and service continuity.
A packet loss frequency feedback loop with sampling period granularity is introduced. By calculating the packet loss frequency when the CPU utilization exceeds a threshold and performing uniform packet loss control in the next cycle, combined with the CPU monitoring module, packet statistics module and packet loss control module, controlled packet dropping is achieved to smooth CPU utilization.
Through multiple iterations, the CPU utilization rate tends to stabilize near the target threshold, avoiding the risk of system overload and concentrated packet loss over time, thus improving system stability and service continuity.
Smart Images
Figure CN122053493A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of 5G communication technology, specifically to a method for CPU congestion control in handling traffic overload. Background Technology
[0002] The 5G-R communication system requires the SCP to have a self-protection mechanism under full load operation, and should not cause the equipment to crash due to overload. By continuously increasing the call volume between multiple peers and setting the length of each call packet to 2.6K, without flow control, the CPU reaches the expected utilization rate without packet loss. Further increasing the call volume and enabling flow control allows the CPU utilization rate to be stably maintained near the expected threshold.
[0003] Scp starts a monitoring thread to obtain core data such as CPU from key files that record the system's running status in the Linux system, calculates the CPU utilization, and the collection time granularity can be accurate to the millisecond level. It can be adjusted according to business needs. Theoretically, the smaller the granularity, the more accurate the calculated CPU utilization.
[0004] When the SCP send / receive thread receives a message, it uses the monitored CPU utilization to determine whether CPU congestion control is needed. If the CPU utilization exceeds the expected threshold, the message is forwarded or dropped according to the corresponding congestion control strategy. The strategy can be set to normal processing, direct dropping, or returning a specific HTTP failure code response.
[0005] Existing algorithms can stabilize CPU utilization at the expected value for scenarios with uniform call volume. However, user call volume is not always perfectly uniform. For example, if 6000 calls per second are received, some may be completed within a few hundred milliseconds of congestion. When call volume is concentrated in a short period, it can easily cause a spike in CPU utilization. If congestion control is based solely on CPU utilization, from a temporal perspective, service data packets will be dropped in a concentrated manner, causing a momentary drop in CPU usage. But when the service volume surges again in the next cycle, CPU utilization will continue to spike before falling back down, making it difficult to stabilize near the target threshold. Summary of the Invention
[0006] The purpose of this invention is to provide a method for handling CPU congestion control in the context of excessive workload, so as to solve the problems mentioned in the background art.
[0007] To solve the above-mentioned technical problems, the present invention provides the following technical solution: a method for handling CPU congestion control when the workload is overloaded, including step S1, initializing the sampling period and threshold parameters: configuring the sampling period duration, CPU utilization threshold and communication channel between the HTTP sending and receiving thread and the CPU monitoring module during the SCP startup phase, and clearing the received packet count and forwarded packet count at the beginning of the sampling period, while initializing the packet loss frequency parameters and related state variables for the packet loss control module; Step S2: Collect CPU utilization and count the number of received packets in the current sampling period: The HTTP sending and receiving thread increments the number of received packets in the sampling period by one each time a new packet is received, and obtains the latest CPU utilization monitoring data from the CPU monitoring module for use in determining whether to enter the congestion control branch, while continuously tracking whether the sampling period has ended. Step S3, Normal forwarding is performed when the CPU utilization rate is lower than the threshold: When the HTTP sending and receiving thread detects that the CPU utilization rate does not exceed the preset threshold while processing the current message, the message is directly forwarded to the backend processing module. At the same time, the message is counted in the number of forwarded messages in the current sampling period, and the statistical results of the received and forwarded quantities in the period are retained at the end of the sampling period for subsequent calculations. Step S4: When the CPU utilization rate exceeds the threshold, calculate the packet loss frequency based on the statistical results of the previous sampling period: When the HTTP sending and receiving thread detects that the CPU utilization rate exceeds the preset threshold while processing the message, the packet loss control module calls the statistical results of the number of received messages and the number of forwarded messages in the previous sampling period, calculates the packet loss frequency corresponding to the next sampling period according to the preset calculation relationship, and sends the packet loss frequency as a control parameter to the HTTP sending and receiving thread. Step S5: When the CPU utilization exceeds the threshold, uniform packet loss is performed according to the packet loss frequency and periodic iteration is carried out: In the new sampling period, the HTTP sending and receiving thread determines whether the current packet needs to be dropped based on the current CPU utilization and the packet loss frequency obtained in step S4 when processing each message. By controlling the dropping of messages within the sampling period, the overall packet loss behavior is made to present an approximately uniform distribution on the time axis. At the end of the sampling period, the packet loss frequency of the next sampling period is updated based on the statistical results of this period. In this way, the cyclic iteration achieves the effect of smoothing the CPU utilization.
[0008] According to the above technical solution, step S1 further includes the following sub-steps: S1-1, when SCP starts, a CPU monitoring thread is created, and the sampling period T[n] time length and sampling start time are configured for the monitoring thread, where T[n] represents the nth sampling period and n is the sampling time point number that is incremented in time. The CPU monitoring thread reads the raw statistical data such as the runtime of each processing core in user mode and kernel mode from the key file provided by the operating system that records the system running status. S1-2, the CPU monitoring thread calculates the CPU utilization rate in each sampling period T[n] based on the statistical difference between the current time and the start time of the sampling period, records the calculated CPU utilization rate as cpuUsage, and sets the CPU utilization rate threshold cpuThreshold so as to determine whether to enter the CPU congestion control process in subsequent sampling periods. S1-3 At the beginning of each sampling period T[n], the CPU monitoring thread sends cpuUsage to the HTTP sending and receiving thread through a preset inter-process communication mechanism. At the same time, the statistical variables recvpaks[n] (number of received packets), sendpaks[n] (number of forwarded packets), and undropakts (number of consecutive packets not dropped) are cleared and initialized. The initial value of the initial packet loss frequency variable frequency is preset for subsequent sampling periods, so that subsequent statistics and packet loss control are based only on the data re-accumulated in this sampling period.
[0009] According to the above technical solution, step S2 further includes the following sub-steps: S2-1, When the HTTP receiving thread receives each HTTP request message from the service peer within the current sampling period T[n], it increments the number of received messages recvpaks[n] by one and records a receiving timestamp for the message. The timestamp has a time precision of milliseconds and is used to determine whether the sampling period to which the message belongs is close to the end time. S2-2, After receiving each HTTP request message, the HTTP sending and receiving thread reads the latest CPU utilization monitoring value cpuUsage from the shared data area provided by the CPU monitoring thread, compares cpuUsage with the preset CPU utilization threshold cpuThreshold, and marks the current message as a message that does not need to perform packet loss control when cpuUsage is less than or equal to cpuThreshold, and marks the current message as a message that may need to perform packet loss control when cpuUsage is greater than cpuThreshold. S2-3, the HTTP sending and receiving thread continuously repeats the operations of receiving messages and reading cpuUsage within the sampling period T[n]. It compares the recorded timestamp with the start time of the sampling period T[n]. When it detects that the time interval between the current time and the start time of the sampling period reaches the set duration of the sampling period T[n], it determines that the current sampling period T[n] has ended, providing a time limit for subsequent steps to calculate the packet loss frequency and update the control parameters based on the statistical results of this period.
[0010] According to the above technical solution, step S3 further includes the following sub-steps: S3-1, when the HTTP sending and receiving thread detects that cpuUsage is less than or equal to cpuThreshold while processing a certain message received within the sampling period T[n], it determines that the current message is a message received under the condition that the CPU is not overloaded and does not trigger the packet loss control logic. S3-2, when the condition of S3-1 is met, the HTTP sending and receiving thread forwards the current message to the downstream business processing logic. After the forwarding is successful, the number of forwarded messages in the current sampling period T[n] is incremented by one, and the current message is marked as a normal forwarded message so that the message is not included in the discard statistics. S3-3, within the sampling period T[n], the HTTP sending and receiving thread continuously repeats the operations of receiving packets, comparing cpuUsage and cpuThreshold, and forwarding packets and accumulating sendpaks[n] when the CPU is not overloaded. When the sampling period T[n] ends according to step S2-3, the recvpaks[n] and sendpaks[n] corresponding to this sampling period are retained as the statistical basis for calculating the packet loss frequency in the next sampling period T[n+1], thereby maintaining the normal forwarding path of business packets and forming complete statistical data in the scenario where the CPU is not overloaded.
[0011] According to the above technical solution, step S4 further includes the following sub-steps: S4-1, when the HTTP sending and receiving thread detects that cpuUsage is greater than cpuThreshold when processing a certain message received within the sampling period T[n], the packet loss control module is triggered. The packet loss control module reads the number of received messages recvpaks[n] and the number of forwarded messages sentpaks[n] that have been fixed in the previous sampling period T[n] as input parameters for calculating the current packet loss frequency; S4-2, the packet loss control module calculates the packet loss frequency parameter frequency based on recvpaks[n] and sendpaks[n] in the previous sampling period T[n]. The packet loss frequency frequency is determined according to the following formula: frequency=recvpaks[n] / recvpaks[n]-sendpaks[n], Where T[n] represents the nth sampling period, recvpaks[n] represents the total number of packets received within the sampling period T[n], sendpaks[n] represents the total number of packets successfully forwarded within the sampling period T[n], and frequency represents the packet loss frequency parameter used to control the upper limit of the number of consecutive packets not dropped in the next sampling period T[n+1] when the CPU utilization exceeds cpuThreshold; S4-3 After completing the packet loss frequency calculation in S4-2, the packet loss control module sends the calculated frequency and the associated control status to the HTTP transceiver thread. This enables the HTTP transceiver thread to perform controlled statistics on the number of consecutive undropped packets based on the frequency when processing packets in the subsequent sampling period T[n+1]. As a result, packet loss control is executed in a more uniform manner when the CPU utilization exceeds the threshold.
[0012] According to the above technical solution, step S5 further includes the following sub-steps: S5-1, within the sampling period T[n+1], when the HTTP send and receive thread receives each new message, it increments the number of messages received in the current sampling period recvpaks[n+1] by one, and reads the current CPU usage cpuUsage from the CPU monitoring thread. When cpuUsage is less than or equal to cpuThreshold, the current message is forwarded normally according to the method in step S3-2 and sendpaks[n+1] is incremented by one. The current message does not participate in packet loss control. S5-2, within the sampling period T[n+1], when the HTTP sending and receiving thread detects that cpuUsage is greater than cpuThreshold, it activates the packet loss control logic based on the packet loss frequency parameter frequency obtained in step S4-2, and maintains a variable undropakts to count the number of consecutive undropped packets. When undropakts is less than frequency, the current packet is forwarded and undropakts is incremented by one, and sendpaks[n+1] is incremented by one. When undropakts is greater than or equal to frequency, the current packet is dropped to complete a packet loss operation, and undropakts is cleared to start counting the number of consecutive undropped packets in the next round. Thus, within the sampling period T[n+1], the packet loss behavior is nearly uniformly distributed in the time series. S5-3, at the end of the sampling period T[n+1], the HTTP sending and receiving thread recalculates the new packet loss frequency parameter frequency for the next sampling period T[n+2] based on the recorded recvpaks[n+1] and sendpaks[n+1] and the calculation method given in step S4-2, and provides the updated frequency to the packet loss control module. By repeating the operations from S5-1 to S5-3 through multiple sampling periods, the CPU utilization rate gradually converges to a stable state with small fluctuations around cpuThreshold in the scenario of concentrated high traffic volume access.
[0013] According to the above technical solution, the system adopted by this method includes the following three main modules: The CPU monitoring module is used to periodically read and record key files of system operation status in the operating system where SCP is located and extract CPU usage information to generate monitoring data that reflects real-time CPU utilization, providing a status basis for subsequent congestion control. The message statistics module is used to accumulate and count the number of received and forwarded messages within the current period when the HTTP sending and receiving thread receives a business message, with a preset sampling period as the granularity, so as to provide the packet loss control module with the statistical results of received and forwarded quantities. The packet loss control module is used to execute packet loss control strategies based on the statistical results provided by the packet statistics module when the CPU utilization rate is detected to exceed a preset threshold. When the threshold is not exceeded, the packets are allowed to be forwarded normally. When the threshold is exceeded, the controlled packet loss method is used to suppress the CPU utilization rate from continuing to rise and improve the time stability of the CPU utilization rate.
[0014] According to the above technical solution, the CPU monitoring module includes a CPU data acquisition unit and a CPU utilization calculation unit, wherein: the CPU data acquisition unit is used to read raw data related to CPU usage from the critical status file of the operating system and parse it to obtain the runtime information of each processing core in user mode and kernel mode, providing input for subsequent CPU utilization calculation; the CPU utilization calculation unit is used to periodically calculate the current CPU utilization at the millisecond time granularity based on the raw data obtained by the CPU data acquisition unit and generate a CPU utilization monitoring value, and provide the CPU utilization monitoring value to the HTTP sending and receiving thread; The message statistics module includes a received message counting unit and a forwarded message counting unit. The received message counting unit is used to accumulate the number of received messages according to the current sampling period when the HTTP send / receive thread receives each service message, and output the total number of received messages recvpaks[n] in the sampling period at the end of the sampling period. The forwarded message counting unit is used to accumulate the number of forwarded messages according to the current sampling period when the HTTP send / receive thread successfully forwards each service message, and output the total number of forwarded messages sendpaks[n] in the sampling period at the end of the sampling period. The packet loss control module includes a packet loss frequency calculation unit and a packet loss execution unit. The packet loss frequency calculation unit is used to calculate the packet loss frequency parameter frequency for the next sampling period at the end of each sampling period based on the total number of received packets recvpaks[n] and the total number of forwarded packets sendpaks[n] in the current sampling period, providing a quantitative control basis for subsequent packet loss execution. The packet loss execution unit is used to controllably discard packets in the current sampling period based on the packet loss frequency parameter frequency provided by the packet loss frequency calculation unit when the HTTP send / receive thread processes packets and detects that the CPU utilization rate exceeds a preset threshold, and to update the statistical count and packet loss control status in the current sampling period when discarding packets.
[0015] Compared with existing technologies, the beneficial effects achieved by this invention are as follows: This invention introduces a packet loss frequency feedback loop with sampling period granularity into the traditional CPU utilization congestion control framework. The number of received and forwarded packets in the previous sampling period is used as state variables to calculate the packet loss frequency corresponding to the next sampling period. When the CPU utilization exceeds a preset threshold, packet loss is uniformly performed according to this packet loss frequency, enabling the number of packet losses in each sampling period to adaptively match the service access volume. After several sampling periods of iterative convergence, the CPU utilization changes from its original periodic surge and fall to a dynamic equilibrium with smaller amplitude near the target threshold. In scenarios with concentrated high traffic, this avoids the system risk caused by instantaneous overload and reduces the phenomenon of concentrated excessive packet loss in the service over time, which is beneficial to improving the overall system stability and service continuity. Attached Figure Description
[0016] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a schematic diagram of the CPU congestion control service process of the present invention; Figure 2 This is a schematic diagram of CPU utilization congestion control according to the present invention. Detailed Implementation
[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0018] Please see Figure 1 and Figure 2 The present invention provides a technical solution: a method for handling CPU congestion control when the workload is overloaded, including step S1, initializing sampling period and threshold parameters: configuring the sampling period duration, CPU utilization threshold and communication channel between the HTTP sending and receiving thread and the CPU monitoring module during the SCP startup phase, and clearing the received packet count and forwarded packet count at the beginning of the sampling period, while initializing the packet loss frequency parameters and related state variables for the packet loss control module. Step S2: Collect CPU utilization and count the number of received packets in the current sampling period: The HTTP sending and receiving thread increments the number of received packets in the sampling period by one each time a new packet is received, and obtains the latest CPU utilization monitoring data from the CPU monitoring module for use in determining whether to enter the congestion control branch, while continuously tracking whether the sampling period has ended. Step S3, Normal forwarding is performed when the CPU utilization rate is lower than the threshold: When the HTTP sending and receiving thread detects that the CPU utilization rate does not exceed the preset threshold while processing the current message, the message is directly forwarded to the backend processing module. At the same time, the message is counted in the number of forwarded messages in the current sampling period, and the statistical results of the received and forwarded quantities in the period are retained at the end of the sampling period for subsequent calculations. Step S4: When the CPU utilization rate exceeds the threshold, calculate the packet loss frequency based on the statistical results of the previous sampling period: When the HTTP sending and receiving thread detects that the CPU utilization rate exceeds the preset threshold while processing the message, the packet loss control module calls the statistical results of the number of received messages and the number of forwarded messages in the previous sampling period, calculates the packet loss frequency corresponding to the next sampling period according to the preset calculation relationship, and sends the packet loss frequency as a control parameter to the HTTP sending and receiving thread. Step S5: When the CPU utilization rate exceeds the threshold, uniform packet loss is performed according to the packet loss frequency and periodic iteration is performed: In the new sampling period, the HTTP sending and receiving thread determines whether the current packet needs to be dropped based on the current CPU utilization rate and the packet loss frequency obtained in step S4 when processing each message. By controlling the dropping of messages within the sampling period, the overall packet loss behavior is made to present an approximately uniform distribution on the time axis. At the end of the sampling period, the packet loss frequency of the next sampling period is updated based on the statistical results of this period. In this way, the cyclic iteration achieves the effect of smoothing the CPU utilization rate. Step S1 further includes the following sub-steps: S1-1, when SCP starts, a CPU monitoring thread is created, and the sampling period T[n] time length and sampling start time are configured for the monitoring thread, where T[n] represents the nth sampling period and n is the sampling time point number that is incremented in time. The CPU monitoring thread reads the raw statistical data such as the runtime of each processing core in user mode and kernel mode from the key file provided by the operating system that records the system running status. S1-2, the CPU monitoring thread calculates the CPU utilization rate in each sampling period T[n] based on the statistical difference between the current time and the start time of the sampling period, records the calculated CPU utilization rate as cpuUsage, and sets the CPU utilization rate threshold cpuThreshold so as to determine whether to enter the CPU congestion control process in subsequent sampling periods. S1-3, at the beginning of each sampling period T[n], the CPU monitoring thread sends cpuUsage to the HTTP sending and receiving thread through a preset inter-process communication mechanism. At the same time, the statistical variables recvpaks[n] (number of received packets), sendpaks[n] (number of forwarded packets), and undropakts (number of consecutive packets not dropped) are cleared and initialized. The initial value of the initial packet loss frequency variable frequency is preset for subsequent sampling periods, so that subsequent statistics and packet loss control are based only on the data re-accumulated in this sampling period. By uniformly setting the sampling period T[n] and CPU utilization threshold cpuThreshold during the SCP startup phase, and having an independent CPU monitoring thread collect raw data from the operating system status file and calculate cpuUsage at the beginning of each sampling period, while simultaneously recvpaks[n], sendpaks[n], undropakts, and frequency to zero, all subsequent statistics are strictly segmented according to the sampling period, avoiding interference from residual data across periods on the control logic. This step group ensures that the time granularity and statistical scope of the CPU monitoring data are completely consistent across periods, providing stable and comparable basic data for subsequent packet loss frequency calculation; at the same time, decoupling CPU monitoring from the HTTP sending and receiving threads reduces the overhead of business threads accessing the operating system status file, which is beneficial to improving the overall real-time performance and stability of the system.
[0019] Step S2 further includes the following sub-steps: S2-1, When the HTTP receiving thread receives each HTTP request message from the business peer within the current sampling period T[n], it increments the number of messages received in the current sampling period recvpaks[n] by one and records the receiving timestamp for the message. The time precision of the timestamp is in milliseconds, which is used to determine whether the sampling period to which the message belongs is close to the end time. S2-2, After receiving each HTTP request message, the HTTP sending and receiving thread reads the latest CPU utilization monitoring value cpuUsage from the shared data area provided by the CPU monitoring thread, compares cpuUsage with the preset CPU utilization threshold cpuThreshold, and marks the current message as a message that does not need to perform packet loss control when cpuUsage is less than or equal to cpuThreshold, and marks the current message as a message that may need to perform packet loss control when cpuUsage is greater than cpuThreshold. S2-3, the HTTP sending and receiving thread continuously repeats the operations of receiving messages and reading cpuUsage within the sampling period T[n]. It compares the recorded timestamp with the start time of the sampling period T[n]. When it is detected that the time interval between the current time and the start time of the sampling period reaches the set duration of the sampling period T[n], the current sampling period T[n] is determined to be over, providing a time limit for subsequent steps to calculate the packet loss frequency and update the control parameters based on the statistical results of this period. By accumulating recvpaks[n] and recording timestamps accurate to milliseconds each time an HTTP request packet is received, and simultaneously reading the latest cpuUsage from the shared data area upon packet arrival and comparing it with a preset cpuThreshold, packets are marked in real time as either normal or potentially entering congestion control. This allows for fine-grained characterization of service access intensity and CPU load status at the packet level. Furthermore, comparing the timestamp with the start time of the sampling period ensures the clarity and consistency of the sampling period boundaries. The implementation of this set of steps enables the system to obtain CPU usage and period position information at the moment service packets arrive, providing accurate triggering conditions for subsequent normal forwarding and packet loss control logic. This facilitates timely control activation during periods of concentrated service load, reducing the duration of overload.
[0020] Step S3 further includes the following sub-steps: S3-1, when the HTTP sending and receiving thread detects that cpuUsage is less than or equal to cpuThreshold while processing a certain message received within the sampling period T[n], it determines that the current message is a message received under the condition that the CPU is not overloaded and does not trigger the packet loss control logic. S3-2, when the condition of S3-1 is met, the HTTP sending and receiving thread forwards the current message to the downstream business processing logic. After the forwarding is successful, the number of forwarded messages in the current sampling period T[n] is incremented by one, and the current message is marked as a normal forwarded message so that the message is not included in the discard statistics. S3-3, within the sampling period T[n], the HTTP sending and receiving thread continuously repeats the operations of receiving packets, comparing cpuUsage and cpuThreshold, and forwarding packets and accumulating sendpaks[n] when the CPU is not overloaded. When the sampling period T[n] ends according to step S2-3, the recvpaks[n] and sendpaks[n] corresponding to this sampling period are retained as the statistical basis for calculating the packet loss frequency in the next sampling period T[n+1], so as to maintain the normal forwarding path of business packets and form complete statistical data in the scenario where the CPU is not overloaded. By consistently forwarding packets along the normal path and accumulating sendpaks[n] when cpuUsage is less than or equal to cpuThreshold, and continuously executing a closed-loop process of receiving, judging, forwarding, and statistics throughout the entire sampling period, and retaining pairs of recvpaks[n] and sendpaks[n] as input for calculating the packet loss frequency in the next period after the sampling period ends, this ensures that no unnecessary packet loss is introduced in service areas where CPU overload does not occur, thus maintaining the original throughput and quality of service of the existing network service processing logic. This step group ensures that the system only enables packet loss control when it is truly needed, still covers all services when the CPU load is normal, and simultaneously accumulates complete statistics on received and forwarded data, which is beneficial for the accurate and reliable calculation of subsequent packet loss frequency and avoids unnecessary interference to services caused by the control algorithm under normal load scenarios.
[0021] Step S4 further includes the following sub-steps: S4-1, when the HTTP sending and receiving thread detects that cpuUsage is greater than cpuThreshold when processing a certain message received within the sampling period T[n], the packet loss control module is triggered. The packet loss control module reads the number of received messages recvpaks[n] and the number of forwarded messages sentpaks[n] that have been fixed in the previous sampling period T[n] as input parameters for calculating the current packet loss frequency; S4-2, the packet loss control module calculates the packet loss frequency parameter frequency based on recvpaks[n] and sendpaks[n] in the previous sampling period T[n]. The packet loss frequency frequency is determined according to the following formula: frequency=recvpaks[n] / recvpaks[n]-sendpaks[n], Where T[n] represents the nth sampling period, recvpaks[n] represents the total number of packets received within the sampling period T[n], sendpaks[n] represents the total number of packets successfully forwarded within the sampling period T[n], and frequency represents the packet loss frequency parameter used to control the upper limit of the number of consecutive packets not dropped in the next sampling period T[n+1] when the CPU utilization exceeds cpuThreshold; S4-3 After completing the packet loss frequency calculation in S4-2, the packet loss control module sends the calculated frequency and the associated control status to the HTTP transceiver thread. This enables the HTTP transceiver thread to perform controlled statistics on the number of consecutive undropped packets based on the frequency when processing packets in the subsequent sampling period T[n+1]. As a result, when the CPU utilization exceeds the threshold, packet loss control is performed in a more uniform manner. When `cpuUsage` is detected to be greater than `cpuThreshold`, instead of making a rough judgment based solely on the current instantaneous CPU utilization, the algorithm actively calls upon the statistical results of `recvpaks[n]` and `sendpaks[n]` from the previous sampling period `T[n]`. The difference between the service access strength and the actual forwarding capacity of the previous period is converted into a packet loss frequency parameter `frequency` through a preset calculation relationship and sent to the HTTP sending and receiving threads. This allows the packet loss control strength to adaptively match the overload level of the previous period. This step group is equivalent to introducing a closed-loop feedback of periodic statistics → parameter calculation → parameter distribution on the basis of traditional CPU utilization threshold control. This gives the control algorithm the ability to remember and adapt to the evolving trends of service volume, avoiding the control lag or over-suppression problems caused by relying entirely on instantaneous CPU utilization. It helps to upgrade the overall control process from a simple threshold switch to a quantitative adjustment based on periodic statistics.
[0022] Step S5 further includes the following sub-steps: S5-1, within the sampling period T[n+1], when the HTTP send and receive thread receives each new message, it increments the number of messages received in the current sampling period recvpaks[n+1] by one, and reads the current CPU usage cpuUsage from the CPU monitoring thread. When cpuUsage is less than or equal to cpuThreshold, the current message is forwarded normally according to the method in step S3-2 and sendpaks[n+1] is incremented by one. The current message does not participate in packet loss control. S5-2, within the sampling period T[n+1], when the HTTP sending and receiving thread detects that cpuUsage is greater than cpuThreshold, it activates the packet loss control logic based on the packet loss frequency parameter frequency obtained in step S4-2, and maintains a variable undropakts to count the number of consecutive undropped packets. When undropakts is less than frequency, the current packet is forwarded and undropakts is incremented by one, and sendpaks[n+1] is incremented by one. When undropakts is greater than or equal to frequency, the current packet is dropped to complete a packet loss operation, and undropakts is cleared to start counting the number of consecutive undropped packets in the next round. Thus, within the sampling period T[n+1], the packet loss behavior is nearly uniformly distributed in the time series. S5-3, at the end of the sampling period T[n+1], the HTTP sending and receiving thread recalculates the new packet loss frequency parameter frequency for the next sampling period T[n+2] based on the recorded recvpaks[n+1] and sendpaks[n+1] and the calculation method given in step S4-2, and provides the updated frequency to the packet loss control module. By repeating the operations from S5-1 to S5-3 through multiple sampling periods, the CPU utilization rate gradually converges to a stable state with small fluctuations around cpuThreshold in the scenario of concentrated high traffic volume access. Within the new sampling period T[n+1], when cpuUsage is less than or equal to cpuThreshold, packets are forwarded along the normal path, and recvpaks[n+1] and sendpaks[n+1] are accumulated. When cpuUsage is greater than cpuThreshold, the accumulation and clearing of undropakts are controlled according to frequency. Packets are forwarded when undropakts are less than frequency, and packet loss is performed and undropakts are set to zero when undropakts are greater than or equal to frequency. Through this mechanism of limiting the number of consecutive undropped packets, packet loss events are approximately uniformly distributed along the time axis within the sampling period. At the end of the sampling period, recvpaks[n+1] and sendpaks[n+1] are used to recalculate a new frequency for the control of the next period T[n+2], achieving iterative convergence across multiple periods. This step group, on the one hand, truly implements the packet loss frequency obtained from the previous cycle into a uniform time-based discard behavior at the specific packet level, avoiding large-scale packet loss within a short time window when service access is highly concentrated. On the other hand, by periodically updating the frequency, the CPU utilization gradually converges to a stable range close to cpuThreshold over multiple sampling cycles, significantly reducing the oscillation phenomenon of CPU utilization rising, falling, and rising again under the original simple threshold control. Thus, stable CPU load control and more balanced service carrying quality are achieved in scenarios with concentrated high traffic access.
[0023] The system used in this method includes the following three main modules: The CPU monitoring module is used to periodically read and record key files of system operation status in the operating system where SCP is located and extract CPU usage information to generate monitoring data that reflects real-time CPU utilization, providing a status basis for subsequent congestion control. The message statistics module is used to accumulate and count the number of received and forwarded messages within the current period when the HTTP sending and receiving thread receives a business message, with a preset sampling period as the granularity, so as to provide the packet loss control module with the statistical results of received and forwarded quantities. The packet loss control module is used to execute packet loss control strategies based on the statistical results provided by the packet statistics module when the CPU utilization rate is detected to exceed a preset threshold. When the threshold is not exceeded, the packets are allowed to be forwarded normally. When the threshold is exceeded, the controlled packet loss method is used to suppress the CPU utilization rate from continuing to rise and improve the time stability of the CPU utilization rate. The CPU monitoring module includes a CPU data acquisition unit and a CPU utilization calculation unit. The CPU data acquisition unit is used to read raw data related to CPU usage from the critical status file of the operating system and parse it to obtain the runtime information of each processing core in user mode and kernel mode, providing input for subsequent CPU utilization calculation. The CPU utilization calculation unit is used to periodically calculate the current CPU utilization at the millisecond time granularity based on the raw data obtained by the CPU data acquisition unit and generate a CPU utilization monitoring value, which is then provided to the HTTP send / receive thread. The message statistics module includes a received message counting unit and a forwarded message counting unit. The received message counting unit is used to accumulate the number of received messages according to the current sampling period when the HTTP send / receive thread receives each service message, and output the total number of received messages recvpaks[n] in the sampling period at the end of the sampling period. The forwarded message counting unit is used to accumulate the number of forwarded messages according to the current sampling period when the HTTP send / receive thread successfully forwards each service message, and output the total number of forwarded messages sendpaks[n] in the sampling period at the end of the sampling period. The packet loss control module includes a packet loss frequency calculation unit and a packet loss execution unit. The packet loss frequency calculation unit is used to calculate the packet loss frequency parameter frequency for the next sampling period at the end of each sampling period based on the total number of received packets recvpaks[n] and the total number of forwarded packets sendpaks[n] in the current sampling period, providing a quantitative control basis for subsequent packet loss execution. The packet loss execution unit is used to controllably discard packets in the current sampling period based on the packet loss frequency parameter frequency provided by the packet loss frequency calculation unit when the HTTP send / receive thread processes packets and detects that the CPU utilization rate exceeds a preset threshold, and to update the statistical count and packet loss control status in the current sampling period when discarding packets.
[0024] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "include," "contain," 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.
[0025] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A method for CPU congestion control in handling excessive workload, characterized in that: include: Step S1, Initialize sampling period and threshold parameters: During the SCP startup phase, configure the sampling period duration, CPU utilization threshold, and communication channel between the HTTP sending and receiving thread and the CPU monitoring module. At the beginning of the sampling period, clear the received message count and forwarded message count, and initialize the packet loss frequency parameters and related status variables for the packet loss control module. Step S2: Collect CPU utilization and count the number of received packets in the current sampling period: The HTTP sending and receiving thread increments the number of received packets in the sampling period by one each time a new packet is received, and obtains the latest CPU utilization monitoring data from the CPU monitoring module for use in determining whether to enter the congestion control branch, while continuously tracking whether the sampling period has ended. Step S3, Normal forwarding is performed when the CPU utilization rate is lower than the threshold: When the HTTP sending and receiving thread detects that the CPU utilization rate does not exceed the preset threshold while processing the current message, the message is directly forwarded to the backend processing module. At the same time, the message is counted in the number of forwarded messages in the current sampling period, and the statistical results of the received and forwarded quantities in the period are retained at the end of the sampling period for subsequent calculations. Step S4: When the CPU utilization rate exceeds the threshold, calculate the packet loss frequency based on the statistical results of the previous sampling period: When the HTTP sending and receiving thread detects that the CPU utilization rate exceeds the preset threshold while processing the message, the packet loss control module calls the statistical results of the number of received messages and the number of forwarded messages in the previous sampling period, calculates the packet loss frequency corresponding to the next sampling period according to the preset calculation relationship, and sends the packet loss frequency as a control parameter to the HTTP sending and receiving thread. Step S5: When the CPU utilization exceeds the threshold, uniform packet loss is performed according to the packet loss frequency and periodic iteration is carried out: In the new sampling period, the HTTP sending and receiving thread determines whether the current packet needs to be dropped based on the current CPU utilization and the packet loss frequency obtained in step S4 when processing each message. By controlling the dropping of messages within the sampling period, the overall packet loss behavior is made to present an approximately uniform distribution on the time axis. At the end of the sampling period, the packet loss frequency of the next sampling period is updated based on the statistical results of this period. In this way, the cyclic iteration achieves the effect of smoothing the CPU utilization.
2. The method for CPU congestion control in handling overloaded workloads according to claim 1, characterized in that: Step S1 further includes the following sub-steps: S1-1, when SCP starts, a CPU monitoring thread is created, and the sampling period T[n] time length and sampling start time are configured for the monitoring thread, where T[n] represents the nth sampling period and n is the sampling time point number that is incremented in time. The CPU monitoring thread reads the raw statistical data such as the runtime of each processing core in user mode and kernel mode from the key file provided by the operating system that records the system running status. S1-2, the CPU monitoring thread calculates the CPU utilization rate in each sampling period T[n] based on the statistical difference between the current time and the start time of the sampling period, records the calculated CPU utilization rate as cpuUsage, and sets the CPU utilization rate threshold cpuThreshold so as to determine whether to enter the CPU congestion control process in subsequent sampling periods. S1-3 At the beginning of each sampling period T[n], the CPU monitoring thread sends cpuUsage to the HTTP sending and receiving thread through a preset inter-process communication mechanism. At the same time, the statistical variables recvpaks[n] (number of received packets), sendpaks[n] (number of forwarded packets), and undropakts (number of consecutive packets not dropped) are cleared and initialized. The initial value of the initial packet loss frequency variable frequency is preset for subsequent sampling periods, so that subsequent statistics and packet loss control are based only on the data re-accumulated in this sampling period.
3. The method for CPU congestion control in handling overloaded workloads according to claim 2, characterized in that: Step S2 further includes the following sub-steps: S2-1, When the HTTP receiving thread receives each HTTP request message from the service peer within the current sampling period T[n], it increments the number of received messages recvpaks[n] by one and records a receiving timestamp for the message. The timestamp has a time precision of milliseconds and is used to determine whether the sampling period to which the message belongs is close to the end time. S2-2, After receiving each HTTP request message, the HTTP sending and receiving thread reads the latest CPU utilization monitoring value cpuUsage from the shared data area provided by the CPU monitoring thread, compares cpuUsage with the preset CPU utilization threshold cpuThreshold, and marks the current message as a message that does not need to perform packet loss control when cpuUsage is less than or equal to cpuThreshold, and marks the current message as a message that may need to perform packet loss control when cpuUsage is greater than cpuThreshold. S2-3, the HTTP sending and receiving thread continuously repeats the operations of receiving messages and reading cpuUsage within the sampling period T[n]. It compares the recorded timestamp with the start time of the sampling period T[n]. When it detects that the time interval between the current time and the start time of the sampling period reaches the set duration of the sampling period T[n], it determines that the current sampling period T[n] has ended, providing a time limit for subsequent steps to calculate the packet loss frequency and update the control parameters based on the statistical results of this period.
4. The method for CPU congestion control in handling overloaded workloads according to claim 3, characterized in that: Step S3 further includes the following sub-steps: S3-1, when the HTTP sending and receiving thread detects that cpuUsage is less than or equal to cpuThreshold while processing a certain message received within the sampling period T[n], it determines that the current message is a message received under the condition that the CPU is not overloaded and does not trigger the packet loss control logic. S3-2, when the condition of S3-1 is met, the HTTP sending and receiving thread forwards the current message to the downstream business processing logic. After the forwarding is successful, the number of forwarded messages in the current sampling period T[n] is incremented by one, and the current message is marked as a normal forwarded message so that the message is not included in the discard statistics. S3-3, within the sampling period T[n], the HTTP sending and receiving thread continuously repeats the operations of receiving packets, comparing cpuUsage and cpuThreshold, and forwarding packets and accumulating sendpaks[n] when the CPU is not overloaded. When the sampling period T[n] ends according to step S2-3, the recvpaks[n] and sendpaks[n] corresponding to this sampling period are retained as the statistical basis for calculating the packet loss frequency in the next sampling period T[n+1], thereby maintaining the normal forwarding path of business packets and forming complete statistical data in the scenario where the CPU is not overloaded.
5. The method for CPU congestion control in handling overloaded workloads according to claim 4, characterized in that: Step S4 further includes the following sub-steps: S4-1, when the HTTP sending and receiving thread detects that cpuUsage is greater than cpuThreshold when processing a certain message received within the sampling period T[n], the packet loss control module is triggered. The packet loss control module reads the number of received messages recvpaks[n] and the number of forwarded messages sentpaks[n] that have been fixed in the previous sampling period T[n] as input parameters for calculating the current packet loss frequency; S4-2, the packet loss control module calculates the packet loss frequency parameter frequency based on recvpaks[n] and sendpaks[n] in the previous sampling period T[n]. The packet loss frequency frequency is determined according to the following formula: frequency=recvpaks[n] / recvpaks[n]-sendpaks[n], Where T[n] represents the nth sampling period, recvpaks[n] represents the total number of packets received within the sampling period T[n], sendpaks[n] represents the total number of packets successfully forwarded within the sampling period T[n], and frequency represents the packet loss frequency parameter used to control the upper limit of the number of consecutive packets not dropped in the next sampling period T[n+1] when the CPU utilization exceeds cpuThreshold; S4-3 After completing the packet loss frequency calculation in S4-2, the packet loss control module sends the calculated frequency and the associated control status to the HTTP transceiver thread. This enables the HTTP transceiver thread to perform controlled statistics on the number of consecutive undropped packets based on the frequency when processing packets in the subsequent sampling period T[n+1]. As a result, packet loss control is executed in a more uniform manner when the CPU utilization exceeds the threshold.
6. The method for CPU congestion control in handling overloaded workloads according to claim 5, characterized in that: Step S5 further includes the following sub-steps: S5-1, within the sampling period T[n+1], when the HTTP send and receive thread receives each new message, it increments the number of messages received in the current sampling period recvpaks[n+1] by one, and reads the current CPU usage cpuUsage from the CPU monitoring thread. When cpuUsage is less than or equal to cpuThreshold, the current message is forwarded normally according to the method in step S3-2 and sendpaks[n+1] is incremented by one. The current message does not participate in packet loss control. S5-2, within the sampling period T[n+1], when the HTTP sending and receiving thread detects that cpuUsage is greater than cpuThreshold, it enables the packet loss control logic based on the packet loss frequency parameter frequency obtained in step S4-2, maintains a variable undropakts that counts the number of consecutive undropped packets, and when undropakts is less than frequency, it forwards the current packet and increments undropakts by one, and at the same time increments sendpaks[n+1] by one; When undropakts is greater than or equal to frequency, the current packet is dropped to complete a packet loss operation, and undropakts is cleared to start counting the number of consecutive undropped packets in the next round, so that the packet loss behavior is nearly uniformly distributed in the time series within the sampling period T[n+1]. S5-3, at the end of the sampling period T[n+1], the HTTP sending and receiving thread recalculates the new packet loss frequency parameter frequency for the next sampling period T[n+2] based on the recorded recvpaks[n+1] and sendpaks[n+1] and the calculation method given in step S4-2, and provides the updated frequency to the packet loss control module. By repeating the operations from S5-1 to S5-3 through multiple sampling periods, the CPU utilization rate gradually converges to a stable state with small fluctuations around cpuThreshold in the scenario of concentrated high traffic volume access.
7. The method for CPU congestion control in handling overloaded workloads according to claim 6, characterized in that: The system used in this method includes the following three main modules: The CPU monitoring module is used to periodically read and record key files of system operation status in the operating system where SCP is located and extract CPU usage information to generate monitoring data that reflects real-time CPU utilization, providing a status basis for subsequent congestion control. The message statistics module is used to accumulate and count the number of received and forwarded messages within the current period when the HTTP sending and receiving thread receives a business message, with a preset sampling period as the granularity, so as to provide the packet loss control module with the statistical results of received and forwarded quantities. The packet loss control module is used to execute packet loss control strategies based on the statistical results provided by the packet statistics module when the CPU utilization rate is detected to exceed a preset threshold. When the threshold is not exceeded, the packets are allowed to be forwarded normally. When the threshold is exceeded, the controlled packet loss method is used to suppress the CPU utilization rate from continuing to rise and improve the time stability of the CPU utilization rate.
8. The method for CPU congestion control in handling overloaded workloads according to claim 7, characterized in that: The CPU monitoring module includes a CPU data acquisition unit and a CPU utilization calculation unit. The CPU data acquisition unit reads raw data related to CPU usage from the operating system's critical status files and parses it to obtain runtime information for each processing core in user mode and kernel mode, providing input for subsequent CPU utilization calculation. The CPU utilization calculation unit, based on the raw data obtained by the CPU data acquisition unit, periodically calculates the current CPU utilization at a millisecond-level time granularity and generates a CPU utilization monitoring value, which is then provided to the HTTP sending and receiving thread. The message statistics module includes a received message counting unit and a forwarded message counting unit. The received message counting unit is used to accumulate the number of received messages according to the current sampling period when the HTTP send / receive thread receives each service message, and output the total number of received messages recvpaks[n] in the sampling period at the end of the sampling period. The forwarded message counting unit is used to accumulate the number of forwarded messages according to the current sampling period when the HTTP send / receive thread successfully forwards each service message, and output the total number of forwarded messages sendpaks[n] in the sampling period at the end of the sampling period. The packet loss control module includes a packet loss frequency calculation unit and a packet loss execution unit. The packet loss frequency calculation unit is used to calculate the packet loss frequency parameter frequency for the next sampling period at the end of each sampling period based on the total number of received packets recvpaks[n] and the total number of forwarded packets sendpaks[n] in the current sampling period, providing a quantitative control basis for subsequent packet loss execution. The packet loss execution unit is used to controllably discard packets in the current sampling period based on the packet loss frequency parameter frequency provided by the packet loss frequency calculation unit when the HTTP send / receive thread processes packets and detects that the CPU utilization rate exceeds a preset threshold, and to update the statistical count and packet loss control status in the current sampling period when discarding packets.