Memory access request scheduling method and apparatus, device, and storage medium
By acquiring monitoring data from business modules, the target business module was identified and its memory access requests were scheduled to the matching NUMA node, thus resolving the latency issue caused by remote memory access across nodes and improving system performance and resource utilization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING BAIDU NETCOM SCI & TECH CO LTD
- Filing Date
- 2020-08-24
- Publication Date
- 2026-07-14
AI Technical Summary
Existing operating systems cannot detect the locality of memory access requirements of business modules, resulting in remote memory access across nodes in the virtualization environment, leading to high latency and low resource utilization.
By acquiring monitoring data from business modules, the target business module is identified, and its memory access requests are scheduled to the matching NUMA node, thereby optimizing the scheduling of memory access requests to reduce latency.
This effectively reduced memory access latency for business modules, improving resource utilization and performance.
Smart Images
Figure CN114090223B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, specifically to the fields of communication technology and data processing, and in particular to memory access request scheduling methods, apparatus, devices, and storage media. Background Technology
[0002] Limited by hardware chip technology, the computing power of a single Central Processing Unit (CPU) tends to reach saturation. Therefore, to achieve higher computing performance, servers tend to increase the number of processors. High-performance servers typically employ a Non-Uniform Memory Architecture (NUMA), where multiple nodes are connected via a high-speed interconnect network, with each node consisting of a set of CPUs and local memory. When a node accesses local memory, the access latency is low, resulting in high performance; however, accessing remote memory incurs relatively high latency, leading to performance degradation. Therefore, to improve system performance, current memory allocators prioritize allocating local memory first, and then consider remote memory.
[0003] Because the operating system cannot currently perceive the memory locality requirements of business modules, it may schedule the memory access requests of business modules to processor cores that are not adjacent to their memory. This can lead to many cross-node remote memory access phenomena in virtualized environments with mixed business deployments, resulting in high business latency and low resource utilization. Summary of the Invention
[0004] A memory access request scheduling method, apparatus, device, and storage medium are provided.
[0005] According to the first aspect, a memory access request scheduling method is provided, comprising: acquiring monitoring data of at least one business module; determining a target business module from the at least one business module based on the monitoring data; determining a target NUMA node matching the target business module from a preset NUMA node set based on the monitoring data; and sending the memory access request of the target business module to the target NUMA node.
[0006] According to a second aspect, a memory access request scheduling device is provided, comprising: a monitoring data acquisition unit configured to acquire monitoring data of at least one business module; a business module determination unit configured to determine a target business module from the at least one business module based on the monitoring data; a target node determination unit configured to determine a target NUMA node matching the target business module from a preset NUMA node set based on the monitoring data; and a first request scheduling unit configured to send the memory access request of the target business module to the target NUMA node.
[0007] According to a third aspect, a memory access request scheduling electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method as described in the first aspect.
[0008] According to a fourth aspect, a non-transitory computer-readable storage medium is provided that stores computer instructions for causing a computer to perform the method as described in the first aspect.
[0009] The technology of this application can identify a suitable business module from among the various business modules and schedule the memory access request of that business module to a matching NUMA node, thereby reducing the memory access latency of the business module.
[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description
[0011] The accompanying drawings are provided for a better understanding of this solution and do not constitute a limitation of this application. Wherein:
[0012] Figure 1 This is an exemplary system architecture diagram in which one embodiment of this application can be applied;
[0013] Figure 2 This is a flowchart of an embodiment of the memory access request scheduling method according to this application;
[0014] Figure 3 This is a schematic diagram of an application scenario of the memory access request scheduling method according to this application;
[0015] Figure 4 This is a flowchart of another embodiment of the memory access request scheduling method according to this application;
[0016] Figure 5This is a flowchart of yet another embodiment of the memory access request scheduling method according to this application;
[0017] Figure 6 This is a schematic diagram of a structure of an embodiment of the memory access request scheduling apparatus according to this application;
[0018] Figure 7 This is a block diagram of an electronic device used to implement the memory access request scheduling method of the embodiments of this application. Detailed Implementation
[0019] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.
[0020] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.
[0021] Figure 1 An exemplary system architecture 100 is shown, in which embodiments of the memory request scheduling method or memory request scheduling apparatus of this application can be applied.
[0022] like Figure 1 As shown, the system architecture 100 may include multiple NUMA nodes 101, multiple business modules 102, and a business module management module 103. Among them, the multiple NUMA nodes 101 include NUMA nodes 1011, 1012, and 1013, and the multiple business modules 102 include business modules 1021, 1022, and 1023.
[0023] Each of the multiple NUMA nodes 101 can include multiple CPU cores, and each CPU core can correspond to a block of memory. CPU cores within the same NUMA node can interact with each other, and CPU cores between different nodes can also interact with each other.
[0024] Each business module in each business module 102 can be a piece of code data that performs a specific task. It can access each NUMA node to perform computation or read and write operations.
[0025] The business module management module 103 can collect information from each business module 102 and then manage each business module 102 based on this information.
[0026] It should be noted that multiple NUMA nodes 101, multiple business modules 102, and business module management module 103 can be set up on the same server or on different servers. When multiple NUMA nodes 101, multiple business modules 102, and business module management module 103 are set up on different servers, they can be distributed in a server cluster.
[0027] It should be noted that the memory access request scheduling method provided in this application embodiment is generally executed by the business module management module 103. Accordingly, the memory access request scheduling device is generally set in the business module management module 103.
[0028] It should be understood that Figure 1 The number of NUMA nodes, service modules, and service module management modules shown is merely illustrative. Depending on implementation needs, there can be any number of NUMA nodes, service modules, and service module management modules.
[0029] Continue to refer to Figure 2 The flowchart 200 illustrates an embodiment of the memory access request scheduling method according to this application. The memory access request scheduling method of this embodiment includes the following steps:
[0030] Step 201: Obtain monitoring data for at least one business module.
[0031] In this embodiment, the execution body of the memory access request scheduling method (e.g., Figure 1 The business module management module 103 shown can acquire monitoring data from at least one business module. Here, a business module can be a code block used to perform a specific task, such as a code block that performs specific processing on a certain parameter. It should be noted that technical personnel can pre-configure each business module, i.e.
[0032] During data processing, business modules may access CPU, cache, and memory, generating log data, parameter values, and modifying files. These traces can all serve as monitoring data. In other words, monitoring data for a business module can be the data generated during its data processing. The executing entity can use code to obtain real-time monitoring data from each business module, or each business module can send its own generated monitoring data to the executing entity in real-time.
[0033] Step 202: Based on the monitoring data, identify the target business module from at least one business module.
[0034] In this embodiment, after obtaining monitoring data from each business module, the executing entity can analyze the monitoring data and determine the target business module from at least one business module based on the analysis results. Specifically, the executing entity can extract memory access bandwidth, memory access frequency, waiting time for memory access, data types stored in memory by the business module, and the amount of data of different memory data types from the monitoring data. Based on these parameters, the executing entity can calculate the sensitivity of each business module to memory access latency. Specifically, the executing entity can calculate the sensitivity of each business module to memory access latency based on memory access bandwidth, waiting time for memory access, and the amount of data of different memory data types. For example, the executing entity can calculate the proportion of each memory data type in the total memory data, and then multiply the memory access bandwidth, waiting time for memory access, and proportion, using the product as the sensitivity of each business module to memory access latency.
[0035] It's understandable that if a business module is more sensitive to memory access latency (i.e., the greater the sensitivity), then a smaller memory access latency will have less impact on the performance of that business module. If a business module is not sensitive to memory access latency, it means that a larger memory access latency will not affect the performance of that business module. Therefore, to ensure the performance of each business module, the executing entity can choose the business module with the greater sensitivity to memory access latency as the target business module.
[0036] Step 203: Based on the monitoring data, determine the target NUMA node that matches the target business module from the preset NUMA node set.
[0037] After identifying the target business module, the executing entity can also determine the target NUMA node matching the target business module from a preset set of NUMA nodes based on monitoring data. Specifically, the executing entity can use the NUMA node with the highest memory usage of the target business module as the target NUMA node matching the target business module. Alternatively, the executing entity can use NUMA nodes whose memory usage of the target business module is within a preset range as the target NUMA nodes matching the target business module.
[0038] Step 204: Send the memory access request of the target business module to the target NUMA node.
[0039] After identifying the target business module and the target NUMA node, the execution entity can send the memory access request of the target business module to the target NUMA node. Since the target business module occupies the most memory among all NUMA nodes, sending the memory access request of the target business module to the target NUMA node allows the target business module to utilize the CPU cores of the target NUMA node for computation, thus avoiding cross-NUMA node memory access and effectively reducing the memory access latency of the target business module.
[0040] See also Figure 3 This illustrates a schematic diagram of an application scenario for the memory access request scheduling method according to this application. Figure 3 In this application scenario, the server includes multiple business modules, namely business modules 301, 302, and 303, and multiple NUMA nodes, namely NUMA nodes 311, 312, and 313. The server can obtain monitoring data from each business module and then analyze the monitoring data to determine that business module 301 is highly sensitive to memory access latency. Therefore, business module 301 is selected as the target business module. Simultaneously, the monitoring data also shows that business module 301 consumes the most memory on NUMA node 312. Therefore, business module 301 is bound to NUMA node 312, and all memory access requests from business module 301 are sent to NUMA node 312.
[0041] The memory access request scheduling method provided in the above embodiments of this application can determine a suitable business module from each business module and schedule the memory access request of the business module to the matching NUMA node, so as to reduce the memory access latency of the business module.
[0042] See also Figure 4 This illustrates flow 400 of another embodiment of the memory access request scheduling method according to this application. Figure 4 As shown, the memory access request scheduling method in this embodiment may include the following steps:
[0043] Step 401: Obtain monitoring data for at least one business module.
[0044] Step 402: Based on the monitoring data, determine the target business module from the at least one business module.
[0045] In this embodiment, the execution entity can specifically be through... Figure 4 The following steps (not shown) are used to determine the target business module: Based on monitoring data, determine at least one of the following: memory access bandwidth, time waiting to access memory, time waiting to access the central processing unit, time waiting to access the cache, and the amount of data of different memory data types; based on the determined information, determine the memory access latency sensitivity value of at least one business module; based on the memory access latency sensitivity value, determine the target business module from at least one business module.
[0046] The executing entity can first analyze the monitoring data to determine at least one of the following parameters: memory access count, memory access bandwidth, time waiting to access memory, time waiting to access the CPU, time waiting to access the cache, and the type of memory data accessed. Memory access bandwidth can be understood as the effective bandwidth when accessing memory. The type of memory data accessed can include RSS memory pages and cache memory pages. Since the layout of RSS memory pages is controllable, while the layout of cache memory pages is not, a higher proportion of RSS memory pages indicates a greater degree of controllability. Based on the determined information above, the executing entity can determine the memory access latency sensitivity value for each business module. Specifically, the executing entity can calculate the memory access latency sensitivity value using the following formula:
[0047] Memory access latency sensitivity = memory access bandwidth × [time waiting to access memory / (time waiting to access memory + time waiting to access cache)] × [data size of RSS memory page / (data size of RSS memory page + data size of cache memory page)].
[0048] Alternatively, the executing entity can calculate the memory access latency sensitivity value using the following formula:
[0049] Memory access latency sensitivity = Number of memory accesses × [Time waiting to access memory / (Time waiting to access memory + Time waiting to access cache)] × [Data size of RSS memory pages / (Data size of RSS memory pages + Data size of cache memory pages)].
[0050] Understandably, a higher memory access latency sensitivity value indicates a more sensitive business module to memory access latency. Appropriately reducing the memory access latency of these business modules will effectively improve their performance. Therefore, the executing entity can then determine the target business module based on the memory access latency sensitivity value. Specifically, the executing entity can use business modules with memory access latency sensitivity values greater than a preset threshold as target business modules, or the business module with the highest memory access latency sensitivity value as the target business module.
[0051] Step 403: Based on the monitoring data, determine the target NUMA node that matches the target business module from the preset NUMA node set.
[0052] In this embodiment, the execution entity can specifically be through... Figure 4 The following steps, not shown, are used to determine the target NUMA node: determine the amount of memory occupied by the target service module in each NUMA node in the NUMA node set; determine the target NUMA node based on the memory access bandwidth and / or the amount of memory occupied by each NUMA node.
[0053] After identifying the target business module, to ensure the memory access latency of the target business module is minimized, the executing entity can first determine the amount of memory occupied by the target business module in each NUMA node. Then, combining this with the memory access bandwidth of each NUMA node, the target NUMA node is determined. For example, the executing entity can choose the NUMA node with the largest memory usage of the target business module as the target NUMA node. Alternatively, it can choose the NUMA node with the largest memory access bandwidth. Or, it can comprehensively consider both memory access bandwidth and memory usage, weighting both factors, and select the NUMA node as the target NUMA node based on the weighted result. In this embodiment, the executing entity can bind the target business module to the NUMA node with the largest memory usage, that is, use the NUMA node with the largest memory usage as the target NUMA node matching the target business module.
[0054] Step 404: Send the memory access request of the target business module to the target NUMA node.
[0055] Step 405: Obtain the hardware resource information of the target NUMA node.
[0056] In this embodiment, the executing entity can also obtain hardware resource information of the target NUMA node. This hardware resource information can be obtained using a preset hardware resource information acquisition tool, or it can be obtained from a database storing the metadata of each NUMA node. The hardware resource information may include information such as the number and configuration of CPU cores included in the NUMA node, the size of the L1 cache, etc.
[0057] Step 406: Determine the resource utilization rate of the target NUMA node based on monitoring data and hardware resource information.
[0058] After obtaining the hardware resource information of the target NUMA node, the executing entity can determine the resource utilization rate of the target NUMA node based on monitoring data and hardware resource information. Specifically, the executing entity can determine the memory utilization rate based on memory capacity and memory usage.
[0059] Step 407: In response to determining that the resource utilization rate is greater than a preset threshold, a backup NUMA node for the target NUMA node is determined from the NUMA node set.
[0060] In this embodiment, if the executing entity determines that the resource utilization rate of the target NUMA node is greater than a preset threshold, it considers the hardware resources of the target NUMA node to be saturated. The preset threshold can be 90%. It is understood that the preset threshold can be a threshold set by technicians based on the actual application scenario. When hardware resources are saturated, the performance of the target NUMA node is considered poor. At this time, a backup NUMA node can be determined from the NUMA node set to handle a portion of the memory access requests from the target service module. Specifically, the executing entity can use the NUMA node with the second largest memory usage among all NUMA nodes as the backup NUMA node for the target NUMA node. Alternatively, the executing entity can select the backup NUMA node based on the amount of free resources available in each NUMA node.
[0061] In some optional implementations of this embodiment, the executing entity can... Figure 4 The following steps, not shown, are used to determine the backup NUMA node: determine the resource utilization of each NUMA node in the NUMA node set; and determine the backup NUMA node for the target NUMA node from the NUMA node set based on the resource utilization of each NUMA node.
[0062] In this implementation, the executing entity can determine the resource utilization rate of each NUMA node. Then, based on the resource utilization rate of each NUMA node, a backup NUMA node for the target NUMA node is determined from the NUMA node set. For example, the executing entity can use the NUMA node with the lowest resource utilization rate as the backup NUMA node.
[0063] Step 408: Forward some memory access requests sent to the target NUMA node to the standby NUMA node.
[0064] After a backup NUMA node is identified, the executing entity can forward some memory access requests sent to the target NUMA node to the backup NUMA node to reduce the processing pressure on the target NUMA node.
[0065] For example, if the resource utilization of the target NUMA node is 95% and the resource utilization of another NUMA node 1 is 50%, then in order to make full use of the hardware resources of NUMA node 1, the execution entity can use NUMA node 1 as a backup NUMA node and forward 20% of the memory access requests to NUMA node 1. This can improve the performance of the target NUMA node and make full use of the hardware resources of the backup NUMA node without reducing the performance of the backup NUMA node.
[0066] The memory access request scheduling method provided in the above embodiments of this application can ensure that the performance of each NUMA node is in a better state, thereby ensuring the normal operation of each service module.
[0067] See also Figure 5 This illustrates a flow 500 of yet another embodiment of the memory access request scheduling method according to this application. The memory access request scheduling method of this embodiment can be applied to a server cluster. For example... Figure 5 As shown, the memory access request scheduling method in this embodiment may include the following steps:
[0068] Step 501: Obtain monitoring data for at least one business module.
[0069] Step 502: Based on the monitoring data, identify the target business module from at least one business module.
[0070] Step 503: Based on the monitoring data, determine the target NUMA node that matches the target business module from the preset NUMA node set.
[0071] Step 504: Send the memory access request of the target business module to the target NUMA node.
[0072] Step 505: Determine the operating status information of the target business module based on the monitoring data.
[0073] In this embodiment, the executing entity can also determine the running status information of the target business module based on monitoring data. Here, the running status information may include multiple parameter values, such as memory access bandwidth value, memory utilization value, etc.
[0074] Step 506: Based on the running status information, determine whether the target business module meets the preset conditions.
[0075] The executing entity can compare the parameter values in the running status information with a preset set of thresholds to determine whether the target business module meets the preset conditions. Specifically, if all parameter values in the running status information are less than the corresponding thresholds in the threshold set, then the target business module is determined to meet the preset conditions.
[0076] Step 507: In response to the failure to meet the preset conditions, determine the remote memory corresponding to the target business module.
[0077] If the target business module does not meet the preset conditions, the executing entity can determine the remote memory corresponding to the target business module. Specifically, the executing entity can parse the process address space layout of the target business module, sample memory accesses, and identify the remote memory. Here, remote memory is relative to local memory. The server where the target NUMA node bound to the target business module resides is the local memory. Remote memory is the memory of NUMA nodes located on other servers in the server cluster.
[0078] Step 508: Migrate the data in the remote memory to the local memory of the target business module.
[0079] Once the execution entity identifies the remote memory location, it can migrate the data from the remote memory to the local memory of the target business module. Specifically, the execution entity can migrate the data from the remote memory to the local memory of the target business module through the kernel system's interface.
[0080] In this way, the target business module can read the contents of the remote memory in the local memory and provide the running status of the target business model.
[0081] The memory access request scheduling method provided in the above embodiments of this application can monitor each business module and improve the performance of each business module.
[0082] Further reference Figure 6 As an implementation of the methods shown in the above figures, this application provides an embodiment of a memory access request scheduling device, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.
[0083] like Figure 6 As shown, the memory access request scheduling device 600 in this embodiment includes: a monitoring data acquisition unit 601, a service module determination unit 602, a target node determination unit 603, and a first request scheduling unit 604.
[0084] The monitoring data acquisition unit 601 is configured to acquire monitoring data from at least one business module.
[0085] The business module determination unit 602 is configured to determine a target business module from at least one business module based on monitoring data.
[0086] The target node determination unit 603 is configured to determine the target NUMA node that matches the target business module from a preset set of NUMA nodes based on monitoring data.
[0087] The first request scheduling unit 604 is configured to send the memory access request of the target service module to the target NUMA node.
[0088] In some optional implementations of this embodiment, the business module determination unit 602 may be further configured to: determine at least one of the following based on monitoring data: memory access count, memory access bandwidth, time waiting to access memory, time waiting to access the central processing unit, time waiting to access the cache, and the amount of data of different memory data types; determine the memory access latency sensitivity value of at least one business module based on the determined information; and determine the target business module from at least one business module based on the memory access latency sensitivity value.
[0089] In some optional implementations of this embodiment, the target node determination unit 603 may be further configured to: determine the amount of memory occupied by the target service module in each NUMA node in the NUMA node set; and determine the target NUMA node based on the memory access bandwidth and / or the amount of memory occupied by each NUMA node.
[0090] In some optional implementations of this embodiment, the device 600 may further include Figure 6 Not shown: Resource information acquisition unit, utilization rate determination unit, backup node determination unit, and second request scheduling unit.
[0091] The resource information acquisition unit is configured to acquire the hardware resource information of the target NUMA node.
[0092] The utilization determination unit is configured to determine the resource utilization of a target NUMA node based on monitoring data and hardware resource information.
[0093] The standby node determination unit is configured to determine the standby NUMA node of the target NUMA node from the NUMA node set in response to determining that the resource utilization rate is greater than a preset threshold.
[0094] The second request scheduling unit is configured to forward a portion of the memory access requests sent to the target NUMA node to the standby NUMA node.
[0095] In some optional implementations of this embodiment, the backup node determination unit is further configured to: determine the resource utilization rate of each NUMA node in the NUMA node set; and determine the backup NUMA node of the target NUMA node from the NUMA node set based on the resource utilization rate of each NUMA node.
[0096] In some optional implementations of this embodiment, the device 600 may further include Figure 6 Not shown: Status information determination unit, judgment unit, remote memory determination unit, and data migration unit.
[0097] The status information determination unit is configured to determine the operating status information of the target business module based on monitoring data.
[0098] The judgment unit is configured to determine whether the target business module meets preset conditions based on the running status information.
[0099] The remote memory determination unit is configured to determine the remote memory corresponding to the target business module in response to the failure to meet preset conditions.
[0100] The data migration unit is configured to migrate data from remote memory to the local memory of the target business module.
[0101] It should be understood that units 601 to 604 recorded in the memory access request scheduling device 600 are respectively related to the reference Figure 2 The steps described in the method correspond to those in the previous section. Therefore, the operations and features described above for the memory access request scheduling method also apply to device 600 and the units contained therein, and will not be repeated here.
[0102] According to embodiments of this application, this application also provides an electronic device and a readable storage medium.
[0103] like Figure 7 The diagram shown is a block diagram of an electronic device for executing a memory access request scheduling method according to an embodiment of this application. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present application described and / or claimed herein.
[0104] like Figure 7 As shown, the electronic device includes one or more processors 701, a memory 702, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise as required. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).Figure 7 Take the 701 processor as an example.
[0105] The memory 702 is the non-transitory computer-readable storage medium provided in this application. The memory stores instructions executable by at least one processor to cause the at least one processor to perform the execution memory access request scheduling method provided in this application. The non-transitory computer-readable storage medium of this application stores computer instructions for causing a computer to perform the execution memory access request scheduling method provided in this application.
[0106] Memory 702, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the memory access request scheduling method in the embodiments of this application (e.g., attached...). Figure 6 The monitoring data acquisition unit 601, business module determination unit 602, target node determination unit 603, and first request scheduling unit 604 are shown. The processor 701 executes various functional applications and data processing of the server by running non-transient software programs, instructions, and modules stored in the memory 702, thereby implementing the memory access request scheduling method in the above method embodiment.
[0107] Memory 702 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created in response to the use of the electronic device that performs memory access requests. Furthermore, memory 702 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory 702 may optionally include memory remotely located relative to processor 701, and these remote memories may be connected to the electronic device that performs memory access requests via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0108] The electronic device executing the memory access request scheduling method may further include an input device 703 and an output device 704. The processor 701, memory 702, input device 703, and output device 704 can be connected via a bus or other means. Figure 7 Taking the example of a connection between China and Israel via a bus.
[0109] Input device 703 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of electronic devices that execute memory access requests, such as touch screens, keypads, mice, trackpads, touchpads, joysticks, one or more mouse buttons, trackballs, joysticks, etc. Output device 704 may include display devices, auxiliary lighting devices (e.g., LEDs), and haptic feedback devices (e.g., vibration motors). The display device may include, but is not limited to, liquid crystal displays (LCDs), light-emitting diode (LED) displays, and plasma displays. In some embodiments, the display device may be a touch screen.
[0110] Various implementations of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, application-specific integrated circuits (ASICs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, the at least one input device, and the at least one output device.
[0111] These computational programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide 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.
[0112] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, 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 sound input, voice input, or tactile input).
[0113] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.
[0114] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.
[0115] According to the technical solution of the embodiments of this application, a suitable business module can be determined from each business module, and the memory access request of the business module can be scheduled to the matching NUMA node to reduce the memory access latency of the business module.
[0116] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.
[0117] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A memory access request scheduling method, comprising: Obtain monitoring data for at least one business module; Based on the monitoring data, a target business module is determined from the at least one business module, wherein the memory access latency sensitivity of the target business module is greater than a preset sensitivity. Based on the monitoring data, a target NUMA node matching the target business module is determined from a preset set of NUMA nodes. The target NUMA node is either the NUMA node that occupies the most memory for the target business module, or a NUMA node whose memory usage rate for NUMA nodes is within a preset range. The memory access request of the target business module is sent to the target NUMA node.
2. The method according to claim 1, wherein, The step of determining the target business module from the at least one business module based on the monitoring data includes: Based on the monitoring data, determine at least one of the following: number of memory accesses, memory access bandwidth, time waiting to access memory, time waiting to access the central processing unit, time waiting to access the cache, and the amount of data of different memory data types. Based on the determined information, determine the memory access latency sensitivity value of the at least one business module; Based on the memory access latency sensitivity value, the target business module is determined from the at least one business module.
3. The method according to claim 2, wherein, The step of determining the target NUMA node matching the target service module from a preset NUMA node set based on the monitoring data includes: Determine the amount of memory occupied by the target service module in each NUMA node of the NUMA node set; The target NUMA node is determined based on the memory access bandwidth and / or memory usage of each NUMA node.
4. The method according to claim 1, wherein, The method further includes: Obtain the hardware resource information of the target NUMA node; Based on the monitoring data and the hardware resource information, the resource utilization rate of the target NUMA node is determined; In response to determining that the resource utilization rate is greater than a preset threshold, a backup NUMA node for the target NUMA node is determined from the NUMA node set; Some memory access requests sent to the target NUMA node are forwarded to the backup NUMA node.
5. The method according to claim 4, wherein, The step of determining the backup NUMA node for the target NUMA node from the NUMA node set includes: Determine the resource utilization rate of each NUMA node in the NUMA node set; Based on the resource utilization of each NUMA node, the backup NUMA node for the target NUMA node is determined from the set of NUMA nodes.
6. The method according to claim 1, wherein, The method further includes: Based on the monitoring data, determine the operating status information of the target business module; Based on the operating status information, determine whether the target business module meets the preset conditions; In response to the failure to meet the preset conditions, the remote memory corresponding to the target business module is determined; The data in the remote memory is migrated to the local memory of the target business module.
7. A memory access request scheduling device, comprising: The monitoring data acquisition unit is configured to acquire monitoring data from at least one business module; A business module determination unit is configured to determine a target business module from the at least one business module based on the monitoring data, wherein the memory access latency sensitivity of the target business module is greater than a preset sensitivity. The target node determination unit is configured to determine, based on the monitoring data, a target NUMA node that matches the target service module from a preset set of NUMA nodes, wherein the target NUMA node is the NUMA node that occupies the most memory for the target service module, or a NUMA node whose memory occupancy rate for NUMA nodes is within a preset range. The first request scheduling unit is configured to send the memory access request of the target service module to the target NUMA node.
8. The apparatus according to claim 7, wherein, The business module determination unit is further configured to: Based on the monitoring data, determine at least one of the following: number of memory accesses, memory access bandwidth, time waiting to access memory, time waiting to access the central processing unit, time waiting to access the cache, and the amount of data of different memory data types. Based on the determined information, determine the memory access latency sensitivity value of the at least one business module; Based on the memory access latency sensitivity value, the target business module is determined from the at least one business module.
9. The apparatus according to claim 8, wherein, The target node determination unit is further configured to: Determine the amount of memory occupied by the target service module in each NUMA node of the NUMA node set; The target NUMA node is determined based on the memory access bandwidth and / or memory usage of each NUMA node.
10. The apparatus according to claim 7, wherein, The device further includes: The resource information acquisition unit is configured to acquire the hardware resource information of the target NUMA node; The utilization determination unit is configured to determine the resource utilization of the target NUMA node based on the monitoring data and the hardware resource information. The backup node determination unit is configured to determine a backup NUMA node for the target NUMA node from the NUMA node set in response to determining that the resource utilization rate is greater than a preset threshold. The second request scheduling unit is configured to forward a portion of the memory access requests sent to the target NUMA node to the backup NUMA node.
11. The apparatus according to claim 10, wherein, The backup node determination unit is further configured to: Determine the resource utilization rate of each NUMA node in the NUMA node set; Based on the resource utilization of each NUMA node, the backup NUMA node for the target NUMA node is determined from the set of NUMA nodes.
12. The apparatus according to claim 7, wherein, The device further includes: The status information determination unit is configured to determine the operating status information of the target business module based on the monitoring data. The judgment unit is configured to determine whether the target business module meets preset conditions based on the running status information; The remote memory determination unit is configured to determine the remote memory corresponding to the target service module in response to the failure to meet the preset conditions; The data migration unit is configured to migrate data from the remote memory to the local memory of the target service module.
13. A memory access request scheduling electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.
14. A non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1-6.