Dynamic resource scheduling method for in-memory computing server and related equipment

Abstract

The application relates to a dynamic resource scheduling method and system of a storage-computing integrated server, comprising the following steps: collecting node load data and a node resource graph of each storage-computing node in a server cluster, performing time series decomposition on the node load data to obtain a load trend component, and performing resource classification on the node resource graph to obtain a heterogeneous resource table; performing fluctuation feature extraction on the load trend component to obtain a window fluctuation entropy value, and performing resource correlation analysis on various resources in the heterogeneous resource table based on the window fluctuation entropy value to obtain a resource association matrix; and according to the resource association matrix, performing resource demand decomposition on a to-be-processed task in the server cluster to obtain a subtask resource vector, and based on the subtask resource vector and the node resource graph, matching a scheduling instruction containing a node identifier and a resource allocation amount for each subtask in the storage-computing node, so that the technical problem that subtask resource configuration mismatch often occurs in an existing scheme is solved.

Description

Technical Field

[0001] This invention relates to the field of server technology, and in particular to a dynamic resource scheduling method and related equipment for in-memory computing servers. Background Technology

[0002] With the rapid development of computationally intensive applications such as artificial intelligence and big data analytics, in-memory computing servers have attracted widespread attention due to their ability to effectively alleviate the memory wall problem in traditional von Neumann architectures. Existing in-memory computing systems typically employ static or threshold-based resource scheduling strategies. These strategies periodically collect basic load metrics such as CPU utilization, memory usage, and storage bandwidth of each in-memory node, and then distribute tasks to relatively idle nodes based on pre-defined resource allocation rules. This approach achieves load balancing to a certain extent and has already been deployed in typical scenarios such as inference services and graph computing.

[0003] However, these scheduling mechanisms generally ignore the trend characteristics of load changes and the dynamic relationship between heterogeneous resources, making decisions based solely on instantaneous load levels. This makes it difficult to accurately predict future resource pressure on nodes when facing task loads with significant time fluctuations and resource coupling dependencies, leading to resource contention or utilization imbalances. Especially in multi-task concurrent environments, existing solutions often suffer from mismatched subtask resource configurations because they cannot identify the collaborative usage patterns between different resource dimensions (such as computing units, in-memory processing units, and on-chip cache), affecting overall scheduling efficiency and system response performance. Summary of the Invention

[0004] The main technical problem addressed in this application is to provide a dynamic resource scheduling method and related equipment for in-memory computing servers, thereby resolving the technical issue of mismatched subtask resource configurations that often occurs in existing solutions.

[0005] To address the aforementioned technical problems, this application employs a dynamic resource scheduling method for in-memory computing servers, comprising the following steps: Collect node load data and node resource map of each computing node in the server cluster; The node load data is decomposed over time to obtain a load trend component that reflects the long-term change pattern of the load, and the node resource map is classified to obtain a heterogeneous resource table. Fluctuation features are extracted from the load trend components to obtain window fluctuation entropy values. Based on the window fluctuation entropy values, resource correlation analysis is performed on various resources in the heterogeneous resource table to obtain a resource association matrix that characterizes the strength of collaborative dependence between resources. Based on the resource association matrix, the resource requirements of the tasks to be processed in the server cluster are deconstructed to obtain subtask resource vectors. Based on the subtask resource vectors and the node resource graph, a scheduling instruction containing a node identifier and resource allocation is matched for each subtask in the storage node.

[0006] Furthermore, the acquisition of node load data and node resource graphs for each computing node in the server cluster includes: The hardware components of the storage nodes are inspected in real time, and the CPU utilization, memory utilization, storage I / O rate and network bandwidth utilization of each storage node are collected to obtain node load data. Based on the hardware components corresponding to the node load data, the hardware connection relationship and resource allocation path of each storage node are scanned to obtain a node resource connection graph. The node resource connection graph is then labeled with node identifiers and classified by resource type to obtain a node resource map.

[0007] Furthermore, the node load data is decomposed over time to obtain a load trend component reflecting the long-term variation pattern of the load, and the node resource map is classified to obtain a heterogeneous resource table, including: The node load data is periodically sampled by a sliding window to obtain multiple load data segments, and a linear fit is performed on each load data segment to obtain the load trend line of each segment. All load trend lines are merged to obtain load trend components. Based on the hardware connection relationships in the node resource map, the resources in the node resource map are topologically sorted to obtain a resource topology sequence. Based on the resource topology sequence, the resources are grouped according to resource type to obtain a heterogeneous resource table.

[0008] Furthermore, the resource correlation analysis of various resources in the heterogeneous resource table based on the window fluctuation entropy value, to obtain a resource association matrix characterizing the strength of collaborative dependency among resources, includes: The window fluctuation entropy value is normalized to obtain a normalized entropy value sequence. Based on the normalized entropy value sequence, the fluctuation of various resources in the heterogeneous resource table under different time windows is compared and analyzed to obtain the fluctuation synchronization degree between various resources. Based on the fluctuation synchronization degree among the various types of resources, the various types of resources are combined in pairs, the synergy dependency coefficient of each resource combination is calculated, and all synergy dependency coefficients are arranged according to the resource combination type to obtain the resource association matrix.

[0009] Furthermore, based on the resource association matrix, the resource requirements of the tasks to be processed within the server cluster are deconstructed to obtain subtask resource vectors, including: The task to be processed is decomposed into a task hierarchy tree, which includes a main task node and multiple sub-task nodes. Based on the resource association matrix, resource requirements are mapped for each sub-task node in the task hierarchy tree to obtain a resource requirement mapping table for each sub-task node. The resource types in the resource requirement mapping table are then quantified and statistically analyzed to obtain the resource requirements of each sub-task node. Based on the resource requirements of each subtask node, the resource requirements of the subtask nodes in the task hierarchy tree are merged to obtain a subtask resource vector. Then, based on the resource association matrix, the resource types in the subtask resource vector are verified to obtain a verified subtask resource vector.

[0010] Furthermore, based on the resource requirements of each sub-task node, the resource requirements of the sub-task nodes in the task hierarchy tree are merged to obtain a sub-task resource vector, including: The resource requirements of each subtask node are categorized by resource type to obtain a set of resource types. The resource requirements of each subtask node's resource type set are then summed to obtain the total requirement of each resource type in the task hierarchy tree. Based on the total demand of each resource type in the task hierarchy tree, the resource demand allocation ratio of the sub-task nodes in the task hierarchy tree is calculated to obtain the allocation ratio of each sub-task node to each resource type. Based on the allocation ratio, the resource demand of each sub-task node is weighted and merged to obtain the sub-task resource vector.

[0011] Furthermore, based on the subtask resource vector and the node resource graph, a scheduling instruction containing a node identifier and resource allocation is matched for each subtask in the computing node, including: The resource types and demand quantities in the subtask resource vector are analyzed to obtain a subtask resource demand list. Based on the node resource graph, the remaining resource quantity of the storage nodes is statistically analyzed to obtain a node resource remaining table. By comparing the subtask resource demand list with the node resource remaining table, a set of candidate nodes that meet the subtask resource requirements is selected. Resource adaptability is calculated for each storage node in the candidate node set to obtain the resource adaptability value of each node. The candidate node set is sorted based on the resource adaptability value to generate a scheduling instruction containing node identifier and resource allocation.

[0012] The present invention also provides a dynamic resource scheduling device for an in-memory computing server, comprising: The data acquisition module is used to collect node load data and node resource map of each computing node in the server cluster; The classification module is used to perform time-series decomposition on the node load data to obtain load trend components that reflect the long-term change pattern of the load, and to classify the node resource map to obtain a heterogeneous resource table. The extraction module is used to extract the fluctuation characteristics of the load trend component, obtain the window fluctuation entropy value, and perform resource correlation analysis on various resources in the heterogeneous resource table based on the window fluctuation entropy value to obtain a resource association matrix that characterizes the strength of collaborative dependence between resources. The deconstruction module is used to deconstruct the resource requirements of the tasks to be processed in the server cluster according to the resource association matrix, obtain the subtask resource vector, and match the scheduling instruction containing the node identifier and resource allocation for each subtask in the storage node based on the subtask resource vector and the node resource graph.

[0013] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the above methods.

[0014] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any of the above methods.

[0015] The above scheme collects node load data and node resource maps of each computing node in the server cluster. It performs time-series decomposition on the node load data to obtain a load trend component reflecting the long-term load variation pattern, and categorizes the node resource maps to obtain a heterogeneous resource table. It extracts fluctuation features from the load trend component to obtain a window fluctuation entropy value, and performs resource correlation analysis on various resources in the heterogeneous resource table based on the window fluctuation entropy value to obtain a resource association matrix characterizing the strength of collaborative dependencies between resources. Based on the resource association matrix, it deconstructs the resource requirements of tasks to be processed within the server cluster to obtain sub-task resource vectors. Based on the sub-task resource vectors and the node resource map, it matches scheduling instructions containing node identifiers and resource allocation amounts for each sub-task in the computing nodes. This solves the technical problem of mismatched sub-task resource configurations that often occurs in existing schemes. It achieves task requirement deconstruction before task scheduling, generates fine-grained sub-task resource vectors, and performs joint matching with the resource association matrix and real-time node resource map, realizing a shift from extensive allocation to precise adaptation, improving resource utilization and task execution efficiency. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a dynamic resource scheduling method for an in-memory computing server according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating step S1 of the method in one embodiment of the present invention; Figure 3 This is a flowchart illustrating step S2 of the method in one embodiment of the present invention; Figure 4 This is a flowchart illustrating step S4 of the method in one embodiment of the present invention; Figure 5 This is a structural block diagram of a dynamic resource scheduling device for an in-memory computing server according to an embodiment of the present invention; Figure 6 This is a schematic block diagram of the structure of a computer device according to an embodiment of the present invention.

[0018] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0020] Specifically, the dynamic resource scheduling method for the in-memory computing server in this embodiment includes the following steps: like Figure 1 As shown, Figure 1 This invention provides a dynamic resource scheduling method for an in-memory computing server, comprising the following steps: Step S1: Collect node load data and node resource map of each storage node in the server cluster; Step S2: Perform time-series decomposition on the node load data to obtain load trend components that reflect the long-term change pattern of the load, and classify the node resource map to obtain a heterogeneous resource table.

[0021] Specifically, when collecting node load data and node resource maps for each in-memory node in the server cluster, monitoring agents deployed on each node periodically acquire the real-time utilization rates of CPU, memory, in-memory computing units, and storage I / O as node load data. Simultaneously, the hardware abstraction layer reads the internal resource topology of the nodes to form a node resource map. The node load data is then decomposed using the STL (Seasonal-Trend decomposition using Loess) method to separate load trend components reflecting long-term changes. At the same time, based on the functional attributes recorded in the node resource map, computing, storage, and dedicated processing units are categorized into different types of resource entries, constructing a heterogeneous resource table containing resource types, capacities, and connectivity relationships. For example, in an AI inference service scenario, the map of a certain in-memory node shows that it is equipped with 8 in-memory computing cores and a two-level cache system. After categorization, these are filled into the "in-memory computing unit" and "cached" categories in the heterogeneous resource table to support subsequent analysis.

[0022] Step S,3: Extract fluctuation features from the load trend component to obtain window fluctuation entropy value, and perform resource correlation analysis on various resources in the heterogeneous resource table based on the window fluctuation entropy value to obtain a resource association matrix that characterizes the strength of collaborative dependence between resources.

[0023] Specifically, the load trend component obtained in the previous step is taken, and continuous data segments are extracted using a sliding time window. The probability distribution of the trend value within each window is calculated, and then substituted into the Shannon entropy formula H = -Σp i log p i The window fluctuation entropy value is obtained, which reflects the degree of disorder in load changes within the corresponding time period. Then, this entropy value is used as a weighting factor to participate in the correlation calculation between the resource utilization rate sequences in the heterogeneous resource table. Specifically, the entropy weighted covariance of each pair of resources is normalized to generate numerical pairs that characterize the dynamic coupling strength. For example, in AI inference scenarios, if the memory unit utilization rate fluctuation entropy of a certain node is high, its correlation with the on-chip cache will be correspondingly enhanced. The correlation values ​​of all resource pairs are finally arranged into a matrix form, which is the resource correlation matrix, used to characterize the collaborative dependency relationship of different resources in actual operation.

[0024] Step S4: Based on the resource association matrix, deconstruct the resource requirements of the tasks to be processed in the server cluster to obtain subtask resource vectors. Based on the subtask resource vectors and the node resource graph, match a scheduling instruction containing a node identifier and resource allocation for each subtask in the storage node.

[0025] Specifically, based on the resource association matrix generated in the previous step, the execution logic of the task to be processed is analyzed, and it is broken down into multiple subtasks that can be executed in parallel or serially. For each subtask, the expected consumption in terms of computing, storage, and data path is calculated, forming a subtask resource vector composed of resource type and demand. Then, combined with the node resource map of each computing node, all available nodes in the cluster are traversed, and the subtask resource vector is compared with the current available resource status of the node. The matching process prioritizes whether highly correlated resource combinations in the resource association matrix can be allocated as a whole to avoid resource fragmentation. For example, in an AI inference task, after a subtask involving a large number of matrix operations is deconstructed, its resource vector shows that it needs to occupy both computing units and cache. During scheduling, nodes with collaborative capabilities and low load fluctuation entropy are selected. Finally, the target node and its specific allocation amount are determined for each subtask, and a scheduling instruction containing node identifier and resource quota is generated and issued.

[0026] In a specific embodiment, such as Figure 2 As shown, the process of collecting node load data and node resource maps for each storage node in the server cluster includes the following steps: S21, perform real-time inspection of the hardware components of the storage node, collect the CPU utilization rate, memory utilization rate, storage IO rate and network bandwidth utilization rate of each storage node, and obtain node load data. S22, based on the hardware components corresponding to the node load data, scan the hardware connection relationship and resource allocation path of each storage node to obtain a node resource connection graph, and perform node identification and resource type classification on the node resource connection graph to obtain a node resource map.

[0027] Specifically, monitoring modules deployed on each in-memory node read the instantaneous values ​​of CPU utilization, memory usage, storage I / O rate, and network bandwidth utilization at fixed sampling intervals from hardware sensors and the operating system kernel interface. These data are then packaged with timestamps to form node load data. Simultaneously, the system calls the underlying device discovery protocol to scan the physical connections and logical paths between the hardware components within the node. For example, it identifies a GPU in-memory unit that is directly connected to the main controller memory via PCIe and shares L3 cache resources. Based on the above connections, a directed graph structure is constructed, which is the node resource connection graph. Each node in the graph is then assigned a unique identifier and labeled with its resource type, such as "in-memory unit," "cache," or "data channel." Finally, all information is integrated to generate a node resource map containing topology and attribute labels, which reflects the actual resource configuration within a single in-memory node. In AI inference task scheduling, this map can be used to determine whether the resources required by a subtask are located within the same access domain.

[0028] In a specific embodiment, such as Figure 3As shown, the step of performing time-series decomposition on the node load data to obtain load trend components reflecting long-term load changes, and classifying the node resource map to obtain a heterogeneous resource table, includes the following steps: S31, the node load data is periodically sampled through a sliding window to obtain multiple load data segments, and a linear fit is performed on each load data segment to obtain the load trend line of each segment; S32, merge all load trend lines to obtain load trend components, and perform topological sorting on the resources in the node resource map based on the hardware connection relationship in the node resource map to obtain a resource topology sequence. Based on the resource topology sequence, group the resources according to resource type to obtain a heterogeneous resource table.

[0029] Specifically, when performing time-series decomposition on the collected node load data, the sliding window length is first set to 15 minutes and the step size to 5 minutes. The continuous time series data such as CPU utilization and memory usage are divided into overlapping data segments. For the sampling points within each data segment, the least squares method is used for linear fitting to calculate the slope and intercept of the change within that time period, forming a straight line reflecting the local trend, i.e., the load trend line. The load trend lines of all adjacent segments are connected end to end to form a trend curve that runs through the entire observation period. This is the load trend component, which filters out short-term jitter and periodic fluctuations and highlights the long-term trend of resource consumption. On another path, when processing the node resource graph, topology sorting is performed based on the connection direction and data flow relationship between the hardware components in the graph. For example, when a memory computing core directly accesses the local SRAM, and the SRAM is connected to the main memory controller via a bus, the sorting result will arrange these resource nodes in order of access level, forming a resource topology sequence with a dependency order. Based on the sequential position in this sequence, combined with preset resource classification rules, resources of the same type are grouped into the same group. For example, all "memory computing unit" entries are merged into one group, and "cached" entries are listed in another group, and their distribution range and capacity parameters in the sequence are recorded. Finally, the information from each group is integrated to generate a heterogeneous resource table. Each item in the table includes resource type, available quantity, topology location index, and associated node identifier. Taking AI inference scenarios as an example, after a task request deploying a multimodal model arrives, the system can quickly identify node combinations with continuous memory computing resource links and in a low-load trend range based on this table to support the efficient execution of subsequent subtasks. The entire process does not rely on black-box prediction, but is implemented based on observable hardware states and mathematical fitting methods, ensuring that the scheduling logic is transparent and traceable.

[0030] In a specific embodiment, such as Figure 4As shown, the step of performing resource correlation analysis on various resources in the heterogeneous resource table based on the window fluctuation entropy value to obtain a resource association matrix characterizing the strength of collaborative dependence among resources includes the following steps: S41, normalize the window fluctuation entropy value to obtain a normalized entropy value sequence, and based on the normalized entropy value sequence, compare and analyze the fluctuation of various resources in the heterogeneous resource table under different time windows to obtain the fluctuation synchronization degree between various resources. S42, based on the fluctuation synchronization degree among the various types of resources, the various types of resources are combined in pairs, the synergy dependency coefficient of each pair of resource combinations is calculated, and all synergy dependency coefficients are arranged according to the resource combination type to obtain the resource association matrix.

[0031] Specifically, after obtaining the window fluctuation entropy values ​​for each time window, the entropy value sequences of all resource types within the same node are first normalized, and then mapped to the [0,1] interval using the minimum-maximum scaling method, as shown in the formula. ,in Indicates the first Class resources in the The original entropy value of each window, This operation eliminates comparison biases caused by differences in dimensions and fluctuation amplitudes between different resources, as the elements in the corresponding normalized entropy value sequence are represented. Subsequently, based on this normalized entropy value sequence, the consistency of the change rhythm of various resources within multiple consecutive windows is analyzed. Specifically, the Pearson correlation coefficient between the entropy value sequences of each pair of resources is calculated as an indicator of their fluctuation synchronicity. The closer the value is to 1 or -1, the stronger the co-directional or inverse response characteristics of the two during load trend disturbances. For example, in scenarios with frequent scheduling of AI inference tasks, the normalized entropy values ​​of the "in-memory unit" and "on-chip cache" of a certain in-memory node often peak at the same time, with a fluctuation synchronicity exceeding 0.8, indicating a tight coupling behavior between the two during high-concurrency model execution. Next, the collaborative dependency coefficient is calculated, treating each pair of resources as an analysis unit and weighting its fluctuation synchronicity with the adjacency relationship in the resource topology sequence. If the two resources not only have high fluctuation synchronicity but also close physical distance in the data path (e.g., sharing the same memory controller), a higher collaborative dependency coefficient is assigned. The coefficient calculation is not limited to adjacent resources but also covers cross-level combinations. For example, the pairing of "network interface" and "main memory" may exhibit moderate synchronization fluctuations due to remote parameter loading. The collaborative dependency coefficients of all resource pairs are ultimately arranged in a two-dimensional matrix, indexed by resource type, with each element outside the diagonal representing the correlation strength of the corresponding resource combination, thus forming a resource correlation matrix. This matrix is ​​not statically configured but is updated dynamically throughout the runtime cycle to ensure it reflects the actual resource interaction patterns under the current workload, providing a dynamic basis for subsequent task deconstruction and scheduling matching. The entire process is driven by observable data, avoiding subjective weight setting and improving the objectivity and adaptability of resource correlation judgment.

[0032] In a specific embodiment, based on the resource association matrix, the resource requirements of the tasks to be processed within the server cluster are deconstructed to obtain subtask resource vectors, including: The task to be processed is decomposed into a task hierarchy tree, which includes a main task node and multiple sub-task nodes. Using a preset task-resource type correspondence table, resource requirements are mapped to each sub-task node in the task hierarchy tree based on the resource association matrix to obtain a resource requirement mapping table for each sub-task node. The resource types in the resource requirement mapping table are then quantified and statistically analyzed to obtain the resource requirements of each sub-task node. Based on the resource requirements of each subtask node, the resource requirements of the subtask nodes in the task hierarchy tree are merged to obtain a subtask resource vector. Then, based on the resource association matrix, the resource types in the subtask resource vector are verified to obtain a verified subtask resource vector.

[0033] Specifically, when deconstructing the resource requirements of a task, the system first splits the task structure based on its execution logic and data dependencies, constructing a hierarchical task tree. This tree is rooted at the main task node and decomposes downwards into multiple independently schedulable sub-task nodes. Directed edges between nodes represent the execution order or data transfer direction. For example, in an AI inference scenario, an image recognition request is split into four sub-task nodes: preprocessing, convolutional feature extraction, pooling operations, and classification output, forming a single-path linear structure. For more complex multimodal fusion tasks, a non-linear tree topology containing parallel branches and feedback loops may be generated. After the splitting is completed, the system enters the resource requirement mapping stage. The system calls a preset task-resource type mapping table, which is generated by analyzing historical operation logs and records the empirical correlation between common task patterns and their typical resource consumption. For example, "convolution operations" typically occupy a high proportion of "in-memory computing units" and "on-chip cache". Building upon this foundation, the mapping accuracy is further optimized using a resource association matrix. Specifically, for each subtask node, an initial resource type suggestion set is first obtained from the corresponding table based on its task type. Then, the co-dependency coefficients of these resources with other types are queried in the resource association matrix. If a resource, though not directly included in the suggestion set, is strongly correlated (e.g., a co-dependency coefficient higher than 0.7), it is considered, thereby expanding or adjusting the original mapping result to form a resource requirement mapping table that better fits the current system state. Subsequently, the resource types in the mapping table are quantitatively analyzed. Based on the subtask's input size, algorithm complexity parameters, and hardware unit processing capabilities, specific requirement values ​​are estimated. For example, the required number of memory units is calculated based on the convolution kernel size, stride, and input feature map size, and the cache bandwidth quota is determined by referring to memory access frequency. Finally, the resource requirements of each subtask node are obtained. Next, a resource requirement merging operation is performed, merging the resource requirements of all subtask nodes in the task hierarchy tree by type. However, this is not a simple summation; rather, it comprehensively considers execution timing and the possibility of resource sharing, appropriately reducing redundancy reservations for subtasks executed serially with staggered resource usage peaks and troughs. After merging, a preliminary subtask resource vector is generated, with dimensions consistent with the heterogeneous resource table, and values ​​representing overall resource requirements. Finally, this vector undergoes correlation verification, which involves pairing resource types and querying the corresponding collaborative dependency coefficients in the resource correlation matrix to check for missing or unbalanced key resources. For example, if the vector contains numerous "in-memory unit" requirements without matching corresponding "data path" resources, even though they should have a high correlation in the matrix, this is considered an abnormal configuration, triggering an alarm or reassessment mechanism. This entire process achieves a layer-by-layer mapping and verification from task semantics to physical resources, improving the accuracy of resource modeling and system adaptability.

[0034] In a specific embodiment, based on the resource requirements of each sub-task node, the resource requirements of the sub-task nodes in the task hierarchy tree are merged to obtain a sub-task resource vector, including: The resource requirements of each subtask node are categorized by resource type to obtain a set of resource types. The resource requirements of each subtask node's resource type set are then summed to obtain the total requirement of each resource type in the task hierarchy tree. Based on the total demand of each resource type in the task hierarchy tree, the resource demand allocation ratio of the sub-task nodes in the task hierarchy tree is calculated to obtain the allocation ratio of each sub-task node to each resource type. Based on the allocation ratio, the resource demand of each sub-task node is weighted and merged to obtain the sub-task resource vector.

[0035] Specifically, after calculating the resource requirements of each subtask node, the resource requirement merging phase begins. First, the resource types involved in each subtask node are categorized and organized into a unified resource type set. This set covers all resource categories appearing in the task hierarchy tree, such as "compute units," "caches," "main memory bandwidth," and "network interfaces," ensuring consistency in subsequent calculations. Then, for each resource type, its corresponding requirement value is found in all subtask nodes and accumulated to obtain the total requirement for that resource throughout the entire task execution cycle. For example, in an AI inference task, if the feature extraction subtask requires 6 compute units and the classification subtask requires 3, then the total requirement for "compute units" is 9. This total requirement reflects the overall expected consumption of various resources by the main task but is not directly used for scheduling and allocation. Next, we need to further analyze the actual resource usage distribution of each subtask node. Based on the aforementioned total demand, we calculate the proportion of each subtask node's resource usage across various resource types, i.e., the allocation ratio. This ratio is calculated by dividing a subtask's demand for that resource by the total demand for that resource. For example, if a preprocessing subtask requires 2 storage units, and the total demand for this type of resource is 9, then its allocation ratio for that resource dimension is 2 / 9. This ratio reflects the relative weight of each subtask in resource usage, not its absolute value. Following this, we proceed to the weighted merging stage. Instead of simple numerical summation, we weight and merge the resource demands of each subtask based on the aforementioned allocation ratio. Specifically, we construct a vector structure indexed by resource type. For each dimension, we iterate through all subtask nodes, multiplying their resource demands by their allocation ratio for that resource, and then summing the results. This ultimately generates a subtask resource vector that comprehensively reflects the resource dependencies within the task. This weighting method effectively distinguishes between critical subtasks and auxiliary operations, preventing the dilution of overall resource allocation accuracy due to the presence of a lightweight subtask. For example, in network-intensive subtasks, although the overall resource requirements are not high, the allocation ratio of "network interface" is close to 1. Therefore, this resource item still maintains a significant weight in the final vector, ensuring that the scheduler prioritizes matching computing nodes with high network throughput capabilities. The entire process relies on the structural information of the task hierarchy tree and quantitative data to advance, with clear logic and traceability, making it suitable for refined resource modeling in complex load environments.

[0036] In a specific embodiment, based on the subtask resource vector and the node resource graph, a scheduling instruction containing a node identifier and resource allocation is matched for each subtask in the computing node, including: The resource types and demand quantities in the subtask resource vector are analyzed to obtain a subtask resource demand list. Based on the node resource graph, the remaining resource quantity of the storage nodes is statistically analyzed to obtain a node resource remaining table. By comparing the subtask resource demand list with the node resource remaining table, a set of candidate nodes that meet the subtask resource requirements is selected. Resource adaptability is calculated for each storage node in the candidate node set to obtain the resource adaptability value of each node. The candidate node set is sorted based on the resource adaptability value to generate a scheduling instruction containing node identifier and resource allocation.

[0037] Specifically, after obtaining the subtask resource vectors and the node resource graphs of each compute node, the scheduling and matching process is initiated. First, each resource type and its corresponding requirement in the subtask resource vectors are analyzed to extract specific resource items and numerical requirements, forming a structured subtask resource requirement list. For example, a subtask might require "≥4 compute units," "≥2GB cache," and "≥1Gbps network bandwidth." Simultaneously, based on the hardware topology and current status information recorded in the node resource graphs, each compute node in the cluster is traversed, its total capacity for various resources is read, and the occupied portion is subtracted to calculate the available resource reserves for each node, summarizing them into a node resource reserve table. Then, the subtask resource requirement list is compared item by item with this table, filtering out compute nodes whose resource reserves meet all requirements, forming a candidate node set. If a node has a low overall load but its compute units are nearly full, it is excluded even if other resources are abundant. Moving to the next stage, to improve matching accuracy, decisions are no longer based solely on "whether the conditions are met." Instead, a resource suitability calculation mechanism is introduced. For each node in the candidate node set, the degree of matching between its resource reserves and subtask requirements is comprehensively considered. Simultaneously, the resource association matrix generated in the previous steps is used to determine whether there are collaborative configuration advantages among the node's internal resources—for example, a node that not only provides sufficient computing units but also whose associated caches and data paths are idle receives a higher suitability score. Specifically, a weighted distance method is used. The supply-demand differences of various resources are normalized and then summed according to the dependency strength in the association matrix. The inverse of the result is used as the resource suitability value; a larger value indicates a better match. Finally, the candidate node set is sorted in descending order based on this value, and the node with the highest ranking is selected as the target node. A scheduling instruction containing its node identifier and the specific amount of resources to be allocated is generated and sent to the underlying execution module. The entire process considers both resource availability and system-level collaborative efficiency, avoiding an isolated view of single-dimensional resource supply and enhancing the rationality and stability of scheduling decisions.

[0038] Please see Figure 5 , Figure 5This is a schematic diagram of the framework of an embodiment of the dynamic resource scheduling device for the in-memory computing server of this application. Figure 5 As shown, the dynamic resource scheduling device of the in-memory computing server includes a data acquisition module 1, used to acquire node load data and node resource map of each in-memory computing node in the server cluster; a classification module 2, used to perform time-series decomposition on the node load data to obtain load trend components reflecting the long-term change law of load, and to classify the node resource map to obtain a heterogeneous resource table; an extraction module 3, used to extract fluctuation features from the load trend components to obtain window fluctuation entropy values, and to perform resource correlation analysis on various types of resources in the heterogeneous resource table based on the window fluctuation entropy values ​​to obtain a resource association matrix used to characterize the collaborative dependency strength between resources; and a deconstruction module 4, used to deconstruct the resource requirements of the tasks to be processed in the server cluster according to the resource association matrix to obtain sub-task resource vectors, and to match scheduling instructions containing node identifiers and resource allocation amounts for each sub-task in the in-memory computing node based on the sub-task resource vectors and the node resource map.

[0039] Reference Figure 6 This invention also provides a computer device whose internal structure can be as follows: Figure 6 As shown, the computer device includes a processor, memory, display screen, input device, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores the data corresponding to this embodiment. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements the above-described method.

[0040] Those skilled in the art will understand that Figure 6 The structures shown are merely block diagrams of some structures related to the present invention and do not constitute a limitation on the computer devices on which the present invention is applied.

[0041] An embodiment of the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. It is understood that the computer-readable storage medium in this embodiment can be a volatile readable storage medium or a non-volatile readable storage medium.

[0042] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the present invention and embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM, etc.

[0043] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0044] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

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

[0046] 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; 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, depending on actual needs.

[0047] Furthermore, the functional units in the various embodiments of this application 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0048] If the integrated unit 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 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 storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0049] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

Claims

1. A dynamic resource scheduling method for an in-memory computing server, characterized in that, Includes the following steps: Collect node load data and node resource map of each computing node in the server cluster; The node load data is decomposed over time to obtain a load trend component that reflects the long-term change pattern of the load, and the node resource map is classified to obtain a heterogeneous resource table. Fluctuation features are extracted from the load trend components to obtain window fluctuation entropy values. Based on the window fluctuation entropy values, resource correlation analysis is performed on various resources in the heterogeneous resource table to obtain a resource association matrix that characterizes the strength of collaborative dependence between resources. Based on the resource association matrix, the resource requirements of the tasks to be processed in the server cluster are deconstructed to obtain subtask resource vectors. Based on the subtask resource vectors and the node resource graph, a scheduling instruction containing a node identifier and resource allocation is matched for each subtask in the storage node.

2. The dynamic resource scheduling method for an in-memory computing server according to claim 1, characterized in that, The data includes node load data and node resource map of each computing node in the data acquisition server cluster, including: The hardware components of the storage nodes are inspected in real time, and the CPU utilization, memory utilization, storage I / O rate and network bandwidth utilization of each storage node are collected to obtain node load data. Based on the hardware components corresponding to the node load data, the hardware connection relationship and resource allocation path of each storage node are scanned to obtain a node resource connection graph. The node resource connection graph is then labeled with node identifiers and classified by resource type to obtain a node resource map.

3. The dynamic resource scheduling method for an in-memory computing server according to claim 1, characterized in that, The node load data is decomposed over time to obtain a load trend component reflecting the long-term load variation pattern. The node resource map is then categorized to obtain a heterogeneous resource table, including: The node load data is periodically sampled by a sliding window to obtain multiple load data segments, and a linear fit is performed on each load data segment to obtain the load trend line of each segment. All load trend lines are merged to obtain load trend components. Based on the hardware connection relationships in the node resource map, the resources in the node resource map are topologically sorted to obtain a resource topology sequence. Based on the resource topology sequence, the resources are grouped according to resource type to obtain a heterogeneous resource table.

4. The dynamic resource scheduling method for an in-memory computing server according to claim 1, characterized in that, Based on the resource association matrix, the resource requirements of the tasks to be processed within the server cluster are deconstructed to obtain subtask resource vectors, including: The task to be processed is decomposed into a task hierarchy tree, which includes a main task node and multiple sub-task nodes. Using a preset task-resource type correspondence table, resource requirements are mapped to each sub-task node in the task hierarchy tree based on the resource association matrix to obtain a resource requirement mapping table for each sub-task node. The resource types in the resource requirement mapping table are then quantified and statistically analyzed to obtain the resource requirements of each sub-task node. Based on the resource requirements of each subtask node, the resource requirements of the subtask nodes in the task hierarchy tree are merged to obtain a subtask resource vector. Then, based on the resource association matrix, the resource types in the subtask resource vector are verified to obtain a verified subtask resource vector.

5. The dynamic resource scheduling method for an in-memory computing server according to claim 5, characterized in that, Based on the resource requirements of each sub-task node, the resource requirements of the sub-task nodes in the task hierarchy tree are merged to obtain a sub-task resource vector, including: The resource requirements of each subtask node are categorized by resource type to obtain a set of resource types. The resource requirements of each subtask node's resource type set are then summed to obtain the total requirement of each resource type in the task hierarchy tree. Based on the total demand of each resource type in the task hierarchy tree, the resource demand allocation ratio of the sub-task nodes in the task hierarchy tree is calculated to obtain the allocation ratio of each sub-task node to each resource type. Based on the allocation ratio, the resource demand of each sub-task node is weighted and merged to obtain the sub-task resource vector.

6. The dynamic resource scheduling method for an in-memory computing server according to any one of claims 1-5, characterized in that, Based on the subtask resource vector and the node resource graph, a scheduling instruction containing a node identifier and resource allocation is matched for each subtask in the computing node, including: The resource types and demand quantities in the subtask resource vector are analyzed to obtain a subtask resource demand list. Based on the node resource graph, the remaining resource quantity of the storage nodes is statistically analyzed to obtain a node resource remaining table. By comparing the subtask resource demand list with the node resource remaining table, a set of candidate nodes that meet the subtask resource requirements is selected. Resource adaptability is calculated for each storage node in the candidate node set to obtain the resource adaptability value of each node. The candidate node set is sorted based on the resource adaptability value to generate a scheduling instruction containing node identifier and resource allocation.

7. A dynamic resource scheduling device for an in-memory computing server, characterized in that, include: The data acquisition module is used to collect node load data and node resource map of each computing node in the server cluster; The classification module is used to perform time-series decomposition on the node load data to obtain load trend components that reflect the long-term change pattern of the load, and to classify the node resource map to obtain a heterogeneous resource table. The extraction module is used to extract the fluctuation characteristics of the load trend component, obtain the window fluctuation entropy value, and perform resource correlation analysis on various resources in the heterogeneous resource table based on the window fluctuation entropy value to obtain a resource association matrix that characterizes the strength of collaborative dependence between resources. The deconstruction module is used to deconstruct the resource requirements of the tasks to be processed in the server cluster according to the resource association matrix, obtain the subtask resource vector, and match the scheduling instruction containing the node identifier and resource allocation for each subtask in the storage node based on the subtask resource vector and the node resource graph.

8. A computer device, characterized in that, The system includes a memory and a processor that are coupled to each other. The memory stores program instructions, and the processor executes the program instructions to implement the dynamic resource scheduling method of the in-memory computing server according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The system stores program instructions that can be executed by a processor, the program instructions being used to implement the dynamic resource scheduling method of the in-memory computing server according to any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, enables the implementation of the dynamic resource scheduling method for the in-memory computing server as described in any one of claims 1 to 6.

Images