Resource allocation method and apparatus, electronic device, and storage medium

Abstract

The application discloses a resource allocation method and device, electronic equipment and a storage medium, relates to the technical field of computers, and the method determines the remainder of a first ratio as the number of remaining cores under the condition that the first ratio between the total number of solid state disks and the total number of physical cores is a non-integer ratio, selects a group of target solid state disks equal to the number of remaining cores from the server in descending order of the priority of a single solid state disk, intelligently realizes resource priority scheduling by determining the group of target solid state disks and the optimal number of physical cores allocated to the target solid state disks, ensures that solid state disks with high priority obtain sufficient physical core resources, and solves the problem of uneven resource allocation caused by the random core binding strategy in resource allocation in the related art, and ensures the stability and maximization of the performance of the solid state disk.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to resource allocation methods, apparatus, electronic devices and storage media. Background Technology

[0002] Current servers extensively utilize Solid State Drives (SSDs) for data storage and retrieval. SSD performance (such as random read / write and sequential read / write speeds) directly impacts storage system efficiency. Modern servers widely employ multi-SSD architectures to meet high-concurrency data access demands. The process of balancing and allocating Central Processing Unit (CPU) cores based on the number of SSDs and task requirements to optimize I / O performance is called CPU resource allocation. In multi-SSD architectures, a common CPU resource allocation method is random core binding, which refers to randomly assigning CPU cores to SSDs.

[0003] However, since the I / O throughput of different SSDs can vary by as much as 15%-20%, the random core binding strategy can easily lead to an unbalanced allocation of CPU resources. Some SSDs may get too much CPU resources, while other SSDs may not have enough resources, causing performance fluctuations and resource waste. Summary of the Invention

[0004] This application provides a resource allocation method, apparatus, electronic device, and storage medium to at least solve the problem of uneven resource allocation caused by the use of random core-binding strategies in resource allocation in related technologies.

[0005] This application provides a resource allocation method, comprising: obtaining the total number of solid-state drives (SSDs) of a server and the total number of physical cores of the server's central processing unit; wherein individual SSDs in the total number of SSDs have different priorities; when a first ratio between the total number of SSDs and the total number of physical cores is not an integer, determining the remainder of the first ratio as the number of remaining cores; selecting a group of target SSDs from the server in descending order of individual SSD priority, which is equal to the number of remaining cores; determining the number of physical cores to be allocated to the target SSDs in the group of target SSDs; and allocating the number of physical cores to the group of target SSDs according to the number of physical cores to be allocated to the target SSDs.

[0006] This application also provides a resource allocation device, comprising: an acquisition module, configured to acquire the total number of solid-state drives (SSDs) of a server and the total number of physical cores of the server's central processing unit; wherein individual SSDs in the total number of SSDs have different priorities; a strategy determination module, configured to, when a first ratio between the total number of SSDs and the total number of physical cores is not an integer, determine the remainder of the first ratio as the number of remaining cores, select a group of target SSDs from the server in descending order of individual SSD priority, and determine the number of physical cores to be allocated to the target SSDs in the group of target SSDs; and an allocation module, configured to allocate the number of physical cores to the group of target SSDs according to the number of physical cores to be allocated to the target SSDs.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described resource allocation methods when executing the computer program.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described resource allocation methods.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described resource allocation methods.

[0010] This application obtains the total number of solid-state drives (SSDs) and the total number of physical cores in real time. When a non-integer ratio exists between the total number of SSDs and the total number of physical cores, the remainder of this ratio is determined as the remaining number of cores. Based on the individual SSDs' priority from highest to lowest, a group of target SSDs equal to the remaining number of cores is selected from the server. By determining a group of target SSDs and the optimal number of physical cores allocated to them, intelligent resource priority scheduling is achieved. This ensures that high-priority SSDs receive sufficient physical core resources, solving the problem of uneven resource allocation caused by random core-binding strategies in related technologies, and ensuring the stability and maximization of SSD performance. Attached Figure Description

[0011] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments 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.

[0012] Figure 1This is an application environment diagram of a resource allocation method provided in an embodiment of this application.

[0013] Figure 2 This is a flowchart illustrating a resource allocation method provided in an embodiment of this application.

[0014] Figure 3 This is an example diagram of a physical core allocation provided in an embodiment of this application.

[0015] Figure 4 This is a flowchart of another resource allocation method provided in the embodiments of this application.

[0016] Figure 5 This is a structural diagram of a resource allocation device provided in an embodiment of this application. Detailed Implementation

[0017] 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 some embodiments of this application, and not all 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 protection scope of this application.

[0018] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0019] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0020] According to one aspect of the embodiments of this application, a resource allocation method is provided. Optionally, in this embodiment, the above-described resource allocation method may be applied, but is not limited to, to applications such as... Figure 1The server shown includes a Central Processing Unit (CPU) 102 and a Solid State Drive (SSD) 104. The CPU 102 plays a central role in computing resource management and performance optimization, intelligently allocating its core resources to different SSDs 104 to maximize performance and improve resource utilization efficiency. As a high-speed storage device, the SSD 104's performance directly affects data access speed and system response time. Through intelligent binding with the CPU, the SSD can be optimized in key metrics such as reducing latency and improving IOPS, thereby enhancing the overall data processing capabilities and business processing efficiency of the server. The server can be, but is not limited to, a cloud server, a server cluster, or other server types.

[0021] The resource allocation method in this application embodiment can be executed by a server. Figure 2 This is a flowchart illustrating an optional resource allocation method according to an embodiment of this application, such as... Figure 2 As shown, the process of this method may include the following steps:

[0022] Step S202: Obtain the total number of solid-state drives and the total number of physical cores of the server's central processing unit.

[0023] Step S204: When the first ratio between the total number of solid-state drives and the total number of physical cores is not an integer, the remainder of the first ratio is determined as the number of remaining cores. According to the priority of individual solid-state drives from high to low, a group of target solid-state drives equal to the number of remaining cores is selected from the server; and the number of physical cores to be allocated to the target solid-state drives in the group of target solid-state drives is determined.

[0024] Step S206: Allocate the number of physical cores to a group of target solid-state drives according to the number of physical cores required for the target solid-state drives.

[0025] The resource allocation method provided in this application is applied to the field of computer technology. The server includes multiple solid-state drives (SSDs) and multiple central processing units (CPUs). Each CPU includes multiple physical cores, where each physical core is the actual execution unit within the CPU, capable of independently executing instruction sets and forming a fundamental component of computing resources. Each SSD is bound to multiple physical cores. This strategy aims to utilize computing resources more efficiently. By allocating appropriate physical cores to SSDs, data access performance can be significantly improved, processing latency reduced, thereby enhancing the overall operating efficiency and business processing capabilities of the server.

[0026] In single-SSD scenarios, by exclusively allocating CPU resources (e.g., binding all physical cores to a single SSD), hardware capabilities can be maximized to achieve the manufacturer's advertised performance (Spec). In multi-SSD architectures, a random core-binding strategy is often used for CPU resource allocation. This strategy involves randomly assigning CPU cores to SSDs. For example, in a server configured with dual CPUs (16 cores each) and four SSDs, random core binding randomly determines the number of cores bound to each SSD. However, since the I / O throughput of different SSDs can vary by as much as 15%-20%, random core binding can easily lead to uneven CPU resource allocation. Some SSDs may receive excessive CPU resources, while others may lack sufficient resources, causing performance fluctuations and resource waste. For instance, a 6-core SSD can achieve 600K IOPS, while a 2-core SSD can only achieve 400K IOPS. Using a random core binding strategy would prevent the overall storage system from meeting the stringent consistency requirements of real-time databases, resulting in performance fluctuations. For example, if a random core binding strategy is adopted, the utilization rate of low-load cores will be consistently below 50%, while high-load cores will become bottlenecks due to contention, resulting in resource waste.

[0027] To address the aforementioned issues, this embodiment allocates CPU resources based on the ratio between the total number of solid-state drives (SSDs) and the total number of physical cores in the server. This intelligent allocation of CPU resources significantly improves SSD performance and effectively solves the problem of uneven resource allocation caused by traditional random core binding strategies.

[0028] In this embodiment, the total number of solid-state drives (SSDs) refers to the number of SSDs installed inside the server. The total number of physical cores refers to the total number of physical cores contained in all CPUs in the server. A single SSD refers to each independent SSD device within the server, and each SSD will be allocated a specific number of physical cores according to a determined core-binding strategy.

[0029] When the ratio (M / N) of the total number of physical cores (M) to the total number of solid-state drives (SSDs) is not an integer, it indicates that simply allocating resources equally cannot meet the performance requirements of all SSDs. In this case, an intelligent priority allocation strategy should be adopted to identify and prioritize the core requirements of performance-critical SSDs. Specifically, the number of cores corresponding to the remainder of the M / N ratio is allocated to multiple high-priority SSDs to form a group of target SSDs. At the same time, the resource allocation of the remaining SSDs is dynamically adjusted based on real-time performance requirements to achieve optimal resource utilization and maximize system performance.

[0030] A target SSD group refers to a set of SSDs that enjoy high priority in the resource allocation strategy. It can be understood that a target SSD group is a set of SSDs selected from the server, in descending order of individual SSD priority, that is equal to the number of remaining cores. These SSDs have high priority in resource allocation and can preferentially obtain additional physical cores to improve data read / write performance. In this embodiment, the remainder of the first ratio is determined as the number of remaining cores, and a target SSD group is selected from the server, in descending order of individual SSD priority, that is equal to the number of remaining cores. Individual SSDs in the total number of SSDs have different priorities. Priority refers to the order in which SSDs are prioritized in resource allocation based on their impact on system performance or the technical characteristics of their link (such as PCIe 4.0). In this embodiment, the remainder of the first ratio is the number of remaining cores. In this embodiment, the number of remaining cores refers to the number of additional physical cores that are not fully allocated after allocating CPU physical cores to SSDs according to the basic ratio and can be used to further optimize the performance of critical SSDs. For example, assuming a total of 32 physical cores, 5 SSDs, and the integer part of the first ratio between the total number of SSDs and the total number of physical cores is 6, with a remainder of 2, then the remaining number of cores is 2, and 2 target SSDs can be selected from the server. In this embodiment, the remaining number of cores can be expressed by the following formula (1):

[0031]

[0032] The number of physical cores required for a target SSD refers to the minimum number of physical cores that must be allocated to meet the performance requirements of the target SSD or to ensure that it is within the same Non-Uniform Memory Access (NUMA) node as a specified CPU. For example, the number of physical cores required to achieve optimal performance can be calculated based on the target SSD's performance requirements, including current IOPS, throughput, latency, and expected business growth. Alternatively, the allocation of physical cores for the target SSD can be dynamically adjusted based on its real-time performance metrics and historical load data.

[0033] Through the embodiments of this application, the total number of solid-state drives (SSDs) and the total number of physical cores are obtained in real time. Under the condition that there is a first ratio between the total number of SSDs and the total number of physical cores that is not an integer, the remainder of the first ratio is determined as the number of remaining cores. According to the priority of individual SSDs from high to low, a group of target SSDs with the same number of remaining cores is selected from the server. By determining a group of target SSDs and the optimal number of physical cores allocated to the target SSDs, resource priority scheduling is intelligently implemented to ensure that high-priority SSDs obtain sufficient physical core resources. This solves the problem of uneven resource allocation caused by the random core binding strategy in resource allocation in related technologies, and ensures the stability and maximization of SSD performance.

[0034] In one exemplary embodiment, obtaining the total number of solid-state drives (SSDs) and the total number of physical cores of the server's central processing unit (CPU) includes:

[0035] Determine the server's topology; the topology includes the physical layout and access relationships between storage devices and different physical cores in the server; based on the topology, determine the total number of solid-state drives and the total number of physical cores of the server's central processing unit.

[0036] In server architectures, SSDs are typically connected to the server's motherboard via PCI-E slots. Different slots may connect to different CPUs and NUMA nodes, impacting SSD access performance. NUMA is a memory management method in multi-processor architectures, primarily used in servers and other high-performance computing systems. In a NUMA architecture system, multiple CPUs are tightly coupled to their respective local memory, forming multiple independent NUMA nodes. Each NUMA node contains at least one CPU and local memory resources that the CPU can directly and quickly access. This means that when a CPU accesses memory within its local node, the access speed is fast and the latency is low, similar to memory access in a single-processor system. However, if a CPU needs to access memory belonging to another node (remote memory), it must do so through an interconnect bus (such as Intel Ultra Path Interconnect (Intel UPI) or AMD Infinity Fabric), which significantly increases access latency and bandwidth consumption. In short, an SSD is bound to a CPU, and a CPU and its local memory constitute a NUMA node.

[0037] As described in the server architecture above, server topology refers to the physical layout of the server's internal hardware components (especially storage devices and physical cores) and the access relationships between them. This topology encompasses the location association between SSDs and the NUMA nodes of the CPU physical cores, and is crucial for optimizing storage performance and resource allocation.

[0038] Optionally, the server runs `lspci -vvv` to confirm the NUMA node relationship between the SSD and the CPU, and uses the `numactl --hardware` command to view the NUMA node distribution, clarifying the layout and access relationships between storage devices and physical cores. The server uses query commands to count all SSD devices inside the server, recording the total number of solid-state drives (N). The server executes the `lscpu` command to obtain physical core count information, recording the total number of physical cores (M), the number of cores per socket, and the distribution of logical cores for the server's CPU. It also uses a script to parse ` / proc / cpuinfo` to distinguish between physical cores and hyper-threaded logical cores.

[0039] This embodiment clarifies the server's topology, including the layout and access relationships between storage devices and physical cores, enabling a faster determination of the total number of solid-state drives and physical cores, and a more rational allocation of computing resources.

[0040] In one exemplary embodiment, determining the number of physical cores required to be allocated to a target solid-state drive in a set of target solid-state drives includes:

[0041] The integer part of the first ratio is determined as the first basic core count, and the number of physical cores equal to the first basic core count is determined as the number of physical cores required to be allocated to the target solid-state drives in a group of target solid-state drives; the first basic core count refers to the number of cores required to be allocated to the target solid-state drives in a group of target solid-state drives.

[0042] Here, the first basic core count refers to the integer part of the first ratio when the first ratio is not an integer. In this embodiment, when the total number of SSDs and the total number of CPU physical cores cannot be precisely matched, the physical cores required by a group of target SSDs are allocated according to the first basic core count. This ensures that the target SSDs receive sufficient CPU support, thereby maximizing their data processing performance. For example, assuming a total of 32 physical cores, 5 SSDs, a first basic core count of 6 cores, and 2 remaining cores, then according to the priority of individual SSDs from high to low, 2 SSDs are selected from the server as a group of target SSDs, and each target SSD is allocated a number of cores equal to the first basic core count (6).

[0043] It's important to note that determining the number of target SSDs based on the number of remaining cores is to ensure that critical SSDs receive additional CPU resources, maximizing their performance. The rationale for this is that remaining cores represent "extra" computing power allocated to high-priority SSDs. By precisely allocating them to a specific number of target SSDs, the I / O processing capabilities of critical SSDs can be maximized without impacting the basic performance of other SSDs, thereby significantly enhancing the overall storage system's responsiveness and data processing efficiency.

[0044] In this embodiment, when the first ratio of the total number of solid-state drives to the total number of physical cores is not an integer, the integer part of the first ratio is defined as the first basic core count, and the remainder is defined as the remaining core count. Then, the target SSD is selected according to the SSD priority, and additional physical cores are provided according to the first basic core count to ensure that the critical SSD can obtain optimal performance, while the other SSDs can also obtain core resources according to the ratio, reducing performance bottlenecks and resource waste.

[0045] In one exemplary embodiment, the above resource allocation method further includes:

[0046] When the first ratio between the total number of solid-state drives and the total number of physical cores is an integer, the first ratio is determined as the second basic core count, and a number of physical cores equal to the second basic core count is allocated to each solid-state drive in the server; the second basic core count refers to the number of cores that need to be allocated to each solid-state drive.

[0047] The first ratio is the mathematical ratio between the total number of physical cores and the total number of solid-state drives (SSDs). In this embodiment, when the first ratio is an integer, it is used as the basis for determining the second basic core count, representing the average number of physical cores that can theoretically be allocated to each SSD. The second basic core count refers to the number of physical cores that should theoretically be allocated to each SSD when the ratio between the total number of SSDs and the total number of physical cores is an integer. The second basic core count can be expressed by the following formula (2), where N represents the total number of SSDs and M represents the total number of physical cores:

[0048]

[0049] For example, if the server has a total of 32 physical cores and 4 SSDs, and the test task type is random / sequential read / write, then the first ratio between the total number of SSDs and the total number of physical cores is 8, i.e., the first ratio is an integer. Therefore, the second basic number of cores is also 8. The core binding strategy is that each SSD in the server needs to be allocated 8 physical cores, i.e., each SSD is allocated 8 cores.

[0050] In this embodiment, when the first ratio between the total number of SSDs and the total number of physical cores is an integer, the first ratio is determined as the second basic core count. The second basic core count refers to the number of cores that a single solid-state drive needs to be allocated. By determining the core binding strategy in this way, the number of cores that each SSD should be bound to is automatically determined. This avoids the situation in related technologies where random core binding strategies cause some SSDs to occupy too many resources while other SSDs have insufficient resources. It ensures that all SSDs can obtain balanced CPU support in multi-tasking scenarios and reduces performance fluctuations.

[0051] In one exemplary embodiment, after allocating the number of physical cores to a group of target solid-state drives according to the number of physical cores required by the target solid-state drives, the resource allocation method further includes:

[0052] The number of physical cores allocated to the other solid-state drives (SSDs) in the server, excluding the target SSDs, is determined by the total number of physical cores in the server.

[0053] The term "other physical cores" refers to the number of remaining physical cores in the server's total physical core count, excluding those already allocated to the target set of SSDs. These remaining cores can be used for subsequent resource allocation optimization. "Other SSDs" refers to the remaining SSDs on the server, excluding the prioritized target set. Resources will be allocated to these SSDs based on the remaining physical cores and other system policies. The number of physical cores allocated to these other SSDs can be dynamically determined based on the performance requirements and workload of the remaining SSDs. For example, if the load on the other SSDs is relatively even, the remaining cores can be roughly evenly distributed among each SSD to maintain overall load balance. Conversely, if a sudden increase in load is detected on some of the other SSDs, the resource allocation of those SSDs will be adjusted first to ensure their performance stability, while other SSDs will be appropriately allocated to avoid a decrease in overall system efficiency.

[0054] In this embodiment, after allocating resources to a group of target SSDs based on the required number of physical cores, resources are further allocated to other SSDs based on the remaining number of physical cores. This ensures that all SSDs have the opportunity to obtain physical core resources matching their performance requirements, avoiding resource idleness and waste, and achieving comprehensive optimization of server resources. This intelligent allocation method not only guarantees the performance of critical SSDs but also ensures that other SSDs receive appropriate physical core support based on their actual workload, contributing to overall system load balancing and preventing performance bottlenecks caused by improper resource allocation.

[0055] In one exemplary embodiment, the number of physical cores allocated to the solid-state drives (SSDs) other than the target SSDs in the server, based on the number of physical cores other than those allocated to the target SSDs, out of the total number of physical cores, includes:

[0056] The second ratio between the number of other physical cores and the number of other solid-state drives in the server excluding the target set of solid-state drives is rounded up to determine the third basic core count; the other solid-state drives are allocated a number of physical cores equal to the third basic core count; the third basic core count refers to the number of physical cores required to be allocated to the other solid-state drives.

[0057] The term "other physical cores" refers to the number of unallocated physical cores remaining after allocating them to the target set of SSDs. "Other SSDs" refers to all SSDs other than the target set. The second ratio describes the ratio between the remaining cores and the number of other SSDs after removing the cores required for the target set from the total number of physical cores. When the second ratio is not an integer, a rounding-up strategy is used to determine the third base core number to ensure fairness and maximize resource utilization. The third base core number refers to the number of physical cores allocated to each other SSD, determined by rounding up the second ratio during resource allocation. The third base core number aims to ensure that non-target SSDs also receive basic performance support, while considering the limited server resources and the need for balanced allocation. For example, assuming there are a total of 32 physical cores, 5 SSDs, a first base core count of 6 cores, 2 remaining cores, 20 other physical cores, and 3 other solid-state drives, then the third base core count obtained by rounding up the second ratio is 7. Therefore, the remaining 3 other solid-state drives are allocated the same number of cores as the third base core count (7).

[0058] It's important to note that the first set of basic cores prioritizes the high-performance requirements of the target SSD, while the third set ensures that all SSDs receive basic CPU support. Allocating physical cores to the target SSD using the first set of basic cores ensures these critical storage devices receive priority resources to meet high-load demands, thereby optimizing the performance of core business processes. The third set of basic cores allocation, rounded up for other SSDs, guarantees that even with limited resources, each SSD receives a fair number of physical cores sufficient to support its basic functions, avoiding performance bottlenecks caused by uneven resource allocation. This differentiated allocation mechanism not only enhances the processing power of the target SSD but also balances the performance of all SSDs, avoiding resource waste and performance bottlenecks, and improving the overall system efficiency and resource utilization.

[0059] In this embodiment, the allocation strategy of the number of physical cores required for the target SSD in a group of target SSDs and the number of physical cores allocated to other SSDs is defined as the core binding strategy. For example, assuming a total of 32 physical cores and 5 SSDs, the core binding strategy can be represented as allocating 7 cores × 3 SSDs + 6 cores × 2 SSDs. That is, the core binding strategy indicates that for the highest and second highest priority target SSDs, each target SSD is allocated 6 physical cores, and for the remaining 3 SSDs, each SSD is allocated 7 physical cores.

[0060] In this embodiment, the ratio of the remaining cores after removing the cores required by the target SSD to the number of non-target SSDs in the server is rounded up to obtain a third basic core count, ensuring that non-target SSDs also receive the necessary CPU resources. By allocating the third basic core count through rounding up, even under resource constraints, each SSD can be guaranteed to have enough physical cores, avoiding performance degradation due to insufficient resources. This achieves overall performance balance and improvement, and solves the shortcomings of uneven resource allocation and overly coarse resource allocation in multi-SSD environments.

[0061] In one exemplary embodiment, for example, Figure 3 An example diagram of physical core allocation provided for an embodiment of this application, such as... Figure 3 As shown, assuming the server has two physical CPUs (CPU0 and CPU1), each with 16 physical cores, for a total of 32 physical cores, and five SSDs are installed on the server, the first two SSDs (SSD1 and SSD2) are located on the first NUMA node and associated with CPU0, and the latter three SSDs (SSD3, SSD4, and SSD5) are located on the second NUMA node and associated with CPU1. Assuming SSD1 and SSD2 require 6 cores, and SSD3, SSD4, and SSD5 require 7 cores, then 6 cores are allocated from CPU0 to SSD1 and SSD2 respectively, leaving CPU0 with 4 cores; and 7 cores are allocated from CPU1 to SSD3 and SSD4 respectively, leaving CPU1 with 2 cores. Since the remaining 6 cores from CPU0 and CPU1 are insufficient to allocate to SSD5, this embodiment provides the following solution for situations where the SSD does not achieve expected performance due to insufficient CPU resources or the allocation principle of SSDs and their associated CPUs being in the same NUMA node is not satisfied:

[0062] Method 1: If the specified CPU and the specified SSD are on the same memory access node, and the number of remaining cores of the specified CPU is less than the number of physical cores required to be allocated to the specified SSD, then the number of remaining cores of the specified CPU will be used as the number of cores allocated to the specified SSD. Here, the specified SSD refers to an SSD that does not achieve the expected performance due to insufficient physical core resources or cannot meet the allocation principle that the SSD and the bound CPU are on the same memory node (such as a NUMA node). The specified CPU is the CPU bound to the specified SSD.

[0063] For example, in the example above, SSD3, SSD4, and SSD5 are located on the second NUMA node and are associated with CPU1. SSD3, SSD4, and SSD5 need to be allocated 7 cores. 7 cores are allocated from CPU1 to SSD3 and SSD4 respectively. CPU1 has 2 cores remaining, and the remaining 2 cores in CPU1 are used as the number of cores allocated to SSD5.

[0064] Method 2: When a specified CPU is located on the same memory access node as a specified SSD, and the number of remaining cores of the specified CPU is less than the number of physical cores required to allocate to the specified SSD, determine the multiple SSDs bound to the specified CPU, and the number of physical cores required to allocate to the SSDs other than the specified SSD. Continuously monitor the CPU core utilization of the SSDs other than the specified SSD. Select at least one borrowed SSD from the SSDs other than the specified SSD, and borrow a specified number of cores from at least one borrowed SSD. Use the number of remaining cores of the specified CPU and the specified number of cores borrowed from at least one borrowed SSD as the number of cores allocated to the specified SSD. Continuously monitor the CPU core utilization of the specified SSD. If the CPU core utilization of the specified SSD is less than a preset utilization threshold, release the borrowed specified cores. Here, a borrowed SSD refers to an SSD bound to the specified CPU with a CPU core utilization less than the preset utilization threshold; the specified number of cores refers to the minimum number of physical cores required to meet the performance requirements of the specified SSD and be located on the same memory node as the specified CPU.

[0065] For example, such as Figure 3As shown in the example above, SSD3, SSD4, and SSD5 are located on the second NUMA node and are associated with CPU1. SSD3, SSD4, and SSD5 need to be allocated 7 cores. 7 cores are allocated from CPU1 to SSD3 and SSD4 respectively. CPU1 has 2 cores remaining, and SSD5 still needs 5 cores. The utilization rate of CPU cores of SSD3 and SSD4 is continuously monitored. Assuming that the utilization rate of SSD3 and SSD4 is less than the preset utilization rate threshold, 5 cores are borrowed from SSD3 and SSD4. For example, 2 cores are borrowed from SSD3 and 3 cores are borrowed from SSD4. The remaining 2 cores of CPU1 and the 5 borrowed cores are allocated to the designated solid-state drive. The utilization rate of the CPU cores of SSD5 is continuously monitored. If the utilization rate of the CPU cores of SSD5 is less than the preset utilization threshold, the 5 borrowed cores are released. For example, the 2 cores borrowed from SSD3 are returned to SSD3, and the 3 cores borrowed from SSD4 are returned to SSD4.

[0066] In this embodiment, when the performance requirements of a specified solid-state drive (SSD) exceed the remaining resources of a specified central processing unit (CPU), additional physical cores can be intelligently borrowed from a low-load SSD. This ensures that the specified SSD achieves the expected performance, avoids performance bottlenecks, and ensures that the cores of the specified SSD and the specified CPU are allocated within the same NUMA node, reducing cross-node access latency and improving data access speed and overall system response time consistency. By continuously monitoring the CPU core utilization of all SSDs, it is possible to effectively prevent some cores from being in a low-utilization state for a long time, avoiding resource idleness. Once the performance requirements of a specified SSD decrease or the system load changes, causing the utilization of its bound cores to decrease, the system can automatically release the previously borrowed cores and allocate them to SSDs or applications that need them more, achieving efficient resource reallocation.

[0067] In one exemplary embodiment, the central processing unit's operating module includes a performance mode and a power-saving mode; the performance mode refers to the mode in which the central processing unit operates at its highest frequency; the power-saving mode refers to the mode in which the central processing unit dynamically adjusts its frequency according to the load. The resource allocation method further includes:

[0068] Set the CPU to performance mode and disable power saving mode; perform performance tests on the server after the settings are configured, and analyze the test results. If the server's performance value is less than or equal to the preset threshold, adjust the core binding strategy. The core binding strategy refers to the number of physical cores that need to be allocated to a single solid-state drive in the server. According to the core binding strategy, reallocate the required number of physical cores to the single solid-state drive until the server's performance value is greater than the preset threshold.

[0069] C-states are typically techniques that limit CPU frequency or core usage to reduce power consumption. Disabling C-states means removing any power limits on the CPU, allowing it to run at full speed without being affected by power-saving policies. During performance testing, cpupower is used to force the CPU to run at its highest frequency, eliminating interference from power-saving policies and optimizing SSD data processing performance.

[0070] Core binding strategy is a method that intelligently determines the number of physical cores allocated to each SSD based on the ratio of the total number of SSDs to the total number of physical cores. In this embodiment, the core binding strategy includes the number of physical cores allocated to the target SSD in a group of target SSDs, and the number of physical cores allocated to the other SSDs in the server besides the target group of SSDs. The core binding strategy can be dynamic. Assuming the total number of SSDs in the server is N and the total number of physical cores is M, it can be adaptively adjusted according to the ratio of N to M. For example, if N / M is less than 0.5, that is, the number of SSDs is relatively small compared to the number of physical cores, then more physical cores can be allocated to each SSD, such as twice the ratio of M / N, to fully utilize computing resources and improve SSD performance. Conversely, if N / M is greater than or equal to 0.5, fewer cores may need to be allocated to each SSD to maintain overall system responsiveness and avoid resource bottlenecks caused by over-allocation.

[0071] In another example, the core binding strategy is adjusted based on the type of workload the server is currently handling (e.g., I / O-intensive, compute-intensive) and the ratio of the total number of SSDs (N) to the total number of physical cores (M). For instance, under I / O-intensive workloads, even with a low N / M ratio, more cores might be allocated to each SSD because the SSDs have higher performance requirements. Conversely, in compute-intensive tasks, the number of cores allocated to SSDs can be appropriately reduced based on the N / M ratio to ensure sufficient computing resources.

[0072] In another example, considering the varying workloads faced by the server at different times, the core binding strategy can be designed to intelligently adjust across time periods. For instance, during peak daytime hours, due to frequent user activity and high concurrency requests on SSDs, sufficient cores should be allocated to each SSD based on the N / M ratio to ensure response speed. Conversely, during off-peak nighttime hours, with reduced user activity, the number of cores bound to SSDs can be reduced, freeing up idle resources for background maintenance or energy optimization.

[0073] After determining the core binding strategy, that is, after determining the number of physical cores required for a single SSD in the server, record and apply this strategy. For each SSD, according to the determined core binding strategy, use the taskset command to set the range of physical cores it is bound to, and monitor the SSD's I / O load and physical core usage in real time. Fine-tune the allocation as necessary to maintain optimal performance.

[0074] Performance testing refers to the process of measuring the read / write speed, latency, and other performance metrics of the solid-state drives (SSDs) on a server under different CPU binding strategies using testing tools (such as FIO). The test results are used to evaluate and adjust the core binding strategy to achieve optimal SSD performance. Preset thresholds are standards for measuring whether server storage performance meets requirements, typically based on specifications (SPEC) provided by the SSD manufacturer. If the performance metrics in the test results are lower than or equal to this threshold, it indicates that the current core binding strategy is not fully utilizing SSD performance and adjustments are needed. When performance test results do not meet the preset threshold, the CPU core and SSD binding method is adjusted. This may include reallocating the number of physical cores, modifying the core-SSD mapping, or adjusting the core operating frequency, until the performance value in the test results exceeds the preset threshold, ensuring that SSD performance reaches its optimal state.

[0075] In this embodiment, by setting the CPU to performance mode and disabling power-saving mode before performance testing, it is possible to ensure that the CPU runs at its highest frequency without the restriction of power-saving policies, thereby maximizing the performance potential of the hardware and obtaining accurate test results. Through performance testing and result analysis, the server performance bottleneck under the current configuration can be accurately identified. If the performance does not meet the standards, the core binding policy adjustment is triggered to optimize resource allocation in a targeted manner.

[0076] In one exemplary embodiment, when a new SSD is added or the hardware configuration is changed, the random core binding strategy lacks dynamic adjustment capabilities, requiring manual resource reallocation. Manually changing CPU core binding relies heavily on experience, is complex and error-prone, has poor scalability, and significantly increases maintenance costs. Therefore, to address this issue, in this embodiment, before allocating the required number of physical cores to a single SSD according to the core binding strategy, and before reallocating the required number of physical cores to a single SSD according to the adjusted core binding strategy, the resource allocation method further includes at least one of the following methods:

[0077] Method 1: Using a pre-trained prediction model, dynamically adjust the core binding strategy based on the server's real-time load data to obtain the adjusted core binding strategy.

[0078] Method 2: Simulate the execution of the core-binding strategy through a virtual machine, and dynamically adjust the core-binding strategy based on the simulation results to obtain the adjusted core-binding strategy.

[0079] Method 3: When the server adopts a heterogeneous hardware architecture, the hardware interface provided by the hardware abstraction layer can be used to shield the differences in the underlying hardware of the server, and the core binding strategy can be dynamically adjusted according to the server's hardware configuration to obtain the adjusted core binding strategy.

[0080] Method 1 refers to an intelligent resource allocation scheme that utilizes a pre-trained machine learning model (predictive model) to dynamically adjust the SSD-CPU core binding strategy based on changes in the server's real-time workload. The predictive model is trained using collected CPU and SSD performance data under different load conditions. Method 1 can predict the optimal CPU core allocation in real time to maximize SSD performance, reduce resource waste, and improve the overall system's response speed and processing efficiency. Real-time load data includes CPU utilization, SSD I / O operation frequency, memory access patterns, etc. This data is input into the predictive model, which outputs a predicted core binding strategy. If the match between the predicted and currently determined core binding strategies is greater than a preset matching threshold, the currently determined strategy is not adjusted. Otherwise, the actual CPU core allocation is automatically adjusted according to the predicted strategy to achieve performance optimization.

[0081] Method two refers to building a simulation model in a virtualized environment to simulate the system's operating state under different core-binding strategies, monitor the virtual machine load in real time, and evaluate its impact on SSD performance. The virtual machine, as a simulation platform, allows testing of the currently determined core-binding strategy without affecting the actual system operation. When the simulation results (such as IOPS, latency, and other key performance indicators) under the currently determined core-binding strategy do not meet preset requirements, the strategy is intelligently adjusted based on the simulation results to best suit the current load conditions and then applied to the actual server to achieve precise optimization of SSD performance. This method not only improves the efficiency of resource allocation but also reduces the risks of debugging in a real environment.

[0082] Method 3, as described above, proposes a mechanism for dynamically adjusting core binding strategies in server environments employing heterogeneous hardware architectures (different CPU architectures, new storage media, etc.). It provides a unified hardware interface through a Hardware Abstraction Layer (HAL), enabling upper-layer software to transparently access and manage underlying hardware resources without needing to concern itself with the specific implementation details. In heterogeneous hardware environments, Method 3 can automatically identify different hardware characteristics, such as ARM architecture CPUs versus Intel architecture CPUs, and ordinary SSDs versus Optane SSDs, and intelligently adjust the binding strategy between SSDs and CPU cores based on the server's hardware configuration. Method 3 overcomes the limitations of traditional binding strategies when dealing with heterogeneous hardware, improves system compatibility and scalability, and ensures efficient and stable operation even in diverse hardware architectures.

[0083] Figure 4 This is a flowchart of another resource allocation method provided in the embodiments of this application, such as... Figure 4 As shown, at the start of resource allocation, the server topology is first determined through environment awareness. This topology determines the relationship between SSD and CPU NUMA nodes, acquires CPU topology information, and analyzes physical and logical cores. Secondly, a core-binding strategy is determined based on the ratio of the total number of SSDs to the total number of physical cores, prioritizing the allocation of remaining cores. Further, the core-binding strategy is optimized through three methods: dynamic model tuning, cloud environment adaptation, and heterogeneous hardware tuning. Dynamic model tuning specifically includes loading a machine learning model, predicting the optimal core-binding strategy, and adjusting the strategy in real time based on this optimal strategy. Cloud environment adaptation specifically includes monitoring virtual machine load and dynamically allocating CPU and SSD resources. Heterogeneous hardware tuning adapts to ARM architecture CPUs and new storage media. Further, CPU tuning is configured, specifically by setting the CPU to performance mode and disabling power-saving mode to force the CPU to run at its highest frequency. After configuration, final testing and FIO testing are performed, test data is collected, performance metrics are analyzed, and performance is compared with manufacturer performance standards (such as SPEC). The core-binding strategy is then adjusted based on the analysis results.

[0084] For example, configure a dual-CPU (16 cores each) server with four NVMe SSDs; install the FIO testing tool and configure the test scripts. The server executes `lspci -vvv` to confirm the NUMA node relationship between the SSDs and CPUs. The server executes `numactl --hardware` to view the NUMA node distribution. The server executes `lscpu` to obtain CPU topology information. Server input parameters: number of SSDs = 4, test task type = random read / write, number of CPU physical cores = 32. The server determines the core-binding strategy based on the ratio between the total number of SSDs and the total number of physical cores, i.e., allocating 8 cores per SSD. The server predicts the optimal core-binding strategy using a pre-trained machine learning model (predictive model) based on real-time load data and dynamically adjusts the strategy. Alternatively, the server deploys a test platform in a virtualization environment to monitor virtual machine load in real time and dynamically adjusts CPU and SSD resource allocation, i.e., dynamically adjusts the core-binding strategy. Alternatively, the server deploys a test platform on an ARM architecture server, installs Optane SSDs, and uses a hardware abstraction layer to shield the underlying hardware differences and automatically adjust the core-binding strategy. After adjusting the core binding strategy, the server executes the cpupower command, sets the CPU to performance mode, performs performance tests, and analyzes the test results. If the analysis results indicate that the server's performance value is less than or equal to a preset threshold, the core binding strategy is adjusted, and the required number of physical cores is reallocated to the individual solid-state drives according to the core binding strategy until the server's performance value is greater than the preset threshold.

[0085] This embodiment demonstrates a significant improvement in SSD performance through intelligent CPU resource allocation, with IOPS and latency metrics reaching or exceeding the manufacturer's advertised performance. It also enhances resource utilization, increasing CPU core utilization from 50% using traditional methods to over 85%, reducing resource waste. Furthermore, it promotes standardization and reproducibility, providing a reproducible testing process to minimize human error and ensure consistent test results. The introduction of machine learning models predicts optimal core-binding strategies based on historical load data, achieving intelligent resource allocation and performance optimization, thus reducing operational costs. This embodiment not only supports traditional physical machine environments but also extends to virtualization scenarios and heterogeneous hardware environments, enhancing system flexibility and scalability.

[0086] In one exemplary embodiment, the server includes multiple central processing units (CPUs), and the CPUs of the multiple CPUs and local memory constitute a memory access node; the CPUs of the multiple CPUs include multiple physical cores.

[0087] A memory access node is a physical unit consisting of one or more CPUs and directly connected local memory. For example, a memory access node can be a NUMA node. During data access, the CPUs within a memory access node prioritize accessing local memory to reduce cross-node communication latency and improve processing efficiency.

[0088] In one embodiment, according to the core-binding strategy, the required number of physical cores is reallocated to a single solid-state drive, including:

[0089] Based on the server topology, determine the target CPU bound to the single solid-state drive; the topology includes the physical layout and access relationship between storage devices and different physical cores in the server; the single solid-state drive and the target CPU are located on the same memory access node; allocate the number of physical cores in the target CPU that are located on the same memory access node as the single solid-state drive and that are equal to the number of physical cores required by the single solid-state drive to the single solid-state drive.

[0090] The server topology has been explained in the above embodiments and will not be repeated here.

[0091] The target CPU is selected within the server topology as the CPU bound to a single solid-state drive (SSD) to optimize its data read / write performance. In related technologies, cross-NUMA node access requires the memory path to traverse the interconnect bus, resulting in additional latency. Therefore, to address this issue, in this application, the target CPU and the single SSD reside on the same memory access node, reducing cross-node access latency and ensuring efficient data access. It should be noted that the allocation of physical cores to the single SSD can be done within the same NUMA node, not just through reallocating the number of physical cores. Intra-node access latency is significantly lower than cross-node access latency. The same NUMA node allocation method helps maintain high SSD data read / write speeds, and by ensuring the SSD and the CPU core processing its requests are on the same node, data processing efficiency can be significantly improved.

[0092] For example, suppose a server has two physical CPUs (CPU0 and CPU1), each with 16 physical cores, for a total of 32 physical cores. The server has four SSDs installed. The first two SSDs (SSD1 and SSD2) are located on the first NUMA node and associated with CPU0, while the latter two SSDs (SSD3 and SSD4) are located on the second NUMA node and associated with CPU1. Thus, for SSD1, the target CPU is CPU0. Assuming each SSD needs to bind 8 physical cores, then for SSD1, 8 consecutive or similarly performing physical cores in CPU0 will be bound. Similarly, SSD2 will bind to another 8 physical cores in CPU0; while SSD3 and SSD4 will each bind to 8 physical cores in CPU1. If the server's physical core distribution is: CPU0 has cores 0-15, and CPU1 has cores 16-31. Therefore, SSD1 can be bound to CPU0 cores 0-7, SSD2 to cores 8-15; SSD3 to CPU1 cores 16-23, and SSD4 to cores 24-31. This allocation ensures that each SSD is bound to a sufficient number of directly connected CPU cores, and all SSD-CPU bindings are within their respective NUMA nodes, thereby optimizing data access paths, reducing cross-node access latency, and improving storage performance.

[0093] By setting the SSD and CPU to the same NUMA node in this embodiment, data access latency can be significantly reduced, I / O throughput and overall SSD performance can be improved, the data access mode under the NUMA architecture can be optimized, the overhead of cross-node memory access can be reduced, and data access efficiency can be improved.

[0094] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0095] Embodiments of this application also provide a resource allocation device, such as... Figure 5 As shown, it includes:

[0096] The acquisition module 502 is used to acquire the total number of solid-state drives and the total number of physical cores of the server's central processing unit.

[0097] The strategy determination module 504 is used to determine the remainder of the first ratio as the number of remaining cores when the first ratio between the total number of solid-state drives and the total number of physical cores is not an integer; select a group of target solid-state drives from the server in descending order of priority of individual solid-state drives, which is equal to the number of remaining cores; and determine the number of physical cores to be allocated to the target solid-state drives in the group of target solid-state drives.

[0098] The allocation module 506 is used to allocate the number of physical cores to a group of target solid-state drives according to the number of physical cores required by the target solid-state drives.

[0099] For a description of the features in the embodiment corresponding to the resource allocation device, please refer to the relevant description in the embodiment corresponding to the resource allocation method, which will not be repeated here.

[0100] In an exemplary embodiment, the acquisition module 502 is further configured to determine the topology of the server; the topology includes the physical layout and access relationships between storage devices and different physical cores in the server; and based on the topology, determine the total number of solid-state drives and the total number of physical cores of the server's central processing unit.

[0101] In an exemplary embodiment, the strategy determination module 504 is further configured to determine the integer part of the first ratio as the first base core number, and determine the number of physical cores equal to the first base core number as the number of physical cores required to be allocated to the target solid-state drives in a group of target solid-state drives; the first base core number refers to the number of cores required to be allocated to the target solid-state drives in a group of target solid-state drives.

[0102] In an exemplary embodiment, the strategy determination module 504 is further configured to determine the first ratio as the second basic core number when the first ratio between the total number of solid-state drives and the total number of physical cores is an integer, and to allocate a number of physical cores equal to the second basic core number to a single solid-state drive in the server; the second basic core number refers to the number of cores required to be allocated to a single solid-state drive.

[0103] In one exemplary embodiment, the strategy determination module 504 is further configured to allocate the number of physical cores to the other solid-state drives in the server, excluding the set of target solid-state drives, based on the number of physical cores in the total number of physical cores other than the physical cores allocated to the set of target solid-state drives.

[0104] In an exemplary embodiment, the strategy determination module 504 is further configured to round up the second ratio between the number of other physical cores and the number of other solid-state drives in the server excluding the target set of solid-state drives, and determine the resulting integer as the third basic core number; allocate a number of physical cores equal to the third basic core number to the other solid-state drives; the third basic core number refers to the number of physical cores required to be allocated to the other solid-state drives.

[0105] In an exemplary embodiment, the CPU's operating module includes a performance mode and a power-saving mode; the performance mode refers to the CPU operating at its highest frequency; the power-saving mode refers to the CPU dynamically adjusting its frequency according to the load; the allocation module 506 is further configured to set the CPU to performance mode and disable power-saving mode; perform performance testing on the configured server and analyze the test results; if the analysis results indicate that the server's performance value is less than or equal to a preset threshold, adjust the core-binding strategy; the core-binding strategy refers to the number of physical cores required to be allocated to a single solid-state drive in the server; according to the adjusted core-binding strategy, reallocate the required number of physical cores to the single solid-state drive until the server's performance value is greater than the preset threshold.

[0106] In one exemplary embodiment, the server includes multiple central processing units (CPUs), and the CPUs of the multiple CPUs and local memory constitute a memory access node; the CPUs of the multiple CPUs include multiple physical cores; the allocation module 506 is further configured to determine a target CPU bound to a single solid-state drive (SSD) according to the server's topology; the topology includes the physical layout and access relationships between storage devices and different physical cores in the server; the single SSD and the target CPU are located in the same memory access node; and the number of physical cores in the target CPU that are located in the same memory access node as the single SSD and that are equal to the number of physical cores required by the single SSD are allocated to the single SSD.

[0107] In one exemplary embodiment, before reallocating the required number of physical cores to a single solid-state drive according to the adjusted core-binding strategy, the strategy determination module 504 is further configured to perform at least one of the following methods:

[0108] By using a pre-trained prediction model and based on real-time server load data, the core binding strategy is dynamically adjusted to obtain the adjusted core binding strategy.

[0109] The core-binding strategy is simulated and executed using a virtual machine. Based on the simulation results, the core-binding strategy is dynamically adjusted to obtain the adjusted core-binding strategy.

[0110] When the server adopts a heterogeneous hardware architecture, the hardware interface provided by the hardware abstraction layer can shield the underlying hardware differences of the server and dynamically adjust the core binding strategy according to the server's hardware configuration to obtain the adjusted core binding strategy.

[0111] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the resource allocation method embodiments described above.

[0112] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described resource allocation method embodiments at runtime.

[0113] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0114] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described resource allocation method embodiments.

[0115] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described resource allocation method embodiments.

[0116] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0117] The resource allocation method, apparatus, electronic device, and storage medium provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A resource allocation method, characterized in that, include: Obtain the total number of solid-state drives (SSDs) and the total number of physical cores of the server's central processing unit (CPU); individual SSDs within the total number of SSDs have different priorities; When the first ratio between the total number of SSDs and the total number of physical cores is not an integer, the remainder of the first ratio is determined as the remaining number of cores. A group of target SSDs, equal to the remaining number of cores, is selected from the server according to the priority of individual SSDs from high to low. The integer part of the first ratio is determined as the first base number of cores. The number of physical cores equal to the first base number of cores is determined as the number of physical cores required to be allocated to the target SSDs in the group of target SSDs. The first base number of cores refers to the number of cores required to be allocated to the target SSDs in the group of target SSDs. Based on the required number of physical cores for the target SSDs, the following steps are taken: First, the number of physical cores allocated to the group of target SSDs is determined. Then, the second ratio between the total number of physical cores (excluding those allocated to the group of target SSDs) and the number of other SSDs in the server (excluding the group of target SSDs) is rounded up to the nearest integer, which is then determined as the third basic core count. Finally, the other SSDs are allocated a number of physical cores equal to the third basic core count. The third basic core count refers to the number of physical cores required to be allocated to the other SSDs. Specifically, when allocating physical cores to the individual solid-state drive each time, the allocation method is adopted using the same non-uniform memory access node; the allocation method using the same non-uniform memory access node means that the individual solid-state drive and the physical core that processes its request are on the same non-uniform memory access node; the non-uniform memory access node includes at least one central processing unit and local memory resources directly accessed by the at least one central processing unit.

2. The resource allocation method according to claim 1, characterized in that, The process of obtaining the total number of solid-state drives (SSDs) and the total number of physical cores of the server's central processing unit includes: Determine the topology of the server; the topology includes the physical layout and access relationships between storage devices and different physical cores in the server; Based on the topology, determine the total number of solid-state drives (SSDs) and the total number of physical cores of the server's central processing unit (CPU).

3. The resource allocation method according to claim 1, characterized in that, The method further includes: When the first ratio between the total number of solid-state drives and the total number of physical cores is an integer, the first ratio is determined as the second basic core count, and a number of physical cores equal to the second basic core count is allocated to each solid-state drive in the server; the second basic core count refers to the number of cores required to be allocated to each solid-state drive.

4. The resource allocation method according to claim 1, characterized in that, The central processing unit's operating modules include a performance mode and a power-saving mode; the performance mode refers to the central processing unit operating at its highest frequency; the power-saving mode refers to the central processing unit dynamically adjusting its frequency according to the load; the method further includes: Set the central processing unit to the performance mode and disable the power saving mode; The server is configured and its performance is tested. The test results are analyzed. If the performance value of the server is less than or equal to a preset threshold, the core binding strategy is adjusted. The core binding strategy refers to the number of physical cores that need to be allocated to a single solid-state drive in the server. According to the adjusted core-binding strategy, the required number of physical cores are reallocated to the single solid-state drive until the performance value of the server is greater than the preset threshold.

5. The resource allocation method according to claim 4, characterized in that, The server includes multiple central processing units (CPUs), and each CPU and local memory form a memory access node; each CPU includes multiple physical cores; the step of reallocating the required number of physical cores to the single solid-state drive according to the adjusted core-binding strategy includes: Based on the server's topology, a target CPU bound to the single solid-state drive is determined; the topology includes the physical layout and access relationships between storage devices and different physical cores in the server; the single solid-state drive and the target CPU are located on the same memory access node. Allocate the target central processing unit to the single solid-state drive a number of physical cores that are in the same memory access node as the single solid-state drive and that are equal to the number of physical cores required by the single solid-state drive.

6. The resource allocation method according to claim 4, characterized in that, Before reallocating the required number of physical cores to the single solid-state drive according to the adjusted core-binding strategy, the method further includes at least one of the following methods: The core-binding strategy is dynamically adjusted based on the real-time load data of the server using a pre-trained prediction model, resulting in the adjusted core-binding strategy. The core-binding strategy is simulated and executed using a virtual machine, and the core-binding strategy is dynamically adjusted based on the simulation results to obtain the adjusted core-binding strategy. When the server adopts a heterogeneous hardware architecture, the hardware interface provided by the hardware abstraction layer shields the underlying hardware differences of the server, and dynamically adjusts the core binding strategy according to the hardware configuration of the server to obtain the adjusted core binding strategy.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the resource allocation method as described in any one of claims 1 to 6.

Images