Data scheduling method and device based on NUMA architecture, medium and product

Abstract

The invention provides a data scheduling method and device based on an NUMA architecture, a medium and a product, and relates to the field of financial science and technology and application of a large model in the field of financial science and technology. According to the method, performance parameters, used for indicating the load state, of multiple nodes under the NUMA architecture are obtained, then the performance parameters of the multiple nodes are input into a load prediction model, and the load condition and the remote overhead condition of each node in a preset time period are obtained; and performing dynamic scheduling processing on the to-be-executed tasks and / or memory data corresponding to the plurality of nodes based on the load condition and the remote overhead condition of the plurality of nodes. According to the method, through dynamic perception and adaptive optimization, remote access across NUMA nodes can be remarkably reduced, the data locality is improved, and the effect of improving the throughput and the response time of a database system in a high-concurrency and large-scale data processing scene is achieved.

Description

Technical Field

[0001] This application relates to the field of fintech and the application of large models in fintech, and in particular to a data scheduling method, apparatus, medium and product based on NUMA architecture. Background Technology

[0002] Non-Uniform Memory Access (NUMA) architecture has become standard in modern high-performance servers. In this architecture, each processor socket is equipped with local memory, while accessing remote memory across sockets introduces significant increases in latency and bandwidth consumption. Therefore, effectively reducing remote memory access and improving data locality has become a core issue in optimizing the performance of multi-processor, multi-core systems.

[0003] To fully leverage the computing potential of multi-core processors, modern analytical database systems widely adopt pipelining executor architectures. This architecture breaks down query operators into fine-grained tasks and schedules them using thread pools, enabling high-concurrency query processing and gradually replacing the traditional volcano model execution approach. However, although the operating system provides basic non-consistent memory access optimization mechanisms, such as allocating memory to processor nodes closer to running processes, the lack of awareness of the database's internal execution logic and data flow characteristics means that general optimization strategies are insufficient to meet the high-performance requirements of online analytical processing workloads in analytical databases.

[0004] Therefore, how to achieve dynamic scheduling of task load under NUMA architecture is the problem that needs to be solved. Summary of the Invention

[0005] This application provides a data scheduling method, apparatus, medium, and product based on NUMA architecture to perform authentication processing on APIs, thereby ensuring the legality and security of the data processing process.

[0006] Firstly, this application provides a data scheduling method based on a NUMA architecture. The method includes:

[0007] Obtain performance parameters of multiple nodes under a NUMA architecture, wherein the performance parameters are used to indicate the load status of the corresponding nodes;

[0008] The performance parameters of multiple nodes are input into the load prediction model to obtain the prediction result for each node. The load prediction model is used to predict the load and remote overhead of the corresponding node within a preset time period.

[0009] Based on the prediction results of multiple nodes, the tasks to be executed and / or memory data corresponding to multiple nodes are dynamically scheduled and processed.

[0010] In one possible implementation, the performance parameters include: real-time task queue length; the prediction results include: predicted task queue length within a preset time period; and the dynamic scheduling of tasks to be executed corresponding to multiple nodes based on the prediction results of multiple nodes includes:

[0011] Based on the predicted task queue length, it is determined whether there are busy nodes and idle nodes among the multiple nodes, wherein the predicted task queue length of the busy node is greater than the predicted task queue length of the idle node.

[0012] If present, at least one unexecuted task from the busy node will be migrated to the real-time task queue of the idle node.

[0013] In one possible implementation, determining whether there are busy nodes and idle nodes among multiple nodes based on the predicted task queue length includes:

[0014] For any one of the multiple nodes, determine whether the length of the predicted task queue of the node is greater than a preset length;

[0015] If so, then the node is determined to be a busy node;

[0016] The node with the smallest predicted task queue length among multiple nodes is designated as the idle node.

[0017] In one possible implementation, migrating at least one unexecuted task from the busy node to the real-time task queue of the idle node includes:

[0018] Determine the first remote access cost of at least one of the unexecuted tasks on a busy node during task migration;

[0019] If the remote access cost is less than the first preset access cost, at least one unexecuted task of the busy node is migrated to the real-time task queue of the idle node.

[0020] In one possible implementation, the performance parameters include: real-time remote access counts; the prediction results include: predicted remote access costs; and the dynamic scheduling processing of memory data corresponding to multiple nodes based on the prediction results of multiple nodes includes:

[0021] Determine whether the predicted remote access cost is greater than the second preset access cost;

[0022] If the predicted remote access cost is greater than the second preset access cost, the memory data, access node and data node corresponding to the remote access are determined, and the memory data is the data that is frequently accessed remotely by the access node.

[0023] The memory data within the data node is migrated to the access node.

[0024] In one possible implementation, an I / O proxy thread is deployed on each node, and the method further includes:

[0025] For any one of the multiple nodes, when the computing thread of that node performs a write operation, a corresponding write task is generated based on the data to be written and the metadata.

[0026] The write task is added to the task queue of the I / O agent thread of the node, so that the I / O agent thread executes the corresponding write task based on the task queue.

[0027] Secondly, this application provides a data scheduling device based on a NUMA architecture, the device comprising:

[0028] The acquisition module is used to acquire performance parameters of multiple nodes under the NUMA architecture, and the performance parameters are used to indicate the load status of the corresponding nodes.

[0029] The processing module is used to input the performance parameters of multiple nodes into the load prediction model to obtain the prediction result for each node. The load prediction model is used to predict the load and remote overhead of the corresponding node within a preset time period.

[0030] The processing module is also used to dynamically schedule and process the tasks to be executed and / or memory data corresponding to multiple nodes based on the prediction results of multiple nodes.

[0031] In one possible implementation, the performance parameters include: real-time task queue length, and the prediction result includes: predicted task queue length within a preset time period. The processing module is specifically used to determine, based on the predicted task queue length, whether there are busy nodes and idle nodes among multiple nodes, wherein the predicted task queue length of the busy node is greater than the predicted task queue length of the idle node; and if so, to migrate at least one unexecuted task of the busy node to the real-time task queue of the idle node.

[0032] In one possible implementation, the processing module is specifically used to determine, for any one of the multiple nodes, whether the predicted task queue length of the node is greater than a preset length; if so, determine that the node is a busy node; and designate at least one node with the smallest predicted task queue length among the multiple nodes as the idle node.

[0033] In one possible implementation, the processing module is specifically configured to determine a first remote access cost for at least one of the unexecuted tasks of a busy node during task migration; and, if the remote access cost is less than a first preset access cost, migrate at least one unexecuted task of the busy node to the real-time task queue of the idle node.

[0034] In one possible implementation, the performance parameters include: real-time remote access counts, the prediction result includes: predicted remote access cost, and the processing module is specifically used to determine whether the predicted remote access cost is greater than a second preset access cost; if the predicted remote access cost is greater than the second preset access cost, determine the memory data, access node, and data node corresponding to the remote access, wherein the memory data is data frequently accessed remotely by the access node; and migrate the memory data in the data node to the access node.

[0035] In one possible implementation, each node is equipped with an I / O proxy thread. The processing module is further configured to generate a corresponding write task based on the data to be written and metadata when the computing thread of any one of the multiple nodes performs a write operation; and to add the write task to the task queue of the I / O proxy thread of the node, so that the I / O proxy thread executes the corresponding write task based on the task queue.

[0036] Thirdly, this application provides a data scheduling device based on a NUMA architecture, comprising: a processor, and a memory communicatively connected to the processor;

[0037] The memory stores computer-executed instructions;

[0038] The processor executes computer execution instructions stored in the memory to implement the first aspect and / or various possible implementations of the first aspect.

[0039] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0040] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0041] The data scheduling method, apparatus, medium, and product based on NUMA architecture provided in this application obtain performance parameters of multiple nodes under NUMA architecture to indicate load status, and then input the performance parameters of multiple nodes into a load prediction model to obtain the load status and remote overhead of each node within a preset time period; then, based on the load status and remote overhead of multiple nodes, dynamically schedule and process the tasks to be executed and / or memory data corresponding to multiple nodes; through dynamic perception and adaptive optimization, this method can significantly reduce remote access across NUMA nodes, improve data locality, and achieve the effect of improving the throughput and response time of database systems in high-concurrency and large-scale data processing scenarios. Attached Figure Description

[0042] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0043] Figure 1 A flowchart illustrating a data scheduling method based on a NUMA architecture provided in this application embodiment. Figure 1 ;

[0044] Figure 2 A flowchart illustrating a data scheduling method based on a NUMA architecture provided in this application embodiment. Figure 2 ;

[0045] Figure 3 A flowchart illustrating a data scheduling method based on a NUMA architecture provided in this application embodiment. Figure 3 ;

[0046] Figure 4 A schematic diagram of a data scheduling device based on a NUMA architecture provided in this application embodiment;

[0047] Figure 5 This is a schematic diagram of the structure of a data scheduling device based on a NUMA architecture, provided in an embodiment of this application.

[0048] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0049] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0050] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0051] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0052] It should be noted that the data scheduling method, apparatus, medium and product based on NUMA architecture provided in this application can be used in the field of fintech and the application of large models in fintech, and can also be used in any field other than the field of fintech and the application of large models in fintech. The application field of the data scheduling method, apparatus, medium and product based on NUMA architecture in this application is not limited.

[0053] First, the terms used in this application will be explained:

[0054] NUMA architecture: In a multi-core central processing unit (CPU), different CPU cores access different memory locations at different speeds.

[0055] Executor: In modern database systems, the executor is responsible for executing queries. Within the SQL execution stack, it receives the execution plan generated by the optimizer and performs calculations on the data through the data read / write interfaces provided by the storage engine to obtain the result set. In distributed databases, the executor is also responsible for inter-node network data exchange and transmission.

[0056] Data locality refers to the ideal scenario where an operator, after completing its computation and passing the result to the next operator, is scheduled to run on the same CPU core (or node). Inter-core memory swapping or inter-node network transfer is a very time-consuming operation, necessitating a trade-off between data locality and data / processing speed skew. This trade-off presents a challenge for scheduling algorithm design.

[0057] Multi-core NUMA architecture has become the mainstream in modern servers. Its characteristic is that each CPU socket has local memory, and cross-slot access to remote memory incurs high latency and bandwidth loss. For example, in a dual-socket server, each socket's read bandwidth to local memory can reach 100+ GB / s, while cross-slot access only provides about one-third of that bandwidth; remote memory access latency is often more than twice that of local access. Therefore, reducing remote memory access and improving data locality are key to optimizing system performance in multi-socket, multi-core environments.

[0058] To fully tap the potential of multi-core computing, modern analytical database systems widely adopt pipelined executor architectures. By breaking down query operators into fine-grained tasks and scheduling them by thread pools, high-concurrency query processing is achieved, gradually replacing the traditional volcano model execution method.

[0059] Traditional volcano model executors typically achieve parallelization by inserting data exchange operators, but their lack of hardware topology awareness between thread scheduling and data distribution leads to frequent cross-node memory accesses by computational tasks, causing bus bandwidth contention and increased query latency. In contrast, pipelined execution models, with their fine-grained task scheduling capabilities, offer the possibility of dynamically being aware of inconsistent memory access topologies. Some existing optimization frameworks improve data locality to some extent by partitioning data by node and combining mechanisms such as work-stealing and delayed scheduling.

[0060] However, although the operating system provides basic non-uniform memory access optimization mechanisms, such as allocating memory to processor nodes closer to running processes, the lack of awareness of the database's internal execution logic and data flow characteristics makes it difficult for general optimization strategies to meet the high-performance requirements of online analytical processing workloads in analytical databases.

[0061] Therefore, how to achieve dynamic scheduling of task load under NUMA architecture is the problem that needs to be solved.

[0062] To address the aforementioned issues, this application provides a data scheduling method based on a NUMA architecture. This method obtains performance parameters from multiple nodes within the NUMA architecture that indicate their load status. These parameters are then input into a load prediction model to obtain the load and remote overhead of each node within a preset time period. Based on the load and remote overhead of the multiple nodes, the method dynamically schedules the tasks to be executed and / or memory data corresponding to each node. Through dynamic perception and adaptive optimization, this method significantly reduces remote access across NUMA nodes, improves data locality, and achieves the effect of increasing the throughput and response time of the database system in high-concurrency and large-scale data processing scenarios.

[0063] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0064] Figure 1 A flowchart illustrating a data scheduling method based on a NUMA architecture provided in this application embodiment. Figure 1 .like Figure 1 As shown in the embodiments of this application, the data scheduling method based on NUMA architecture includes:

[0065] S101. Obtain the performance parameters of multiple nodes under the NUMA architecture.

[0066] Performance parameters can indicate the load status of the corresponding node. These parameters may include, for example, the actual task queue length, the actual number of remote accesses, the CPU utilization of each thread, and the local memory hit rate. For instance, performance parameters may also include the progress of the currently executing task.

[0067] The actual task queue length can represent, for example, the number of tasks to be executed on the corresponding node at the current moment; the actual number of remote accesses can represent, for example, the memory access frequency of the corresponding node across NUMA nodes at the current moment.

[0068] This step can acquire performance parameters in real time, or according to a preset period or based on a scheduled task. For example, the acquisition module can start a low-overhead monitoring thread or scheduled task to periodically collect the running data and performance parameters of each NUMA node.

[0069] Understandably, the acquisition process in this step could employ a lock-free design, and only retrieve key summary information to ensure that it does not interfere with normal query execution.

[0070] S102. Input the performance parameters of multiple nodes into the load prediction model to obtain the prediction results for each node.

[0071] The load forecasting model is used to assess potential load imbalances and remote overhead on nodes. For example, it can predict the load and remote overhead of a corresponding node within a preset time period.

[0072] For example, load prediction models can predict the predicted task queue length of a node within a preset time period based on the actual task queue length of the corresponding node. They can also predict the remaining execution time of a node based on the actual task queue length and the corresponding processing speed. Furthermore, they can predict the potential non-local access cost of a task based on the actual number of remote accesses.

[0073] Load prediction models can be obtained through iterative training based on historical performance parameters of multiple NUMA nodes under a NUMA architecture.

[0074] S103. Based on the prediction results of multiple nodes, dynamically schedule and process the tasks to be executed and / or memory data corresponding to multiple nodes.

[0075] The prediction results may include, for example, the remaining execution time of the corresponding node, the predicted task queue length within a preset time period, and the predicted remote access cost. These prediction results can characterize the load and remote access overhead of the corresponding node.

[0076] Understandably, if the prediction results indicate that a task on a certain node will lag significantly behind other nodes, or if a task continues to receive a large number of remote accesses, resulting in poor performance, then dynamic scheduling can be performed on the tasks to be executed and / or the memory data corresponding to multiple nodes.

[0077] For example, if the prediction result indicates that there is a backlog of tasks in the queue of node 0, while node 1 is in an idle state, the remaining data sharding tasks of node 0 can be re-marked as node 1 affinity and added to the task queue of node 1 so that the thread of node 1 can process the data sharding tasks.

[0078] For example, if a prediction indicates that a certain data block is frequently accessed by threads not belonging to the same node, then that data block can be migrated to the memory of a frequently accessed node. This makes subsequent access to that data local, thereby improving the cache hit rate.

[0079] Understandably, in certain analytical scenarios (such as loading large amounts of data), writing files to the system can become a bottleneck. If the computation thread directly performs cross-NUMA write operations, it may incur two types of overhead: first, data is copied from the local node to the target storage node; second, access to the storage device may deviate from the local node, leading to bus communication issues.

[0080] In one possible implementation, to reduce NUMA overhead in high-concurrency write scenarios, an I / O proxy thread can be deployed on each NUMA node. This I / O proxy thread is responsible for handling persistent write requests on the local node. The following explanation uses any one of multiple NUMA nodes as an example:

[0081] When the compute thread on the NUMA node performs a write operation, it generates a corresponding write task based on the data to be written and metadata. Then, it adds the write task to the task queue of the I / O agent thread on the local node. The I / O agent thread on the local node will execute the corresponding write task based on the task queue.

[0082] In this step, operations involving writing to disk, SSD, or persistent memory (PM) during Pipeline execution are no longer directly executed by the compute thread using system calls. Instead, the compute thread packages the data to be written and metadata into a write task, pushes it to the queue of the I / O agent thread on the local node, and then returns asynchronously to continue processing other compute tasks. Upon detecting a write request, the I / O agent thread performs the actual write operation on the local node.

[0083] Because the I / O agent thread is topologically close to the device controller, this ensures that the data write path is confined to the local node, avoiding remote memory access and cross-bus data transfer caused by cross-node writes.

[0084] For example, the I / O proxy thread is equipped with a lock-free circular buffer queue. Each computation thread enqueues a write request in a non-blocking manner and wakes up the I / O proxy thread using a lightweight notification mechanism. After the I / O proxy thread obtains write requests in batches, it can perform the write operation using the local asynchronous I / O interface provided by the operating system. For write operations that require transactional guarantees, the proxy thread can also assume the responsibility of flushing to disk and acknowledgment, asynchronously notifying the computation thread of the results, thereby decoupling computation from I / O.

[0085] This step achieves write localization under high write pressure scenarios by deploying I / O proxy threads on each NUMA node: the threads of computation tasks do not need to get stuck in slow I / O operations, reducing context switching and thread blocking; furthermore, data is always written to disk or persisted on the local node, minimizing NUMA remote memory access and cross-node bus communication. Adding a local I / O proxy mechanism can significantly improve total write throughput and reduce the impact of write operations on query latency, ensuring the system's stable performance under mixed read and write loads.

[0086] The data scheduling method based on NUMA architecture provided in this application obtains performance parameters of multiple nodes under the NUMA architecture to indicate their load status, and then inputs these performance parameters into a load prediction model to obtain the load status and remote overhead of each node within a preset time period. Based on the load status and remote overhead of multiple nodes, the method dynamically schedules the tasks to be executed and / or memory data corresponding to the multiple nodes. Through dynamic perception and adaptive optimization, this method can significantly reduce remote access across NUMA nodes, improve data locality, and achieve the effect of improving the throughput and response time of the database system in high-concurrency and large-scale data processing scenarios.

[0087] Figure 2 A flowchart illustrating a data scheduling method based on a NUMA architecture provided in this application embodiment. Figure 2 The performance parameters in this embodiment include: real-time task queue length, and the prediction result includes: the predicted task queue length within a preset time period. This embodiment of the application is... Figure 1 Based on the embodiments, a possible implementation method for dynamically scheduling tasks corresponding to multiple nodes based on prediction results is described in detail. For example... Figure 2 As shown in the embodiments of this application, the data scheduling method based on NUMA architecture includes:

[0088] S201. Based on the predicted task queue length, determine whether there are busy nodes and idle nodes among multiple nodes.

[0089] Busy nodes can be NUMA nodes with multiple tasks waiting to be executed in the task queue or high load. Idle nodes can be NUMA nodes with no tasks waiting to be executed or low load.

[0090] In this step, for example, the node with the longest predicted task queue among multiple nodes can be designated as a busy node, or a node with a predicted task queue length greater than a first preset length can be designated as a busy node. The first preset length can be, for example, 80, 100, etc.

[0091] Alternatively, the node with the smallest predicted task queue length among multiple nodes can be designated as an idle node, or a node with a predicted task queue length less than a second preset length can be designated as an idle node. This application does not impose any restrictions on this.

[0092] Understandably, the number of busy nodes and idle nodes can be one, multiple, or even zero. The prediction task queue length of busy nodes is greater than the prediction task queue length of idle nodes.

[0093] In one possible implementation, the specific method for determining whether there are busy nodes and idle nodes among multiple nodes is as follows:

[0094] For any one of the multiple nodes, determine whether the length of the prediction task queue of that node is greater than a preset length; if so, determine that the node as a busy node; and designate at least one node with the smallest prediction task queue length among the multiple nodes as an idle node.

[0095] S202. If it exists, determine the first remote access cost of at least one unexecuted task of the busy node during task migration.

[0096] The first remote access cost may include, for example, data movement overhead, cache invalidation overhead, and synchronization and metadata management overhead.

[0097] Understandably, when a task is migrated to a thread on node B for execution, the data that the task needs to process is still stored in the memory of node A. At this time, the system usually needs to move or copy this data from the memory of node A to the memory of node B.

[0098] This data movement itself requires bandwidth on the cross-node interconnect bus. If the amount of data being moved is large (such as a large hash table or data shard), this migration operation will generate a high-latency, high-bandwidth data transmission on the bus, which may temporarily block other normal remote access requests.

[0099] Furthermore, when the task begins execution on node B, it will immediately encounter a large number of cache misses. It needs to reload data from memory, and the first few memory accesses are likely to be high-latency remote accesses (accessing the memory of node A). This will result in extremely low execution efficiency for the task in the initial stage after migration, completely negating any potential benefits of the migration.

[0100] After determining the existence of busy and idle nodes, the purpose of this step, which identifies the first remote access cost of at least one unexecuted task on a busy node during task migration, is to weigh the costs and benefits of this task migration.

[0101] S203. Determine whether the first remote access cost is less than the preset access cost; if yes, proceed to step S205; if no, proceed to step S204.

[0102] The preset access cost can be a general access cost or a predicted access benefit calculated based on the data corresponding to the above task migration. This application does not impose any restrictions on this.

[0103] If the cost of the first remote access is less than the preset access cost, it indicates that the benefits of this task migration outweigh the losses. Therefore, at least one unexecuted task from a busy node can be migrated to the real-time task queue of an idle node.

[0104] If the cost of the first remote access is greater than the preset access cost, it indicates that the benefit of this task migration is less than the loss, so the task migration procedure will not be executed.

[0105] S204. Do not execute the task migration procedure.

[0106] S205. Migrate at least one unexecuted task from a busy node to the real-time task queue of an idle node.

[0107] The data scheduling method based on NUMA architecture provided in this application determines whether there are busy nodes and idle nodes among multiple nodes based on the predicted task queue length. When busy nodes and idle nodes exist, and the benefits of task migration outweigh the losses, the corresponding task migration procedure is executed. This method can improve the accuracy and response speed of dynamic adjustment strategies, and further optimize system throughput and resource utilization in high-concurrency scenarios.

[0108] Figure 3 A flowchart illustrating a data scheduling method based on a NUMA architecture provided in this application embodiment. Figure 3 The performance parameters in this embodiment include: the number of real-time remote accesses, and the prediction results include: the predicted remote access cost. This embodiment of the application is... Figure 1 Based on the embodiments, a possible implementation method for dynamically scheduling and processing the memory data corresponding to multiple nodes based on the prediction results of multiple nodes is described in detail. For example... Figure 3 As shown in the embodiments of this application, the data scheduling method based on NUMA architecture includes:

[0109] S301. Determine whether the predicted remote access cost is greater than the second preset access cost; if yes, proceed to step S303; if no, proceed to step S302.

[0110] The purpose of this step, which determines whether the predicted remote access cost is greater than the second preset access cost, is to determine whether the benefits or costs of data migration outweigh the costs.

[0111] If the predicted cost of remote access is greater than the second preset cost, it indicates that the benefits of this data migration outweigh the losses, and therefore the corresponding memory data migration program can be executed.

[0112] If the predicted remote access cost is less than the second preset access cost, it indicates that the benefit of this data migration is less than the loss, so the corresponding memory data migration program does not need to be executed.

[0113] S302, Do not execute the memory data migration procedure.

[0114] S303. Determine the memory data, access node, and data node corresponding to remote access.

[0115] Among them, memory data can be, for example, data that is frequently accessed remotely by the accessed node.

[0116] Understandably, after determining to execute the memory data migration program, it is necessary to determine the corresponding migration object and the object being migrated so that the subsequent execution of the memory data migration program can proceed.

[0117] This step improves the accuracy and response speed of dynamic adjustment strategies by quantifying thresholds, thereby further optimizing system throughput and resource utilization in high-concurrency scenarios.

[0118] S304. Migrate the memory data in the data node to the access node.

[0119] The data scheduling method based on NUMA architecture provided in this application achieves fine-grained control over data migration through a dynamic judgment mechanism based on preset thresholds. For example, data is migrated first when hot data is frequently accessed, reducing latency in cross-node memory access. This mechanism improves the accuracy and response speed of dynamic adjustment strategies by quantifying threshold judgments, thereby further optimizing system throughput and resource utilization in high-concurrency scenarios.

[0120] Figure 4 This is a schematic diagram of a data scheduling device based on a NUMA architecture, provided as an embodiment of this application. Figure 4 As shown, the data scheduling device 400 based on NUMA architecture provided in this embodiment includes:

[0121] The acquisition module 401 is used to acquire the performance parameters of multiple nodes under the NUMA architecture. The performance parameters are used to indicate the load status of the corresponding nodes.

[0122] The processing module 402 is used to input the performance parameters of multiple nodes into the load prediction model to obtain the prediction result of each node. The load prediction model is used to predict the load and remote overhead of the corresponding node within a preset time period.

[0123] The processing module 402 is also used to dynamically schedule and process the tasks to be executed and / or memory data corresponding to multiple nodes based on the prediction results of multiple nodes.

[0124] In one possible implementation, the performance parameters include: real-time task queue length, the prediction result includes: predicted task queue length within a preset time period, and the processing module 402 is specifically used to determine whether there are busy nodes and idle nodes among multiple nodes based on the predicted task queue length, wherein the predicted task queue length of the busy node is greater than the predicted task queue length of the idle node; and if so, to migrate at least one unexecuted task of the busy node to the real-time task queue of the idle node.

[0125] In one possible implementation, the processing module 402 is specifically used to determine, for any one of the multiple nodes, whether the length of the predicted task queue of the node is greater than a preset length; if so, the node is determined to be a busy node; and at least one node with the smallest predicted task queue length among the multiple nodes is designated as an idle node.

[0126] In one possible implementation, the processing module 402 is specifically configured to determine the first remote access cost of at least one unexecuted task of a busy node during task migration; and if the remote access cost is less than the first preset access cost, migrate at least one unexecuted task of the busy node to the real-time task queue of the idle node.

[0127] In one possible implementation, the performance parameters include: real-time remote access counts, and the prediction results include: predicted remote access cost. The processing module 402 is specifically used to determine whether the predicted remote access cost is greater than a second preset access cost; if the predicted remote access cost is greater than the second preset access cost, it determines the memory data, access node, and data node corresponding to the remote access, where the memory data is the data frequently accessed by the accessed node; and it migrates the memory data in the data node to the access node.

[0128] In one possible implementation, each node is equipped with an I / O proxy thread. The processing module 402 is also used to generate a corresponding write task based on the data to be written and metadata when the computing thread of any of the multiple nodes performs a write operation; and to add the write task to the task queue of the node's I / O proxy thread so that the I / O proxy thread can execute the corresponding write task based on the task queue.

[0129] The data scheduling device based on NUMA architecture provided in this embodiment can execute the methods provided in the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0130] Figure 5 This is a schematic diagram of a data scheduling device based on a NUMA architecture, provided as an embodiment of this application. Figure 5 As shown, the data scheduling device 500 based on NUMA architecture provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 500 also includes a communication interface 503. The processor 501, memory 502, and communication interface 503 are connected via a bus 504.

[0131] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0132] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0133] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0134] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0135] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0136] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0137] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0138] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0139] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0140] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0142] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0144] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0145] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0146] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0147] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0148] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0149] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0150] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0151] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0152] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0153] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A data scheduling method based on NUMA architecture, characterized in that, The method includes: Obtain performance parameters of multiple nodes under a NUMA architecture, wherein the performance parameters are used to indicate the load status of the corresponding nodes; The performance parameters of multiple nodes are input into the load prediction model to obtain the prediction result for each node. The load prediction model is used to predict the load and remote overhead of the corresponding node within a preset time period. Based on the prediction results of multiple nodes, the tasks to be executed and / or memory data corresponding to multiple nodes are dynamically scheduled and processed.

2. The method according to claim 1, characterized in that, The performance parameters include: real-time task queue length; the prediction results include: predicted task queue length within a preset time period; and the dynamic scheduling of tasks to be executed corresponding to multiple nodes based on the prediction results of multiple nodes includes: Based on the predicted task queue length, it is determined whether there are busy nodes and idle nodes among the multiple nodes, wherein the predicted task queue length of the busy node is greater than the predicted task queue length of the idle node. If present, at least one unexecuted task from the busy node will be migrated to the real-time task queue of the idle node.

3. The method according to claim 2, characterized in that, The step of determining whether there are busy nodes and idle nodes among multiple nodes based on the predicted task queue length includes: For any one of the multiple nodes, determine whether the length of the predicted task queue of the node is greater than a preset length; If so, then the node is determined to be a busy node; The node with the smallest predicted task queue length among multiple nodes is designated as the idle node.

4. The method according to claim 2, characterized in that, The step of migrating at least one unexecuted task from the busy node to the real-time task queue of the idle node includes: Determine the first remote access cost of at least one of the unexecuted tasks on a busy node during task migration; If the remote access cost is less than the first preset access cost, at least one unexecuted task of the busy node is migrated to the real-time task queue of the idle node.

5. The method according to any one of claims 1-4, characterized in that, The performance parameters include: real-time remote access counts; the prediction results include: predicted remote access costs; and the dynamic scheduling processing of memory data corresponding to multiple nodes based on the prediction results of multiple nodes includes: Determine whether the predicted remote access cost is greater than the second preset access cost; If the predicted remote access cost is greater than the second preset access cost, the memory data, access node and data node corresponding to the remote access are determined, and the memory data is the data that is frequently accessed remotely by the access node. The memory data within the data node is migrated to the access node.

6. The method according to any one of claims 1-5, characterized in that, Each node has an I / O proxy thread deployed on it, and the method further includes: For any one of the multiple nodes, when the computing thread of that node performs a write operation, a corresponding write task is generated based on the data to be written and the metadata. The write task is added to the task queue of the I / O agent thread of the node, so that the I / O agent thread executes the corresponding write task based on the task queue.

7. A data scheduling device based on NUMA architecture, characterized in that, The device includes: The acquisition module is used to acquire performance parameters of multiple nodes under the NUMA architecture, and the performance parameters are used to indicate the load status of the corresponding nodes. The processing module is used to input the performance parameters of multiple nodes into the load prediction model to obtain the prediction result for each node. The load prediction model is used to predict the load and remote overhead of the corresponding node within a preset time period. The processing module is also used to dynamically schedule and process the tasks to be executed and / or memory data corresponding to multiple nodes based on the prediction results of multiple nodes.

8. A data scheduling device based on NUMA architecture, characterized in that, include: Memory; processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6.

Images