SSD test first artifact - FIO

 

Original address http://www.ssdfans.com/ssd%E6%B5%8B%E8%AF%95%E7%AC%AC%E4%B8%80%E7%A5%9E%E5%99%A8- fio-2/

For SSD performance testing, the best tool is FIO.

 

The lovely young man above is named Jens Axboe. He is a student who did not graduate from the Department of Computer Science at the University of Copenhagen in Denmark. He also has a famous fellow named Linus. Jens is 40 years old this year (2017), and has been in contact with Linux since the age of 16. Later, he became a Linux developer. Now he is the master of Linux Kernel, responsible for the maintenance of the block device layer. This block device layer is the layer most closely related to our SSD, connecting the upper file system and the lower device driver. He has developed many useful programs, such as Deadline in Linux IO Scheduler, CFQ Scheduler, and the famous ace test tool FIO. Jens used to work in Fusion-IO, Oracle and other companies, and now he is at Facebook. Dumb heard that Facebook has the highest salary for code farmers in Silicon Valley.

 

FIO is an open source testing tool developed by Jens with very powerful functions. This article only introduces some of the basic functions.

 

Thread, Queue Depth, Offset, Synchronous Asynchronous, DirectIO, BIO

 

Before using FIO, you must first have some basic knowledge of SSD performance testing.

 

Thread refers to how many read or write tasks are executing in parallel at the same time. Generally speaking, a core in a CPU can only run one thread at a time. If there is only one core, if you want to run multiple threads, you can only use time slices, each thread runs for a period of time, and all threads use this core in turn. Linux uses Jiffies to represent how many time slices a second is divided into. Generally, Jiffies are 1000 or 100, so the time slice is 1 millisecond or 10 milliseconds.

 

Generally, it only takes a few microseconds for a computer to send a read and write command to the SSD, but it takes hundreds of microseconds or even a few milliseconds for the SSD to execute the command. If a read and write command is issued, then the thread sleeps all the time, waiting for the result to come back before waking up to process the result. This is called synchronous mode . It is conceivable that the synchronous mode is a waste of SSD performance, because there are many parallel units in the SSD. For example, there are 8-16 data channels in a general enterprise SSD, and each channel has 4-16 parallel logical units (LUN, Plane, etc.). ), so 32-256 read and write commands can be executed at the same time. Synchronous mode means that only one of the parallel units is working, which is a waste of time.

 

In order to improve parallelism, in most cases, SSD reads and writes use asynchronous mode . It is to send commands in a few microseconds. After the thread is sent, it will not wait there stupidly, but continue to send the following commands. If the previous command is executed, the SSD notification will inform the CPU through interrupts or polling, and the CPU will call the callback function of the command to process the result. The advantage of this is that everyone in the SSD can be divided into dozens or hundreds of parallel units, and the efficiency is greatly increased.

 

However, in asynchronous mode, the CPU cannot send commands to the SSD indefinitely. For example, if the SSD executes read and write, if there is a freeze, it is possible that the system will continue to send commands, thousands or even tens of thousands. On the one hand, the SSD cannot handle it, and on the other hand, so many commands will occupy a lot of memory. , the system will also hang up. In this way, there is a parameter called the queue depth . For example, a queue depth of 64 means that all commands sent by the system are sent to a queue with a size of 64. If it is full, it cannot be sent again. After the previous read and write commands have been executed, the queue can be vacated before continuing to fill in commands.

 

An SSD or a file has a size. When testing reading and writing, setting Offset can start the test from a certain offset address. For example, starting from the offset address of offset=4G.

 

When Linux reads and writes, the kernel maintains the cache, and the data is first written to the cache, and then written to the SSD in the background. When reading, the data in the cache is also read first. This can speed up the speed, but once the power is turned off, the data in the cache will be gone. So there is a mode called DirectIO , which skips the cache and reads and writes directly to the SSD.

 

Linux reads and writes SSD and other block devices using BIO , Block-IO, which is a data structure that includes the logical address LBA, data size, and memory address of the data block.

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325344301&siteId=291194637