Method for binding application instance to processor core and related device

Abstract

This application relates to a method for binding an application instance to processor cores and related devices. The method includes: determining the number of processor cores required by the application instance in response to a request to create the application instance when the NUMA function of multiple processors is enabled; obtaining information about the allocatable processor cores of the multiple processors; selecting a number of processors from the multiple processors to allocate processor cores to the application instance based on the number of allocatable processor cores of the multiple processors, minimizing the number of selected processors; and binding the allocated processor cores to the application instance. This application solves the problem of reduced application performance due to the activation of the NUMA function, thereby improving application performance.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method for binding an application instance to a processor core and related devices. Background Art

[0002] When adapting a processor (CPU) to an application, such as a database program, and enabling the processor's non-uniform memory access (NUMA) feature, application instances are randomly bound to processor cores. This can cause the application instances to access memory across NUMA nodes or even across processors in different sockets, degrading application performance. Summary of the Invention

[0003] The method for binding an application instance to a processor core and the related devices provided in this embodiment at least solve the problem in the related art of reduced application performance due to activation of the NUMA function.

[0004] A method for binding an application instance to a processor core, comprising:

[0005] When NUMA functions of the multiple processors are enabled, in response to a request to create an application instance, determining the number of processor cores required by the application instance;

[0006] Acquiring information about allocatable processor cores of the plurality of processors;

[0007] Selecting a number of processors from the plurality of processors according to the number of allocatable processor cores of the plurality of processors to allocate processor cores to the application instance, and minimizing the number of selected processors;

[0008] The allocated processor core is bound to the application instance.

[0009] In some embodiments, selecting a number of processors from the plurality of processors to allocate processor cores to the application instance based on the number of allocatable processor cores of the plurality of processors, and minimizing the number of selected processors comprises:

[0010] sorting the plurality of processors according to the number of allocatable processor cores of the plurality of processors;

[0011] When the number of processor cores required by the application instance is not greater than the number of allocatable processor cores of one or more processors of the plurality of processors, selecting a processor with the least number of allocatable processor cores from the one or more processors to allocate processor cores to the application instance;

[0012] When the number of processor cores required by the application instance is greater than the number of allocatable processor cores of each of the multiple processors, a processor with the largest number of allocatable processor cores is selected from the multiple processors to allocate processor cores to the application instance.

[0013] In some embodiments, each of the plurality of processors includes a plurality of NUMA nodes, each NUMA node being associated with one or more processor cores of the processor; and selecting, based on a number of allocatable processor cores of the plurality of processors, a number of processors from the plurality of processors to allocate processor cores to the application instance comprises:

[0014] Get the NUMA node information of the selected processor;

[0015] When the number of processor cores required by the application instance is not greater than the number of processor cores allocatable on one of the selected NUMA nodes, processor cores are allocated to the application instance from the allocatable processor cores on the one NUMA node.

[0016] In some embodiments, selecting a number of processors from the plurality of processors to allocate processor cores to the application instance based on the number of allocatable processor cores of the plurality of processors further includes:

[0017] When the number of processor cores required by the application instance is greater than the number of processor cores allocatable to each NUMA node in the selected processor, obtaining the affinity between processor cores and memories between any two NUMA nodes in the processor; and

[0018] According to the affinity values ​​in ascending order, two or more NUMA nodes are selected from the NUMA nodes of the processor, and processor cores are allocated to the application instance from the allocatable processor cores of the two or more NUMA nodes, wherein a smaller affinity value indicates a faster speed of processors accessing memory between each pair of NUMA nodes.

[0019] In some embodiments, obtaining information about allocatable processor cores of the plurality of processors includes:

[0020] In a case where the application instance is an application instance that shares a processor, obtaining allocated time slice ratios of the multiple processors; if the allocated time slice ratios of the multiple processors are lower than a set value, selecting a processor based on the processor load, and determining that all processor cores of the selected processor are allocatable processor cores;

[0021] In a case where the application instance is an application instance that exclusively uses a processor, idle processor cores in the multiple processors are obtained, and the idle processor cores are determined to be allocatable processor cores.

[0022] In some embodiments, binding the allocated processor core to the application instance includes:

[0023] The allocated processor core is bound to the process of the application instance through the Linux CGroup, and the binding information is written into the configuration file of the Linux CGroup.

[0024] In some embodiments, after writing the binding information into the Linux CGroup configuration file, the method further includes:

[0025] Check whether the binding information in the configuration file has taken effect;

[0026] If the binding information is not effective, the process information of the application instance corresponding to the binding information is re-acquired, the allocated processor core is bound to the re-acquired process of the application instance, and the binding information is updated to the configuration file.

[0027] In some embodiments, after writing the binding information into the Linux CGroup configuration file, the method further includes:

[0028] In a case where the application instance is an application instance that shares a processor, rebinding the application instance to the allocatable processor cores of the multiple processors according to the instance load of the application instance so as to balance the instance loads of the multiple processors; and updating the binding information of the application instance to the configuration file;

[0029] In a case where the application instance is an application instance that uses a dedicated processor, determine whether the instance load of the application instance on a single NUMA node is higher than a first load value; if the instance load of the application instance on a single NUMA node is higher than the first load value, rebind the application instance to the allocatable processor cores of multiple NUMA nodes; and update the binding information of the application instance to the configuration file.

[0030] In some embodiments, the method further comprises:

[0031] In the case where the application instance is an application instance that uses a dedicated processor, the processor cores bound to two application instances in the application instance are exchanged so that the processor core required by at least one of the application instances is bound to the processor core of a NUMA node, or the processor cores required by the two application instances are each bound to the processor core of a NUMA node.

[0032] A controller for binding an application instance to a processor core includes: a processor, and a memory for storing a program, wherein the program includes instructions, and when the instructions are executed by the processor, the processor executes any one of the above methods.

[0033] A non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to execute any one of the methods described above.

[0034] The method and related devices for binding application instances to processor cores provided in this embodiment determine the number of processor cores required for an application instance in response to a request to create an application instance when the NUMA function of multiple processors is enabled; obtain information about allocable processor cores of the multiple processors; select several processors from the multiple processors based on the number of allocable processor cores of the multiple processors to allocate processor cores to the application instance, and minimize the number of selected processors; and bind the allocated processor cores to the application instance, thereby solving the problem of reduced application performance due to the enabling of the NUMA function and improving application performance.

[0035] The details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0037] Figure 1 This is a flowchart of the method for binding an application instance to a processor core in this embodiment.

[0038] Figure 2 FIG. 4 is a schematic diagram of the NUMA architecture of the processor of this embodiment.

[0039] Figure 3FIG. 4 is a schematic diagram of NUMANode affinity in this embodiment.

[0040] Figure 4 Schematic diagram of offline scheduling in this embodiment.

[0041] Figure 5 Schematic diagram of the structure of the electronic device of this embodiment. DETAILED DESCRIPTION

[0042] The following describes embodiments of the present invention in more detail with reference to the accompanying drawings. Although certain embodiments of the present invention are shown in the accompanying drawings, it should be understood that the present invention can be implemented in various forms and should not be construed as being limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present invention. It should be understood that the accompanying drawings and embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0043] It should be understood that the various steps described in the method implementation of this embodiment can be performed in different orders and / or in parallel. In addition, the method implementation may include additional steps and / or omit the steps shown. The scope of this embodiment is not limited in this respect.

[0044] As used herein, the term "including" and its variations are open-ended, i.e., "including but not limited to." The term "based on" means "based, at least in part, on." The term "one embodiment" means "at least one embodiment," the term "another embodiment" means "at least one additional embodiment," and the term "some embodiments" means "at least some embodiments." Other terms are defined in the following description.

[0045] It should be noted that the modifications of "one" and "multiple" mentioned in this embodiment are illustrative rather than restrictive. Those skilled in the art should understand that unless otherwise clearly indicated in the context, they should be understood as "one or more".

[0046] Explanation of terms

[0047] RDS: Relational Database Service, the full English name is Relational Database Service.

[0048] CPU: The full name is Central Processing Unit. It is used to execute code and process various logic. It can be called the brain of the computer. Usually, CPU refers to the CPU Package, which is also called the physical CPU.

[0049] CPU core: A processor core is a separate execution unit within a CPU package. Currently, a CPU package typically includes multiple processing units, known as a multi-core CPU. Application instance specifications are described as xCyG, where xC (e.g., 1C, 5C, etc.) indicates that the application instance can use x processor cores, and yG indicates that the application instance can use y GB of memory.

[0050] CPU Socket: Socket for short. The CPU Package is installed on the motherboard through a slot. This slot is called a Socket. One Socket can accommodate one CPU Package.

[0051] NUMA: The full name is Non-Uniform Memory Access, and its Chinese name is non-uniform memory access. It is a technical architecture and also refers to the functions based on this technical architecture. Under the NUMA technical architecture, memory and processor cores are assigned to different NUMA nodes (Node), and each NUMA node has its own integrated memory controller (IMC). Within the NUMA node, the IMC bus is used for communication between different processor cores; between NUMA nodes, QPI (Quick Path Interconnect) is used for communication. The latency of QPI communication is higher than that of the IMC bus, that is, there is a difference in the distance between the processor cores accessing the memory, and this distance is described by DISTANCES.

[0052] NUMANode: A group of processor cores and memory devices with similar distances under the NUMA architecture form a NUMANode.

[0053] DISTANCES: In the NUMA architecture, the distance between the processor core and the memory device; also known as affinity. A processor core accesses memory within a NUMA node with the shortest distance, resulting in the fastest speed and the highest affinity. Affinity is expressed as the value of DISTANCES. Therefore, a higher affinity indicates a lower value.

[0054] Application instances that share a CPU: referred to as RDS shared instances. These instances share the CPU but not the memory or disk. CPU resources are allocated based on time slicing and the shared instance's specifications.

[0055] An application instance with dedicated CPU resources: referred to as an RDS dedicated instance; it exclusively uses CPU, memory, and disk resources.

[0056] An application is composed of various classes that do not occupy processes and memory. After the application class is instantiated, an application instance is obtained. The application instance includes one or more processes and may also include one or more threads. Processes and threads occupy processor cores and memory to run and implement corresponding functions. The application of the embodiment of the present invention can be a service program or a client program. For example, the application can be a database service program or a database client program. The processor core refers to a separate execution unit in the processor. The processor of the embodiment of the present invention includes but is not limited to a CPU or other type of processor with multiple separate execution units, such as a graphics processing unit (GPU), a tensor processing unit (TPU) or a microprocessor (MPU).

[0057] To solve at least one of the problems mentioned in the background art, this embodiment provides a method for binding an application instance to a processor core, which is applied to a core binding controller. Figure 1 FIG. 1 is a flow chart of the method for binding an application instance to a processor core according to this embodiment. Figure 1 As shown, the process includes the following steps:

[0058] Step S101 : When NUMA functions of multiple processors are enabled, in response to a request to create an application instance, determining the number of processor cores required by the application instance.

[0059] Step S102: Acquire information on allocatable processor cores of multiple processors.

[0060] Step S103 : selecting a number of processors from the plurality of processors to allocate processor cores to the application instance according to the number of allocable processor cores of the plurality of processors, and making the number of selected processors the minimum.

[0061] Step S104: Bind the allocated processor core to the application instance.

[0062] It should be noted that the multiple processors in the above steps refer to multiple processor packages (eg, CPUPackage). In this embodiment, the term "Socket" is sometimes used to refer to a processor package.

[0063] Through the above steps, when creating an application instance, if the NUMA function of multiple processors has been enabled, processor cores are allocated according to the number of processor cores required by the application instance from the processor's allocatable cores, and the number of processors selected for the application instance is the minimum compared to any other allocation method. This ensures that an application instance is bound to the minimum number of processors (preferably one) as much as possible. This avoids binding application instances to different processors when processor core resources are sufficient, which may cause application instances to access memory across sockets, thereby improving the performance of the RDS database system.

[0064] When allocating processor cores to application instances, if the application instances are randomly assigned to processors that meet the requirements without planning the distribution of the allocable cores of the processors after the allocation is completed, the processor cores on each processor may be fragmented after the initial random allocation of processor cores to some application instances. This may result in the application instances being unable to be bound to a smaller number of processors even if the total number of processor cores can meet the requirements of the application instances. To this end, in some embodiments, in step S103, planning is also performed based on the number of allocable processor cores of each processor and the number of processor cores required by the application instances, while ensuring that the number of selected processors is minimal. For example, in step S103, multiple processors may be sorted according to the number of allocable processor cores of the multiple processors; then (Case 1), if the number of processor cores required by the application instance is not greater than the number of allocable processor cores of one or more of the multiple processors, the processor with the least number of allocable processor cores is selected from the one or more processors to allocate processor cores to the application instance.

[0065] The above steps avoid binding the application instance to the processor with the most allocatable cores. Instead, the application instance is assigned a core by selecting a suitable processor from one or more processors that can meet the application instance's core requirements, namely the processor with the fewest allocatable cores. This allows the remaining allocatable cores to be concentrated on a single processor, effectively ensuring a more reasonable binding result when binding processor cores to other application instances in the future.

[0066] Similarly, to ensure that the application instance can be bound to the minimum number of processors, if (Scenario 2) the number of processor cores required by the application instance is greater than the number of allocatable CPU cores of each of the multiple processors, then in some embodiments, the processor with the largest number of allocatable processor cores can be selected from the multiple processors to allocate processor cores to the application instance. For any unmet processor core requirements of the application instance, allocation continues based on Scenario 1 and Scenario 2 until all processor core requirements of the application instance are met.

[0067] Because the IMC bus is used to communicate between different processor cores within a NUMA node, and QPI (Quick Path Interconnect) is used for communication between NUMA nodes. The latency of QPI communication is higher than that of the IMC bus. Therefore, if an application instance can be bound to a processor core within the same NUMA node, the efficiency of the application instance in accessing memory will be optimized. In some embodiments, each of the multiple processors includes multiple NUMA nodes, and each NUMA node is associated with one or more processor cores of the processor. Then, in the above-mentioned step S103, the NUMA node information of the selected processor can be obtained; if the number of processor cores required by the application instance is not greater than the number of allocatable processor cores of a NUMA node in the selected processor, processor cores are allocated to the application instance from the allocatable processor cores of a NUMA node.

[0068] By using the above method, application instances are preferentially bound to the processor cores within a NUMA node, thereby optimizing the memory access efficiency of the application instance and further improving the performance of the RDS database system.

[0069] If the number of processor cores required by the application instance is greater than the number of processor cores that can be allocated to the NUMA node, and the application instance cannot be bound to the processor cores within a NUMA node, then in some embodiments, a neighboring NUMA node with the highest affinity to the current NUMA node may be selected based on the affinity between the processor cores and the memory between the NUMA nodes, and the remaining processor cores required by the application instance may be bound to the allocable processor cores of the neighboring NUMA node. For example, if the number of processor cores required by the application instance is greater than the number of processor cores that can be allocated to each NUMA node in the selected processor, the affinity between the processor cores and the memory between each pair of NUMA nodes in the processor is obtained; and then, in ascending order of affinity values, two or more NUMA nodes are selected from the processor's NUMA nodes, and processor cores are allocated to the application instance from the allocable processor cores of the two or more NUMA nodes, wherein a smaller affinity value indicates a faster memory access speed between the processors between each pair of NUMA nodes.

[0070] Through the above-described embodiment, application instances are preferentially bound to the allocatable processor cores of the same NUMA node. If the allocatable processor cores of a single NUMA node cannot meet the demand, the application instance is bound to the allocatable processor cores of multiple NUMA nodes of the same processor package. If the allocatable processor cores of a single processor package cannot meet the demand, the application instance is bound to the allocatable processor cores of one or more NUMA nodes of different processor packages. This approach maximizes the memory access efficiency of the processor cores bound to the application instance under current conditions, thereby improving the performance of the RDS database system.

[0071] Because application instances can be divided into two types: those that share a processor and those that exclusively own a processor, the allocatable processor cores have different meanings for these two types of application instances.

[0072] For application instances sharing a processor, whether the processor still has allocatable cores depends on whether the proportion of the processor's time slices occupied reaches the maximum allowable proportion. For example, for a processor with 100% time slices, in order to ensure system stability and cope with high-level burst tasks at the system level, a portion of the time slices may be reserved to ensure that all application instances bound to the processor's cores have the opportunity to obtain processor core execution time within the allocated time slices, while ensuring normal system operation. This maximum allowable proportion is a set value, such as 80%, 90%, or 95%.

[0073] For application instances that share a processor, as long as the allocated time ratio of the processor does not exceed the above-mentioned set value, all processor cores of the processor can be regarded as allocable processor cores, that is, application instances that share a processor can be bound to any processor core of the processor. However, in order to ensure load balancing and to ensure that the affinity of the processor cores in accessing the memory is the highest, when the loads of multiple processors (the proportion of occupied time slices) do not exceed the maximum allowed ratio, the processor with the smallest processor load can be determined and all processor cores of the processor can be determined to be allocable processor cores. When binding processor cores for application instances in a processor package, the application instance is also bound to the allocable processor cores of the same NUMA node in the processor package as much as possible according to the affinity.

[0074] Therefore, in some embodiments, obtaining information on allocatable processor cores of multiple processors includes: when the application instance is an application instance that shares a processor, obtaining the allocated time slice ratios of the multiple processors; if the allocated time slice ratios of the multiple processors are lower than a set value, selecting a processor based on the processor load, and determining that all processor cores of the selected processor are allocatable processor cores.

[0075] For an application instance that exclusively uses a processor, whether the processor still has allocatable processor cores depends on whether there are any processor cores in the processor that are not bound to any other application instance or process. Therefore, in some embodiments, obtaining information about allocatable processor cores of multiple processors includes: if the application instance is an application instance that exclusively uses a processor, obtaining idle processor cores in the multiple processors and determining the idle processor cores as allocatable processor cores.

[0076] In some embodiments, binding the allocated processor core to the application instance includes binding the allocated processor core to a process of the application instance via a Linux CGroup and writing the binding information to the Linux CGroup configuration file. By writing the binding information to the Linux CGroup configuration file, a core binding rule is formed, enabling recovery or offline scheduling of the application instance's bound core.

[0077] For example, the recovery of the core binding of an application instance based on a configuration file. In some embodiments, after the binding information is written to the configuration file of the Linux CGroup, it is possible to periodically check whether the binding information in the configuration file has taken effect; if the binding information is not effective, the process information of the application instance corresponding to the binding information is retrieved, the allocated processor core is bound to the process of the re-retrieved application instance, and the binding information is updated to the configuration file. In cases where the process of the application instance is recycled, resulting in a process restart, or the device where the processor is located is restarted, the process number of the application instance may be changed, or the binding relationship between the application instance and the processor core may become invalid. In the above manner, the recovery of the core binding of the application instance is triggered periodically or based on a machine or process restart, which can ensure that the application instance can run stably.

[0078] For example, offline scheduling of application instances is performed based on a configuration file. In some embodiments, after the binding information is written to the Linux CGroup configuration file, if the application instance is an application instance that shares a processor, the application instance is re-bound to the allocatable processor cores of multiple processors based on the instance load of the application instance to balance the instance loads of the multiple processors; and the binding information of the application instance is updated in the configuration file.

[0079] In some of the embodiments, when the application instance is an application instance that uses a dedicated processor, it is determined whether the instance load of the application instance on a single NUMA node is higher than a first load value; when the instance load of the application instance on a single NUMA node is higher than the first load value, the application instance is re-bound to the allocatable processor cores of multiple NUMA nodes; and the binding information of the application instance is updated to the configuration file.

[0080] The above embodiments are based on instance load optimization and are intended to balance instance loads on different processors or different NUMA nodes, thereby making system resource utilization more reasonable.

[0081] In other embodiments, offline scheduling of application instances based on a configuration file further includes: if the application instance is an application instance that uses a dedicated processor, swapping the processor cores bound to two application instances in the application instance, such that the processor core required by at least one of the application instances is bound to a processor core of a single NUMA node, or the processor cores required by the two application instances are each bound to a processor core of a single NUMA node. In this manner, the processor cores bound to the application instances are defragmented, thereby allowing multiple application instances currently bound to a processor core of a single processor to be concentrated onto as few NUMA nodes as possible, thereby improving memory access efficiency for the processor cores bound to the application instances.

[0082] The above-mentioned offline scheduling can be performed periodically or based on event triggering. For example, the event can be that the instance load value of the application instance is greater than a certain set value. In particular, in the case where the application instance is an application instance with a dedicated processor, the offline scheduling based on instance load is intended to disperse the processor cores bound to an application instance to multiple NUMA nodes or processors, while the offline scheduling based on processor core defragmentation is intended to concentrate the processor cores bound to an application instance to one NUMA node. That is, the above-mentioned two offline scheduling methods are opposite processes. Therefore, a critical value of the instance load value of an application instance can be set to distinguish which offline scheduling strategy to adopt.

[0083] The above embodiment will be described and illustrated below by taking a processor package with 64 processor cores as an example with reference to the accompanying drawings.

[0084] This embodiment aims to prioritize binding the processor cores required by the application instance within the NUMA Node based on the NUMA Node affinity relationship, and secondly bind them within the same Socket across NUMA Nodes, and avoid cross-Socket binding as much as possible.

[0085] Figure 2 : is a schematic diagram of the NUMA architecture of the processor of this embodiment. Figure 2 The upper and lower figures show two sockets respectively. The upper Socket0 includes NUMANodes 0 to 7, a total of 8 NUMANodes. The lower Socket1 includes NUMANodes 8 to 15, a total of 8 NUMA Nodes. Figure 2 Each NUMA Node in the Socket consists of 8 cores, each core is connected to a 5Gb memory unit via the IMC bus. Since the socket is a processor with 64 cores, Figure 2 Each Socket has a total of 8×8 cores.

[0086] like Figure 2 As shown in the figure, because NUMANode 0 to 7 belong to Socket 0 and NUMANode 8 to 15 belong to Socket 1, when applying for an 8-core application instance, in order to avoid processor cross-Socket memory access, the c5 to c8 processor cores under NUMA Node 3 are not selected. Instead, the processor cores on Node 8 and Node 9 are selected.

[0087] The method for binding application instances to processor cores in this embodiment can be implemented by a computer system. The computer system may include a NUMANode collector, a processor core resource manager, an application instance core binding controller (online), and an application instance core binding controller (offline). The functions of each of these modules or units are described below.

[0088] NUMANode Collector

[0089] Using the NUMActl instruction, which is compatible with processor chips from various manufacturers, it calculates the NUMA architecture corresponding to the processor chip, including the number of NUMA nodes and the number of processor cores in each NUMA node.

[0090] Collect processor and memory affinity within the same NUMA node and between different NUMA nodes, and within the same processor socket and between different processor sockets, and identify the critical affinity between processor and memory in cross-socket scenarios.

[0091] Identify whether there is memory inserted in the memory slots under each NUMA node. When binding memory nodes later, only the nodes with inserted memory sticks are bound.

[0092] Processor core resource manager

[0093] Maintain the number of processor cores and core numbers under each NUMA Node node.

[0094] Stores processor and memory affinity data within the same NUMA node and between different NUMA nodes, and within the same processor socket and between different processor sockets.

[0095] Maintain the allocated processor cores and control resource levels.

[0096] Application instance binding core controller

[0097] Based on the number of processor cores required by the instance specifications and the remaining processor cores on each NUMANode in the current resource manager, processor cores are allocated first within the NUMA Node, then across nodes, and finally across sockets.

[0098] Use the CGroup tool to bind the allocated processor cores to the application instance processes and related threads.

[0099] CGroup is a mechanism in Linux for managing processes by group. From a user perspective, CGroup technology organizes all processes in the system into an independent tree. Each tree contains all the processes in the system. Each node of the tree is a process group, and each tree is associated with one or more subsystems. The role of the tree is to group processes, and the role of the subsystem is to operate on these groups.

[0100] Use the CGroup tool to bind the corresponding NUMA Node memory node based on the bound processor core.

[0101] Update the binding relationship between the application instance and the processor core in the local configuration file.

[0102] Application instance binding core offline controller

[0103] Based on the binding relationship between application instances and processor cores in the local configuration file, the CGroup configuration is refreshed regularly to prevent the CGroup configuration from becoming invalid due to machine restart or application instance process restart.

[0104] Analyze the binding relationship between all application instances and processor cores on the current host, defragment the processor cores, and refresh the binding relationship between application instances and processor cores.

[0105] In some embodiments, based on the above-mentioned computer system, when the application instance is an instance of a shared processor, the application instance core binding is implemented through a process including the following steps:

[0106] Step 1: Select the application instance type and create the application instance.

[0107] Step 2: Use the NUMA Node collector to obtain the NUMA architecture and socket number of the current processor.

[0108] Step 3: The processor core resource manager queries the current remaining allocatable memory and the processor sales ratio. If the memory is insufficient or exceeds the maximum allocated shard time ratio allowed by the processor, the creation of this application instance is terminated. If the resources are sufficient, a socket is randomly selected and the processor core of the NUMA Node corresponding to the socket is returned. Figure 2 The 64-core Socket 0 corresponds to processor cores 0 to 63, and the Socket 1 corresponds to processor cores 65 to 127.

[0109] In step 4, the application instance core binding controller binds the processor core returned by the resource manager to the application instance process and the corresponding thread through the CGroup command.

[0110] Step 5: Calculate the processor ratio available to the application instance based on the application instance specifications and the number of bound processor cores. Use the CGroup command to limit processor usage. For example, if a 2-core application instance is bound to Socket 0, the processor time available to the instance is 2 / 64 of the total processor time.

[0111] In step 6, all NUMA nodes with memory sticks inserted are bound to the application instance process and the corresponding threads through CGroup, and memory usage is limited through CGroup according to the application instance specifications.

[0112] In some embodiments, based on the above-mentioned computer system, when the application instance is an instance of a dedicated processor, the application instance core binding is implemented through a process including the following steps:

[0113] Step 1: Select the application instance type and create the application instance.

[0114] Step 2: Obtain the NUMA architecture and socket number of the current processor through the NUMA Node collector.

[0115] In step 3, the NUMA Node collector determines whether to identify cross-socket NUMA Nodes based on the number of sockets. If the number of sockets is 1, there is no cross-socket situation. If the number of sockets is greater than 1, the NUMA Node affinities are sorted and the maximum affinity is used as the condition for identifying cross-socket NUMA Nodes.

[0116] Figure 3 This is a schematic diagram of NUMA Node affinity in this embodiment. Figure 3Shown Figure 2 The affinity between the NUMANodes of the two processors. Figure 3 In the figure, both the horizontal and vertical axes are NUMA Node numbers, and the values ​​are the affinity between each NUMA Node. It can be seen that when the affinity value reaches the maximum value of 100 (the affinity is the minimum at this time), cross-socket situation occurs.

[0117] In step 4, the processor core resource manager queries the currently available memory and the number of processor cores that can be allocated. If the memory or the number of processor cores is insufficient, the creation of this application instance is terminated. If the resources are sufficient, the processor cores are allocated within the NUMA node based on the affinity of the processor and memory. The processor cores are then allocated across NUMA nodes within a socket, and finally across sockets.

[0118] In step 5, the application instance core binding controller binds the processor core returned by the resource manager to the application instance process and the corresponding thread through the CGroup command. Because the instance exclusively uses the processor, the instance uses 100% of the processor time.

[0119] In step 6, all NUMA nodes with memory sticks inserted are bound to the application instance process and the corresponding threads through CGroup, and memory usage is limited through CGroup according to the application instance specifications.

[0120] In some embodiments, based on the aforementioned computer system, offline scheduling of application instance core binding is implemented through a process including the following steps:

[0121] Step 1: The application instance is bound to the offline controller that starts a scheduled task to periodically check whether the CGroup configuration of the application instance is effective.

[0122] In step 2, if a machine or process restart causes the process ID in the CGroup core binding rule to change, the offline controller will obtain the latest process ID and refresh it to the CGroup core binding rule.

[0123] In step 3, the offline controller analyzes the distribution of currently allocated processor cores and rebalances resources. For shared instances, the controller balances the instances to different sockets based on the instance load. For dedicated instances, the controller distributes the highly loaded instances to different NUMA nodes.

[0124] Step 4: For dedicated instances, identify whether processor cores are allocated across sockets. Figure 4 This is a schematic diagram of offline scheduling in this embodiment. Figure 4 As shown in the figure, Node3 and Node8 are each assigned 5 cores to the same application instance. If the 5-core instance on Node3 is assigned to Node8, 8 cores of Node3 will be idle. Through offline scheduling, the 8-core instance will be re-bound to Node3.

[0125] A 64-core processor package of model FT2500 was used to stress test the database performance of an instance of mysql.x8.medium.2 (resources required are 2C16G) using the sysbench tool. When the conventional method of random core binding is used to bind the cores, the instance is bound to two cores on Node7 and Node8; when the core binding method of this embodiment is used to bind the cores, the instance is bound to two cores on Node0. The number of queries per second (QPS) at different concurrency numbers of 1 to 512 was tested under the corresponding core binding results. QPS can reflect the performance index of the database, and the higher the value, the better the performance. The test results are shown in Table 1. In the scenario where the NUMA function of the processor is turned on, compared with accessing memory across sockets, binding the application instance to a NUMA node node of a socket, compared with binding to different NUMA Nodes, the average performance is improved by 20%.

[0126]

[0127]

[0128] Table 1 Performance test results corresponding to different core binding methods

[0129] This embodiment further provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, wherein the computer program, when executed by the at least one processor, causes the electronic device to perform a method according to an embodiment of the present disclosure.

[0130] This embodiment further provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor of a computer, is used to cause the computer to perform the method according to the embodiment of the present disclosure.

[0131] refer to Figure 5, a block diagram of an electronic device 500 that can serve as a server or client of the present disclosure will now be described, which is an example of a hardware device that can be applied to various aspects of the present disclosure. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or required herein.

[0132] like Figure 5 As shown, electronic device 500 includes a computing unit 501, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. Various programs and data required for the operation of device 500 can also be stored in RAM 503. Computing unit 501, ROM 502, and RAM 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to bus 504.

[0133] Multiple components within electronic device 500 are connected to I / O interface 505, including an input unit 506, an output unit 507, a storage unit 508, and a communication unit 509. Input unit 506 can be any type of device capable of inputting information into electronic device 500. Input unit 506 can receive input numeric or character information and generate key signal inputs related to user settings and / or function control of the electronic device. Output unit 507 can be any type of device capable of presenting information and may include, but is not limited to, a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. Storage unit 508 may include, but is not limited to, a magnetic disk or an optical disk. Communication unit 509 allows electronic device 500 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks, and may include, but is not limited to, a modem, a network card, an infrared communication device, a wireless communication transceiver and / or a chipset, such as a Bluetooth device, a WiFi device, a WiMax device, a cellular communication device, and / or the like.

[0134] The computing unit 501 may be a variety of general and / or specialized processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a CPU, a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above. For example, in some embodiments, the above methods (e.g., Figure 1 The methods shown in the foregoing examples may be implemented as computer software programs that are tangibly contained in a machine-readable medium, such as the storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 500 via the ROM 502 and / or the communication unit 509. In some embodiments, the computing unit 501 may be configured to perform the foregoing methods in any other appropriate manner (e.g., by means of firmware).

[0135] The program code for implementing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the processor or controller, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0136] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0137] As used in this disclosure, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and / or device (e.g., a magnetic disk, an optical disk, a memory, a programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0138] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) display) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0139] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0140] Computer systems may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The client and server relationship arises through computer programs running on the respective computers and having a client-server relationship to each other.

[0141] It should be understood that the specific embodiments described herein are only used to explain this application and are not used to limit it. Based on the embodiments provided in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0142] Obviously, the accompanying drawings are merely examples or embodiments of the present application. A person skilled in the art can also apply the present application to other similar situations based on these drawings without inventive effort. Furthermore, it is understandable that, although the work involved in this development process may be complex and lengthy, certain design, manufacturing, or production changes based on the technical content disclosed in this application are merely routine technical means for a person skilled in the art and should not be considered to constitute a deficiency in the disclosure of the present application.

[0143] The term "embodiment" as used in this application refers to specific features, structures, or characteristics described in conjunction with the embodiment that can be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily mean that the embodiment is the same, nor does it mean that it is mutually exclusive with other embodiments and is independent or optional. It is understood, either explicitly or implicitly, by those skilled in the art that the embodiments described in this application can be combined with other embodiments when there is no conflict.

[0144] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of patent protection. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A method for binding an application instance to a processor core, comprising: When NUMA functions of the multiple processors are enabled, in response to a request to create an application instance, determining the number of processor cores required by the application instance; Acquiring information about allocatable processor cores of the plurality of processors; Selecting a number of processors from the plurality of processors according to the number of allocatable processor cores of the plurality of processors to allocate processor cores to the application instance, and minimizing the number of selected processors; Binding the allocated processor core to the application instance; Binding the allocated processor core to the process of the application instance through the Linux CGroup, and writing the binding information to the Linux CGroup configuration file; Check whether the binding information in the configuration file has taken effect; If the binding information is not effective, reacquire process information of the application instance corresponding to the binding information, bind the allocated processor core to the reacquired process of the application instance, and update the binding information to the configuration file; After writing the binding information into the Linux CGroup configuration file, the method further includes: In a case where the application instance is an application instance that shares a processor, rebinding the application instance to the allocatable processor cores of the multiple processors according to the instance load of the application instance so as to balance the instance loads of the multiple processors; and updating the binding information of the application instance to the configuration file; The rebinding of the application instance to the allocatable processor cores of the plurality of processors according to the instance load of the application instance includes: Get the number of sockets allocated to the processor; If the amount of allocatable memory of the allocated processor core is insufficient or exceeds the maximum allowed allocated shard time ratio of the processor, the creation of the application instance is terminated; if the amount of allocatable memory of the allocated processor core is sufficient or does not exceed the maximum allowed allocated shard time ratio of the processor, a socket is randomly selected, and the processor core of the NUMA node corresponding to the socket is bound to the process of the application instance; If the application instance is an application instance that uses a dedicated processor, determining whether an instance load of the application instance on a single NUMA node is higher than a first load value; if the instance load of the application instance on a single NUMA node is higher than the first load value, rebinding the application instance to allocatable processor cores of multiple NUMA nodes; and updating the binding information of the application instance to the configuration file; When the instance load of the application instance on a single NUMA node is higher than the first load value, rebinding the application instance to allocatable processor cores of multiple NUMA nodes includes: If the allocated processor core has sufficient allocatable memory, the processor core is allocated within the NUMA node based on the affinity between the processor and memory; or, Allocate processor cores across NUMA nodes within a socket; or, Allocate processor cores across sockets.

2. The method according to claim 1, wherein According to the number of allocatable processor cores of the multiple processors, selecting a number of processors from the multiple processors to allocate processor cores to the application instance, and minimizing the number of selected processors comprises: sorting the plurality of processors according to the number of allocatable processor cores of the plurality of processors; When the number of processor cores required by the application instance is not greater than the number of allocatable processor cores of one or more processors of the plurality of processors, selecting a processor with the least number of allocatable processor cores from the one or more processors to allocate processor cores to the application instance; When the number of processor cores required by the application instance is greater than the number of allocatable processor cores of each of the multiple processors, a processor with the largest number of allocatable processor cores is selected from the multiple processors to allocate processor cores to the application instance.

3. The method according to claim 1, wherein Each processor of the plurality of processors includes a plurality of NUMA nodes, and each NUMA node is associated with one or more processor cores of the processor; According to the number of allocatable processor cores of the multiple processors, selecting a number of processors from the multiple processors to allocate processor cores to the application instance includes: Get the NUMA node information of the selected processor; When the number of processor cores required by the application instance is not greater than the number of processor cores allocatable on one of the selected NUMA nodes, processor cores are allocated to the application instance from the allocatable processor cores on the one NUMA node.

4. The method according to claim 3, wherein: According to the number of allocatable processor cores of the multiple processors, selecting a number of processors from the multiple processors to allocate processor cores to the application instance further includes: When the number of processor cores required by the application instance is greater than the number of processor cores allocatable to each NUMA node in the selected processor, obtaining the affinity between processor cores and memories between any two NUMA nodes in the processor; and According to the affinity values ​​in ascending order, two or more NUMA nodes are selected from the NUMA nodes of the processor, and processor cores are allocated to the application instance from the allocatable processor cores of the two or more NUMA nodes, wherein a smaller affinity value indicates a faster speed of processors accessing memory between each pair of NUMA nodes.

5. The method according to claim 1, wherein Acquiring information about allocatable processor cores of the plurality of processors includes: In a case where the application instance is an application instance that shares a processor, obtaining allocated time slice ratios of the multiple processors; if the allocated time slice ratios of the multiple processors are lower than a set value, selecting a processor based on the processor load, and determining that all processor cores of the selected processor are allocatable processor cores; In a case where the application instance is an application instance that exclusively uses a processor, idle processor cores in the multiple processors are obtained, and the idle processor cores are determined to be allocatable processor cores.

6. The method according to claim 1, wherein The method further comprises: In the case where the application instance is an application instance that uses a dedicated processor, the processor cores bound to two application instances in the application instance are exchanged so that the processor core required by at least one of the application instances is bound to the processor core of a NUMA node, or the processor cores required by the two application instances are each bound to the processor core of a NUMA node.

7. An electronic device comprising: A processor, and a memory storing a program, wherein the program comprises instructions which, when executed by the processor, cause the processor to perform the method according to any one of claims 1 to 6.

8. A non-transitory computer-readable storage medium storing computer instructions, wherein: The computer instructions are used to cause the computer to execute the method according to any one of claims 1 to 6.

Images