Performance test method and device of solid state disk, electronic equipment and storage medium

Abstract

The application relates to a solid state disk performance testing method and device, electronic equipment and storage medium, wherein the solid state disk performance testing method comprises the following steps: obtaining hard disk information and a configuration file of a solid state disk to be tested; calling a test process of a test tool to make the test process build a steady state environment for the solid state disk corresponding to the hard disk information according to the configuration file, and obtaining a first performance parameter of the solid state disk in the steady state environment building process; determining whether the fluctuation of the first performance parameter meets a preset condition; when the fluctuation of the first performance parameter meets the preset condition, performing performance testing on the solid state disk according to the configuration file to obtain test data. The application embodiment can realize full automation and standardization of solid state disk performance testing, eliminate subjective differences of manual steady state environment building, and improve the reproducibility and test efficiency of test results.

Description

Technical Field

[0001] This application relates to the field of server testing, and more particularly to a method, apparatus, electronic device, and storage medium for testing the performance of a solid-state drive. Background Technology

[0002] In server testing, the hard drive is a critical component, and its performance directly affects the overall storage function and performance of the entire system, making it a key focus during the testing process. When testing hard drive performance, especially with large-capacity solid-state drives (SSDs), which typically feature high bandwidth and high IOPS (Input / Output Counts per Second), setting up a stable environment before testing is crucial.

[0003] However, establishing a stable environment is affected by various factors. As hard drive capacity increases, the difficulty of setting up the environment increases significantly, and the time required also increases accordingly. During performance profiling or actual testing, an incomplete stable environment can easily lead to large fluctuations in performance test data, making the test results unreliable. Rebuilding the stable environment again will consume a significant amount of time, adversely affecting the overall project schedule. Summary of the Invention

[0004] In order to solve the above-mentioned technical problems, or at least partially solve the above-mentioned technical problems, this application provides a solid-state drive performance testing method, apparatus, electronic device and storage medium.

[0005] Firstly, this application provides a performance testing method for solid-state drives. Obtain the hard drive information and configuration file of the solid-state drive to be tested; The test process of the test tool is invoked so that the test process can build a steady-state environment for the solid-state drive corresponding to the hard disk information according to the configuration file, and obtain the first performance parameters of the solid-state drive during the steady-state environment construction process; Determine whether the fluctuation of the first performance parameter meets the preset conditions; Once it is determined that the fluctuation of the first performance parameter meets the preset conditions, the solid-state drive is subjected to performance testing according to the configuration file to obtain test data.

[0006] This application embodiment obtains hard disk information and configuration files, automatically calls the test process to complete the construction of a steady-state environment and quantifies the achievement of steady-state conditions, and then seamlessly performs solid-state hard disk performance testing based on the configuration files. This achieves full automation and standardization of solid-state hard disk performance testing, eliminates subjective differences in manually building a steady-state environment, and improves the reproducibility of test results and test efficiency.

[0007] Optionally, determining whether the fluctuation of the first performance parameter meets preset conditions includes: Determine whether the fluctuation curve of the first performance parameter shows a downward trend within a first preset time period; If the fluctuation curve of the first performance parameter shows a downward trend within a first preset time period, determine whether the fluctuation curve of the first performance parameter fluctuates within a first range within a second preset time period after the first preset time period. If it is determined that the fluctuation curve of the first performance parameter fluctuates within a first range during a second preset time period after the first preset time period, then the fluctuation of the first performance parameter is determined to meet the preset conditions.

[0008] This application embodiment uses a two-level determination mechanism that first determines the downward trend and then determines the steady fluctuation to accurately identify the turning point when the solid-state drive enters the stable period from the performance decline period. This avoids misjudgment based on a single threshold and ensures the reliability and consistency of steady-state determination.

[0009] Optionally, before invoking the test process, the method further includes: Obtain the NUMA node to which the solid-state drive belongs; Bind the preset test tools to the CPU cores contained in the NUMA node; The target CPU core for executing the test process is determined based on the hard disk information. The test process is bound to the target CPU core so that when the test process is invoked, the test process is executed on the target CPU core.

[0010] This application embodiment automatically obtains the non-uniform memory access topology information of the solid-state drive and dynamically binds the test process to the central processing unit core of the same node, eliminating the tediousness and errors of manual core binding, maximizing the utilization of local memory access bandwidth, and significantly improving the accuracy and throughput of performance testing.

[0011] Optionally, the solid-state drive is subjected to performance testing according to the configuration file to obtain test data, including: According to a preset first number of times, a performance test process is performed on the solid-state drive to obtain multiple second performance parameters collected during each performance test. If, based on multiple sets of second performance parameters collected during multiple performance tests, it is determined that the performance of the solid-state drive does not meet the preset conditions, the solid-state drive is optimized according to the first optimization strategy. The test process of calling the test tool is re-executed so that the test process can build a stable environment for the optimized solid-state drive according to the configuration file, and obtain the first performance parameters of the solid-state drive during the stable environment construction process, until the number of times the test process is called reaches the second time, or the performance of the solid-state drive meets the preset conditions. Based on the work log recorded by the test tool each time it is optimized, test data is generated when exiting the loop.

[0012] This application embodiment achieves adaptive optimization of substandard hard drives by introducing a closed-loop feedback mechanism of multi-round performance testing and automatic tuning. It can try various tuning methods without manual intervention, significantly shortening the performance debugging cycle and ensuring that the final test data has reference value.

[0013] Optionally, a performance testing process is performed on the solid-state drive, including: Obtain multiple test cases and their execution order from the configuration file; Generate multiple test commands based on the test cases; Execute multiple test commands in the specified execution order to obtain multiple second performance parameters.

[0014] This application embodiment drives the serial execution of test cases through configuration files, enabling testers to flexibly define and adjust test matrices without writing complex scripts. This ensures environmental isolation and controllable sequence between tests of different specifications, and significantly improves the automation level of multi-dimensional performance testing.

[0015] Optionally, the performance test of the solid-state drive based on the configuration file to obtain test data further includes: For each group of second performance parameters, determine whether each second performance parameter in that group is within the corresponding second range, and whether the fluctuation of each second performance parameter in multiple groups of second performance parameters exceeds the preset stability threshold. If each second performance parameter is within its corresponding second range and the fluctuation of each second performance parameter is less than a preset stability threshold, then the hard drive performance of the solid-state drive is determined to meet the preset conditions. If at least one second performance parameter is outside the corresponding second range, or if the fluctuation of at least one second performance parameter is greater than the preset stability threshold, the hard drive performance is determined to not meet the preset conditions.

[0016] This application embodiment comprehensively evaluates the performance level of solid-state drives by combining single-time performance benchmarking with multi-round stability assessment, avoiding misjudgments or omissions caused by occasional fluctuations, and providing a reliable basis for automatic optimization decisions.

[0017] Optionally, obtain the hard drive information of the solid-state drive to be tested, including: Obtain a list of hard drives, which includes information about multiple solid-state drives; Candidate solid-state drives (SSDs) that support preset protocols are selected based on information from multiple SSDs. Determine whether there is a solid-state drive among the candidate solid-state drives that matches the drive information; If a candidate solid-state drive (SSD) exists that matches the drive information, the SSD corresponding to the drive information is formatted. Obtain information about the formatted solid-state drive as the drive information.

[0018] This application embodiment ensures a clean and uniform SSD environment for testing by automatically obtaining a hard drive list, filtering NVMe protocol SSDs, matching target disks, performing formatting, and re-obtaining formatted information. This eliminates the interference of residual data on performance testing and automatically uses the formatted information as input for subsequent tests, thus achieving complete automation of the test preparation stage.

[0019] Secondly, this application provides a solid-state drive performance testing device, comprising: The acquisition module is used to obtain the hard drive information and configuration files of the solid-state drive to be tested. The calling module is used to call the test process of the test tool so that the test process can build a steady-state environment for the solid-state drive corresponding to the hard disk information according to the configuration file and obtain the first performance parameters of the solid-state drive during the steady-state environment construction process. The determination module is used to determine whether the fluctuation of the first performance parameter meets the preset conditions; The testing module is used to determine whether the fluctuation of the first performance parameter meets the preset conditions, and to perform performance testing on the solid-state drive according to the configuration file to obtain test data.

[0020] Thirdly, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the performance testing method for a solid-state drive as described in any of the first aspects.

[0021] Fourthly, this application provides a computer-readable storage medium storing a program for a solid-state drive performance testing method, wherein when the program for the solid-state drive performance testing method is executed by a processor, it implements the steps of the solid-state drive performance testing method described in any of the first aspects.

[0022] The technical solutions provided in this application have the following advantages compared with the prior art: This application embodiment obtains hard disk information and configuration files, automatically calls the test process to complete the construction of a steady-state environment and quantifies the achievement of steady-state conditions, and then seamlessly performs solid-state hard disk performance testing based on the configuration files. This achieves full automation and standardization of solid-state hard disk performance testing, eliminates subjective differences in manually building a steady-state environment, and improves the reproducibility of test results and test efficiency. Attached Figure Description

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

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart illustrating a performance testing method for a solid-state drive provided in this application embodiment; Figure 2 for Figure 1 Flowchart of step S103; Figure 3 Another flowchart of a solid-state drive performance testing method provided in this application embodiment; Figure 4 for Figure 1 A flowchart of step S104; Figure 5 for Figure 4 Flowchart of step S401; Figure 6 for Figure 4 Another flowchart for step S401; Figure 7 for Figure 1 Flowchart of step S101; Figure 8 A structural diagram of a solid-state drive performance testing device provided in an embodiment of this application; Figure 9This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] Establishing a stable environment for large-capacity solid-state drives (SSDs) is influenced by various factors. As drive capacity increases, the difficulty and time required for environment setup significantly rise. During performance profiling or actual testing, an incomplete stable environment can lead to large fluctuations in performance test data, rendering the results unreliable. Rebuilding the stable environment again is time-consuming and negatively impacts the overall project schedule. Therefore, this application provides a method, apparatus, electronic device, and storage medium for testing the performance of solid-state drives (SSDs). Through automated testing, it helps testers build a consistent stable environment and perform different hard drive performance tests according to testing needs. The stable environment setup and performance testing are integrated into a single automated test script. Testers only need to execute the script with one click to automatically perform hard drive tests. If the hard drive performance fails to meet standards, the automated test script can perform more professional optimization settings and automatically retest the hard drive to obtain the corresponding test results. This achieves one-click execution of hard drive performance stable environment setup, performance testing, and data processing. On the one hand, it allows the test machine to run continuously even at night, making full use of machine resources, reducing wasted testing time, and shortening the testing cycle. On the other hand, it improves testing efficiency and reduces the risk of errors and omissions caused by human operation, ensuring test quality.

[0028] This application provides a method for testing the performance of a solid-state drive, such as... Figure 1 As shown, it includes: Step S101: Obtain the hard drive information and configuration file of the solid-state drive to be tested; In this embodiment of the application, the solid-state drive refers to the non-volatile memory express (NVMe) protocol solid-state drive used in a server with a non-uniform memory access (NUMA) architecture. The hard drive information includes the hard drive letter, capacity, bus address and the NUMA node to which it belongs. The configuration file is a text file that defines the test specifications, such as / usr / local / FIO_Per_Case.txt.

[0029] This application allows users to define different test specifications (block size bs, queue depth iodepth, number of tasks numjobs, etc.) as test items that can be enabled or disabled independently through configuration files such as / usr / local / FIO_Per_Case.txt. Users or administrators can maintain and select different configuration files according to different hard drive types, capacities, or test objectives.

[0030] In this step, the automated test script obtains the drive letter and bus information of the solid-state drive under test by scanning the system block device list, and reads the configuration file under the preset path. The configuration file lists multiple test items and their enabled status in the form of equal signs.

[0031] For example, the tool uses the command `lsblk -d -o NAME,ROTA` to obtain all block devices, filters out device names starting with "nvme" as candidate SSDs, and determines the SSD to be tested as "nvme0n1" based on user input or default rules. At the same time, it reads the file ` / usr / local / FIO_Per_Case.txt`, which contains configurations such as sequential read 1M equals 1, random write 4k depth 32 equals 1, etc.

[0032] Step S102: Invoke the test process of the test tool so that the test process can build a steady-state environment for the solid-state drive corresponding to the hard disk information according to the configuration file, and obtain the first performance parameters of the solid-state drive during the steady-state environment construction process. In this embodiment of the application, the testing tool refers to a collection of automated test scripts developed based on the Shell language (hereinafter referred to as the tool), the test process refers to the flexible input / output (flexible I / O Tester, fio) process that is called, and the steady-state environment setup refers to the process of stabilizing the background operations such as internal garbage collection of the solid-state drive through continuous write load. The first performance parameter includes write bandwidth, input / output operations per second (IOPS), or latency.

[0033] In this step, the automated script constructs input / output test commands based on the steady-state setup parameters in the configuration file and calls the taskset or non-uniform memory access control (numactl) command to bind the process to the central processing unit core on the same NUMA node as the solid-state drive for execution. At the same time, background monitoring is started, and performance logs are periodically collected as the primary performance parameter.

[0034] For example: The tool executes the command `taskset -c 8-15 fio --name=precondition --filename= / dev / nvme0n1 --rw=write --bs=1M --iodepth=64 --runtime=1800s --write_bw_log=steady_bw`, and records the bandwidth value every 500 milliseconds during the run, thus obtaining the first performance parameter.

[0035] Step S103: Determine whether the fluctuation of the first performance parameter meets the preset conditions; In this embodiment of the application, the preset condition refers to the criterion used to determine whether the solid-state drive has reached a steady state, specifically, the coefficient of variation of the first performance parameter is lower than a preset threshold within multiple consecutive sampling periods.

[0036] In this step, the built-in steady-state determination function of the automated script calculates the average value and standard deviation of the first performance parameter in real time over a recent period, thereby obtaining the coefficient of variation, and determining whether the coefficient of variation meets the threshold requirement for multiple consecutive periods.

[0037] For example, the tool calculates the bandwidth variation coefficient of the most recent 10 sampling points every 10 seconds. If the variation coefficients obtained from three consecutive calculations are all below 5%, the fluctuation is determined to meet the preset conditions.

[0038] Step S104: Determine that the fluctuation of the first performance parameter meets the preset conditions, and perform a performance test on the solid-state drive according to the configuration file to obtain test data.

[0039] In this embodiment of the application, performance testing refers to running test cases according to various block sizes, queue depths, number of tasks, and read / write modes defined in the configuration file. The test data includes bandwidth logs, latency logs, logs of the number of input / output operations per second generated for each test, as well as the final charts and reports.

[0040] In this step, once the steady-state determination is passed, the tool automatically stops the steady-state load build and reads all enabled test items in the configuration file. It then sequentially calls the Flexible Input / Output Test Process to execute each test case, while recording the output log for each test case. Finally, it calls the Flexible Input / Output Test Plotting Tool (fio_generate_plots) to convert the logs into charts and generate a Portable Document Format (PDF) report to display the test results. Testers can clearly see the test results and easily output and save the report. The report can also be provided to customers who need it, shortening the testing cycle of hard drive components and reducing the time spent on report preparation.

[0041] For example, the tool executes commands such as fio --rw=randread --bs=4k --iodepth=32 in sequence, with each command running for 60 seconds, collecting files such as rr_4k_bw.log and rr_4k_clat.log, then runs fio_generate_plots to generate performance curves, and finally uses pandoc to output the test report.

[0042] This application embodiment obtains hard disk information and configuration files, automatically calls the test process to complete the construction of a steady-state environment and quantifies the achievement of steady-state conditions, and then seamlessly performs solid-state hard disk performance testing based on the configuration files. This achieves full automation and standardization of solid-state hard disk performance testing, eliminates subjective differences in manually building a steady-state environment, and improves the reproducibility of test results and test efficiency.

[0043] In another embodiment of this application, step S103 determines whether the fluctuation of the first performance parameter meets a preset condition, such as... Figure 2 As shown, it includes: Step S201: Determine whether the fluctuation curve of the first performance parameter shows a downward trend within a first preset time period; In this embodiment of the application, the fluctuation curve of the first performance parameter refers to a continuous data sequence plotted with time as the horizontal axis and performance index value as the vertical axis. The first preset time period refers to a fixed duration in the initial stage of the steady-state construction process. The downward trend refers to the curve slope being continuously negative or showing an overall decreasing characteristic.

[0044] In this step, the tool performs linear regression or sliding window comparison on the collected first performance parameter sequence, calculates the direction of change of the mean of each sampling point within the first preset time period, and determines that the mean of the later segment is less than the mean of the earlier segment as a downward trend.

[0045] For example: The tool sets the first preset time period to the first 300 seconds, samples a bandwidth point every 10 seconds, calculates the average bandwidth from the 1st to the 150th second and the average bandwidth from the 151st to the 300th second. If the latter is less than the former and the difference exceeds 10%, it is determined to be a downward trend.

[0046] Step S202: If the fluctuation curve of the first performance parameter shows a downward trend within the first preset time period, determine whether the fluctuation curve of the first performance parameter fluctuates within the first range within the second preset time period after the first preset time period. In this embodiment of the application, the second preset time period refers to another fixed duration immediately following the first preset time period, and the first range refers to the preset performance index fluctuation range, such as plus or minus five percent of the average value within that time period.

[0047] In this step, after confirming the downward trend, the tool continues to monitor the performance data within the second preset time period, calculates the maximum, minimum and average values ​​of all sampled points within this time period, and determines whether the difference between the maximum and minimum values ​​is less than the average value multiplied by the first range threshold.

[0048] For example: the second preset time period is 300 to 600 seconds. The tool calculates that the average bandwidth within this 300 seconds is 800 megabytes per second. If the maximum bandwidth is 820 megabytes per second and the minimum bandwidth is 780 megabytes per second, the difference of 40 megabytes per second is less than 800 multiplied by five percent, which equals 40 megabytes per second. Therefore, it is determined that the bandwidth fluctuates within the first range.

[0049] Step S203: If it is determined that the fluctuation curve of the first performance parameter fluctuates within a first range during a second preset time period after the first preset time period, it is determined that the fluctuation of the first performance parameter meets the preset conditions.

[0050] In this embodiment of the application, meeting the preset conditions indicates that the solid-state drive has reached a stable state, and the stable state construction process can be exited and the performance testing phase can be entered.

[0051] In this step, the tool continuously checks the fluctuations within the second preset time period. If all sampling points fall within the first range, the steady-state flag is set to true, the steady-state load is automatically stopped, and the steady-state achievement time is recorded.

[0052] For example, the tool detects that the bandwidth fluctuation is consistently between 780 and 820 megabytes per second after 600 seconds, determines that the preset conditions are met, terminates the flexible input / output test precondition process, and outputs the log indicating that the steady-state environment has been set up, which takes 600 seconds.

[0053] This application embodiment uses a two-level determination mechanism that first determines the downward trend and then determines the steady fluctuation to accurately identify the turning point when the solid-state drive enters the stable period from the performance decline period. This avoids misjudgment based on a single threshold and ensures the reliability and consistency of steady-state determination.

[0054] In another embodiment of this application, before the test process is invoked in step S102, the method is as follows: Figure 3 As shown, it also includes: Step S301: Obtain the NUMA node to which the solid-state drive belongs; In this embodiment of the application, a NUMA (Non-Uniform Memory Access) node refers to a memory architecture in a multi-processor system that divides the CPU core and memory into different regions, with each solid-state drive connected to a NUMA node via a peripheral component fast interconnect bus.

[0055] In this step, the tool obtains the Fast Interconnect Bus address of the peripheral component by reading the symbolic link under / sys / block / device name, and then queries the NUMA node number to which the hard drive belongs by reading the / sys / class / pci_bus / bus address / numa_node file.

[0056] For example: executing `ll / sys / block / nvme0n1` returns a link pointing to `.. / devices / pci0000:00 / 0000:00:1c.0 / 0000:01:00.0 / `, extracting the bus address `0000:01:00.0`, and then executing `cat / sys / class / pci_bus / 0000:01 / numa_node` returns an output of 1, indicating that the solid-state drive belongs to NUMA node 1.

[0057] Step S302: Bind the preset test tool to the CPU cores contained in the NUMA node; In this embodiment of the application, the preset test tool refers to the input / output test tool used to perform input / output load, the central processing unit core is the central processing unit core, and binding refers to restricting the process to run on a specified core through non-uniform memory access control or task setting commands.

[0058] In this step, the tool uses the numactl --hardware command to obtain a list of all CPU cores contained in the NUMA node number obtained in the previous step, and then generates binding parameters for use when calling the test process later.

[0059] For example: numactl --hardware shows that node 1 contains CPU cores 8 to 15. The tool records this core range and uses the taskset -c 8-15 as a prefix command when starting a flexible input / output test.

[0060] Step S303: Determine the target CPU core for executing the test process based on the hard disk information; In this embodiment of the application, the target CPU core refers to a specific core or core range in the CPU core set belonging to the same NUMA node as the solid-state drive, so as to realize that the computing is close to the storage to reduce cross-node access latency.

[0061] In this step, the tool selects the core range corresponding to the NUMA node of the solid-state drive from the binding parameters as the target core. If the node has multiple cores, all cores can be selected or a portion of them can be specified.

[0062] For example: if the tool confirms that the solid-state drive is on NUMA node 1, and the cores of node 1 are 8 to 15, then the target CPU cores are determined to be cores 8 to 15.

[0063] Step S304: Bind the test process to the target CPU core so that when the test process is invoked, the test process is executed on the target CPU core.

[0064] In this embodiment, the test process is the input / output test process that is subsequently started. The binding operation is performed by adding the flexible input / output test when it is called through task settings or non-uniform memory access control commands, so as to ensure that the process runs only on the specified central processing unit core.

[0065] In this step, the tool uses the binding command as a prefix when constructing each input / output test command, such as `taskset -c 8-15 fio parameter` or `numactl --cpunodebind=1 --membind=1 fio parameter`, thereby binding the process to the kernel.

[0066] For example, the tool executes the command `numactl --cpunodebind=1 --membind=1 fio --name=test--filename= / dev / nvme0n1 --rw=randread`, which forces the flexible input / output test process to use the CPU and memory of NUMA node 1, avoiding cross-node access.

[0067] This application embodiment automatically obtains the non-uniform memory access topology information of the solid-state drive and dynamically binds the test process to the central processing unit core of the same node, eliminating the tediousness and errors of manual core binding, maximizing the utilization of local memory access bandwidth, and significantly improving the accuracy and throughput of performance testing.

[0068] In another embodiment of this application, step S104 performs a performance test on the solid-state drive according to the configuration file to obtain test data, such as... Figure 4 As shown, it includes: Step S401: Perform a performance test on the solid-state drive according to a preset first number of times, and obtain multiple second performance parameters collected during each performance test. In this embodiment of the application, the first number is a pre-set baseline test round, and the second performance parameter includes indicators such as the number of input / output operations per second, bandwidth, and latency generated by different test cases in each performance test.

[0069] In this step, the tool runs a complete round of performance testing according to the test cases in the configuration file, records the output of each test case as a set of second performance parameters, and repeats this process for the first few rounds.

[0070] For example, if the initial value is set to 1, the tool will execute all the test items in the configuration file in sequence, collect the number of input / output operations per second and the average latency for each test item, and form a set of second performance parameters.

[0071] Step S402: If the hard disk performance of the solid-state drive does not meet the preset conditions based on multiple sets of second performance parameters collected during multiple performance tests, the solid-state drive is optimized according to the first optimization strategy. In this embodiment of the application, the hard disk performance not meeting the preset conditions means that the test results do not reach the expected performance baseline. The first optimization strategy includes deep optimization operations such as adjusting the NVMe protocol interrupt aggregation parameters, modifying the input / output scheduler, and forcing the central processing unit performance mode.

[0072] In this step, the tool analyzes the second performance parameter. If it finds that the key indicators are below the threshold and the system soft interrupt utilization is high, it is determined to be an interrupt bottleneck and the first tuning strategy is executed, such as using NVMe protocol commands to set interrupt aggregation parameters.

[0073] For example, the tool detected that the number of input / output operations per second for 4K random read was only 500K, while the specification should be 800K. At the same time, it monitored that the soft interrupt utilization rate of the central processing unit exceeded 30%. So it executed the command nvme set-feature / dev / nvme0n1 -f 8 -v 0x0109 to set the interrupt aggregation threshold to 265 inputs and outputs.

[0074] Step S403: Re-execute the test process of calling the test tool so that the test process can build a stable environment for the optimized solid-state drive according to the configuration file, and obtain the first performance parameters of the solid-state drive during the stable environment construction process, until the number of times the test process is called reaches the second time, or the performance of the solid-state drive meets the preset conditions. Based on the work log recorded by the test tool each time it is optimized, test data is generated when exiting the loop.

[0075] In this embodiment, the second number is the maximum number of retries, and the work log includes the raw data of each test, the tuning operation record, and the final report.

[0076] In this step, the tool automatically jumps back to the steady-state setup step after each optimization, re-executes the complete process, and accumulates the number of retries. When the performance meets the target or reaches the second count, the loop stops, and all logs are collected to generate the final test data.

[0077] For example: After the first optimization and retest, the number of input / output operations per second increased to 700K but still did not meet the target. The tool performed a second optimization, changed the input / output scheduler to none, and after another test, the number of input / output operations per second reached 820K, meeting the condition. The tool stopped retrying and generated a portable document-formatted report containing the two optimization records and the final performance curve.

[0078] This application embodiment achieves adaptive optimization of substandard hard drives by introducing a closed-loop feedback mechanism of multi-round performance testing and automatic tuning. It can try various tuning methods without manual intervention, significantly shortening the performance debugging cycle and ensuring that the final test data has reference value.

[0079] In another embodiment of this application, step S401 performs a performance test on the solid-state drive, such as... Figure 5 As shown, it includes: Step S501: Obtain multiple test cases and their execution order from the configuration file; In this embodiment of the application, a test case refers to each line of test items defined in the configuration file, and the execution order is the order in which the test items are arranged from top to bottom in the file.

[0080] In this step, the tool reads the configuration file line by line, parses the test item names on the left side of the equals sign and the enable flags on the right side of the equals sign, and adds the test items with the enable flag set to 1 to the execution list in the order they are read.

[0081] For example, if the configuration file contains the following: sequential read 1M equals 1, random write 4k depth 32 equals 1, and random read 4k depth 64 equals 0, then the obtained test cases will be in the order of sequential read 1M and random write 4k depth 32.

[0082] Step S502: Generate multiple test commands based on the test cases; In this embodiment of the application, each test case corresponds to a flexible input / output test command. The command includes parameters such as read / write mode, block size, queue depth, and runtime. The parameter values ​​are obtained by parsing the test case name.

[0083] In this step, the tool dynamically constructs flexible input and output test parameters according to the naming rules of the test cases. For example, a test case that randomly writes 4k depth 32 is parsed as --rw=randwrite --bs=4k --iodepth=32, and then concatenates fixed parameters such as --runtime=60s.

[0084] For example: For a test case that reads 1M sequentially, the tool generates the command fio --name=seq_read_1M --rw=read --bs=1M --iodepth=32 --runtime=60s --filename= / dev / nvme0n1 --write_bw_log=seq_read_1M.

[0085] Step S503: Execute multiple test commands in the specified execution order to obtain multiple second performance parameters.

[0086] In this embodiment of the application, the execution order is the order of the test case list, and the second performance parameter is the average number of input / output operations per second, bandwidth, and latency, etc., output after each flexible input / output test command finishes running.

[0087] In this step, the tool uses a loop structure to sequentially call each generated flexible input / output test command, and waits for each command to finish executing before starting the next one, while saving the output log of each command to a specified directory.

[0088] For example: The tool first executes a sequential read command of 1M, waits 60 seconds to collect seq_read_1M_bw.log and parses it to obtain a bandwidth of 2500 megabytes per second, and then executes a random write command of 4k depth 32, resulting in 350K input / output operations per second.

[0089] This application embodiment drives the serial execution of test cases through configuration files, enabling testers to flexibly define and adjust test matrices without writing complex scripts. This ensures environmental isolation and controllable sequence between tests of different specifications, and significantly improves the automation level of multi-dimensional performance testing.

[0090] In yet another embodiment of this application, as Figure 6As shown, step S104 involves performing a performance test on the solid-state drive according to the configuration file to obtain test data, and also includes: Step S601: For each group of second performance parameters, determine whether each second performance parameter in the group is within the corresponding second range, and whether the fluctuation of each second performance parameter in multiple groups of second performance parameters exceeds the preset stability threshold. In this embodiment of the application, the second range refers to the performance baseline range of each second performance parameter, and the stability threshold refers to the allowable fluctuation range of the performance change of the same second performance parameter in multiple rounds of testing, for example, the coefficient of variation is less than two percent.

[0091] In this step, the tool compares each second performance parameter with a pre-stored performance baseline range and calculates the standard deviation or coefficient of variation of the same second performance parameter across different rounds to determine whether it exceeds the stability threshold.

[0092] Step S602: If each second performance parameter is within the corresponding second range and the fluctuation of each second performance parameter is less than the preset stability threshold, it is determined that the hard disk performance of the solid-state drive meets the preset conditions. In this embodiment of the application, meeting the preset conditions means that the hard disk performance meets the standard and is stable, and the tuning loop can be stopped.

[0093] In this step, the tool uses a combination of logical OR and logical AND to make judgments. As long as each second performance parameter falls within the performance baseline range and the fluctuations of each second performance parameter in multiple rounds are less than the stability threshold, the overall performance of the solid-state drive is considered to meet the requirements.

[0094] For example, if the number of 4K random read operations per second is 500K, which is within the corresponding second range, and the sequential write bandwidth is 1000 megabytes per second, which is within the corresponding second range, and the fluctuation of the number of input / output operations per second in the two rounds of testing is less than 10% and the bandwidth fluctuation is less than 8% in the two rounds of testing, then the preset conditions are met.

[0095] Step S603: If at least one second performance parameter is outside the corresponding second range, or the fluctuation of at least one second performance parameter is greater than the preset stability threshold, it is determined that the hard disk performance does not meet the preset conditions.

[0096] In this embodiment of the application, failure to meet the preset conditions indicates that the hard drive has not met the standard or its performance is unstable in any test dimension, and deep tuning needs to be triggered.

[0097] In this step, the tool checks all secondary performance parameters. If one or more secondary performance parameters fall outside the performance baseline range or the inter-cycle fluctuation of one or more secondary performance parameters exceeds the stability threshold, the overall condition is deemed not met.

[0098] For example, if the number of input / output operations per second for 4K random read is 820K, which is outside the second range or fluctuates by more than 1.5%, it is still determined that the performance does not meet the preset conditions, regardless of whether other second performance parameters exceed the standard.

[0099] This application embodiment comprehensively evaluates the performance level of solid-state drives by combining single-time performance benchmarking with multi-round stability assessment, avoiding misjudgments or omissions caused by occasional fluctuations, and providing a reliable basis for automatic optimization decisions.

[0100] In another embodiment of this application, step S101 involves obtaining the hard drive information of the solid-state drive to be tested, such as... Figure 7 As shown, it includes: Step S701: Obtain a list of hard drives, which includes information on multiple solid-state drives; In this embodiment of the application, the hard disk list refers to the collection of all block devices currently in the system, and the information of the solid-state drive includes the device name, device type and device capacity.

[0101] In this step, the automated test script obtains all block device nodes by calling operating system commands or traversing the system device directory, and records the name and attributes of each node as a list of hard disks.

[0102] For example, the tool executes the command lsblk -d -o NAME,ROTA or traverses the / sys / block / directory to get the output nvme0n1, nvme1n1, sda, and stores these device names in a list.

[0103] Step S702: Filter candidate solid-state drives that support the preset protocol based on the information of multiple solid-state drives; In this embodiment of the application, the preset protocol is the NVMe protocol, and the candidate solid-state drive refers to a solid-state drive whose device name is prefixed with nvme.

[0104] In this step, the tool iterates through each device name in the hard drive list, uses a string prefix matching method to determine whether the device name starts with nvme, and adds the successfully matched devices to the candidate solid-state drive list.

[0105] For example: select nvme0n1 and nvme1n1 as candidate solid-state drives from the list of hard drives nvme0n1, nvme1n1, and sda.

[0106] Step S703: Determine whether there is a solid-state drive among the candidate solid-state drives that matches the drive information; In this embodiment of the application, hard disk information refers to the target solid-state drive letter that is pre-specified by the user or set through a configuration file.

[0107] In this step, the tool compares the candidate solid-state drive list with the pre-acquired hard drive information to determine whether the target drive letter in the hard drive information exists in the candidate list.

[0108] For example, if the user specifies the hard drive information as nvme0n1, and the candidate list contains nvme0n1 and nvme1n1, then it is determined that a matching solid-state drive exists.

[0109] Step S704: If there is a solid-state drive among the candidate solid-state drives that matches the hard disk information, format the solid-state drive corresponding to the hard disk information; In this embodiment, formatting refers to performing low-level formatting or file system creation operations on the solid-state drive to clear all existing data on the hard drive and establish a unified file system structure. Performing unified formatting on the test hard drive can unify the pre-test environment of the hard drive, ensuring that all tests start from a clean and consistent logical state of the hard drive, eliminating the influence of residual data or historical file system differences.

[0110] In this step, the tool calls the nvme format command and sets the user data erase options, or calls the mkfs.ext4 command to create a file system on the target solid-state drive, and waits for the command to complete.

[0111] For example, after matching nvme0n1, the tool executes the command nvme format / dev / nvme0n1 --ses=1, or executes mkfs.ext4 / dev / nvme0n1 to restore the hard drive to a state similar to its factory settings.

[0112] Step S705: Obtain the information of the formatted solid-state drive as the drive information.

[0113] In this embodiment of the application, the information of the formatted solid-state drive refers to the drive letter, capacity, and file system type of the drive after the formatting operation is completed, which is used as input for subsequent testing processes.

[0114] In this step, the tool rereads the device node information of the solid-state drive, confirms successful formatting, and passes the drive letter and path of the drive as the final drive information to the subsequent stable environment setup step.

[0115] For example, after formatting nvme0n1, the tool executes lsblk again to confirm that the device exists and there are no errors, and then uses / dev / nvme0n1 as hard disk information for subsequent call test processes.

[0116] This application embodiment ensures a clean and uniform SSD environment for testing by automatically obtaining a hard drive list, filtering NVMe protocol SSDs, matching target disks, performing formatting, and re-obtaining formatted information. This eliminates the interference of residual data on performance testing and automatically uses the formatted information as input for subsequent tests, thus achieving complete automation of the test preparation stage.

[0117] For ease of understanding, this application also provides an embodiment in practical application, as follows: Step 1: Display tuning suggestions, prompting users to optimize strategies and check configuration information. Purpose: To unify and optimize system-level configurations before testing begins, ensuring a consistent test baseline. Specific steps: a. Output prompts: The tool will print out the BIOS / UEFI settings that need to be checked or optimized, such as: CPU power consumption settings: It is recommended to set TDP to performance mode to avoid frequency throttling caused by power limiting. CPU power status: It is recommended to disable deep power-saving options such as C-State in the BIOS to prevent CPU frequency fluctuations during testing. PCIe link status: It is recommended to disable the ASPM power-saving function of the PCIe link.

[0118] b. Check system configuration: The tool will automatically run some shell commands to check the current status, such as: check CPU frequency policy: cat / sys / devices / system / cpu / cpu / cpufreq / scaling_go Vernor is displayed, prompting the user to confirm whether to set it to performance. Current kernel parameters are checked. Programming logic: This step primarily provides information and preparatory checks; it does not change the system state and aims to guide the user to manually enter BIOS settings or confirm system configuration as instructed.

[0119] Step 2: Determine if the hard drive under test is an NVMe drive. Purpose: To quickly filter out high-performance SSDs that support the NVMe protocol for testing. Specific steps: a. Get a list of hard drives: Use the command lsblk -d -o NAME,ROTA or ls / sys / block / to list all block devices.

[0120] b. Identification Protocol: Iterate through each device name (e.g., sda, nvme0n1). The judgment logic is: if the device name starts with 'nvme', it is determined to be an NVMe hard drive. This is because the Linux kernel uniformly names NVMe devices in the format nvme[controller number]n[namespace number].

[0121] c. Branch Processing: If no device with a name starting with "nvme" is found, the process ends. Programming Logic: This is a simple string matching judgment. The tool reads the system block device list and filters out drive letters whose device names contain the prefix "nvme".

[0122] Step 3: Select and format the hard drives to be tested. Purpose: To select the target drive from all NVMe drives and restore it to a clean, uniform initial state, eliminating the impact of residual data or historical file system differences. Specific steps: a. Filtering the target disk: "Filtering" refers to determining which hard drive to test based on user input, configuration files, or default rules (such as selecting the first NVMe disk, nvme0n1). For example, the tool might obtain the target drive letter by interactively prompting or reading the configuration file / usr / local / disk_target.conf.

[0123] b. Secure Erase and Formatting: Secure Erase: To completely reset the SSD controller's FTL mapping table and achieve optimal performance, the `nvme format` command may be invoked with the `--ses=1` (user data erase) option set. File System Formatting: Use the command `mkfs.ext4 / dev / nvme0n1` or `mkfs.xfs / dev / nvme0n1` to create a uniform file system on the target disk. Formatting will erase all data on the disk.

[0124] Programming logic: This step involves a decision point, which locks a specific hard disk device node according to preset rules, and then executes a formatting command on that device.

[0125] Step 4: Check the bus information and NUMA topology of the hard drive under test. Purpose: To collect hardware topology information for subsequent "core binding" operations, enabling "computing closer to storage" and reducing latency when accessing across NUMA nodes. Specific steps: a. View bus information: Use the command `ll / sys / block / nvme0n1` (ll is an alias for `ls -l`) to view the symbolic links of the device in the ` / sys / ` file system. This link path will contain information like `.. / devices / pci0000:00 / 0000:00:1c.0 / 0000:01:00.0 / ...`, where `0000:01:00.0` is the PCIe bus device address (BUS ID) corresponding to the NVMe hard drive.

[0126] b. Read NUMA information: Use the command `cat / sys / class / pci_bus / <bus address> / numa_node` or `lspci -vvv -s<bus address>| grep NUMA` to query which NUMA node this PCIe device belongs to. For example, the output `numa_node 1` indicates that the hard drive is on NUMA node 1.

[0127] c. Function: The obtained NUMA node number will be used directly in the next step to bind the test process to the CPU core of the same node.

[0128] Programming logic: The tool parses a specific path in the / sys / file system, extracts the PCIe address, and then queries the NUMA node number to which the hardware belongs.

[0129] Step 5: Perform core binding on the hard drive under test. Purpose: To lock the test process (fio) to run on the same CPU core of the NUMA node as the NVMe hard drive, maximizing memory access and I / O efficiency. Specific steps: a. Obtain the CPU list: Based on the NUMA node number obtained in the previous step (assuming it is 1), use the numactl --hardware command to view which CPU cores are contained in node 1 (for example, core numbers are 8-15).

[0130] b. Execute Binding: When starting the fio test command, use taskset or numactl to bind the process. Using taskset: The command `taskset -c 8-15 fio ...` binds the fio process to CPU cores 8 through 15 for execution. Using numactl: The command `numactl --cpunodebind=1 --membind=1fio ...` binds the fio process to NUMA node 1 (using the node's CPU and memory).

[0131] Programming logic: The tool generates the corresponding CPU bitmask or node binding parameters based on the NUMA node number, and adds it as a prefix before all subsequent fio test commands.

[0132] Step 6: Set up a stable environment. Purpose: To bring the SSD's performance to a stable and reproducible state (typically referring to background operations such as garbage collection becoming stable). Specific steps: a. Method: Typically, continuous sequential writes are used to "fill" the available space on the disk and trigger internal management operations by the controller. For example, a sequential write task is run using fio, with the write volume being twice the disk capacity or lasting for a certain period of time.

[0133] b. Determining steady state: During the setup process, the tool will monitor performance metrics (such as write bandwidth). When the bandwidth curve drops from its initial high point and eventually fluctuates smoothly within a small range (such as ±5%), it is considered to have reached steady state.

[0134] Programming logic: The tool starts a background, high-intensity sequential write fio task and periodically samples its performance logs. It determines whether a stable threshold has been reached by calculating the variance or standard deviation of the performance data over a recent period.

[0135] This solution embeds the steps for building a stable environment (such as preconditions, load application time, and stability criteria) into an automated script. Regardless of who executes it, the tool follows the same logic and parameters to "polish" the hard drive, bringing it to a reproducible stable state.

[0136] Step 7: Perform hard drive performance tests on the hard drive under test according to the different specifications specified in the configuration file. Purpose: To comprehensively evaluate the hard drive's performance under different read / write modes, block sizes, and queue depths. 1. Block Size (bs) is used to test a hard drive's ability to handle different I / O request unit sizes. For example: Small bs (e.g., 4K, 8K): simulates random read / write intensive scenarios such as databases and virtualization, primarily testing the hard drive's random IOPS (operations per second) and latency. Large bs (e.g., 128K, 1M): simulates sequential read / write intensive scenarios such as video editing and backup, primarily testing the hard drive's sequential bandwidth (throughput, MB / s). By varying bs, a complete performance spectrum of the hard drive can be plotted from "random small files" to "sequential large files".

[0137] 2. Queue Depth (iodepth): This measures how many parallel I / O requests a hard drive can handle simultaneously (i.e., the depth of its command queue). For example: Low queue depth (e.g., 1, 8): Tests the hard drive's latency under low concurrency pressure. The latency at queue depth 1 is the hard drive's "pure response speed." High queue depth (e.g., 32, 64, 256): Tests the hard drive's maximum throughput (IOPS or bandwidth) under high concurrency pressure. When the queue depth increases to a certain value, performance no longer improves, indicating that the hard drive has reached its maximum saturation capacity. By varying the iodepth, one can find the hard drive's performance "inflection point" and "ceiling," evaluating its different performance under light and heavy loads.

[0138] 3. Number of Jobs (numjobs): This is used to test the hard drive's performance when multiple concurrent processes / threads initiate I / O requests simultaneously, simulating real-world scenarios of multiple applications and users concurrently accessing the hard drive. It, along with iodepth, constitutes a stress test of the hard drive's concurrency capabilities, but from different perspectives: iodepth measures the concurrency of a single process, while numjobs measures the concurrency of multiple processes. Increasing numjobs can further push the hard drive's parallel processing capabilities, especially on multi-core CPU systems.

[0139] Specific operations: a. How to test: The tool reads a configuration file (e.g., / usr / local / FIO_Per_Case.txt), which defines combinations of various test cases. For example: [Test Item_Sequential Read_1M]=1, [Test Item_Random Write_4k_Depth 32]=1; b. For each enabled test item, the tool will automatically generate the corresponding fio command and execute it sequentially. For example, for the test of randomly writing 4K at a depth of 32, the generated command includes parameters such as --rw=randwrite --bs=4k --iodepth=32.

[0140] c. Overall Data Compliance Judgment: Absolute Standard: Whether the test results (such as average IOPS) all reach the preset performance baseline value (e.g., according to the product specification, the drive's 4K random read should reach 800K IOPS). Relative Standard: Whether the performance fluctuation in multiple tests or tests with different parameters does not exceed the preset stability threshold (e.g., IOPS fluctuation in three consecutive tests is less than 2%); otherwise, it is judged as not meeting the standard.

[0141] Programming logic: The tool parses the configuration file, loops through each test case marked "1", dynamically replaces the parameters in the fio command template, and then executes them sequentially and collects the result logs.

[0142] Step 8: Triggered when core metrics (such as IOPS of key use cases) are generally met, process the test data. Purpose: To automatically process raw logs into a comprehensive, visual report. Specific steps: a. The tool will automatically call scripts like fio_generate_plots to generate the previously generated plots. _bw.log, Using log files such as _iops.log as input, it generates PNG or SVG format line graphs in batches.

[0143] b. At the same time, the tool will parse the final text summary of the fio output and extract key data such as average IOPS, bandwidth, and latency.

[0144] c. Finally, use tools such as pandoc or wkhtmltopdf to automatically populate charts, data tables, and test configuration information into a predefined Markdown or HTML template and convert it into a PDF report.

[0145] Programming logic: This step is a data pipeline process, following a fixed order: collect logs -> call the plotting script -> parse the text results -> apply a template to generate a report.

[0146] Step 9: Trigger deep tuning when core metrics (such as IOPS for key use cases) are not met. Purpose: To automatically perform lower-level system tuning when performance is substandard, in an attempt to improve performance. Specific operations (continuing from previous content on interrupt aggregation, etc.): a. Diagnosis: Analyze test data. For example, if low IOPS is found along with excessively high %sys (system CPU utilization) or %si (soft interrupt CPU utilization), it may be determined that the interrupt processing is a bottleneck.

[0147] b. Perform optimization: Interrupt aggregation: Use the `nvme set-feature` command to adjust the interrupt aggregation parameters of the NVMe controller to reduce the interrupt frequency. For example: `nvme set-feature / dev / nvme0 -f 8 -v 0x0109`.

[0148] Interrupt aggregation is essentially an optimization strategy that trades a small amount of latency for higher overall throughput. For high-performance NVMe SSDs, each I / O completion generates an interrupt to notify the CPU for processing. Under high load, excessively frequent interrupts consume significant CPU resources in handling context switches, becoming a performance bottleneck. In the NVMe protocol, this is achieved by setting two key parameters: Aggregation threshold: how many I / O completions must accumulate before triggering an interrupt; and Aggregation time: how long to wait before triggering an interrupt, regardless of the accumulated completions. These two parameters need to find the optimal balance between reducing CPU overhead and increasing I / O latency. Improper settings (such as excessively long times) can severely degrade performance.

[0149] According to the NVMe protocol, the host mainly sets interrupt aggregation parameters in the following two ways: a) Global setting, corresponding to Feature ID 08h (Interrupt Coalescing), which applies to all I / O interrupt vectors and sets a uniform aggregation time and threshold; b) Vector-level setting, corresponding to Feature ID 09h (Interrupt VectorConfiguration), which allows for more granular control over a specific individual interrupt vector.

[0150] Adjust the I / O scheduler: Set the NVMe disk scheduler to none: `echo none> / sys / block / nvme0n1 / queue / scheduler`. Adjust the CPU power state: Force the CPU to run at its highest performance level using the `cpupower` command: `cpupower frequency-set -g performance`.

[0151] For example, use the `nvme set-feature` command. First, use a conservative value recommended by the vendor (such as 0x0109 mentioned in a certain cloud documentation, representing a cumulative 265 I / Os) for testing. Based on the test results, dynamically adjust the parameters (for example, if the latency increase is acceptable but the CPU utilization does not decrease significantly, try increasing the threshold), and conduct multiple rounds of rapid iterative testing to find a better solution under the current load.

[0152] c. Verification Loop: After each deep optimization, the tool will jump back to step 6 or step 7 to perform another round (or a simplified version) of steady-state setup and performance testing to verify the optimization effect. This process may loop several times until the target is met or the maximum number of attempts is exceeded.

[0153] After each adjustment, the tool automatically runs a simplified performance test and monitors the trends of two core metrics: CPU utilization (especially interrupts) and I / O latency (such as clat). The goal is to maximize throughput and reduce CPU overhead within acceptable latency limits. If a better configuration is found, it is recorded and applied; if all attempts fail to meet the criteria, a diagnostic report is output, indicating potential other hardware or configuration bottlenecks.

[0154] Programming logic: This is a loop control structure containing "conditional judgment -> execution of specific tuning commands -> re-verification". The tuning strategy itself is rule-based (if-then).

[0155] In another embodiment of this application, a performance testing device for a solid-state drive is also provided, such as... Figure 8 As shown, it includes: Module 11 is used to obtain the hard drive information and configuration file of the solid-state drive to be tested; Module 12 is invoked to invoke the test process of the test tool, so that the test process can build a steady-state environment for the solid-state drive corresponding to the hard disk information according to the configuration file, and obtain the first performance parameters of the solid-state drive during the steady-state environment construction process. The determination module 13 is used to determine whether the fluctuation of the first performance parameter meets the preset conditions; The testing module 14 is used to determine whether the fluctuation of the first performance parameter meets the preset conditions, and to perform performance testing on the solid-state drive according to the configuration file to obtain test data.

[0156] In another embodiment of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus. Memory, used to store computer programs; When the processor executes a program stored in the memory, it implements the solid-state drive performance testing method described in any of the foregoing method embodiments.

[0157] The electronic device provided in this invention allows the processor to execute programs stored in the memory, obtain hard disk information and configuration files, automatically call the test process to complete the construction of a steady-state environment and quantify the achievement of steady-state conditions, and then seamlessly perform solid-state hard disk performance testing according to the configuration file. This achieves full automation and standardization of solid-state hard disk performance testing, eliminates subjective differences in manually constructing a steady-state environment, and improves the reproducibility and efficiency of test results.

[0158] The communication bus 1140 mentioned in the above-mentioned electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus 1140 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0159] The communication interface 1120 is used for communication between the above-mentioned electronic device and other devices.

[0160] The memory 1130 may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0161] The processor 1110 mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0162] In another embodiment of this application, a computer-readable storage medium is also provided, on which a program for a solid-state drive performance testing method is stored. When the program for the solid-state drive performance testing method is executed by a processor, it implements the steps of the solid-state drive performance testing method described in any of the foregoing method embodiments.

[0163] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0164] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A performance testing method for a solid-state drive, characterized in that, include: Obtain the hard drive information and configuration file of the solid-state drive to be tested; The test process of the test tool is invoked so that the test process can build a steady-state environment for the solid-state drive corresponding to the hard disk information according to the configuration file, and obtain the first performance parameters of the solid-state drive during the steady-state environment construction process; Determine whether the fluctuation of the first performance parameter meets the preset conditions; Once it is determined that the fluctuation of the first performance parameter meets the preset conditions, the solid-state drive is subjected to performance testing according to the configuration file to obtain test data.

2. The solid-state drive performance testing method according to claim 1, characterized in that, Determining whether the fluctuation of the first performance parameter meets preset conditions includes: Determine whether the fluctuation curve of the first performance parameter shows a downward trend within a first preset time period; If the fluctuation curve of the first performance parameter shows a downward trend within a first preset time period, determine whether the fluctuation curve of the first performance parameter fluctuates within a first range within a second preset time period after the first preset time period. If it is determined that the fluctuation curve of the first performance parameter fluctuates within a first range during a second preset time period after the first preset time period, then the fluctuation of the first performance parameter is determined to meet the preset conditions.

3. The solid-state drive performance testing method according to claim 1, characterized in that, Before invoking the test process, the method further includes: Obtain the NUMA node to which the solid-state drive belongs; Bind the preset test tools to the CPU cores contained in the NUMA node; The target CPU core for executing the test process is determined based on the hard disk information. The test process is bound to the target CPU core so that when the test process is invoked, the test process is executed on the target CPU core.

4. The solid-state drive performance testing method according to claim 1, characterized in that, The solid-state drive was subjected to performance testing according to the configuration file, and the test data was obtained, including: According to a preset first number of times, a performance test process is performed on the solid-state drive to obtain multiple second performance parameters collected during each performance test. If, based on multiple sets of second performance parameters collected during multiple performance tests, it is determined that the performance of the solid-state drive does not meet the preset conditions, the solid-state drive is optimized according to the first optimization strategy. The test process of calling the test tool is re-executed so that the test process can build a stable environment for the optimized solid-state drive according to the configuration file, and obtain the first performance parameters of the solid-state drive during the stable environment construction process, until the number of times the test process is called reaches the second time, or the performance of the solid-state drive meets the preset conditions. Based on the work log recorded by the test tool each time it is optimized, test data is generated when exiting the loop.

5. The solid-state drive performance testing method according to claim 4, characterized in that, The performance testing process for the solid-state drive includes: Obtain multiple test cases and their execution order from the configuration file; Generate multiple test commands based on the test cases; Execute multiple test commands in the specified execution order to obtain multiple second performance parameters.

6. The solid-state drive performance testing method according to claim 4, characterized in that, The solid-state drive is subjected to performance testing according to the configuration file to obtain test data, which also includes: For each group of second performance parameters, determine whether each second performance parameter in that group is within the corresponding second range, and whether the fluctuation of each second performance parameter in multiple groups of second performance parameters exceeds the preset stability threshold. If each second performance parameter is within its corresponding second range and the fluctuation of each second performance parameter is less than a preset stability threshold, then the hard drive performance of the solid-state drive is determined to meet the preset conditions. If at least one second performance parameter is outside the corresponding second range, or if the fluctuation of at least one second performance parameter is greater than the preset stability threshold, the hard drive performance is determined to not meet the preset conditions.

7. The solid-state drive performance testing method according to claim 1, characterized in that, Obtain the hard drive information of the solid-state drive to be tested, including: Obtain a list of hard drives, which includes information about multiple solid-state drives; Candidate solid-state drives (SSDs) that support preset protocols are selected based on information from multiple SSDs. Determine whether there is a solid-state drive among the candidate solid-state drives that matches the drive information; If a candidate solid-state drive (SSD) exists that matches the drive information, the SSD corresponding to the drive information is formatted. Obtain information about the formatted solid-state drive as the drive information.

8. A performance testing device for a solid-state drive, characterized in that, include: The acquisition module is used to obtain the hard drive information and configuration files of the solid-state drive to be tested. The calling module is used to call the test process of the test tool so that the test process can build a steady-state environment for the solid-state drive corresponding to the hard disk information according to the configuration file and obtain the first performance parameters of the solid-state drive during the steady-state environment construction process. The determination module is used to determine whether the fluctuation of the first performance parameter meets the preset conditions; The testing module is used to determine whether the fluctuation of the first performance parameter meets the preset conditions, and to perform performance testing on the solid-state drive according to the configuration file to obtain test data.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in a memory, it implements the performance testing method for a solid-state drive as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program for a solid-state drive performance testing method, which, when executed by a processor, implements the steps of the solid-state drive performance testing method according to any one of claims 1-7.

Images