Testing method and device for storage equipment

Abstract

The invention discloses a test method and device for a storage device, and relates to the technical field of storage device testing, and the method comprises the steps: controlling a to-be-tested storage device to execute a test task under a reference queue depth included in a queue depth set according to a received test request; detecting an equipment operation parameter and a delay parameter of the to-be-detected storage equipment under the reference queue depth to obtain the reference queue depth, the equipment operation parameter and the delay parameter which have a corresponding relation; detecting a queue depth parameter of the to-be-tested storage device according to the reference queue depth, the device operation parameter and the delay parameter which have the corresponding relation to obtain a target queue depth parameter, and solving the technical problem that the test efficiency of the operation performance of the storage device is relatively low in the related technology. The technical effect of improving the test efficiency of the operation performance of the storage device is achieved.

Description

Technical Field

[0001] The present application relates to the technical field of storage device testing, and in particular to a storage device testing method and apparatus. Background Art

[0002] In recent years, with the surge in data processing demands, storage systems are facing unprecedented challenges. Deploying storage devices addresses data storage needs in application scenarios. Furthermore, to better ensure the data storage efficiency of storage devices in application scenarios, it is often necessary to test the operating performance of storage devices to ensure that they can meet the requirements of high-performance storage in actual deployment scenarios. Related technologies often use fixed queue depth testing to determine the operating performance of storage devices by collecting test data at this queue depth. However, this test queue depth often fails to reflect the actual performance of storage devices under complex workloads, resulting in low efficiency in testing the operating performance of storage devices. Summary of the Invention

[0003] The present application provides a method and apparatus for testing a storage device, so as to at least solve the technical problem of low efficiency in testing the operating performance of a storage device in the related art.

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

[0005] Controlling the storage device under test to execute a test task at a reference queue depth included in a queue depth set according to a received test request, wherein the test request is used to request testing a queue depth parameter of the storage device under test, and the operating performance of the storage device operating at the queue depth indicated by the queue depth parameter meets a target performance requirement;

[0006] Detecting device operation parameters and delay parameters of the storage device under test at the reference queue depth, and obtaining corresponding reference queue depth, device operation parameters, and delay parameters, wherein the device operation parameters are used to indicate a condition in which the storage device under test performs a device operation during execution of the test task at the reference queue depth, and the delay parameters are used to indicate a delay condition in which the storage device under test performs the test task at the reference queue depth;

[0007] The queue depth parameter of the storage device to be tested is detected according to the reference queue depth, device operating parameter and delay parameter having a corresponding relationship, and a target queue depth parameter is obtained.

[0008] The present application also provides a storage device testing device, comprising:

[0009] A first control module is configured to control the storage device under test to execute a test task at a reference queue depth included in a queue depth set according to a received test request, wherein the test request is used to request testing a queue depth parameter of the storage device under test, and the operating performance of the storage device operating at the queue depth indicated by the queue depth parameter meets a target performance requirement;

[0010] a first detection module, configured to detect device operation parameters and delay parameters of the storage device under test at the reference queue depth, and obtain a corresponding reference queue depth, device operation parameters, and delay parameters, wherein the device operation parameters are used to indicate a condition in which the storage device under test performs a device operation during execution of the test task at the reference queue depth, and the delay parameters are used to indicate a delay in the storage device under test performing 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 to be tested according to the reference queue depth, device operating parameter and delay parameter having a corresponding relationship, and obtain a target queue depth parameter.

[0012] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned storage device testing methods when executing the computer program.

[0013] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned storage device testing methods are implemented.

[0014] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned storage device testing methods when executed by a processor.

[0015] Through the present application, by configuring a queue depth set for a storage device to be tested, and then, after receiving a test request, controlling the storage device to be tested to execute a test task according to a reference queue depth included in the queue depth set, the workload state of the storage device in a real usage scenario is simulated, and the device operating parameters and latency parameters at the reference queue depth are detected. The operating performance of the storage device to be tested is tested by detecting the queue depth parameter of the storage device to be tested based on the corresponding reference queue parameters, device operating parameters, and latency parameters, thereby simulating the real and reliable workload state of the device to be tested, thereby improving the test rate of the storage device operating performance and the accuracy of the test results. Therefore, the technical problem of low efficiency in testing the operating performance of storage devices in the related art can be solved, and the technical effect of improving the testing efficiency of the operating performance of storage devices can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

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

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

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

[0020] Figure 4 is a schematic diagram of an optional test system according to an embodiment of the present application;

[0021] Figure 5 is a schematic diagram of an optional mixed load time window allocation according to an embodiment of the present application;

[0022] Figure 6 is an optional test process flow chart according to an embodiment of the present application;

[0023] Figure 7 This is a structural block diagram of a storage device testing apparatus according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

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

[0026] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0027] In conjunction with the specific application environment architecture or specific hardware architecture on which the execution of the storage device testing method depends, the specific application environment architecture or specific hardware architecture is described herein.

[0028] The method embodiments provided in the embodiments of the present application can be executed in a server device or a similar computing device. Taking running on a server device as an example, Figure 1 : is a hardware structure diagram of the test method of the storage device of the embodiment of the present application. Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown) a processor 102 (the processor 102 may include but is not limited to a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. The server device may also include a transmission device 106 and an input / output device 108 for communication functions. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above server device. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0029] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the test method of the storage device in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above-mentioned method. The memory 104 may include a high-speed random access memory, and may also include a 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 a memory remotely located relative to the processor 102, and these remote memories may be connected to a server device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0030] Transmission device 106 is used to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by a communication provider of the server device. In one embodiment, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0031] An embodiment of the present application provides a method for testing a storage device, and the method is described in detail in conjunction with the execution flow of the method for testing a storage device.

[0032] In this embodiment, a method for testing a storage device is provided. Figure 2 is a flow chart of a method for testing a storage device according to an embodiment of the present application. Figure 2 As shown, the method includes the following steps:

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

[0034] Step S204: detecting device operation parameters and delay parameters of the storage device under test at the reference queue depth, and obtaining corresponding reference queue depth, device operation parameters, and delay parameters, wherein the device operation parameters are used to indicate a condition of device operation performed by the storage device under test during execution of the test task at the reference queue depth, and the delay parameters are used to indicate a delay condition of the storage device under test in executing the test task at the reference queue depth;

[0035] Step S206 , detecting a queue depth parameter of the storage device to be tested according to the reference queue depth, device operating parameter, and delay parameter having a corresponding relationship, and obtaining a target queue depth parameter.

[0036] Through the above steps, by configuring a queue depth set for the storage device to be tested, and then after receiving a test request, by controlling the storage device to be tested to execute a test task according to the reference queue depth included in the queue depth set, the workload state of the storage device in a real usage scenario is simulated, and the device operating parameters and latency parameters under the reference queue depth are detected. Then, the operating performance of the storage device to be tested is tested by detecting the queue depth parameter of the storage device to be tested based on the corresponding reference queue parameters, device operating parameters, and latency parameters, thereby achieving the detection of the queue depth parameter of the storage device to be tested in a manner that simulates the real and reliable workload state of the device to be tested, thereby improving the test rate of the storage device operating performance and the accuracy of the test results. Therefore, the technical problem of low efficiency in testing the operating performance of storage devices in the related art can be solved, and the technical effect of improving the testing efficiency of the operating performance of storage devices can be achieved.

[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, non-volatile memory host controller interface specification) protocol, and the storage device may be, but is not limited to, an SSD (Solid State Drive, solid-state drive).

[0038] Optionally, in an embodiment of the present application, queue depth refers to the number of IO requests to be executed on the storage device to be tested. The queue depth set records multiple reference queue depths within the queue depth range supported by the storage device to be tested. The multiple reference queue depths can be multiple queue depths distributed sequentially within the queue depth range, or can also be multiple queue depths distributed sequentially within the queue depth range according to a target queue depth gradient. The purpose of setting the queue depth set in the present application is to reflect the actual 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 an appropriate 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 an embodiment of the present application, the target queue gradient can be a fixed value set based on experience, or can also be generated for the current storage device to be tested based on the device information of the storage device, that is, the queue depth set of the storage device to be tested can be constructed in the following manner: generating a target queue gradient for the storage device to be tested based on the target device information of the storage device to be tested, wherein the target device information is a parameter used to characterize the data storage properties of the storage device to be tested, 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.; dividing the queue depth range supported by the storage device to be tested into multiple reference queue depths according to the target queue gradient, and determining the multiple reference queue depths as the queue depth set. Further generating a target queue gradient of the storage device under test based on the device information of the storage device under test includes: calling a target conversion model to convert an initial queue gradient corresponding to the target device information, wherein the target conversion model records the conversion relationship between device information and queue gradient; dividing a plurality of initial queue depths from the queue depth range supported by the storage device under test according to the initial queue gradient; detecting the initial device operating parameters and initial delay parameters of the storage device under test at the initial queue depth, and obtaining the initial queue depth, initial device operating parameters and initial delay parameters having a corresponding relationship, wherein the initial device operating parameters are used to indicate the initial queue depth of the storage device under test. The storage device performs device operations during the process of executing the test task at the initial queue depth, and the initial delay parameter is used to indicate the delay of the storage device to be tested in executing the test task at the initial queue depth; the initial queue depth, initial device operation parameters and initial delay parameters with corresponding relationships are fitted into an initial fitting curve, wherein the initial fitting curve is used to indicate the changes in the initial device operation parameters and initial delay parameters within the queue depth range of the storage device to be tested; 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 change information to obtain the target queue gradient. In the above embodiment, the queue gradient is dynamically adjusted by using the results of multiple rounds of tests to configure an accurate target queue gradient for the storage device to be tested, so that the reference storage queue with the target queue gradient can better reflect the changing state of the operating performance of the storage device to be tested.

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

[0041] Optionally, in embodiments of the present application, the queue depth parameter may be, but is not limited to, a performance inflection point at which the storage device's operating performance at a certain queue depth is achieved. This refers to a point at which a storage device's operating performance indicator (such as throughput, response time, IOPS, etc.) experiences a significant decline or a sharp slowdown in its growth rate as a certain influencing factor (such as load, queue depth, or concurrency) gradually increases. This inflection point indicates that the storage device has reached its performance limit or bottleneck, and further increases in the queue depth will no longer improve performance and may even worsen it.

[0042] Optionally, in an embodiment of the present application, operational performance is used to indicate the ability of a storage device to execute data input and output commands. The operational performance may include, but is not limited to, data access latency, data read and write rates, and the like. For example, when the data access latency is less than or equal to a target latency threshold, it can be determined that the operational performance of the storage device meets the target performance requirement. When the data read and write rate is greater than or equal to a target rate threshold, it can be determined that the operational performance of the storage device meets the target performance requirement. In the present application, the optimal queue depth of the storage device is obtained by testing the queue depth parameter of the storage device under test, so that the storage device maximizes the execution efficiency of data input and output tasks. Subsequently, in the application of the storage device, data access tasks can be configured for the storage device based on the detected queue depth parameter, thereby improving the data storage efficiency of the storage device in the application scenario.

[0043] In the embodiment provided in step S204, the device operating parameter may include, but is 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), indicating the number of read and write operations per second.

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

[0045] In the embodiment provided in step S206, the target queue depth parameter can be, but is not limited to, obtained by identifying and converting a reference queue depth, device operating parameters, and delay parameters having a corresponding relationship using a target conversion model, wherein the target conversion model records the conversion relationship between the queue depth, device operating parameters, delay parameters, and queue depth parameters having a corresponding relationship.

[0046] Optionally, in an embodiment of the present application, the target queue depth parameter can be, but is not limited to, a target fitting curve fitted using a corresponding reference queue depth, device operating parameters, and delay parameters, wherein the target fitting curve is used to indicate changes in device operating parameters and delay parameters within the queue depth range of the storage device to be tested, and then a performance inflection point is identified from the target fitting curve, wherein the performance inflection point is used to indicate a critical point of the operating performance of the storage device to be tested within the supported queue depth range; according to the operating performance of the storage device indicated by the performance inflection point of the reference queue depth, a queue depth whose operating performance meets the target operating performance requirement is screened from multiple reference queues as the target queue depth parameter.

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

[0048] receiving the test request;

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

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

[0051] Submit input and output commands to the input and output queue according to the target ratio until the test duration is reached, wherein the input and 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.

[0052] Optionally, in an embodiment of the present application, test tasks with multiple reference queue depths may be, but are not limited to, test tasks executed concurrently by a multi-threaded load generator, i.e., the multi-threaded load generator includes multiple load generators that generate test tasks according to the task load indicated by the reference queue depth, each load generator being used to execute a test task with a reference queue depth. By concurrently executing test tasks with multiple reference queue depths, the concurrent pressure of 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 of multiple queues. Optionally, in an embodiment of the present application, 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 distribution 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 to be tested; I / O submission: the submit_io() method processes command issuance; resource contention: calling the conflict LBA submission logic in the load generator.

[0053] Optionally, in an embodiment of the present application, the target ratio is the proportion of random read commands, sequential write commands, and the garbage collection command in the input and output queue. This ratio can affect the execution state of the storage device for the input and output queue tasks, that is, input and output queues with different target ratios have different resource consumption on the storage device, and therefore the execution efficiency of the input and output queue tasks is also different. In an embodiment of the present application, the target ratio can be a fixed value configured based on historical experience, or in order to better test the operating performance of the storage device under test, the ratio of multiple command types can be dynamically adjusted according to the device operating parameters of the storage device when executing the input and output queue. The specific method can be: detecting the device operating parameters of the storage device under test during the execution of the test task of the target input and output queue within the target adjustment period, wherein the device operating parameters are used to indicate the resource consumption of the storage device under test during the execution of the test task (the device operating parameters can 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 proportional adjustment amount corresponding to the device operating parameter; adjusting the initial ratio according to the proportional adjustment amount to obtain the target ratio, wherein the target input and output queue is the test queue configured according to the target ratio.

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

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

[0056] Creating an initial input / output command that meets the target ratio; detecting whether the current flow is in a burst traffic window; if it is detected that the current flow is in the burst traffic window, expanding the scale of the initial input / output command according to the traffic multiplication factor to obtain a reference input / output command; submitting the reference input / output command to the input / output queue; if it is detected that the current flow is not in the burst traffic window, submitting the initial input / output command to the input / output queue;

[0057] In a process of submitting input / output commands to the input / output queue according to a target ratio, submitting a conflicting input / output command to a reference namespace, wherein the reference namespace is different from a namespace of the input / output command, the conflicting input / output command is configured to compete with the input / output command for execution resources, a command volume of the conflicting input / output command is less than a command volume threshold, and an execution area of ​​the conflicting input / output command does not include a reserved area in the storage device under test; and releasing the storage space occupied by the conflicting input / output command after executing the conflicting input / output command.

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

[0059] Optionally, in an embodiment of the present application, burst traffic refers to a number of input / output commands that appear instantaneously in an input / output command queue, which is greater than the number of input / output commands. This command volume 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 a storage device processing high-concurrency input / output commands under extreme conditions is simulated within the burst traffic window.

[0060] Optionally, in an embodiment of the present application, the traffic multiplication coefficient is an extended parameter for expanding the number of commands on the input and output command queue. By expanding the initial input and output command scale on the input and output queue by the traffic multiplication coefficient, the execution scenario of high-concurrency commands by the storage device is simulated.

[0061] Optionally, in an embodiment of the present application, the purpose of submitting conflicting input and output commands to the reference command space is to simulate the resource contention state during the operation of the storage device, thereby deliberately creating queue resource conflicts in multiple NVMe namespaces and verifying the fairness of controller scheduling.

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

[0063] Optionally, in an embodiment of the present application, the command threshold can be, but is not limited to, set based on the total load quantity, and the command threshold can be set based on the target percentage of the total load quantity, such as setting 5% of the total load of the storage device as the command threshold.

[0064] Optionally, in the embodiment of the present application, 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 critical is the physical properties of semiconductors—when the temperature exceeds 85°C, the charge leakage rate of NAND flash memory cells increases exponentially. Using the Arrhenius equation to explain this, the failure rate doubles for every 10°C increase in temperature. When the temperature exceeds the limit, we use nonlinear proportional adjustment: the sequential write load decays according to the S-shaped curve (in the formula, ) to achieve a smooth transition), which can reduce the amount of writing by up to 50%; the Trim command increases the amount of writing by a super-linear , up to 30% improvement. For example, at 90°C, the original ratio of [60%, 30%, 10%] becomes [68%, 15%, 17%]. This design is more in line with thermodynamics than simple linear adjustment—rapidly reducing pressure initially and avoiding excessive reduction later that could affect test integrity.

[0065] Through the above, the introduction of the concept of burst traffic windows enhances the realism and complexity of the test. 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, the 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 performance of the storage device under extreme conditions, especially when facing hot spots and temperature restrictions.

[0066] As an optional implementation manner, detecting the queue depth parameter of the storage device to be tested based on the corresponding reference queue depth, device operating parameter, and latency parameter to obtain a target queue depth parameter includes:

[0067] Fitting the reference queue depth, device operating parameters, and delay parameters having corresponding relationships into a target fitting curve, wherein the target fitting curve is used to indicate changes in the device operating parameters and delay parameters within the queue depth range of the storage device under test;

[0068] Identify a performance inflection point in the target fitting curve, and determine an optimal queue depth for the storage device under test based on the target fitting curve, wherein the performance inflection point is used to indicate a critical point of the operating performance of the storage device under test within a supported queue depth range, the optimal queue depth is the queue depth at which the storage device under test achieves optimal operating performance, and the target queue depth parameters include: the performance inflection point and the optimal queue depth.

[0069] Optionally, in this embodiment of the present application, a performance inflection point refers to a point during a storage device performance test where, as a certain influencing factor (such as load, queue depth, or concurrency) gradually increases, the storage device's operating performance indicators (such as throughput, response time, IOPS, etc.) experience a period of growth before significantly declining, or a sharp slowdown in growth. This inflection point indicates that the storage device has reached its performance limit or bottleneck, and further increases in the influencing factor will no longer improve performance and may even worsen it.

[0070] Optionally, in the embodiment of the present application, the device operating parameter and delay parameter curves at each reference queue depth may be fitted by, but not limited to, a method of smoothing data using cubic spline differences.

[0071] Optionally, in an embodiment of the present application, the performance inflection point in the target fitting curve can be found by calculating the second-order derivative based on the optimal queue depth removed from the top of the target fitting curve. The formula is as follows: f′′(QD)=Δ2LatencyΔQD2f′′(QD)=ΔQD2Δ2Latency; where Latency is the delay parameter and QD is the reference queue depth. When |f′′(QD)|>α (the default threshold is 0.5) and the slope changes by more than 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 uses 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 a curve, the relationship between queue depth and performance metrics can be intuitively demonstrated, allowing the device's performance stability and optimal operating point to be determined under high concurrency. The techniques in this embodiment can provide users with scientifically-defined queue depth setting recommendations, avoiding performance losses caused by improper queue depth settings.

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

[0074] Calculating the second derivative of the target fitting curve;

[0075] Locating, on the target fitting curve according to the second-order derivative, a curve position where the second-order derivative value is greater than a first threshold and the slope change rate is greater than a second threshold;

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

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

[0078] As an optional implementation manner, determining the optimal queue depth of the storage device to be tested according to the target fitting curve includes:

[0079] Extracting the queue depths of the first N positions of the delay parameter from the queue depth range according to the target fitting curve and arranging them from smallest to largest to obtain N candidate queue depths, where N is a positive integer;

[0080] Determining a fluctuation coefficient of each candidate queue depth according to the target fitting curve, wherein the fluctuation coefficient is used to indicate a fluctuation of the corresponding delay parameter within a range of adjacent depths of the candidate queue depth;

[0081] Filtering the candidate queue depth whose fluctuation coefficient is less than a coefficient threshold from the N candidate queue depths to obtain a reference queue depth;

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

[0083] Optionally, in this embodiment of the present application, the optimal queue depth is determined based on a triple-criteria approach, namely latency priority, stability filtering, and performance verification. For example, latency priority selects the three points with the lowest latency (e.g., QD32 / 64 / 128); stability filtering excludes points with a fluctuation coefficient greater than 15%; and performance verification selects the QD with the highest IOPS among the remaining points.

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

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

[0086] In the process of detecting the device operating parameters and latency parameters of the storage device under test at the reference queue depth, detecting the bandwidth parameters of the storage device under test;

[0087] A queue depth at which the bandwidth parameter is greater than or equal to a bandwidth threshold and the delay parameter is greater than or equal to a delay threshold is identified from the target fitting curve as a scheduling bottleneck point of the controller.

[0088] This embodiment expands the scope of performance testing by monitoring bandwidth parameters, facilitating a more comprehensive assessment of storage device performance bottlenecks. Bandwidth parameters reflect the data transfer speed of a storage device. Combined with latency parameters, they can reveal scheduling efficiency issues in high-concurrency scenarios. The techniques in this embodiment can help users identify storage device scheduling bottlenecks, providing guidance for subsequent performance optimization.

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

[0090] Detecting the unit operation amount and delay time of the storage device under test at the reference queue depth to obtain a corresponding reference queue depth, device operation parameters, and delay parameters, wherein the device operation parameters include the unit operation amount, the delay parameters include the delay time, and the unit operation amount is used to indicate the number of input and output operations that the storage device under test is allowed to process within a unit time.

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

[0092] During the process of the storage device under test executing the test task, detecting whether the storage device under test has an abnormality;

[0093] When an abnormality is detected in the storage device under test, the context of unfinished device operations in all current queues on the storage device under test is saved, and a hardware error snapshot of the storage device under test is generated, wherein the hardware error snapshot is used to record operation information of the storage device under test when the abnormality occurs;

[0094] Controlling the storage device under test to adjust 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 PCIe rate reduced by a first magnitude compared to a current PCIe rate, a queue depth upper limit reduced by a second magnitude compared to a current queue depth upper limit, a power supply voltage reduced by a third magnitude compared to a current power supply voltage, and a burst flow in load intensity reduced by a fourth magnitude compared to a current burst flow;

[0095] When it is detected that the storage device under test is operating through the current device, the operating parameters of the storage device under test are controlled to be restored to the operating parameters when the abnormality occurred according to the context and the hardware error snapshot, and the test task is continued.

[0096] Optionally, in an embodiment of the present application, the link rate may be, but is not limited to, a PCIe link rate.

[0097] This embodiment of the application designs a hybrid random / sequential read / write test model for high-performance storage devices to simulate the latency and throughput limits in high-concurrency scenarios. The test system consists of a hardware environment and software processes.

[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 (monitors 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, and 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, #Single queue depth test duration (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 a threshold (such as 85°C), the sequential write ratio is automatically reduced and the Trim command ratio is increased to trigger garbage collection (GC), simulating a real-world heat dissipation constraint scenario.

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

[0114] Key algorithms:

[0115] # Define a workload generator function to generate I / O operations under the 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] # Loop 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 whether it is in the burst traffic window;

[0124] if in_burst_window():

[0125] # If yes, submit a larger I / O request and adjust the size using the traffic multiplier;

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

[0127] else:

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

[0129] submit_io(io_type);

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

[0131] latency = measure_command_completion_time(io_queue);

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

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

[0134] Competitive 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 the 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 is a schematic diagram of an optional resource contention module according to an embodiment of the present application, such as Figure 3 As shown, the resource contention module's design strategy is as follows: A fixed region is used: the tail 64MB of space starting at 0xFFFF0000 (all namespaces map to the same physical die); selection is based on the fact that in the SSD's internal parallel architecture, the tail region often corresponds to cross-channel access hotspots. Immediately trimming frees up space after conflicting operations (to prevent data carryover); limiting conflicting I / O volume to ≤ 5% of the total load; skipping SSD reserved areas (OP / firmware areas); and ensuring authenticity: using a 10μs submission interval to simulate a realistic contention window, with the conflict range covering the intersection of multiple dies and planes. Namespace-level isolation is ensured through ns_io_queue[i].submit().

[0142] Step 3: Collect the SMART log and PCIe link layer status of the SSD in real time. Table 1 is a data collection table according to an embodiment of the present application, as shown in Table 1:

[0143] Table 1

[0144]

[0145] The bandwidth in Table 1 is used in the performance inflection point detection engine as follows: as an auxiliary dimension when constructing IOPS-latency curves (marking potential bottlenecks when bandwidth utilization exceeds 90%) and identifying controller bottlenecks in root cause analysis (for example, a sudden increase in latency at high bandwidth indicates PCIe channel overload).

[0146] The parameters in Table 1, including media wear (P / E cycles), temperature, and bad block count, are used in root cause analysis after exception handling. When the trigger voltage is out of tolerance or the bit error rate exceeds the standard, the report checks whether the wear level is > 80%. If so, it is marked as "NAND aging causes increased voltage sensitivity." Improvement suggestions are provided in the output report (high wear levels indicate a need to reduce deployment load levels).

[0147] Exception handling mechanism:

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

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

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

[0151] 3. Switch to safe mode and reduce the frequency to try again. For safe mode frequency reduction, refer to Table 2:

[0152] Table 2

[0153]

[0154] Step 4: The performance inflection point detection engine outputs a test report (including the 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-order derivative to find the inflection point:

[0158]

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

[0160] The correlation relationship of 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 increases by 52%);

[0167] Root Cause Analysis:

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

[0169] Improvement suggestions:

[0170] Updated firmware to v2.1+ (optimized 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 data set from QD1 to QD256 (or a set range) must be collected. Inflection point detection relies on global curve fitting (across queue depths).

[0172] Triple judgment criteria: Latency priority: select the three points with the lowest latency (such as QD32 / 64 / 128); Stability filtering: exclude points with a fluctuation coefficient >15%; Performance verification: select the QD with the highest IOPS among 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: Test environment temperature (℃)

[0181] Practical application: When a corporate disk with PE=3000 is 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% across different SSD types (SLC / MLC / TLC / QLC) and environmental conditions.

[0187] The above embodiment adopts the following key measures: designing a dynamically adjustable "random read and write + sequential read and write + Trim command" mixed load generation algorithm, the ratio of which can be configured according to the test scenario (such as 70% random read + 20% sequential write + 10% Trim).

[0188] By splitting the time window, we can simulate the burst traffic of business scenarios (such as the periodic peak of database log writing).

[0189] Build a "queue depth gradient climbing" test process: gradually increase from QD1 to QD256 (the upper limit of the NVMe protocol), and 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 controller scheduling fairness.

[0191] IOPS-latency curves are analyzed based on second-order derivatives to automatically identify performance inflection points (such as a 50% latency increase at QD128) and mark them as the critical value of the SSD's concurrency capability.

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

[0193] 1. Multi-threaded load generator:

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

[0195] Interaction: Receives parameter instructions from the dynamic mixed load model and exchanges data with the NVMe SSD through the PCIe interface. Figure 5 is an optional hybrid load time window allocation diagram according to an embodiment of the present application, such as Figure 5 As shown in the figure, it records how to dynamically allocate and manage time windows for different types of IO operations (such as random reads, sequential writes, Trim commands, 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 indicators such as IOPS, bandwidth, and latency distribution, typically at a frequency of 10Hz.

[0198] Interaction: Works synchronously with the multi-threaded load generator to collect 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 inflection point detection engine:

[0200] Function: Uses a mathematical model to automatically identify the inflection point on the performance curve to determine the critical point of the SSD's concurrency capability.

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

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

[0203] Function: Responsible for real-time monitoring of SSD temperature, power supply fluctuations, SMART logs, PCIe link status, etc. When an anomaly is detected, such as a high PCIe bit error rate or voltage tolerance, it triggers an exception handling mechanism, including pausing the test, saving a hardware snapshot, and switching to safe mode for retrying.

[0204] Interaction: Directly connects to multi-threaded load generators and NVMe SSDs, monitors their status, and interrupts or adjusts the load generator's work when necessary.

[0205] 5. Result analysis and report generation module:

[0206] Function: This function aggregates the analysis results of the performance inflection point detection engine and all performance data collected during the entire test process to generate 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 exception handling and status monitoring module to integrate collected data and analysis results and ultimately generate a test report.

[0208] Figure 6 This is an optional test process flow chart according to an embodiment of the present application, such as Figure 6 As shown, the module interactions during the test process include:

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

[0210] 2. Load generation and data collection: The load generator generates I / O requests according to the configuration. At the same time, the NVMe protocol analysis module and exception handling module begin to monitor performance indicators and SSD status in real time.

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

[0212] 4. Anomaly detection and handling: When the anomaly handling module detects an anomaly, such as excessive temperature or excessive PCIe link bit error rate, it immediately pauses the load generator and executes the anomaly handling process, including saving unfinished I / O context and generating a hardware snapshot.

[0213] 5. Result summary and report generation: After the test is completed, the result analysis and report generation module integrates all data, including performance inflection point analysis, exception reports and performance indicators, to generate the final test report.

[0214] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0215] The embodiment of the present application also provides a testing device for a storage device, Figure 7 is a structural block diagram of a test device for a storage device according to an embodiment of the present application, such as Figure 7 As shown, the device includes:

[0216] A first control module is configured to control the storage device under test to execute a test task at a reference queue depth included in a queue depth set according to a received test request, wherein the test request is used to request testing a queue depth parameter of the storage device under test, and the operating performance of the storage device operating at the queue depth indicated by the queue depth parameter meets a target performance requirement;

[0217] a first detection module, configured to detect device operation parameters and delay parameters of the storage device under test at the reference queue depth, and obtain a corresponding reference queue depth, device operation parameters, and delay parameters, wherein the device operation parameters are used to indicate a condition in which the storage device under test performs a device operation during execution of the test task at the reference queue depth, and the delay parameters are used to indicate a delay in the storage device under test performing 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 to be tested according to the reference queue depth, device operating parameter and delay parameter having a corresponding relationship, and obtain a target queue depth parameter.

[0219] By configuring a queue depth set for a storage device to be tested, and then, upon receiving a test request, controlling the storage device to be tested to execute a test task according to a reference queue depth included in the queue depth set, the workload state of the storage device in a real usage scenario is simulated, and the device operating parameters and latency parameters at the reference queue depth are detected. Furthermore, the operating performance of the storage device to be tested is tested by detecting the queue depth parameter of the storage device to be tested based on the corresponding reference queue parameters, device operating parameters, and latency parameters, thereby simulating the real and reliable workload state of the device to be tested, thereby improving the test rate of the storage device operating performance and the accuracy of the test results. Therefore, the technical problem of low efficiency in testing the operating performance of storage devices in the related art can be solved, and the technical effect of improving the testing efficiency of the operating performance of storage devices can be achieved.

[0220] Optionally, the first control module includes:

[0221] A receiving unit, 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 are traversed:

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

[0224] Submit input and output commands to the input and output queue according to the target ratio until the test duration is reached, wherein the input and 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.

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

[0226] Creating an initial input / output command that meets the target ratio; detecting whether the current flow is in a burst traffic window; if it is detected that the current flow is in the burst traffic window, expanding the scale of the initial input / output command according to the traffic multiplication factor to obtain a reference input / output command; submitting the reference input / output command to the input / output queue; if it is detected that the current flow is not in the burst traffic window, submitting the initial input / output command to the input / output queue;

[0227] In a process of submitting input / output commands to the input / output queue according to a target ratio, submitting a conflicting input / output command to a reference namespace, wherein the reference namespace is different from a namespace of the input / output command, the conflicting input / output command is configured to compete with the input / output command for execution resources, a command volume of the conflicting input / output command is less than a command volume threshold, and an execution area of ​​the conflicting input / output command does not include a reserved area in the storage device under test; and releasing the storage space occupied by the conflicting input / output command after executing the conflicting input / output command.

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

[0229] Optionally, the second detection module includes:

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

[0231] A second processing unit is configured to identify a performance inflection point in the target fitting curve and determine an optimal queue depth for the storage device under test based on the target fitting curve, wherein the performance inflection point indicates a critical point of the operating performance of the storage device under test within a supported queue depth range, the optimal queue depth is a queue depth at which the storage device under test achieves optimal operating performance, and the target queue depth parameters include the performance inflection point and the optimal queue depth.

[0232] Optionally, the second processing unit is configured to:

[0233] Calculating the second derivative of the target fitting curve;

[0234] Locating, on the target fitting curve according to the second-order derivative, a curve position where the second-order derivative value is greater than a first threshold and the slope change rate is greater than a second threshold;

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

[0236] Optionally, the second processing unit is configured to:

[0237] Extracting the queue depths of the first N positions of the delay parameter from the queue depth range according to the target fitting curve and arranging them from smallest to largest to obtain N candidate queue depths, where N is a positive integer;

[0238] Determining a fluctuation coefficient of each candidate queue depth according to the target fitting curve, wherein the fluctuation coefficient is used to indicate a fluctuation of the corresponding delay parameter within a range of adjacent depths of the candidate queue depth;

[0239] Filtering the candidate queue depth whose fluctuation coefficient is less than a coefficient threshold from the N candidate queue depths to obtain a reference queue depth;

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

[0241] Optionally, the device further includes:

[0242] A third detection module is configured to detect a bandwidth parameter of the storage device under test during the process of detecting the device operation parameter and the delay parameter of the storage device under test at the reference queue depth;

[0243] An identification module is configured to identify, from the target fitting curve, a queue depth at which the bandwidth parameter is greater than or equal to a bandwidth threshold and the delay parameter is greater than or equal to a delay threshold as a scheduling bottleneck point of the controller.

[0244] Optionally, the first detection module includes:

[0245] A detection unit is configured to detect the unit operation amount and delay time of the storage device under test at the reference queue depth, and obtain a corresponding reference queue depth, device operation parameters, and delay parameters, wherein the device operation parameters include the unit operation amount, the delay parameters include the delay time, and the unit operation amount is used to indicate the number of input and output operations that the storage device under test is allowed to process within a unit time.

[0246] Optionally, the device further includes:

[0247] A fourth detection module is used to detect whether the storage device under test is abnormal during the process of the storage device under test executing the test task;

[0248] a first processing module configured to, upon detecting that an abnormality occurs on the storage device under test, save the context of uncompleted device operations of all current queues on the storage device under test, and generate a hardware error snapshot of the storage device under test, wherein the hardware error snapshot is used to record operation information of the storage device under test when an abnormality occurs;

[0249] The second processing module controls the storage device under test to adjust the operating parameters to the target mode to retry the current device operation in the test task, and detects whether the storage device under test passes the current device operation, wherein the target mode includes: a link rate reduced by a first amplitude compared to the current link rate, a queue depth upper limit reduced by a second amplitude compared to the current queue depth upper limit, a power supply voltage reduced by a third amplitude compared to the current power supply voltage, and a burst flow in the load intensity reduced by a fourth amplitude compared to the current burst flow;

[0250] The second control module is used to control the operating parameters of the storage device under test to be restored to the operating parameters when the abnormality occurs and continue to execute the test task according to the context and the hardware error snapshot when it is detected that the storage device under test is operated by the current device.

[0251] For descriptions of features in the embodiments corresponding to the storage device testing apparatus, reference may be made to the relevant descriptions of the embodiments corresponding to the storage device testing method, which will not be detailed here.

[0252] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps of any of the above-mentioned storage device testing method embodiments.

[0253] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned storage device testing method embodiments when running.

[0254] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0255] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned storage device testing method embodiments are implemented.

[0256] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned storage device testing method embodiments are implemented.

[0257] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may 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 above is a detailed introduction to a storage device testing method and apparatus provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only intended to help understand the method and core ideas of the present application. It should be pointed out that, for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A method for testing a storage device, characterized in that: include: Controlling the storage device under test to execute a test task at a reference queue depth included in a queue depth set according to a received test request, wherein the test request is used to request testing a queue depth parameter of the storage device under test, and the operating performance of the storage device operating at the queue depth indicated by the queue depth parameter meets a target performance requirement; Detecting device operation parameters and delay parameters of the storage device under test at the reference queue depth, and obtaining corresponding reference queue depth, device operation parameters, and delay parameters, wherein the device operation parameters are used to indicate a condition in which the storage device under test performs a device operation during execution of the test task at the reference queue depth, and the delay parameters are used to indicate a delay condition in which the storage device under test performs the test task at the reference queue depth; The queue depth parameter of the storage device to be tested is detected according to the reference queue depth, device operating parameter and delay parameter having a corresponding relationship, and a target queue depth parameter is obtained.

2. The storage device testing method according to claim 1, wherein: The controlling the storage device to be tested to execute the test task at the reference queue depth included in the queue depth set according to the received test request includes: receiving the test request; In response to the test request, traverse each of the reference queue depths and repeatedly perform the following operations until all of the reference queue depths in the queue depth set are traversed: Create input and output queues according to the reference queue depth currently traversed; Submit input and output commands to the input and output queue according to the target ratio until the test duration is reached, wherein the input and 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.

3. The storage device testing method according to claim 2, wherein: Submitting the input / output command to the input / output queue according to the target ratio includes at least one of the following: Creating an initial input / output command that meets the target ratio; detecting whether the current flow is in a burst flow window; and if it is detected that the current flow is in the burst flow window, expanding the scale of the initial input / output command according to a flow multiplication factor to obtain a reference input / output command; Submitting the reference input / output command to the input / output queue; submitting the initial input / output command to the input / output queue when detecting that the system is not currently in the burst traffic window; In a process of submitting input / output commands to the input / output queue according to a target ratio, submitting a conflicting input / output command to a reference namespace, wherein the reference namespace is different from a namespace of the input / output command, the conflicting input / output command is configured to compete with the input / output command for execution resources, a command volume of the conflicting input / output command is less than a command volume threshold, and an execution area of ​​the conflicting input / output command does not include a reserved area in the storage device under test; and releasing the storage space occupied by the conflicting input / output command after executing the conflicting input / output command. While submitting input and output commands to the input and output queue according to the target ratio, the operating temperature of the storage device to be tested is detected; when the operating temperature is greater than or equal to the temperature threshold, the proportion of the sequential write commands in the input and output commands is reduced and the proportion of the garbage collection commands is increased.

4. The storage device testing method according to claim 1, wherein: The detecting the queue depth parameter of the storage device to be tested according to the reference queue depth, the device operating parameter, and the delay parameter having the corresponding relationship to obtain the target queue depth parameter includes: Fitting the reference queue depth, device operating parameters, and delay parameters having corresponding relationships into a target fitting curve, wherein the target fitting curve is used to indicate changes in the device operating parameters and delay parameters within the queue depth range of the storage device under test; Identify a performance inflection point in the target fitting curve, and determine an optimal queue depth for the storage device under test based on the target fitting curve, wherein the performance inflection point is used to indicate a critical point of the operating performance of the storage device under test within a supported queue depth range, the optimal queue depth is the queue depth at which the storage device under test achieves optimal operating performance, and the target queue depth parameters include: the performance inflection point and the optimal queue depth.

5. The storage device testing method according to claim 4, wherein: The identifying a performance inflection point in the target fitting curve includes: Calculating the second derivative of the target fitting curve; Locating, on the target fitting curve according to the second-order derivative, a curve position where the second-order derivative value is greater than a first threshold and the slope change rate is greater than a second threshold; The queue depth corresponding to the position of the curve in the queue depth range is determined as the performance inflection point.

6. The storage device testing method according to claim 4, wherein: Determining the optimal queue depth of the storage device to be tested according to the target fitting curve includes: Extracting the queue depths of the first N positions of the delay parameter from the queue depth range according to the target fitting curve and arranging them from smallest to largest to obtain N candidate queue depths, where N is a positive integer; Determining a fluctuation coefficient of each candidate queue depth according to the target fitting curve, wherein the fluctuation coefficient is used to indicate a fluctuation of the corresponding delay parameter within a range of adjacent depths of the candidate queue depth; Filtering the candidate queue depth whose fluctuation coefficient is less than a coefficient threshold from the N candidate queue depths to obtain a reference queue depth; The queue depth having the largest device operation parameter corresponding to the reference queue depth is determined as the optimal queue depth.

7. The storage device testing method according to claim 4, wherein: The method further comprises: In the process of detecting the device operating parameters and latency parameters of the storage device under test at the reference queue depth, detecting the bandwidth parameters of the storage device under test; A queue depth at which the bandwidth parameter is greater than or equal to a bandwidth threshold and the delay parameter is greater than or equal to a delay threshold is identified from the target fitting curve as a scheduling bottleneck point of the controller.

8. The storage device testing method according to claim 1, wherein: The detecting the device operating parameters and the delay parameters of the storage device under test at the reference queue depth to obtain the reference queue depth, the device operating parameters, and the delay parameters having a corresponding relationship includes: Detecting the unit operation amount and delay time of the storage device under test at the reference queue depth to obtain a corresponding reference queue depth, device operation parameters, and delay parameters, wherein the device operation parameters include the unit operation amount, the delay parameters include the delay time, and the unit operation amount is used to indicate the number of input and output operations that the storage device under test is allowed to process within a unit time.

9. The storage device testing method according to claim 1, wherein: The method further comprises: During the process of the storage device under test executing the test task, detecting whether the storage device under test has an abnormality; When an abnormality is detected in the storage device under test, the context of unfinished device operations in all current queues on the storage device under test is saved, and a hardware error snapshot of the storage device under test is generated, wherein the hardware error snapshot is used to record operation information of the storage device under test when the abnormality occurs; Controlling the storage device under test to adjust 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 link rate reduced by a first value compared to a current link rate, a queue depth upper limit reduced by a second value compared to a current queue depth upper limit, a power supply voltage reduced by a third value compared to the current power supply voltage, and a burst flow in load intensity reduced by a fourth value compared to the current burst flow; When it is detected that the storage device under test is operating through the current device, the operating parameters of the storage device under test are controlled to be restored to the operating parameters when the abnormality occurred according to the context and the hardware error snapshot, and the test task is continued.

10. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the storage device testing method according to any one of claims 1 to 9 when executing the computer program.

Images