Method and apparatus for testing storage devices

Abstract

The application discloses a kind of test method and device of storage device, it is related to storage device test technical field, including: according to the test request received control to be tested storage device in the reference queue depth included in queue depth set under execution test task;The device operating parameter and delay parameter of the described to be tested storage device under the reference queue depth are detected, and the reference queue depth, device operating parameter and delay parameter with corresponding relationship are obtained;According to the reference queue depth, device operating parameter and delay parameter with corresponding relationship of the described to be tested storage device queue depth parameter are detected, and target queue depth parameter is obtained, solve the technical problem that the test efficiency of the running performance of storage device is lower in related art, reach the technical effect of improving the test efficiency of the running performance of storage device.

Description

Technical Field

[0001] This application relates to the field of storage device testing technology, and in particular to testing methods and apparatus for storage devices. Background Technology

[0002] In recent years, with the surge in data processing demands, storage systems have faced unprecedented challenges. Deploying storage devices addresses data storage needs in various application scenarios. Furthermore, to better ensure the data storage efficiency of these devices under these scenarios, it is often necessary to test their operational performance to guarantee that they can meet the high-performance storage requirements of actual deployments. Among related technologies, fixed queue depth testing is commonly used. By collecting test data at this queue depth, the operational performance of the storage device is determined. However, this test queue depth often fails to reflect the true performance of the storage device under complex workloads, resulting in low testing efficiency. Summary of the Invention

[0003] This application provides a testing method and apparatus for storage devices, in order to at least solve the technical problem of low testing efficiency for the operating performance of storage devices in related technologies.

[0004] This application provides a testing method for a storage device, including:

[0005] The test request controls the storage device under test to execute test tasks at reference queue depths included in the queue depth set. The test request is used to request queue depth parameters of the storage device under test. The performance of the storage device running at the queue depth indicated by the queue depth parameters meets the target performance requirements.

[0006] The device operation parameters and latency parameters of the storage device under test at the reference queue depth are detected to obtain a corresponding reference queue depth, device operation parameters and latency parameters. The device operation parameters are used to indicate the device operation performed by the storage device under test during the execution of the test task at the reference queue depth, and the latency parameters are used to indicate the latency of the storage device under test in executing the test task at the reference queue depth.

[0007] The queue depth parameter of the storage device under test is detected based on the corresponding reference queue depth, device operation parameters, and latency parameters to obtain the target queue depth parameter.

[0008] This application also provides a testing apparatus for a storage device, comprising:

[0009] The first control module is used to control the storage device under test to execute test tasks at a reference queue depth included in the queue depth set according to the received test request. The test request is used to request the queue depth parameter of the storage device under test, and the running performance of the storage device at the queue depth indicated by the queue depth parameter meets the target performance requirement.

[0010] The first detection module is used to detect the device operation parameters and latency parameters of the storage device under test at the reference queue depth, and obtain the reference queue depth, device operation parameters and latency parameters with corresponding relationships. The device operation parameters are used to indicate the device operation status of the storage device under test during the execution of the test task at the reference queue depth, and the latency parameters are used to indicate the latency of the storage device under test in executing the test task at the reference queue depth.

[0011] The second detection module is used to detect the queue depth parameter of the storage device under test based on the corresponding reference queue depth, device operation parameters and latency parameters, and obtain the target queue depth parameter.

[0012] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the testing method of any of the above-described memory devices.

[0013] 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 the test method for any of the above-described storage devices.

[0014] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the testing method for any of the above-described storage devices.

[0015] This application, by configuring a queue depth set for the storage device under test, and then, upon receiving a test request, controlling the storage device to execute test tasks according to the reference queue depths included in the queue depth set, simulates the workload state of the storage device under real-world usage scenarios. It then detects the device's operating parameters and latency parameters at the reference queue depths. By testing the queue depth parameters of the storage device under test based on the corresponding reference queue parameters, device operating parameters, and latency parameters, the application achieves a reliable simulation of the storage device's workload state to detect its queue depth parameters, thus improving the testing speed and accuracy of the test results. Therefore, it solves the technical problem of low testing efficiency for storage device performance in related technologies, achieving the technical effect of improving the testing efficiency of storage device performance. Attached Figure Description

[0016] 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.

[0017] Figure 1 This is a hardware structure block diagram of a testing method for a storage device according to an embodiment of this application;

[0018] Figure 2 This is a flowchart of a testing method for a storage device according to an embodiment of this application;

[0019] Figure 3 This is a schematic diagram of an optional resource contention module according to an embodiment of this application;

[0020] Figure 4 This is a schematic diagram of an optional testing system according to an embodiment of this application;

[0021] Figure 5 This is a schematic diagram of an optional hybrid load time window allocation according to an embodiment of this application;

[0022] Figure 6 This is a flowchart of an optional testing process according to an embodiment of this application;

[0023] Figure 7 This is a structural block diagram of a testing apparatus for a storage device according to an embodiment of this application. Detailed Implementation

[0024] 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.

[0025] 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.

[0026] 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.

[0027] The specific application environment architecture or specific hardware architecture on which the testing methods for storage devices depend is described here.

[0028] The methods and embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure block diagram of a testing method for a storage device according to an embodiment of this application. For example... Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0029] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the testing method of the storage device in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0030] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0031] The embodiments of this application provide a testing method for a storage device, and the method is described in detail below in conjunction with the execution flow of the testing method for the storage device.

[0032] This embodiment provides a testing method for a storage device. Figure 2 This is a flowchart of a testing method for a storage device according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0033] Step S202: Control the storage device under test to execute a test task at a reference queue depth included in the queue depth set according to the received test request, wherein the test request is used to request the queue depth parameter of the storage device under test, and the running performance of the storage device at the queue depth indicated by the queue depth parameter meets the target performance requirement.

[0034] Step S204: Detect the device operation parameters and latency parameters of the storage device under test at the reference queue depth to obtain a corresponding reference queue depth, device operation parameters, and latency parameters. The device operation parameters are used to indicate the device operation performed by the storage device under test during the execution of the test task at the reference queue depth, and the latency parameters are used to indicate the latency of the storage device under test in executing the test task at the reference queue depth.

[0035] Step S206: Detect the queue depth parameter of the storage device under test based on the corresponding reference queue depth, device operation parameters, and latency parameters to obtain the target queue depth parameter.

[0036] Through the above steps, by configuring a queue depth set for the storage device under test, and then, upon receiving a test request, controlling the storage device to execute test tasks according to the reference queue depths included in the queue depth set, the workload state of the storage device under real-world usage scenarios is simulated. This allows for the detection of device operating parameters and latency parameters at the reference queue depth. Furthermore, by detecting the queue depth parameters of the storage device under test based on the corresponding reference queue parameters, device operating parameters, and latency parameters, the performance of the storage device under test is tested. This method achieves the detection of the queue depth parameters of the storage device under test in a realistic and reliable manner, improving the testing speed and accuracy of the test results. Therefore, it solves the technical problem of low testing efficiency for storage device performance in related technologies, achieving the technical effect of improving the testing efficiency of storage device performance.

[0037] In the embodiment provided in step S202, the storage device may be, but is not limited to, a storage device that supports the NVME (Non-Volatile Memory Express) protocol, and the storage device may include, but is not limited to, SSD (Solid State Drive).

[0038] Optionally, in this embodiment, queue depth refers to the number of IO requests to be executed on the storage device under test. The queue depth set records multiple reference queue depths within the queue depth range supported by the storage device under test. These multiple reference queue depths can be multiple queue depths that are sequentially and continuously distributed within the queue depth range, or they can be multiple queue depths that are sequentially distributed within the queue depth range according to the target queue depth gradient. The purpose of setting the queue depth set in this application is to reflect the real performance of the storage device under complex loads. Therefore, the number of reference queue depths included in the queue depth set to be tested can be adjusted by adjusting the queue depth gradient. By adjusting the queue depth gradient to a suitable gradient value, the parameters obtained from the test can better reflect the changing state of the storage device's operating performance, thereby improving the accuracy of the test results while ensuring the test rate.

[0039] Optionally, in this embodiment, the target queue gradient can be a fixed value set based on experience, or it can be generated for the current storage device under test based on the device information of the storage device. That is, the queue depth set of the storage device under test can be constructed in the following way: the target queue gradient of the storage device under test is generated based on the target device information of the storage device under test, wherein the target device information is a parameter used to characterize the data storage attributes of the storage device under test, and the target device information may include, but is not limited to, the data access rate of the storage device, the resource capacity of the storage device, etc.; the target queue gradient is used to divide the queue depth range supported by the storage device under test into multiple reference queue depths, and the multiple reference queue depths are determined as the queue depth set. Further generating the target queue gradient of the storage device under test (DUT) based on its device information includes: calling a target transformation model to convert the target device information into an initial queue gradient, wherein the target transformation model records the transformation relationship between device information and queue gradient; dividing multiple initial queue depths from the queue depth range supported by the DUT according to the initial queue gradient; detecting the initial device operation parameters and initial latency parameters of the DUT at the initial queue depths to obtain corresponding initial queue depths, initial device operation parameters, and initial latency parameters, wherein the initial device operation parameters are used to indicate the DUT's... The test involves the storage device performing device operations during the test task at the initial queue depth. The initial latency parameter indicates the latency of the storage device under test during the test task at the initial queue depth. The corresponding initial queue depth, initial device operation parameters, and initial latency parameters are fitted into an initial fitting curve, which indicates the changes in the initial device operation parameters and initial latency parameters within the queue depth range of the storage device under test. The slope transformation information of the initial fitting curve is detected. The initial queue gradient is adjusted according to the gradient adjustment method indicated by the slope transformation information to obtain the target queue gradient. In the above embodiment, a multi-round test result-based dynamic queue gradient adjustment method is used to configure an accurate target queue gradient for the storage device under test, thereby enabling the reference storage queue with the target queue gradient to better reflect the changing performance of the storage device under test.

[0040] Optionally, in this embodiment, the test task executed at the reference queue depth is used to simulate the actual operating state of the device under test at the current reference queue depth. This may include, but is not limited to, adjusting the proportion of various data access tasks (data access tasks may include, but are not limited to, random write tasks, sequential write tasks, garbage collection tasks, etc.) in the input / output commands at the reference queue depth according to the operating parameters of the storage device during the IO processing. By adjusting the proportion of data access tasks in the input / output commands according to the operating parameters of the storage device during the IO task execution, the true operating performance of the storage device can be better explored. The test task may also include, but is not limited to, adding bursty data processing tasks during the test at the reference queue depth to simulate the storage device's performance in handling burst traffic during operation. This solution does not limit this aspect.

[0041] Optionally, in this embodiment, the queue depth parameter may be, but is not limited to, the performance inflection point of the storage device at a certain queue depth. That is, as a certain influencing factor (such as load, queue depth, concurrency, etc.) gradually increases, the storage device's performance indicators (such as throughput, response time, IOPS, etc.) will experience a turning point from growth to a significant decrease or a sharp slowdown in the growth rate. This turning point marks the storage device reaching its performance limit or bottleneck, after which further increases in its influence will no longer improve performance and may even worsen it.

[0042] Optionally, in this embodiment, operational performance is used to indicate the storage device's ability to execute data input / output commands. Operational performance may include, but is not limited to, data access latency, data read / write rate, etc. For example, if the data access latency is less than or equal to a target latency threshold, it can be determined that the storage device's operational performance meets the target performance requirements; if the data read / write rate is greater than or equal to a target rate threshold, it can be determined that the storage device's operational performance meets the target performance requirements. In this application, the optimal queue depth of the storage device is obtained by testing its queue depth parameter, maximizing the efficiency of the storage device's data input / output tasks. Subsequently, in applications using the storage device, data access tasks can be configured based on the detected queue depth parameter, thereby improving the data storage efficiency of the storage device in application scenarios.

[0043] In the embodiment provided in step S204, the device operation parameters may include, but are not limited to, IOPS (Input / Output Operations Per Second), which is an indicator for measuring the random access performance of computer storage devices (such as hard disks, solid-state drives, and storage area networks), representing the number of read and write operations per second.

[0044] Optionally, in the embodiments of this application, the latency parameter may be, but is not limited to, the data access latency of the storage device detected by the storage device during the execution of the test task.

[0045] In the embodiment provided in step S206, the target queue depth parameter may be, but is not limited to, obtained by using a target conversion model to identify and convert the corresponding reference queue depth, device operation parameters, and delay parameters. The target conversion model records the conversion relationship between the corresponding queue depth, device operation parameters, delay parameters, and queue depth parameters.

[0046] Optionally, in this embodiment, the target queue depth parameter may be, but is not limited to, a target fitting curve fitted using a corresponding reference queue depth, device operating parameters, and latency parameters. The target fitting curve indicates the changes in device operating parameters and latency parameters within the queue depth range of the storage device under test, thereby identifying a performance inflection point from the target fitting curve. This performance inflection point indicates the critical point of the operating performance of the storage device under test within the supported queue depth range. The target queue depth parameter is selected from multiple reference queues based on the operating performance of the storage device indicated by the performance inflection point of the reference queue depth, ensuring that the operating performance meets the target operating performance requirements.

[0047] As an optional implementation, controlling the storage device under test to execute the test task at a reference queue depth included in the queue depth set according to the received test request includes:

[0048] Receive the test request;

[0049] In response to the test request, traverse each of the reference queue depths and repeat the following operations until all reference queue depths in the queue depth set have been traversed:

[0050] Create input and output queues according to the reference queue depth currently being traversed;

[0051] Input / output commands are submitted to the input / output queue according to a target ratio until the test duration is reached. The input / output commands include random read commands, sequential write commands, and garbage collection commands. The target ratio indicates the proportion of random read commands, sequential write commands, and garbage collection commands.

[0052] Optionally, in this embodiment, the test tasks at multiple reference queue depths can be, but are not limited to, test tasks executed concurrently by a multi-threaded load generator. That is, the multi-threaded load generator includes multiple load generators that generate test tasks according to the task load indicated by the reference queue depth, with each load generator executing a test task at one reference queue depth. By concurrently executing test tasks at multiple reference queue depths, the concurrent pressure on the storage device at different queue depths is tested, creating a multi-queue parallel access scenario for the storage device. The detection of controller scheduling bottlenecks in multi-queue concurrent scenarios relies on the simultaneous pressure applied to multiple queues. Optionally, in this embodiment, the load generator may, but is not limited to, perform the following test operations according to the reference queue depth: I / O type selection: weight allocation of various data access tasks (including random read commands, sequential write commands, and garbage collection commands) is implemented through random.choices(); burst traffic detection: the in_burst_window() function determines the time window, thereby increasing the task load within the burst traffic event window, thereby configuring burst traffic for the storage device under test; I / O submission: the submit_io() method handles command issuance; resource contention: conflict LBA submission logic is called in the load generator.

[0053] Optionally, in this embodiment, the target ratio is the proportion of random read commands, sequential write commands, and garbage collection commands in the input / output queue. This ratio can affect the execution status of the storage device's input / output queue tasks. That is, different target ratios of input / output queues result in different resource consumption of the storage device, and therefore different execution efficiencies for the input / output queue tasks. In this embodiment, the target ratio can be a fixed value configured based on historical experience, or, to better test the operating performance of the storage device under test, the ratio of various command types can be dynamically adjusted according to the device operating parameters when the storage device executes the input / output queue. Specifically, this can be achieved by: detecting the device operating parameters of the storage device under test during the execution of the target input / output queue test task within the target adjustment period. The device operating parameters indicate the resource consumption of the storage device under test during the execution of the test task (device operating parameters may include, but are not limited to, the temperature value of the storage device, the task response rate of the storage device, etc.); then converting the ratio adjustment amount corresponding to the device operating parameters; and adjusting the initial ratio according to the ratio adjustment amount to obtain the target ratio, wherein the target input / output queue is a test queue configured according to the target ratio.

[0054] Through the above, this embodiment simulates the load pressure in real-world business scenarios by traversing different queue depths and generating mixed-type I / O commands according to a preset target ratio. This ensures the comprehensiveness and accuracy of the test. By controlling the proportion of different types of I / O commands (random read, sequential write, garbage collection), the performance of storage devices when handling complex business can be evaluated more precisely. It effectively detects the performance of storage devices at different queue depths, including IOPS, latency, and bandwidth, helping users understand the device's behavior in high-concurrency environments.

[0055] As an optional implementation, submitting input / output commands to the input / output queue according to the target ratio includes at least one of the following:

[0056] Create an initial input / output command that conforms to the target ratio; detect whether the current period is within a burst flow window; if the current period is within the burst flow window, expand the scale of the initial input / output command according to the flow multiplication factor to obtain a reference input / output command; submit the reference input / output command to the input / output queue; if the current period is not within the burst flow window, submit the initial input / output command to the input / output queue.

[0057] During the process of submitting input / output commands to the input / output queue according to the target ratio, conflicting input / output commands are submitted to a reference namespace, wherein the reference namespace is different from the namespace of the input / output commands. The conflicting input / output commands are configured to compete for execution resources with the input / output commands. The command size of the conflicting input / output commands is less than a command size threshold. The execution area of ​​the conflicting input / output commands does not include the reserved area in the storage device under test. After executing the conflicting input / output commands, the storage space occupied by the conflicting input / output commands is released.

[0058] While submitting input / output commands to the input / output queue according to the target ratio, the operating temperature of the storage device under test is detected; if the operating temperature is greater than or equal to the temperature threshold, the proportion of sequential write commands in the input / output commands is reduced and the proportion of garbage collection commands is increased.

[0059] Optionally, in this embodiment, burst traffic refers to the instantaneous occurrence of a greater number of input / output commands than the normal input / output command queue, where the number of commands far exceeds the average value or normal traffic level of the input / output command queue. By setting a burst traffic window, the execution state of the storage device under extreme conditions for high-concurrency input / output commands is simulated within the burst traffic window.

[0060] Optionally, in this embodiment, the traffic multiplication factor is an expansion parameter that expands the number of commands on the input / output command queue. By expanding the initial input / output command scale on the input / output queue through the traffic multiplication factor, the storage device can simulate the execution scenario of high-concurrency commands.

[0061] Optionally, in the embodiments of this application, the purpose of submitting conflict input / output commands to the reference command space is to simulate the resource contention state during the operation of the storage device, thereby intentionally creating queue resource conflicts in multiple NVMe namespaces to verify the fairness of controller scheduling.

[0062] Optionally, in this embodiment of the application, the storage space occupied by the conflict input / output command is released after the conflict input / output command is executed, so as to realize the Trim release of space immediately after the conflict operation, thereby avoiding data residue.

[0063] Optionally, in the embodiments of this application, the command threshold may be set based on the total load, but is not limited to the target percentage of the total load. For example, 5% of the total load of the storage device may be set as the command threshold.

[0064] Optionally, in this embodiment, the temperature threshold may be, but is not limited to, 85°C. In the art, 85°C is considered the critical point for consumer-grade SSDs. More importantly, there are semiconductor physical characteristics—when the temperature exceeds 85°C, the charge leakage rate of NAND flash memory cells increases exponentially. Explained using the Arrhenius equation, this means the failure rate doubles for every 10°C increase in temperature. When the temperature exceeds the limit, we employ a non-linear proportional adjustment: the sequential write load decays according to an S-shaped curve (using the formula...). (Achieves a smooth transition), reducing write volume by up to 50%; the Trim command, on the other hand, increases write volume superlinearly. The maximum increase is 30%. For example, at 90℃, the original ratio [60%, 30%, 10%] will become [68%, 15%, 17%]. This design is more in line with thermodynamic laws than simple linear adjustment—rapid pressure reduction in the initial stage, and avoidance of excessive reduction in the later stage that would affect the integrity of the test.

[0065] The above content, by introducing the concept of bursty traffic windows, enhances the realism and complexity of the test. Furthermore, by creating resource contention between different namespaces, the multi-queue scheduling capabilities of the storage device are tested. By dynamically adjusting the command ratio and scale, fluctuations in business traffic and the resource management challenges faced by the storage device are simulated. This allows for a more accurate reflection of the storage device's performance under extreme conditions, especially when facing hot zones and temperature limitations.

[0066] As an optional implementation, the step of detecting the queue depth parameter of the storage device under test based on the corresponding reference queue depth, device operating parameters, and latency parameters to obtain the target queue depth parameter includes:

[0067] The corresponding reference queue depth, device operating parameters, and latency parameters are fitted to a target fitting curve, wherein the target fitting curve is used to indicate the changes in device operating parameters and latency parameters within the queue depth range of the storage device under test;

[0068] Identify the performance inflection point in the target fitting curve and determine the optimal queue depth of the storage device under test based on the target fitting curve. The performance inflection point is used to indicate the critical point of the operational performance of the storage device under test within the supported queue depth range. The optimal queue depth is the queue depth at which the storage device under test achieves optimal operational performance. The target queue depth parameter includes the performance inflection point and the optimal queue depth.

[0069] Optionally, in this embodiment, the performance inflection point refers to the point during the performance testing of the storage device where, as a certain influencing factor (such as load, queue depth, concurrency, etc.) gradually increases, the storage device's operating performance indicators (such as throughput, response time, IOPS, etc.) will experience a transition from growth to a significant decline or a sharp slowdown in the growth rate. This inflection point signifies that the storage device has reached its performance limit or bottleneck, and further increases in its influence will no longer improve performance but may even worsen it.

[0070] Optionally, in the embodiments of this application, the device operating parameters and delay parameters curves at each reference queue depth can be fitted by a method of smoothing data using cubic spline interpolation.

[0071] Optionally, in this embodiment, the optimal queue depth based on removing the top of the target fitted curve can be found by calculating the second derivative of the performance inflection point in the target fitted curve, as follows: f′′(QD)=Δ2LatencyΔQD2f′′(QD)=ΔQD2Δ2Latency; where Latency is the delay parameter, QD is the reference queue depth, and when |f′′(QD)|>α (the threshold is 0.5 by default) and the slope change exceeds 30%, it is marked as a performance inflection point. The queue depth to which the performance inflection point belongs is determined as the optimal queue depth.

[0072] This embodiment utilizes a mathematical model to analyze test data to identify performance inflection points, a crucial step in evaluating the concurrency capabilities of storage devices. By fitting curves, the relationship between queue depth and performance metrics can be visually displayed, thereby determining the device's performance stability and optimal operating point under high concurrency. The technology in this embodiment provides users with scientific recommendations for queue depth settings, avoiding performance losses caused by improper queue depth settings.

[0073] As an optional implementation, identifying the performance inflection point in the target fitting curve includes:

[0074] Calculate the second derivative of the target fitted curve;

[0075] Based on the second derivative, locate the curve position on the target fitting curve where the second derivative value is greater than the first threshold and the rate of change of slope is greater than the second threshold.

[0076] The queue depth corresponding to the position of the curve within the range of queue depths is determined as the performance inflection point.

[0077] This embodiment uses mathematical methods to identify performance inflection points, ensuring the objectivity and accuracy of the test results. In principle, the second derivative reflects the rate of change of the curve's slope and is a key indicator for inflection point identification. In terms of effect, the technology in this embodiment can accurately identify the critical point where storage device performance begins to decline, which is crucial for optimizing the concurrent performance of storage systems.

[0078] As an optional implementation, determining the optimal queue depth of the storage device under test based on the target fitting curve includes:

[0079] Based on the target fitting curve, extract the queue depths that are the first N positions of the queue depth range with the delay parameter arranged in ascending order, to obtain N candidate queue depths, where N is a positive integer;

[0080] The fluctuation coefficient of each candidate queue depth is determined based on the target fitting curve, wherein the fluctuation coefficient is used to indicate the fluctuation of the corresponding delay parameter in the adjacent depth range of the candidate queue depth;

[0081] From the N candidate queue depths, the candidate queue depths whose fluctuation coefficient is less than the coefficient threshold are selected to obtain the reference queue depth;

[0082] The queue depth with the largest corresponding device operation parameter in the reference queue depth is determined as the optimal queue depth.

[0083] Optionally, in this embodiment, the optimal queue depth is determined based on a triple judgment criterion, which includes latency priority, stable row filtering, and performance verification. For example, latency priority: select the 3 points with the lowest latency (e.g., QD32 / 64 / 128); stability filtering: exclude points with fluctuation coefficient >15%; performance verification: select the QD with the highest IOPS among the remaining points.

[0084] Based on the above, this embodiment analyzes the fluctuations in latency parameters to further filter out the queue depth with the most stable performance. This is a crucial step in determining the optimal queue depth. The fluctuation coefficient reflects the stability of latency parameters within a certain queue depth range and is a key indicator for evaluating device performance reliability. The technology in this embodiment helps users find a queue depth that maximizes device operational performance while maintaining stable latency parameters, thereby achieving optimal performance of storage devices in practical applications.

[0085] As an optional implementation, the method further includes:

[0086] During the process of detecting the device operation parameters and latency parameters of the storage device under test at the reference queue depth, the bandwidth parameters of the storage device under test are detected.

[0087] The queue depths in the target fitting curves where the bandwidth parameter is greater than or equal to the bandwidth threshold and the delay parameter is greater than or equal to the delay threshold are identified as scheduling bottlenecks of the controller.

[0088] This embodiment expands the dimensions of performance testing by monitoring bandwidth parameters, helping to more comprehensively evaluate the performance bottlenecks of storage devices. Bandwidth parameters reflect the data transfer speed of storage devices, and combined with latency parameters, analysis can reveal scheduling efficiency issues in high-concurrency scenarios. The technology in this embodiment helps users identify scheduling bottlenecks in storage devices, providing direction for subsequent performance optimization.

[0089] As an optional implementation, the step of detecting the device operation parameters and latency parameters of the storage device under test at the reference queue depth to obtain a corresponding reference queue depth, device operation parameters, and latency parameters includes:

[0090] The unit operation quantity and latency of the storage device under test at the reference queue depth are detected to obtain the corresponding reference queue depth, device operation parameters and latency parameters. The device operation parameters include the unit operation quantity, and the latency parameters include the latency time. The unit operation quantity is used to indicate the number of input and output operations that the storage device under test is allowed to process per unit time.

[0091] As an optional implementation, the method further includes:

[0092] During the execution of the test task by the storage device under test, it is detected whether the storage device under test malfunctions.

[0093] When an anomaly is detected in the storage device under test, the context of all unfinished device operations in all queues on the storage device under test is saved, and a hardware error snapshot of the storage device under test is generated. The hardware error snapshot is used to record the operating information of the storage device under test when an anomaly occurs.

[0094] The system controls the storage device under test to adjust its operating parameters to the target mode and retry the current device operation in the test task, and detects whether the storage device under test passes the current device operation. The target mode includes: a first value decrease in PCIe rate compared to the current PCIe rate, a second value decrease in queue depth limit compared to the current queue depth limit, a third value decrease in power supply voltage compared to the current power supply voltage, and a fourth value decrease in burst traffic in load intensity compared to the current burst traffic.

[0095] If the device under test is detected to be operating through the current device, the operating parameters of the device under test are restored to the operating parameters at the time of the anomaly based on the context and the hardware error snapshot, and the test task continues to be executed.

[0096] Optionally, in the embodiments of this application, the link rate may be, but is not limited to, the PCIe link rate.

[0097] This application proposes a hybrid random / sequential read / write test model for high-performance storage devices to simulate latency and throughput limits under high-concurrency scenarios. The test system comprises a hardware environment and software procedures.

[0098] The hardware environment includes:

[0099] The NVMe SSD under test (connected to a PCIe 4.0 / 5.0 slot);

[0100] Test host (must be equipped with a multi-core CPU to simulate high concurrency);

[0101] High-speed data acquisition card (to monitor the impact of SSD power supply fluctuations on performance);

[0102] The software process includes:

[0103] Step 1: Configure test parameters (mixed load ratio, queue depth range, single test duration).

[0104] Input parameters:

[0105] "workload_ratio":[0.6,0.3,0.1],#Random read:Sequential write:Trim command ratio;

[0106] "queue_depth_range":[1,2,4,8,16,32,64,128,256],#queue depth gradient;

[0107] "test_duration_per_qd":300, # Duration of single-queue depth test (seconds);

[0108] "burst_window_config":{# Burst traffic simulation configuration;

[0109] "interval":60,#burst period (seconds);

[0110] "intensity_factor": 3.0, # Traffic multiplication factor;

[0111] Dynamic adjustment rules:

[0112] If the SSD temperature exceeds the threshold (e.g., 85℃), the sequential write ratio will be automatically reduced and the proportion of Trim commands will be increased to trigger garbage collection (GC), simulating a real-world thermal constraint scenario.

[0113] Step 2: Start the multi-threaded load generator, with each thread independently controlling a queue depth.

[0114] Key Algorithm:

[0115] # Define a workload generator function to generate I / O operations under specified namespace, queue depth, and workload ratio;

[0116] def workload_generator(namespace_id, queue_depth, workload_ratio):

[0117] # Create an NVMe I / O queue;

[0118] io_queue= create_io_queue(namespace_id, depth=queue_depth);

[0119] # Repeat the test until the set test duration is reached;

[0120] while not timeout(test_duration_per_qd):

[0121] # Select the I / O type (random read, sequential write, or Trim command) based on the workload ratio;

[0122] io_type=random.choices(["randread","seqwrite","trim"],weights=workload_ratio)[0];

[0123] # Check if you are in a period of sudden traffic surge;

[0124] if in_burst_window():

[0125] # If so, submit a larger I / O request, adjusting the size using a traffic multiplier;

[0126] submit_io(io_type, size=burst_intensity_factor * base_io_size)

[0127] else:

[0128] # Otherwise, submit I / O requests at the normal size;

[0129] submit_io(io_type);

[0130] #Real-time acquisition of latency data (μs-level accuracy);

[0131] latency = measure_command_completion_time(io_queue);

[0132] # Record queue depth, I / O type, and latency data for later analysis;

[0133] log_data(queue_depth, io_type, latency);

[0134] Competition interference factor implementation:

[0135] Actively create resource contention between multiple namespaces:

[0136] / / Intentionally submit conflicting I / O requests at adjacent timestamps;

[0137] for (int i=0; i <active_namespaces; i++) {

[0138] # Submit conflicting Logical Block Address Ranges (LBAs) in each active namespace to simulate resource contention;

[0139] ns_io_queue[i].submit(conflicting_lba_range);

[0140] }

[0141] Figure 3 This is a schematic diagram of an optional resource contention module according to an embodiment of this application, such as... Figure 3 As shown, the design strategy of the resource contention module is as follows: Fixed area: The last 64MB space starting from 0xFFFF0000 is used (all namespaces map to the same physical die); Selection basis: In the internal parallel architecture of SSD, the last area usually corresponds to cross-channel access hotspots. Trim immediately after a conflict to release space (avoid data residue); Limit the amount of conflicting I / O to ≤ 5% of the total load; Skip the SSD reserved area (OP / firmware area); Realism guarantee: Use 10μs intervals to submit to simulate a real contention window, the conflict range covers the intersection area of ​​multiple dies / multiple planes, and namespace-level isolation is ensured by ns_io_queue[i].submit().

[0142] Step 3: Real-time collection of SSD SMART logs and PCIe link layer status. Table 1 is a data collection table according to an embodiment of this application, as shown in Table 1:

[0143] Table 1

[0144]

[0145] In Table 1, bandwidth is used in the performance inflection point detection engine as: an auxiliary dimension when building IOPS-latency curves (marked as a potential bottleneck when bandwidth utilization is >90%) and to identify controller bottlenecks in root cause analysis (e.g., a sudden increase in latency under high bandwidth indicates PCIe channel overload).

[0146] The parameters in Table 1, namely media wear (P / E Cycles), temperature, and number of bad blocks, are used in the root cause analysis after anomaly handling: when the trigger voltage exceeds the tolerance or the bit error rate exceeds the standard, check whether the wear is >80% (if it exceeds the standard, it is marked as "NAND aging leads to increased voltage sensitivity") and the improvement suggestions in the output report are based on (if the wear is high, it will prompt "the deployment load level needs to be reduced").

[0147] Exception handling mechanism:

[0148] If a PCIe bit error rate > 1e is detected -12 If the voltage exceeds the tolerance, the test will be automatically paused and the following actions will be triggered:

[0149] 1. Save the incomplete I / O context of all current queues;

[0150] 2. Generate a hardware error snapshot (including an SSD register dump);

[0151] 3. Switch to Safe Mode and retry with reduced frequency. Refer to Table 2 for details on reducing frequency in Safe Mode:

[0152] Table 2

[0153]

[0154] Step 4: The performance inflection point detection engine outputs a test report (including a recommended optimal queue depth).

[0155] Inflection point identification algorithm:

[0156] 1. Fitting the IOPS-Latency curve: using cubic spline interpolation to smooth the data.

[0157] 2. Calculate the second derivative to find the inflection point:

[0158]

[0159] When |f''(QD)|>α (threshold default 0.5) and the slope change exceeds 30%, it is marked as a performance inflection point.

[0160] The correlation between key parameters in this embodiment is shown in Table 3:

[0161] Table 3

[0162]

[0163] Output report template:

[0164] NVMe SSD Performance Inflection Point Test Report;

[0165] Recommended optimal queue depth: QD64;

[0166] Inflection point: QD128 (latency suddenly increased by 52%);

[0167] Root cause analysis:

[0168] Controller scheduling bottleneck (NS queue switching latency > 80μs).

[0169] Suggestions for improvement:

[0170] Update firmware to v2.1+ (optimize multi-namespace polling algorithm).

[0171] The test report is generated uniformly after all queue depth tests are completed. The design logic is as follows: a complete dataset from QD1 to QD256 (or a set range) needs to be collected. Inflection point detection relies on global curve fitting (across queue depths).

[0172] Triple judgment criteria: Latency priority: Select the 3 points with the lowest latency (e.g., QD32 / 64 / 128); Stability filtering: Exclude points with fluctuation coefficient >15%; Performance verification: Select the QD with the highest IOPS from the remaining points;

[0173] Performance inflection point threshold adjustment mechanism:

[0174] The dynamic threshold system is shown in Table 4:

[0175] Table 4

[0176]

[0177] Calculation formula:

[0178] αadj = 0.5 × nominal durability

[0179] Actual durability × e − 0.05(T − 25) × α × adj = 0.5 Actual durability Nominal durability × e − 0.05(T − 25)

[0180] T: Ambient temperature during testing (°C)

[0181] Practical application: A company's panel with PE=3000 was tested at 60℃;

[0182] α = 0.5 × 5000;

[0183] 3000×e−0.05(60−25)=0.42;

[0184] α = 0.5 × 3000;

[0185] 5000×e−0.05(60−25)=0.42;

[0186] This design ensures that the inflection point detection accuracy remains >95% under different SSD types (SLC / MLC / TLC / QLC) and environmental conditions.

[0187] The above embodiments employ the following key approach: designing a dynamically adjustable hybrid load generation algorithm of "random read / write + sequential read / write + Trim command", the ratio of which can be configured according to the test scenario (e.g., 70% random read + 20% sequential write + 10% Trim).

[0188] By segmenting time windows, we can simulate sudden traffic spikes in business scenarios (such as periodic peaks in database log writes).

[0189] Construct a "queue depth gradient ramping" test process: gradually increase from QD1 to QD256 (the upper limit of the NVMe protocol), continuously test and record IOPS, latency, and bandwidth data for each gradient.

[0190] Introducing a "queue contention interference factor": Intentionally creating queue resource conflicts between multiple NVMe namespaces to verify the fairness of controller scheduling.

[0191] Based on second derivative analysis of the IOPS-latency curve, the system automatically identifies performance inflection points (such as a 50% increase in latency at QD128) and marks them as critical values ​​for the SSD's concurrency capability.

[0192] Figure 4 This is a schematic diagram of an optional testing system according to an embodiment of this application, such as... Figure 4 As shown, it mainly includes the following key modules, which work together to achieve performance evaluation of NVMe SSDs in high-concurrency scenarios: multi-threaded load generator, NVMe protocol analysis module, performance inflection point detection engine, anomaly handling and status monitoring module, and result analysis and report generation module.

[0193] 1. Multi-threaded load generator:

[0194] Functionality: Based on the parameters and configuration of the hybrid load model, generate multiple types of I / O requests, including random reads, sequential writes, and Trim commands, as well as simulate burst traffic. Each thread independently controls a queue depth to simulate a high-concurrency environment.

[0195] Interaction: Receives parameter commands from the dynamic hybrid load model and exchanges data with the NVMe SSD via the PCIe interface. Figure 5 This is a schematic diagram of an optional mixed load time window allocation according to an embodiment of this application, such as... Figure 5 As shown, it records how to dynamically allocate and manage time windows for different types of I / O operations (such as random read, sequential write, Trim command, etc.) to simulate load changes in real application scenarios.

[0196] 2. NVMe Protocol Analysis Module:

[0197] Function: Real-time monitoring and analysis of NVMe SSD performance metrics, such as IOPS, bandwidth, latency distribution, etc., typically at a frequency of 10Hz.

[0198] Interaction: Works synchronously with the multi-threaded load generator, collects data from NVMe SSDs, and feeds the data back to the performance inflection point detection engine and the result analysis and report generation module.

[0199] 3. Performance Kilometer Point Detection Engine:

[0200] Function: Using a mathematical model, it automatically identifies inflection points on the performance curve to determine the critical point of SSD concurrency capability.

[0201] Interaction: Based on the performance data provided by the NVMe protocol analysis module, inflection point analysis is performed, and the results are passed to the result analysis and report generation module.

[0202] 4. Exception handling and status monitoring module:

[0203] Function: It is responsible for real-time monitoring of SSD temperature, power supply fluctuations, SMART logs, PCIe link status, etc. When an anomaly is detected, such as excessively high PCIe bit error rate or excessive voltage, it will trigger the anomaly handling mechanism, including pausing the test, saving hardware snapshots, and switching to safe mode for retry.

[0204] Interaction: Connects directly to the multi-threaded load generator and NVMe SSD, monitors their status, and interrupts or adjusts the load generator's operation when necessary.

[0205] 5. Results Analysis and Report Generation Module:

[0206] Function: Summarizes the analysis results of the performance inflection point detection engine, as well as all performance data collected throughout the testing process, and generates a comprehensive test report, including the recommended optimal queue depth, the location of the performance inflection point, and its cause analysis.

[0207] Interaction: Collaborates with the performance inflection point detection engine, NVMe protocol analysis module, and anomaly handling and status monitoring module to integrate collected data and analysis results, ultimately generating a test report.

[0208] Figure 6 This is an optional test process flowchart according to an embodiment of this application, such as... Figure 6 As shown, the module interactions during the testing process include:

[0209] 1. Test Initialization: The load generator receives test parameter configurations from the dynamic hybrid load model, such as queue depth range, load ratio, and single test duration.

[0210] 2. Load generation and data acquisition: The load generator generates I / O requests according to the configuration, while the NVMe protocol analysis module and the exception handling module start real-time monitoring of performance indicators and SSD status.

[0211] 3. Performance data analysis: The performance inflection point detection engine obtains performance data from the NVMe protocol analysis module and identifies inflection points.

[0212] 4. Anomaly Detection and Handling: When the anomaly is detected, such as excessive temperature or excessive PCIe link bit error rate, the anomaly handling module will immediately pause the load generator and execute the anomaly handling process, including saving the incomplete I / O context and generating a hardware snapshot.

[0213] 5. Results Summary and Report Generation: After the test is completed, the results analysis and report generation module integrates all data, including performance inflection point analysis, anomaly reports and performance indicators, to generate the final test report.

[0214] 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.

[0215] Embodiments of this application also provide a testing apparatus for a storage device. Figure 7 This is a structural block diagram of a testing apparatus for a storage device according to an embodiment of this application, such as... Figure 7 As shown, the device includes:

[0216] The first control module is used to control the storage device under test to execute test tasks at a reference queue depth included in the queue depth set according to the received test request. The test request is used to request the queue depth parameter of the storage device under test, and the running performance of the storage device at the queue depth indicated by the queue depth parameter meets the target performance requirement.

[0217] The first detection module is used to detect the device operation parameters and latency parameters of the storage device under test at the reference queue depth, and obtain the reference queue depth, device operation parameters and latency parameters with corresponding relationships. The device operation parameters are used to indicate the device operation status of the storage device under test during the execution of the test task at the reference queue depth, and the latency parameters are used to indicate the latency of the storage device under test in executing the test task at the reference queue depth.

[0218] The second detection module is used to detect the queue depth parameter of the storage device under test based on the corresponding reference queue depth, device operation parameters and latency parameters, and obtain the target queue depth parameter.

[0219] By configuring a queue depth set for the storage device under test, and then, upon receiving a test request, controlling the storage device to execute test tasks according to the reference queue depths included in the queue depth set, the workload state of the storage device under real-world usage scenarios is simulated. This allows for the detection of device operation parameters and latency parameters at the reference queue depth. Furthermore, by detecting the queue depth parameters of the storage device under test based on the corresponding reference queue parameters, device operation parameters, and latency parameters, the performance of the storage device under test is tested. This method achieves the detection of the queue depth parameters of the storage device under test in a realistic and reliable manner, improving the testing speed and accuracy of storage device performance. Therefore, it solves the technical problem of low testing efficiency for storage device performance in related technologies, achieving the technical effect of improving the testing efficiency of storage device performance.

[0220] Optionally, the first control module includes:

[0221] A receiving unit is configured to receive the test request;

[0222] The first processing unit is configured to respond to the test request, traverse each of the reference queue depths, and repeatedly perform the following operations until all the reference queue depths in the queue depth set have been traversed:

[0223] Create input and output queues according to the reference queue depth currently being traversed;

[0224] Input / output commands are submitted to the input / output queue according to a target ratio until the test duration is reached. The input / output commands include random read commands, sequential write commands, and garbage collection commands. The target ratio indicates the proportion of random read commands, sequential write commands, and garbage collection commands.

[0225] Optionally, the first processing unit is configured to perform at least one of the following operations:

[0226] Create an initial input / output command that conforms to the target ratio; detect whether the current period is within a burst flow window; if the current period is within the burst flow window, expand the scale of the initial input / output command according to the flow multiplication factor to obtain a reference input / output command; submit the reference input / output command to the input / output queue; if the current period is not within the burst flow window, submit the initial input / output command to the input / output queue.

[0227] During the process of submitting input / output commands to the input / output queue according to the target ratio, conflicting input / output commands are submitted to a reference namespace, wherein the reference namespace is different from the namespace of the input / output commands. The conflicting input / output commands are configured to compete for execution resources with the input / output commands. The command size of the conflicting input / output commands is less than a command size threshold. The execution area of ​​the conflicting input / output commands does not include the reserved area in the storage device under test. After executing the conflicting input / output commands, the storage space occupied by the conflicting input / output commands is released.

[0228] While submitting input / output commands to the input / output queue according to the target ratio, the operating temperature of the storage device under test is detected; if the operating temperature is greater than or equal to the temperature threshold, the proportion of sequential write commands in the input / output commands is reduced and the proportion of garbage collection commands is increased.

[0229] Optionally, the second detection module includes:

[0230] A fitting unit is used to fit the corresponding reference queue depth, device operating parameters and latency parameters into a target fitting curve, wherein the target fitting curve is used to indicate the changes in device operating parameters and latency parameters within the queue depth range of the storage device under test;

[0231] The second processing unit is used to identify the performance inflection point in the target fitting curve and determine the optimal queue depth of the storage device under test based on the target fitting curve. The performance inflection point is used to indicate the critical point of the operating performance of the storage device under test within the supported queue depth range. The optimal queue depth is the queue depth at which the storage device under test achieves optimal operating performance. The target queue depth parameter includes the performance inflection point and the optimal queue depth.

[0232] Optionally, the second processing unit is used for:

[0233] Calculate the second derivative of the target fitted curve;

[0234] Based on the second derivative, locate the curve position on the target fitting curve where the second derivative value is greater than the first threshold and the rate of change of slope is greater than the second threshold.

[0235] The queue depth corresponding to the position of the curve within the range of queue depths is determined as the performance inflection point.

[0236] Optionally, the second processing unit is used for:

[0237] Based on the target fitting curve, extract the queue depths that are the first N positions of the queue depth range with the delay parameter arranged in ascending order, to obtain N candidate queue depths, where N is a positive integer;

[0238] The fluctuation coefficient of each candidate queue depth is determined based on the target fitting curve, wherein the fluctuation coefficient is used to indicate the fluctuation of the corresponding delay parameter in the adjacent depth range of the candidate queue depth;

[0239] From the N candidate queue depths, the candidate queue depths whose fluctuation coefficient is less than the coefficient threshold are selected to obtain the reference queue depth;

[0240] The queue depth with the largest corresponding device operation parameter in the reference queue depth is determined as the optimal queue depth.

[0241] Optionally, the device further includes:

[0242] The third detection module is used to detect the bandwidth parameters of the storage device under test during the process of detecting the device operation parameters and latency parameters of the storage device under test at the reference queue depth.

[0243] The identification module is used to identify queue depths from the target fitting curve where the bandwidth parameter is greater than or equal to the bandwidth threshold and the delay parameter is greater than or equal to the delay threshold as scheduling bottlenecks of the controller.

[0244] Optionally, the first detection module includes:

[0245] The detection unit is used to detect the unit operation quantity and latency time of the storage device under test at the reference queue depth, and obtain the reference queue depth, device operation parameters and latency parameters with corresponding relationships. The device operation parameters include the unit operation quantity, and the latency parameters include the latency time. The unit operation quantity is used to indicate the number of input and output operations that the storage device under test is allowed to process per unit time.

[0246] Optionally, the device further includes:

[0247] The fourth detection module is used to detect whether the storage device under test is malfunctioning during the execution of the test task.

[0248] The first processing module is used to save the context of all unfinished device operations in the current queues of the storage device under test when an anomaly is detected in the storage device under test, and to generate a hardware error snapshot of the storage device under test, wherein the hardware error snapshot is used to record the operating information of the storage device under test when an anomaly occurs.

[0249] The second processing module controls the storage device under test to adjust its operating parameters to the target mode and retry the current device operation in the test task, and detects whether the storage device under test passes the current device operation. The target mode includes: a first value decrease in link rate compared to the current link rate, a second value decrease in queue depth limit compared to the current queue depth limit, a third value decrease in power supply voltage compared to the current power supply voltage, and a fourth value decrease in burst traffic in load intensity compared to the current burst traffic.

[0250] The second control module is used to, upon detecting that the storage device under test is operated by the current device, control the operating parameters of the storage device under test to be restored to the operating parameters at the time of the abnormality based on the context and the hardware error snapshot, and continue to execute the test task.

[0251] For a description of the features in the embodiment corresponding to the testing apparatus for the storage device, please refer to the relevant description in the embodiment corresponding to the testing method for the storage device, which will not be repeated here.

[0252] 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 above-described test method embodiments of the storage device.

[0253] 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 the test method embodiments of any of the above-described storage devices when run.

[0254] 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.

[0255] 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 the test method embodiments of any of the above-described storage devices.

[0256] 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 the test method embodiments of any of the above storage devices.

[0257] 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.

[0258] The foregoing has provided a detailed description of a testing method and apparatus for a storage device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. 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 testing method for a storage device, characterized in that, include: The test request controls the storage device under test to execute test tasks at reference queue depths included in the queue depth set. The test request is used to request queue depth parameters of the storage device under test. The performance of the storage device running at the queue depth indicated by the queue depth parameters meets the target performance requirements. The device operation parameters and latency parameters of the storage device under test at the reference queue depth are detected to obtain a corresponding reference queue depth, device operation parameters and latency parameters. The device operation parameters are used to indicate the device operation performed by the storage device under test during the execution of the test task at the reference queue depth, and the latency parameters are used to indicate the latency of the storage device under test in executing the test task at the reference queue depth. The queue depth parameter of the storage device under test is detected based on the corresponding reference queue depth, device operation parameters, and latency parameters to obtain the target queue depth parameter; The step of controlling the storage device under test to execute test tasks at reference queue depths included in the queue depth set according to the received test request includes: receiving the test request; responding to the test request, traversing each of the reference queue depths, and repeatedly performing the following operations until all reference queue depths in the queue depth set have been traversed: creating an input / output queue according to the currently traversed reference queue depth; and submitting input / output commands to the input / output queue according to a target ratio until the test duration is reached, wherein the input / output commands include: random read commands, sequential write commands, and garbage collection commands, and the target ratio is used to indicate the proportion of the random read commands, the sequential write commands, and the garbage collection commands; The step of detecting the queue depth parameter of the storage device under test based on the corresponding reference queue depth, device operating parameters, and latency parameters to obtain the target queue depth parameter includes: fitting the corresponding reference queue depth, device operating parameters, and latency parameters into a target fitting curve, wherein the target fitting curve is used to indicate the changes in device operating parameters and latency parameters within the queue depth range of the storage device under test; identifying the performance inflection point in the target fitting curve, and determining the optimal queue depth of the storage device under test based on the target fitting curve, wherein the performance inflection point is used to indicate the critical point of the operational performance of the storage device under test within the supported queue depth range, and the optimal queue depth is the queue depth at which the storage device under test achieves optimal operational performance; the target queue depth parameter includes: the performance inflection point and the optimal queue depth. The method further includes: during the execution of the test task by the storage device under test, detecting whether the storage device under test has encountered an anomaly; if an anomaly is detected, saving the context of all unfinished device operations in the current queues on the storage device under test, and generating a hardware error snapshot of the storage device under test, wherein the hardware error snapshot is used to record the operating information of the storage device under test under the condition of an anomaly; controlling the storage device under test to adjust its operating parameters to a target mode to retry the current device operation in the test task, and detecting whether the storage device under test passes the current device operation, wherein the target mode includes: a first magnitude decrease in link rate compared to the current link rate, a second magnitude decrease in queue depth limit compared to the current queue depth limit, a third magnitude decrease in power supply voltage compared to the current power supply voltage, and a fourth magnitude decrease in burst traffic in load intensity compared to the current burst traffic; if the storage device under test is detected to have passed the current device operation, controlling the operating parameters of the storage device under test to be restored to the operating parameters when the anomaly occurred according to the context and the hardware error snapshot, and continuing to execute the test task.

2. The testing method for the storage device according to claim 1, characterized in that, The step of submitting input / output commands to the input / output queue according to the target ratio includes at least one of the following: Create initial input / output commands that conform to the target ratio; detect whether the current period is within a burst flow window; if the current period is within the burst flow window, expand the scale of the initial input / output commands according to the flow multiplication factor to obtain reference input / output commands; Submit the reference input / output command to the input / output queue; If it is detected that the current period is not within the burst flow window, the initial input / output command is submitted to the input / output queue; During the process of submitting input / output commands to the input / output queue according to the target ratio, conflicting input / output commands are submitted to a reference namespace, wherein the reference namespace is different from the namespace of the input / output commands. The conflicting input / output commands are configured to compete for execution resources with the input / output commands. The command size of the conflicting input / output commands is less than a command size threshold. The execution area of ​​the conflicting input / output commands does not include the reserved area in the storage device under test. After executing the conflicting input / output commands, the storage space occupied by the conflicting input / output commands is released. While submitting input / output commands to the input / output queue according to the target ratio, the operating temperature of the storage device under test is detected; if the operating temperature is greater than or equal to the temperature threshold, the proportion of sequential write commands in the input / output commands is reduced and the proportion of garbage collection commands is increased.

3. The testing method for the storage device according to claim 1, characterized in that, The identification of the performance inflection point in the target fitting curve includes: Calculate the second derivative of the target fitted curve; Based on the second derivative, locate the curve position on the target fitting curve where the second derivative value is greater than the first threshold and the rate of change of slope is greater than the second threshold. The queue depth corresponding to the position of the curve within the range of queue depths is determined as the performance inflection point.

4. The testing method for the storage device according to claim 1, characterized in that, Determining the optimal queue depth of the storage device under test based on the target fitting curve includes: Based on the target fitting curve, extract the queue depths that are the first N positions of the queue depth range with the delay parameter arranged in ascending order, to obtain N candidate queue depths, where N is a positive integer; The fluctuation coefficient of each candidate queue depth is determined based on the target fitting curve, wherein the fluctuation coefficient is used to indicate the fluctuation of the corresponding delay parameter in the adjacent depth range of the candidate queue depth; From the N candidate queue depths, the candidate queue depths whose fluctuation coefficient is less than the coefficient threshold are selected to obtain the reference queue depth; The queue depth with the largest corresponding device operation parameter in the reference queue depth is determined as the optimal queue depth.

5. The testing method for a storage device according to claim 1, characterized in that, The method further includes: During the process of detecting the device operation parameters and latency parameters of the storage device under test at the reference queue depth, the bandwidth parameters of the storage device under test are detected. The queue depths in the target fitting curves where the bandwidth parameter is greater than or equal to the bandwidth threshold and the delay parameter is greater than or equal to the delay threshold are identified as scheduling bottlenecks for the controller.

6. The testing method for a storage device according to claim 1, characterized in that, The step of detecting the device operation parameters and latency parameters of the storage device under test at the reference queue depth to obtain the corresponding reference queue depth, device operation parameters, and latency parameters includes: The unit operation quantity and latency of the storage device under test at the reference queue depth are detected to obtain the corresponding reference queue depth, device operation parameters and latency parameters. The device operation parameters include the unit operation quantity, and the latency parameters include the latency time. The unit operation quantity is used to indicate the number of input and output operations that the storage device under test is allowed to process per unit time.

7. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the test method for the storage device as described in any one of claims 1 to 6 when executing the computer program.

Images