Thread pool management method and computing device

Abstract

The invention provides a thread pool management method and computing equipment, when a thread group corresponding to a service needs to be expanded, it is ensured that the sum of the number of threads included in the thread pool is fixed, and the thread group corresponding to each service at least comprises a guarantee thread group, so that CPU resources corresponding to each service cannot be preempted, and the service performance of the service is improved. Therefore, the service stability of the non-hotspot service which is not expanded is ensured, the CPU resource of the service is not preempted by the traffic peak service, and the service experience of a user is ensured.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method for managing a thread pool and a computing device. Background Technology

[0002] With the development of the internet, business complexity is increasing, as is the demand for timely information processing. More and more businesses require multi-threaded processing. "Thread pool technology" can effectively manage multi-threaded resources by controlling the number of threads through certain strategies and dynamically allocating tasks to these threads based on system load. This avoids the overhead of frequently creating and destroying threads, improving thread reusability and scalability. "Thread pool technology" separates business session requests from central processing unit (CPU) worker threads, enabling the isolation and allocation of CPU resources. In multi-tenant systems, the thread pool groups threads, with each group serving the business of a specific tenant.

[0003] In real-world business scenarios, some services have low traffic volumes. These services require continuous and stable operation. If resources are excessively over-allocated, these services will easily be preempted by other services during peak traffic periods, threatening their stability. In CPU resource contention scenarios, the CPU resources a service can acquire are strongly correlated with the number of its threads. Excessive expansion of the thread group for hot services may lead to severe CPU resource preemption by thread groups for other services. Therefore, the thread pool's allocation and scheduling methods for threads in different service thread groups directly affect the stability of each service and the user experience.

[0004] However, existing scheduling schemes cannot guarantee the stability of low-traffic services, making such services susceptible to the impact of high-traffic services. Summary of the Invention

[0005] This application provides a thread pool management method that, while satisfying the needs of thread groups for various services to scale up and down as required and share resources, also maintains a fixed total number of threads in the thread pool, ensuring that the CPU resources of each thread remain constant. Furthermore, the number of threads in each thread group is not less than the guaranteed number of threads, thus guaranteeing the stability of various services and the user's service experience.

[0006] Firstly, a method for managing thread pools is provided, which can be executed by computing devices (e.g., servers), computing device clusters, virtual instances (virtual machines, container bare metal servers), or by components of computing devices (e.g., chips or circuits).

[0007] The method includes: acquiring parameter configuration information, which includes a first parameter and a second parameter, wherein the first parameter represents the number of threads supported by a core of a central processing unit (CPU), and the second parameter represents the number of cores of the CPU; determining the total number of threads included in a thread pool based on the parameter configuration information, wherein the total number of threads included in the thread pool is fixed; acquiring service configuration information, which includes a third parameter corresponding to each of multiple services, wherein the third parameter represents the minimum number of CPU cores corresponding to the service; determining the number of guarantee threads corresponding to each of the multiple services based on the third parameter and the first parameter; and controlling the threads included in the thread groups corresponding to each of the multiple services based on the total number of threads included in the thread pool and the number of guarantee threads corresponding to each of the multiple services, wherein each thread group corresponding to each service includes at least a first number of threads, the first number being the number of guarantee threads.

[0008] In this application's embodiments, "multiple services" can be understood as multiple services of the same user, or multiple services of different users.

[0009] For example, parameter configuration information can be configured by the user through a configuration interface. For example, business configuration information can be pre-configured by the user.

[0010] In this embodiment of the application, the ratio between the total number of threads included in the thread pool and the number of cores of the central processing unit is the first parameter.

[0011] In this embodiment, during the thread group expansion process, the total number of threads in the thread pool remains unchanged. This can also be understood as the CPU resources of each thread remaining stable. Furthermore, this application proposes that each service's corresponding thread group must include at least a guaranteed thread group. This ensures the stability of non-hotspot services that are not expanded, preventing their CPU resources from being preempted by peak traffic periods. It also avoids increased CPU context switching overhead and concurrency conflicts caused by an excessive number of threads in the thread pool, maintaining an optimal thread-to-core ratio, thereby improving overall system efficiency and ensuring a superior user experience.

[0012] In conjunction with the first aspect, in one possible implementation, the method further includes: determining the number of super-split threads corresponding to each of the multiple services based on the total number of threads included in the thread pool and the third parameter corresponding to each of the multiple services, wherein the number of super-split threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the service, in addition to the guarantee threads; and controlling the threads included in the thread group corresponding to each of the multiple services based on the total number of threads included in the thread pool and the number of guarantee threads corresponding to each of the multiple services, including: controlling the threads included in the thread group corresponding to each of the multiple services based on the total number of threads included in the thread pool, the number of guarantee threads corresponding to each of the multiple services, and the number of super-split threads corresponding to each of the multiple services.

[0013] As can be seen from the above scheme, in this embodiment of the application, each service's corresponding thread group includes at least a guarantee thread, and may further include super-division threads. Therefore, the number of threads that each service should have may include the number of guarantee threads and the number of super-division threads, thereby meeting the super-division requirements of the service and the scaling requirements of the thread group.

[0014] In conjunction with the first aspect, in one possible implementation, the business configuration information also includes a fourth parameter corresponding to each of the multiple businesses. The fourth parameter is used to characterize the number of demand threads corresponding to the business. Based on the total number of threads included in the thread pool, the number of guarantee threads corresponding to each of the multiple businesses, and the number of super-division threads corresponding to each of the multiple businesses, the threads included in the thread groups corresponding to each of the multiple businesses are controlled. This includes: based on the total number of threads included in the thread pool, the number of guarantee threads corresponding to each of the multiple businesses, the number of super-division threads corresponding to each of the multiple businesses, and the number of demand threads corresponding to each of the multiple businesses, the threads included in the thread groups corresponding to each of the multiple businesses are controlled.

[0015] In conjunction with the first aspect, in one possible implementation, when the number of demand threads corresponding to each of the multiple services is less than or equal to the number of deserved threads corresponding to each of the multiple services, the number of threads included in the thread group corresponding to each of the multiple services is the number of demand threads. Here, the number of deserved threads is the sum of the number of guaranteed threads and the number of super-allocated threads. The number of super-allocated threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the service, in addition to the guaranteed threads.

[0016] In conjunction with the first aspect, in one possible implementation, when the number of demand threads corresponding to each of the multiple services is greater than or equal to the number of threads that should be allocated to each of the multiple services, the number of threads included in the thread group corresponding to each of the multiple services is the number of threads that should be allocated. The number of threads that should be allocated is the sum of the number of guaranteed threads and the number of super-allocated threads. The number of super-allocated threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the service, in addition to the guaranteed threads.

[0017] In conjunction with the first aspect, in one possible implementation, if the number of required threads corresponding to the first business among multiple businesses is less than or equal to the number of threads that should be allocated to the first business, the number of threads included in the thread group corresponding to the first business is the required threads corresponding to the first business; if the number of required threads corresponding to each of the remaining businesses (excluding the first business) is greater than or equal to the number of threads that should be allocated to each of the remaining businesses, the number of threads included in the thread group corresponding to each of the remaining businesses is the target thread number, wherein the target thread number is less than or equal to the allocated thread number, the allocated thread number is determined based on the third parameter corresponding to each of the remaining businesses and the number of remaining threads, and the number of remaining threads is the total number of threads remaining in the thread pool excluding the number of required threads corresponding to the first business; wherein the number of threads that should be allocated is the sum of the number of guaranteed threads and the number of super-allocated threads, and the number of super-allocated threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the business, in addition to the guaranteed threads.

[0018] In conjunction with the first aspect, in one possible implementation, the business configuration information also includes a fifth parameter corresponding to each of the multiple businesses. The fifth parameter is used to characterize the maximum number of threads corresponding to the business. The number of target threads corresponding to the remaining businesses is the minimum of the maximum number of threads corresponding to the remaining businesses and the number of allocated threads.

[0019] In this embodiment, a method is proposed that the minimum number of CPU cores corresponding to a business function be used as the preemption weight for threads in a thread group. The number of super-allocated threads is then allocated to each business's thread group according to this weight. When the number of threads required by a business is less than the number of threads it should receive, threads are allocated to the business's thread group based on the required number of threads. Conversely, when the number of threads required by a business is greater than the number of threads it should receive, threads are allocated to the business's thread group based on the preemption weight. This method achieves thread resource sharing and supports CPU over-allocation while ensuring a stable total number of threads in the thread pool, thereby improving CPU resource utilization.

[0020] In conjunction with the first aspect, in one possible implementation, the method is applied to a cloud service system, which includes infrastructure that provides cloud services. The infrastructure includes at least one cloud data center, and each cloud data center includes at least one server. The infrastructure is used to execute the scheme in any of the possible implementations of the above method.

[0021] Secondly, this application proposes a computing device for performing the method described in the first aspect. Specifically, the device may include units and / or modules for performing the method proposed in this application, such as an acquisition module, a determination module, and a control module.

[0022] For example, the computing device may be a server, a server cluster, or the infrastructure that provides cloud services in a cloud service system.

[0023] For example, the computing device can be a virtual instance, such as a virtual machine, a container bare metal server, etc.

[0024] Thirdly, this application provides a computing device comprising: at least one processor for executing a computer program or instructions stored in a memory to perform the method described in the first aspect. Optionally, the device further comprises a memory for storing the computer program or instructions. Optionally, the device further comprises a communication interface through which the processor reads the computer program or instructions stored in the memory.

[0025] In one implementation, the computing device is a device for implementing the functions of the above-described method in a chip.

[0026] In another implementation, the computing device is a chip, chip system, or circuit used to implement the functions described above in a chip.

[0027] Fourthly, this application provides a processor, including: an input circuit, an output circuit, and a processing circuit. The processing circuit is used to receive signals through the input circuit and to transmit signals through the output circuit, causing the processor to execute the method described in the first aspect.

[0028] In specific implementation, the processor can be one or more chips, the input circuit can be input pins, the output circuit can be output pins, and the processing circuit can be transistors, gate circuits, flip-flops, and various logic circuits. The input signal received by the input circuit can be received and input by, for example, but not limited to, a transceiver, and the signal output by the output circuit can be, for example, but not limited to, output to and transmitted by a transmitter. Furthermore, the input circuit and the output circuit can be the same circuit, which is used as both the input circuit and the output circuit at different times. This application does not limit the specific implementation of the processor and various circuits.

[0029] Unless otherwise specified, or if it does not contradict its actual function or internal logic in the relevant description, the transmission and acquisition / reception operations involved in the processor can be understood as processor output and reception, input and other operations, or as transmission and reception operations performed by radio frequency circuits and antennas. This application does not limit them in this regard.

[0030] Fifthly, a processing apparatus is provided, including a processor and a memory. The processor is used to read instructions stored in the memory and to receive signals via a transceiver and transmit signals via a transmitter to execute the method described in the first aspect.

[0031] Optionally, the processor may be one or more, and the memory may be one or more.

[0032] Optionally, the memory may be integrated with the processor, or the memory may be separated from the processor.

[0033] In specific implementation, the memory can be a non-transitory memory, such as read-only memory (ROM), which can be integrated with the processor on the same chip or set on different chips. The embodiments of this application do not limit the type of memory or the way the memory and processor are set.

[0034] It should be understood that the relevant data interaction process, such as sending the first information, can be the process of the processor outputting the first information, and the receiving capability information can be the process of the processor receiving input capability information. Specifically, the data output by the processor can be sent to the transmitter, and the input data received by the processor can come from the transceiver. Here, the transmitter and the transceiver can be collectively referred to as the transceiver.

[0035] The processing device mentioned in the fifth aspect above can be one or more chips. The processor in the processing device can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, integrated circuit, etc.; when implemented in software, the processor can be a general-purpose processor that reads software code stored in memory. This memory can be integrated into the processor or located outside the processor and exist independently.

[0036] In a sixth aspect, a computing cluster is provided, including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, such that the computing device cluster performs the method described in any possible implementation of the first aspect.

[0037] Optionally, the processor can be a general-purpose processor, which can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, integrated circuit, etc.; when implemented in software, the processor can be a general-purpose processor that reads software code stored in memory. This memory can be integrated into the processor or located outside the processor and exist independently.

[0038] In a seventh aspect, a computer-readable storage medium is provided that stores program code for execution by a device, the program code including the method described in the first aspect.

[0039] Eighthly, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the method described in the first aspect.

[0040] A ninth aspect provides a chip system including a processor for calling and running a computer program from a memory, causing a device equipped with the chip system to perform the method of the first aspect described above. Attached Figure Description

[0041] Figure 1 This is a schematic diagram of a thread pool provided in an embodiment of this application.

[0042] Figure 2 This is a schematic diagram of a system architecture applicable to an embodiment of this application.

[0043] Figure 3 This is a schematic block diagram of a thread pool management method 300 provided in an embodiment of this application.

[0044] Figure 4 This is a schematic diagram of a thread pool applicable to an embodiment of this application.

[0045] Figure 5 This is a schematic flowchart of a thread pool management method 500 provided in an embodiment of this application.

[0046] Figure 6 This is a schematic diagram of a cloud service system architecture applicable to the embodiments of this application.

[0047] Figure 7 This is a schematic block diagram of the computing device 700 provided in the embodiments of this application.

[0048] Figure 8 This is a schematic block diagram of a computing device 800 provided in an embodiment of this application.

[0049] Figure 9This is a schematic diagram of the architecture of a computing device cluster provided in an embodiment of this application.

[0050] Figure 10 This is a schematic diagram showing the connection between computing devices 900A and 900B via a network provided in an embodiment of this application. Detailed Implementation

[0051] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0052] To facilitate understanding of the technical solutions provided in the embodiments of this application, the technical terms involved in this application are briefly introduced below. It should be noted that the introduction of technical terms in this application is only for the purpose of helping to understand the technical solutions and should not be construed as limiting the application.

[0053] 1. Thread pool technology

[0054] For example, a "thread pool" is a form of multi-threaded processing where tasks are added to a queue during processing, and these tasks are automatically started after threads are created. Thread pool technology separates business session requests from the central processing unit (CPU) worker threads, enabling the isolation and allocation of CPU resources. Simultaneously, during periods of high business activity, the task queue can maintain a stable number of threads, thus maintaining a better thread / core ratio and improving overall efficiency. In multi-tenant scenarios, the thread pool can be divided into multiple thread groups, each serving a specific tenant's business, and the number of threads can be adjusted based on business usage. For example... Figure 1 As shown, for example, the thread pool includes three thread groups, each serving a different business function. Each thread group has its own listener to listen for business requests and distribute them to threads within the group. The listener also adds requests for business functions exceeding the number of threads to a waiting queue, thereby maintaining a stable number of threads and making the system run more efficiently. In other words, if all threads in the current thread group are busy and there are no spare threads to provide services for the business, then the requests for that business function will be queued.

[0055] 2. CPU resource overload

[0056] Typically, traffic to underlying systems like databases in financial, e-commerce, and social networking businesses fluctuates significantly, with peak traffic lasting only a short period, leaving CPU resources idle for most of the time. Deploying multiple services across peak traffic periods within the same system (also known as "resource multi-tenancy") can substantially improve CPU utilization. In a multi-service (or "multi-tenant") thread pool, the pool needs to be able to expand its thread count during peak traffic periods for a particular service to effectively allocate CPU resources to that service's thread group. However, this can lead to a situation where the number of threads created in the pool exceeds the system's maximum allowed number, resulting in resource over-allocation.

[0057] In real-world business scenarios, some services experience low traffic. The key requirement for these services is continuous stability. If resources are excessively over-allocated, these services are easily preempted by other services during peak traffic periods, threatening their stability. In CPU resource contention scenarios, the CPU resources a service can acquire are strongly correlated with the number of its threads. Excessive expansion of the thread group for hot-traffic services can lead to severe CPU resource preemption for other service thread groups. Therefore, the thread pool's allocation and scheduling method for threads in different service thread groups directly impacts the stability of each service and the user experience. However, existing scheduling schemes cannot guarantee the stability of low-traffic services, making them vulnerable to the influence of hot-traffic services.

[0058] In view of this, this application provides a thread pool management method that ensures that the total number of threads in the thread pool is fixed when the thread group corresponding to a business needs to be expanded, and that each business thread group includes at least a guaranteed thread group, so that the CPU resources corresponding to each business will not be preempted, thereby ensuring the business stability of non-hotspot businesses that have not been expanded, and ensuring that the CPU resources of such businesses are not preempted by peak traffic businesses, thus guaranteeing the user's business experience.

[0059] Figure 2 This is a schematic diagram of a system architecture to which this application applies, such as Figure 2 As shown, the system includes a client 210 and a scheduling module 220. The scheduling module 220 in the thread pool can control the number of threads in the thread group corresponding to each service, thereby processing service requests sent from the client 210.

[0060] In one possible implementation, the scheduling module 220 is used to obtain parameter configuration information, which includes a first parameter and a second parameter; the scheduling module 220 is used to determine the total number of threads included in the thread pool based on the parameter configuration information; the scheduling module 220 is used to obtain business configuration information, which includes a third parameter corresponding to each of the multiple businesses; the scheduling module 220 is used to determine the number of guarantee threads corresponding to each of the multiple businesses based on the third parameter and the first parameter; the scheduling module 220 is used to control the threads included in the thread groups corresponding to each of the multiple businesses based on the total number of threads included in the thread pool and the number of guarantee threads corresponding to each of the multiple businesses.

[0061] In this embodiment of the application, the first parameter is used to characterize the number of threads supported by one core of a central processing unit, the second parameter is used to characterize the number of cores of the central processing unit, and the third parameter is used to characterize the minimum number of cores of the central processing unit corresponding to the service.

[0062] In this embodiment of the application, the total number of threads included in the thread pool is fixed.

[0063] In one possible implementation, the scheduling module 220 is used to determine the number of super-division threads corresponding to each of the multiple services based on the total number of threads included in the thread pool and the third parameter corresponding to each of the multiple services; the scheduling module 220 is used to control the threads included in the thread groups corresponding to each of the multiple services based on the total number of threads included in the thread pool, the number of guarantee threads corresponding to each of the multiple services, and the number of super-division threads corresponding to each of the multiple services.

[0064] In one possible implementation, the scheduling module 220 is used to control the threads included in the thread groups corresponding to each of the multiple services based on the total number of threads included in the thread pool, the number of guarantee threads corresponding to each of the multiple services, the number of super-division threads corresponding to each of the multiple services, and the number of demand threads corresponding to each of the multiple services.

[0065] In this embodiment of the application, the service configuration information also includes a fourth parameter corresponding to each of the multiple services. The fourth parameter is used to characterize the number of demand threads corresponding to the service.

[0066] Figure 3 This application provides a thread pool management method 300. For example, this method can be executed by a virtual instance (e.g., a virtual machine, a container bare metal server), a computing device cluster, a server, or a scheduling module in a computing device. Figure 3 As shown, the method 300 includes:

[0067] 310. Obtain parameter configuration information, which includes the first parameter and the second parameter.

[0068] In this embodiment of the application, the first parameter is used to characterize the number of threads supported by one core of a central processing unit, and the second parameter is used to characterize the number of cores of the central processing unit.

[0069] For example, the first parameter could be that each CPU supports 4 threads (or, as can be understood, that each CPU can run 4 threads). For example, the second parameter could be a 16-core runtime environment.

[0070] For example, the parameter configuration information can be configured by the user through a configuration interface. It should be understood that the number of CPU cores of a device is usually fixed at the factory, and the number of threads supported by one CPU core also has an optimal configuration. It is generally not recommended that users modify these parameter configuration information.

[0071] 320. Based on the parameter configuration information, determine the total number of threads included in the thread pool. The total number of threads included in the thread pool is fixed.

[0072] For example, when the first parameter is 4 threads per CPU and the second parameter is 16 cores, the total number of threads in the thread pool is determined to be 4 × 16 = 64. That is, in this example, the total number of threads in the thread pool is 64. Even in the scenario of resource over-allocation, the total number of threads in the thread pool is fixed at 64.

[0073] In one possible implementation, the ratio between the total number of threads in the thread pool and the number of CPU cores is a first parameter. Alternatively, in this embodiment, the ratio between the total number of threads in the thread pool and the number of CPU cores is fixed and is the first parameter.

[0074] 330. Obtain service configuration information, which includes the third parameters corresponding to each of the multiple services.

[0075] In this embodiment of the application, the third parameter is used to characterize the minimum number of cores of the central processing unit corresponding to the service.

[0076] In one possible implementation, service configuration information can be pre-configured by the user. For example, the user can configure the minimum number of CPU cores for each service based on its characteristics.

[0077] For example, suppose the user configures the minimum number of cores min_cpu for service #1 to be 4, and the user configures the minimum number of cores min_cpu for service #2 to be 8.

[0078] In this application's embodiments, "multiple services" can be understood as multiple services of the same user, or multiple services of different users.

[0079] 340. Based on the third and first parameters corresponding to each of the multiple services, determine the number of guarantee threads corresponding to each of the multiple services.

[0080] For example, assuming the first parameter is that each CPU supports 4 threads, and the user configures the minimum number of cores min_cpu for service #1 to be 4, then the number of guaranteed threads for service #1 is 4 × 4 = 16; assuming the user configures the minimum number of cores min_cpu for service #2 to be 8, then the number of guaranteed threads for service #2 is 4 × 8 = 32.

[0081] 350. Based on the total number of threads in the thread pool and the number of guarantee threads corresponding to each of the multiple services, control the threads included in the thread groups corresponding to each of the multiple services.

[0082] For example, assuming the total number of threads in the thread pool is 64, the guarantee threads for business #1 are 16, and the guarantee threads for business #2 are 32, then the scheduling module can schedule 16 threads in the thread group corresponding to business #1 to guarantee the service of business #1; the scheduling module can schedule 32 threads in the thread group corresponding to business #2 to guarantee the service of business #2.

[0083] In this embodiment, during the thread group expansion process, the total number of threads in the thread pool remains unchanged. This can also be understood as the CPU resources of each thread remaining stable. Furthermore, this application proposes that each service's corresponding thread group must include at least a guaranteed thread group. This ensures the stability of non-hotspot services that are not expanded, preventing their CPU resources from being preempted by peak traffic periods. It also avoids increased CPU context switching overhead and concurrency conflicts caused by an excessive number of threads in the thread pool, maintaining an optimal thread-to-core ratio, thereby improving overall system efficiency and ensuring a superior user experience.

[0084] In one possible implementation, method 300 further includes: determining the number of super-division threads corresponding to each of the multiple services based on the total number of threads in the thread pool and the third parameter corresponding to each of the multiple services. At this time, the threads included in the thread groups corresponding to each of the multiple services are controlled based on the total number of threads in the thread pool, the number of guarantee threads corresponding to each of the multiple services, and the number of super-division threads corresponding to each of the multiple services.

[0085] In this embodiment of the application, the number of super-division threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the business, in addition to the guarantee threads.

[0086] For example, suppose there are multiple services including service #1 and service #2. The minimum number of CPU cores corresponding to service #1 is 4 (i.e., min_cpu is 4), and the minimum number of CPU cores corresponding to service #2 is 8 (i.e., min_cpu is 8). At this time, the number of super-threads corresponding to each service can be determined by using a weighted algorithm based on the total number of threads included in the thread pool and the minimum number of CPU cores corresponding to each service.

[0087] In one possible implementation, the number of super-threads corresponding to the business can be obtained using the following formula (1):

[0088]

[0089] Among them, total worker_num This can be understood as the total number of threads included in the thread pool, min_worker_num i This can be understood as the number of guaranteed threads corresponding to business i, min_cpu i This can be understood as the minimum number of CPU cores corresponding to business i, where n is a positive integer greater than or equal to 2.

[0090] In another possible implementation, the number of super-division threads corresponding to the business logic can be obtained using the following formula (2) and the number of guaranteed threads:

[0091]

[0092] It can also be understood that formula (2) can directly calculate the number of threads that each business should receive. The number of super-threads corresponding to each business can be obtained by subtracting the number of guaranteed threads from the number of threads that each business should receive.

[0093] This can also be understood as follows: if a business peak occurs later, in addition to the guaranteed threads allocated to each business, some extra threads can be allocated to each business based on its corresponding super-division threads, thereby better serving the business. For example, based on the above formula, the number of super-division threads corresponding to business #1 can be determined to be 5 (for example, it can be rounded to the nearest integer), and the number of super-division threads corresponding to business #2 can be 11 (for example, it can be rounded to the nearest integer).

[0094] Furthermore, the service configuration information also includes a fourth parameter corresponding to each of the multiple services. This fourth parameter is used to characterize the number of demand threads corresponding to the service. In this embodiment, for example, the number of demand threads corresponding to a service can be used to indicate the "average number of concurrent requests" of the service. Considering that the number of demand threads for each service may differ, in order to ensure that the threads in the thread pool are used reasonably, this embodiment proposes to control the threads included in the thread groups corresponding to each of the multiple services based on the total number of threads included in the thread pool, the number of guarantee threads corresponding to each of the multiple services, the number of super-division threads corresponding to each of the multiple services, and the number of demand threads corresponding to each of the multiple services.

[0095] Based on the above scheme, it can be seen that each business's corresponding thread group includes at least a guarantee thread, and may further include super-split threads. Therefore, the number of threads that each business should have can include the number of guarantee threads and the number of super-split threads. The following will illustrate this in detail with three scenarios.

[0096] Scene 1:

[0097] When the number of required threads corresponding to each of the multiple business functions is less than or equal to the number of threads that should be provided for each of the multiple business functions, the number of threads included in the thread group corresponding to each of the multiple business functions is the number of required threads.

[0098] For example, as shown in Table 1 below, it can be seen that the required number of threads for business #A1 is 18, and the number of threads that business #A1 should receive is 21; the required number of threads for business #B1 is 40, and the number of threads that business #B1 should receive is 43. That is, the number of threads required by each business is less than the number of threads that each business should receive. In this case, threads are allocated to business #A1 according to its required number, and threads are allocated to business #B1 according to its required number.

[0099] Table 1

[0100]

[0101]

[0102] Scene 2

[0103] When the number of required threads corresponding to each of the multiple business functions is greater than or equal to the number of threads that should be provided for each of the multiple business functions, the number of threads included in the thread group corresponding to each of the multiple business functions is the number of threads that should be provided for.

[0104] For example, as shown in Table 2 below, it can be seen that the required number of threads for business #A2 is 45, and the number of threads that business #A2 should receive is 21; the required number of threads for business #B2 is 55, and the number of threads that business #B2 should receive is 43. That is, the number of threads required by each business is greater than or equal to the number of threads that each business should receive. In this case, business #A2 is allocated threads according to its required number of threads, and business #B2 is allocated threads according to its required number of threads.

[0105] Table 2

[0106]

[0107] Scene 3:

[0108] In this embodiment, when the number of required threads corresponding to the first service among multiple services is less than or equal to the number of threads that should be allocated to the first service, the number of threads included in the thread group corresponding to the first service is the number of required threads corresponding to the first service. When the number of required threads corresponding to each of the remaining services (excluding the first service) is greater than or equal to the number of threads that should be allocated to each of the remaining services, the number of threads included in the thread group corresponding to each of the remaining services is the number of target threads. The number of target threads is less than or equal to the number of allocated threads. The number of allocated threads is determined based on the third parameter corresponding to each of the remaining services and the number of remaining threads. The number of remaining threads is the total number of threads remaining in the thread pool after deducting the number of required threads corresponding to the first service.

[0109] Alternatively, in this embodiment of the application, threads can be preferentially allocated to the thread groups corresponding to services where the number of required threads is less than or equal to the number of threads that should be obtained, and then the remaining threads in the thread pool can be allocated to the thread groups corresponding to services during peak traffic periods.

[0110] In one possible implementation, the service configuration information also includes a fifth parameter for each of the remaining services. This fifth parameter represents the maximum number of threads corresponding to each service. If the maximum number of threads corresponding to the remaining services is less than or equal to the number of allocated threads corresponding to the remaining services, the target number of threads in the thread groups corresponding to the remaining services is the maximum number of threads. If the maximum number of threads corresponding to the remaining services is greater than or equal to the number of allocated threads corresponding to the remaining services, the target number of threads in the thread groups corresponding to the remaining services is the number of allocated threads. Alternatively, the target number of threads corresponding to the remaining services can be understood as the minimum of the "maximum number of threads" and the "number of allocated threads".

[0111] For example, as shown in Table 3 below, it can be seen that business #A3 requires 18 threads, and business #A3 should have 21 threads. Therefore, threads are allocated to business #A3 according to its required number. Business #B3 requires 58 threads, and business #B3 should have 43 threads. At this point, the number of threads remaining in the thread pool is 64 - 18 = 46. Since there are only two businesses, and business #B3 is in a peak traffic period, all 46 threads (i.e., the number of allocated threads) can be allocated to the thread group corresponding to business #B3.

[0112] Referring to Table 3 below, Figure 4 A diagram illustrating the number of threads for different types of services, such as... Figure 4 As shown, in thread group #1 corresponding to business #A3, the number of guaranteed threads is 16, the number of over-allocation threads is 5, the number of required threads is 21, the number of demand threads is 18, and the maximum number of threads is 32; in thread group #2 corresponding to business #B3, the number of guaranteed threads is 32, the number of over-allocation threads is 11, the number of required threads is 43, the number of demand threads is 58, and the maximum number of threads is 64.

[0113] Table 3

[0114]

[0115] For example, as shown in Table 4 below, it can be seen that business #A4 requires 16 threads, and business #A4 should have 21 threads. Therefore, threads can be allocated to business #A4 according to its required number of threads. Business #B4 requires 55 threads, and business #B4 should have 21 threads; business #C4 requires 64 threads, and business #C4 should have 21 threads. After allocating threads to the thread group corresponding to business #A4, the remaining number of threads is 64 - 16 = 48. The remaining 48 threads can be allocated between business #B4 and business #C4 according to a 4:4 ratio of min_cpu. That is, 24 threads are allocated to the thread group corresponding to business #B4 (i.e., the number of allocated threads corresponding to business #B4), and 24 threads are allocated to the thread group corresponding to business #C4 (i.e., the number of allocated threads corresponding to business #C4).

[0116] Table 4

[0117]

[0118] In this embodiment, a method is proposed that the minimum number of CPU cores corresponding to a business function be used as the preemption weight for threads in a thread group. The number of super-allocated threads is then allocated to each business's thread group according to this weight. When the number of threads required by a business is less than the number of threads it should receive, threads are allocated to the business's thread group based on the required number of threads. Conversely, when the number of threads required by a business is greater than the number of threads it should receive, threads are allocated to the business's thread group based on the preemption weight. This method achieves thread resource sharing and supports CPU over-allocation while ensuring a stable total number of threads in the thread pool, thereby improving CPU resource utilization.

[0119] Figure 5 This is a schematic flowchart illustrating a specific thread pool management method 500 provided in an embodiment of this application, such as... Figure 5 As shown, this method can be executed by a scheduling module, for example, and includes:

[0120] 510. Determine the adjustment range of the number of threads in the thread groups corresponding to each of the multiple services.

[0121] For example, based on the business configuration information, the adjustment range of the number of threads in the thread group corresponding to each business can be obtained. Referring to Table 3 above, the range of the number of threads in the thread group corresponding to business #A3 is [16, 32], that is, the number of guarantee threads corresponding to business #A3 is 16, and the maximum number of threads corresponding to business #A3 is 32; the range of the number of threads in the thread group corresponding to business #B3 is [32, 64], that is, the number of guarantee threads corresponding to business #B3 is 32, and the maximum number of threads corresponding to business #B3 is 64.

[0122] 520, determine the number of super-threads corresponding to each of the multiple services.

[0123] The number of super-division threads corresponding to each service can be obtained by referring to formula (1) or (2). For specific explanations and calculation methods of super-division threads for each service, please refer to the relevant explanations in step 350 of the aforementioned method 300, which will not be repeated here.

[0124] For example, referring to Table 3 above, the number of super-division threads corresponding to service #A3 is 5, and the number of super-division threads corresponding to service #B3 is 11.

[0125] 530, retrieves the number of demand threads corresponding to each of the multiple business functions.

[0126] For example, based on business configuration information, the number of threads that should be in the corresponding thread group for each business can be obtained.

[0127] For example, referring to Table 3 above, the number of threads that should be given to business #A3 is 21, and the number of threads that should be given to business #B3 is 43.

[0128] 540. Allocate threads to the thread groups corresponding to multiple services according to the number of guarantee threads, super-resolution threads, and demand threads corresponding to each service respectively.

[0129] Specifically, it includes two rounds of allocation:

[0130] 541. The first round of allocation

[0131] First, allocate threads to the thread groups corresponding to the services where the number of demand threads is less than or equal to the number of deserved threads (i.e., needed_worker_num ≤ deserve_worker_num). The allocation formula is the following formula (3):

[0132] expect_worker_num = max(needed_worker_num, min_worker_num) Formula (3)

[0133] Among them, "expect_worker_num" can be understood as the number of threads finally allocated to the thread group of this service.

[0134] It can also be understood that when allocating, the spare thread quota of non-hot services will be left and allocated to the thread group during the traffic peak period as much as possible in the second round of allocation.

[0135] Referring to Table 3 above, Service #A3 satisfies needed_worker_num = 18 < deserve_worker_num = 21. Therefore, the number of threads in the thread group corresponding to Service #A3 allocated on demand first in this round is: expect_worker_num = 18.

[0136] 542. The second round of allocation

[0137] Specifically, allocate the remaining unallocated threads to their corresponding thread groups according to the ratio of min_cpu corresponding to each service respectively (i.e., needed_worker_num ≥ deserve_worker_num). The allocation formula is the following formula (4):

[0138]

[0139] Among them, remain_worker_num can be understood as the remaining unallocated threads in the first round of allocation, and min_cpu j +…min_cpu m can be understood as the sum of min_cpu corresponding to the services participating in the second round of allocation.

[0140] For example, if the maximum number of threads corresponding to each of the multiple services is less than or equal to the number of allocated threads corresponding to each of the multiple services, the number of target threads in the thread groups corresponding to the remaining services is the maximum number of threads; it can also be understood that the number of target threads corresponding to each service participating in the second round of allocation is the minimum value between the "maximum number of threads" and the "number of allocated threads".

[0141] In this embodiment of the application, in the second round of allocation, the services participating in the allocation share the remaining idle threads remain_worker_num according to their respective min_cpu weights, thereby producing the effect of resource overutilization.

[0142] Referring to Table 3 above, business #B3 satisfies needed_worker_num(58)>deserve_worker_num(43) and participates in the allocation in the second round. The number of remaining threads is remain_worker_num=64-18=46. Since no other business participates in the second round of allocation, all remaining threads will be allocated to business #B3. The number of threads in the thread group corresponding to business #B3 is: expect_worker_num=46. That is, the number of threads in the thread group corresponding to business #B3 can be higher than the number of threads it should receive (deserve_worker_num=43).

[0143] Alternatively, in this embodiment of the application, the quotas related to the thread groups corresponding to multiple services can be recorded. The scheduling module can control (or "adjust") the number of threads in each thread group according to the quotas related to each thread group calculated above. For thread groups where the actual number of threads is higher than the final allocated number of threads, threads can be shut down until the number of threads equals the final allocated number of threads. For thread groups where the actual number of threads is lower than the final allocated number of threads, new threads can be started until the number of threads equals the final allocated number of threads.

[0144] In one possible implementation, after a certain period of sleep, steps 510 to 542 above can be repeated to periodically adjust the number of threads in each thread group.

[0145] Figure 6 This is a schematic diagram of a cloud service scenario used in this application, such as... Figure 6 As shown, this cloud scenario may include: a cloud management platform 610, the Internet 620, and a client 630. For example... Figure 6As shown, the cloud management platform 610 is used to manage the infrastructure that provides multiple cloud services. The infrastructure includes multiple cloud data centers, each containing multiple servers, and each server containing cloud service resources to provide corresponding cloud services to tenants.

[0146] The cloud management platform 610 can be located in a cloud data center and provides access interfaces (such as user interfaces or application program interfaces, APIs). Tenants can use client 630 to remotely access the access interface to register a cloud account and password on the cloud management platform 610 and log in. After successful authentication of the cloud account and password on the cloud management platform 610, the tenant can further select and purchase virtual machines with specific specifications (processor, memory, disk) on the cloud management platform 610. After successful purchase, the cloud management platform 610 provides the remote login account and password for the purchased virtual machine, and client 630 can remotely log in to the virtual machine to install and run the tenant's applications. Therefore, tenants can create, manage, log in to, and operate virtual machines in the cloud data center through the cloud management platform 610.

[0147] The cloud management platform 610 includes, but is not limited to, a tenant console, compute management services, network management services, storage management services, authentication services, and image management services. The tenant console provides an interface or API for interaction with tenants. The compute management services manage servers running virtual machines and containers, as well as bare metal servers. The network management services manage network services (such as gateways and firewalls). The storage management services manage storage services (such as data bucket services). The authentication services manage tenant account passwords. The image management services manage virtual machine images. Tenants use client 630 and can log in to the cloud management platform 610 via the internet 620 to manage their rented cloud services.

[0148] In this embodiment of the application, for example, the various steps of the above-described methods 300 and 500 can be performed by the infrastructure in the cloud service system.

[0149] It is understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0150] Those skilled in the art will recognize that, based on the units and algorithm steps described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is implemented in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0151] This application embodiment can divide the computing device into functional modules according to the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. The following description uses the division of functional modules according to each function as an example.

[0152] Figure 7 This is a schematic block diagram of a computing device 700 provided in an embodiment of this application. As shown in the figure, the computing device 700 may include: an acquisition module 710, a determination module 720, and a control module 730.

[0153] The modules described above are used to execute the respective steps of the methods mentioned above, which will not be elaborated here.

[0154] It should also be understood that the computing device 700 here is embodied in the form of a functional unit. The term "unit" here may refer to application-specific integrated circuits (ASICs), electronic circuits, processors (e.g., shared processors, proprietary processors, or group processors) and memory for executing one or more software or firmware programs, integrated logic circuits, and / or other suitable components that support the described functions.

[0155] The computing device 700 in each of the above schemes has the function of implementing the corresponding steps of methods 300 and 500. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions; for example, the acquisition module, determination module, and control module can be replaced by a processor to respectively execute the transmission and reception operations and related processing operations in each method embodiment. Furthermore, the acquisition module, determination module, or control module can also be a processing circuit.

[0156] It should be pointed out that, Figure 7The computing device mentioned can be the computing device in the aforementioned method embodiments (e.g., a server for providing cloud services), or it can be a chip or chip system corresponding to the computing device, such as a system-on-a-chip (SoC). The processing module is a processor, microprocessor, or integrated circuit integrated on the chip. No limitation is made here.

[0157] Figure 8 This is a schematic block diagram of another computing device 800 provided in an embodiment of this application. As shown, the device 800 includes at least one processor 820. The processor 820 is coupled to a memory and is used to execute instructions stored in the memory to transmit and / or receive signals. Optionally, the device 800 also includes a memory 830 for storing instructions. Optionally, the device 800 also includes a transceiver 810, and the processor 820 controls the transceiver 810 to transmit and / or receive signals.

[0158] It should be understood that the processor 820 and memory 830 described above can be combined into a single processing device, with the processor 820 executing the program code stored in the memory 830 to achieve the aforementioned functions. In specific implementations, the memory 830 can be integrated into the processor 820 or independent of the processor 820.

[0159] It should also be understood that transceiver 810 may include a transceiver (or receiver) and a transmitter (or transmitter). The transceiver may further include an antenna, and the number of antennas may be one or more. Transceiver 810 may have a communication interface or interface circuitry.

[0160] The 840 bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 8 The bus 840 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 840 may include a path for transmitting information between various components of the computing device 800 (e.g., memory 830, processor 820, transceiver 810).

[0161] The memory 830 stores executable program code, and the processor 820 executes this executable program code to implement the functions of the aforementioned acquisition module, determination module, and control module, thereby realizing the thread pool management method in this embodiment. That is, the memory 830 stores instructions for executing the thread pool management method. For example, the processor 820 executes the computer program or instructions stored in the memory 830 to implement the steps in methods 300 and 500 above.

[0162] Figure 9 This is a schematic diagram of a computing device cluster architecture provided in an embodiment of this application. The computing device cluster includes at least one computing device. This computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone. Figure 9 As shown, the computing device cluster includes at least one computing device 900. The memory 930 of one or more computing devices 900 in the computing device cluster may store the same instructions for performing the actions executed in the above-described embodiments 300 and method 500.

[0163] In some possible implementations, the memory 930 of one or more computing devices 900 in the computing device cluster may also store partial instructions for performing the actions executed in methods 300 and 500 described in the above embodiments. In other words, a combination of one or more computing devices 900 can jointly execute instructions for performing the actions executed in methods 300 and 500 described in the above embodiments.

[0164] It should be noted that the memory 930 in different computing devices 900 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the computing device 900. That is, the instructions stored in the memory 930 of different computing devices 900 can implement the functions of one or more of the aforementioned acquisition module, determination module, and control module.

[0165] Alternatively, the memories 930 in different computing devices 900 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the computing devices corresponding to the aforementioned computing devices 700-800. That is, the instructions stored in the memories 930 of different computing devices 900 can implement the functions of one or more modules among the acquisition module, determination module, and control module.

[0166] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 10One possible implementation is shown, such as Figure 10 As shown, the two computing devices 900A and 900B are connected via a network. Specifically, they are connected to the network through the communication interfaces in each computing device.

[0167] It should be understood that Figure 10 The functions of the computing device 900A shown can also be performed by multiple computing devices 900. Similarly, the functions of the computing device 900B can also be performed by multiple computing devices 900.

[0168] Figure 10 The connection method between the computing device clusters shown can be that, considering that the thread pool management method provided in this application requires a large number of parameters to be acquired and calculated, the functions implemented by the acquisition module and the determination module are to be executed by the computing device 900A.

[0169] In this embodiment, a computer program product containing instructions is also provided. The computer program product may be a software or program product containing instructions capable of running on a computing device cluster or stored on any available medium. When run by the computing device cluster, it causes the computing device cluster to perform the methods provided above, or causes the computing device cluster to implement the functions of the apparatus provided above.

[0170] In this embodiment, a computer-readable storage medium is also provided. This computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that, when executed on a computing device, cause the computing device to perform the method described above.

[0171] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0172] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0173] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0174] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0175] In addition, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0176] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0177] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for managing a thread pool, characterized in that, include: Obtain parameter configuration information, which includes a first parameter and a second parameter. The first parameter is used to characterize the number of threads supported by one core of a central processing unit, and the second parameter is used to characterize the number of cores of the central processing unit. Based on the parameter configuration information, the total number of threads included in the thread pool is determined, wherein the total number of threads included in the thread pool is fixed; Obtain service configuration information, which includes a third parameter corresponding to each of multiple services. The third parameter is used to characterize the minimum number of cores of the central processing unit corresponding to the service. The number of guarantee threads corresponding to each of the multiple services is determined based on the third parameter and the first parameter corresponding to each of the multiple services; Based on the total number of threads in the thread pool and the number of guarantee threads corresponding to each of the multiple services, the number of threads included in the thread groups corresponding to each of the multiple services is controlled, wherein each thread group corresponding to each service includes at least a first number of threads, the first number being the number of guarantee threads.

2. The method according to claim 1, characterized in that, The ratio between the total number of threads in the thread pool and the number of cores in the central processing unit is the first parameter.

3. The method according to claim 1 or 2, characterized in that, The method further includes: Based on the total number of threads included in the thread pool and the third parameter corresponding to each of the multiple services, the number of super-distributed threads corresponding to each of the multiple services is determined, wherein the number of super-distributed threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the service, in addition to the guaranteed threads; The step of controlling the threads included in the thread groups corresponding to each of the multiple services based on the total number of threads in the thread pool and the number of guarantee threads corresponding to each of the multiple services includes: Based on the total number of threads in the thread pool, the number of guarantee threads corresponding to each of the multiple services, and the number of super-division threads corresponding to each of the multiple services, the threads included in the thread groups corresponding to each of the multiple services are controlled.

4. The method according to claim 3, characterized in that, The service configuration information also includes a fourth parameter corresponding to each of the multiple services. This fourth parameter is used to characterize the number of demand threads corresponding to the service. The step of controlling the threads included in the thread groups corresponding to each of the multiple services based on the total number of threads in the thread pool, the number of guarantee threads corresponding to each of the multiple services, and the number of super-division threads corresponding to each of the multiple services includes: Based on the total number of threads in the thread pool, the number of guarantee threads corresponding to each of the multiple services, the number of super-division threads corresponding to each of the multiple services, and the number of demand threads corresponding to each of the multiple services, the threads included in the thread groups corresponding to each of the multiple services are controlled.

5. The method according to any one of claims 1 to 4, characterized in that, When the number of demand threads corresponding to each of the multiple services is less than or equal to the number of deserved threads corresponding to each of the multiple services, the number of threads included in the thread group corresponding to each of the multiple services is the number of demand threads, wherein the number of deserved threads is the sum of the number of guaranteed threads and the number of super-allocated threads, and the number of super-allocated threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the service, in addition to the guaranteed threads.

6. The method according to any one of claims 1 to 4, characterized in that, When the number of demand threads corresponding to each of the multiple services is greater than or equal to the number of threads that should be allocated to each of the multiple services, the number of threads included in the thread group corresponding to each of the multiple services is the number of threads that should be allocated. The number of threads that should be allocated is the sum of the number of guaranteed threads and the number of super-allocated threads. The number of super-allocated threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the service, in addition to the guaranteed threads.

7. The method according to any one of claims 1 to 4, characterized in that, If the number of demand threads corresponding to the first service among the multiple services is less than or equal to the number of threads that should be obtained corresponding to the first service, the number of threads included in the thread group corresponding to the first service is the number of demand threads corresponding to the first service. If the number of threads required for each of the remaining services (excluding the first service) is greater than or equal to the number of threads that should be allocated for each of the remaining services, the number of threads included in the thread group corresponding to each of the remaining services is the target number of threads. The target number of threads is less than or equal to the number of allocated threads. The number of allocated threads is determined based on the third parameter corresponding to each of the remaining services and the number of remaining threads. The number of remaining threads is the total number of threads remaining in the thread pool excluding the number of threads required for the first service. The number of threads that should be allocated is the sum of the number of guaranteed threads and the number of super-allocated threads. The number of super-allocated threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the business, in addition to the guaranteed threads.

8. The method according to claim 7, characterized in that, The service configuration information also includes a fifth parameter corresponding to each of the multiple services. The fifth parameter is used to characterize the maximum number of threads corresponding to the service. The number of target threads corresponding to the remaining services is the minimum value between the maximum number of threads corresponding to the remaining services and the number of allocated threads.

9. The method according to any one of claims 1 to 8, characterized in that, The method is applied to a cloud service system, the cloud service system including infrastructure for providing cloud services, the infrastructure including at least one cloud data center, each cloud data center including at least one server, the infrastructure being used to perform the method of any one of claims 1 to 8.

10. A computing device, characterized in that, include: The module includes an acquisition module, a determination module, and a control module. The acquisition module is used to acquire parameter configuration information, which includes a first parameter and a second parameter. The first parameter is used to represent the number of threads supported by one core of a central processing unit, and the second parameter is used to represent the number of cores of the central processing unit. The determining module is used to determine the total number of threads included in the thread pool based on the parameter configuration information, wherein the total number of threads included in the thread pool is fixed. The acquisition module is used to acquire service configuration information, which includes a third parameter corresponding to each of multiple services. The third parameter is used to characterize the minimum number of cores of the central processing unit corresponding to the service. The determining module is used to determine the number of guarantee threads corresponding to each of the multiple services based on the third parameter and the first parameter corresponding to each of the multiple services. The control module is used to control the threads included in the thread groups corresponding to the multiple services based on the total number of threads included in the thread pool and the number of guarantee threads corresponding to each of the multiple services. The thread group corresponding to each service includes at least a first number of threads, where the first number is the number of guarantee threads.

11. The computing device according to claim 10, characterized in that, The ratio between the total number of threads in the thread pool and the number of cores in the central processing unit is the first parameter.

12. The computing device according to claim 10 or 11, characterized in that, The determining module is further configured to determine the number of super-distributed threads corresponding to each of the multiple services based on the total number of threads included in the thread pool and the third parameter corresponding to each of the multiple services, wherein the number of super-distributed threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the service, in addition to the guaranteed threads. The control module is used to control the threads included in the thread groups corresponding to each of the multiple services based on the total number of threads included in the thread pool and the number of guarantee threads corresponding to each of the multiple services, including: The control module is used to control the threads included in the thread groups corresponding to the multiple services based on the total number of threads included in the thread pool, the number of guarantee threads corresponding to each of the multiple services, and the number of super-division threads corresponding to each of the multiple services.

13. The computing device according to claim 12, characterized in that, The service configuration information also includes a fourth parameter corresponding to each of the multiple services. This fourth parameter is used to characterize the number of demand threads corresponding to the service. The control module is used to control the threads included in the thread groups corresponding to each of the multiple services based on the total number of threads in the thread pool, the number of guarantee threads corresponding to each of the multiple services, and the number of super-division threads corresponding to each of the multiple services, including: The control module is used to control the threads included in the thread groups corresponding to the multiple services based on the total number of threads included in the thread pool, the number of guarantee threads corresponding to each of the multiple services, the number of super-division threads corresponding to each of the multiple services, and the number of demand threads corresponding to each of the multiple services.

14. The computing device according to any one of claims 10 to 13, characterized in that, When the number of demand threads corresponding to each of the multiple services is less than or equal to the number of deserved threads corresponding to each of the multiple services, the number of threads included in the thread group corresponding to each of the multiple services is the number of demand threads, wherein the number of deserved threads is the sum of the number of guaranteed threads and the number of super-allocated threads, and the number of super-allocated threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the service, in addition to the guaranteed threads.

15. The computing device according to any one of claims 10 to 13, characterized in that, When the number of demand threads corresponding to each of the multiple services is greater than or equal to the number of threads that should be allocated to each of the multiple services, the number of threads included in the thread group corresponding to each of the multiple services is the number of threads that should be allocated. The number of threads that should be allocated is the sum of the number of guaranteed threads and the number of super-allocated threads. The number of super-allocated threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the service, in addition to the guaranteed threads.

16. The computing device according to any one of claims 10 to 14, characterized in that, If the number of demand threads corresponding to the first service among the multiple services is less than or equal to the number of threads that should be obtained corresponding to the first service, the number of threads included in the thread group corresponding to the first service is the number of demand threads corresponding to the first service. If the number of threads required for each of the remaining services (excluding the first service) is greater than or equal to the number of threads that should be allocated for each of the remaining services, the number of threads included in the thread group corresponding to each of the remaining services is the target number of threads. The target number of threads is less than or equal to the number of allocated threads. The number of allocated threads is determined based on the third parameter corresponding to each of the remaining services and the number of remaining threads. The number of remaining threads is the total number of threads remaining in the thread pool excluding the number of threads required for the first service. The number of threads that should be allocated is the sum of the number of guaranteed threads and the number of super-allocated threads. The number of super-allocated threads is used to indicate the number of threads that can be additionally allocated to the thread group corresponding to the business, in addition to the guaranteed threads.

17. The computing device according to claim 16, characterized in that, The service configuration information also includes a fifth parameter corresponding to each of the multiple services. The fifth parameter is used to characterize the maximum number of threads corresponding to the service. The number of target threads corresponding to the remaining services is the minimum value between the maximum number of threads corresponding to the remaining services and the number of allocated threads.

18. The computing device according to any one of claims 10 to 17, characterized in that, The computing device is applied to a cloud service system, the cloud service system including infrastructure for providing cloud services, the infrastructure including at least one cloud data center, each cloud data center including at least one server, and the infrastructure including modules in the computing device of any one of claims 10 to 17.

19. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1 to 9.

20. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster performs the method as described in any one of claims 1 to 9.

21. A computer-readable storage medium, characterized in that, It includes computer program instructions, which, when executed by a cluster of computing devices, perform the method as described in any one of claims 1 to 9.

Images