Filesystem Benchmark Tool
Total Page:16
File Type:pdf, Size:1020Kb
Masaryk University Faculty of Informatics Filesystem Benchmark Tool Bachelor’s Thesis Tomáš Zvoník Brno, Spring 2019 Masaryk University Faculty of Informatics Filesystem Benchmark Tool Bachelor’s Thesis Tomáš Zvoník Brno, Spring 2019 This is where a copy of the official signed thesis assignment and a copy ofthe Statement of an Author is located in the printed version of the document. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Tomáš Zvoník Advisor: RNDr. Lukáš Hejtmánek, Ph.D. i Acknowledgements I would like to thank my thesis leader Lukáš Hejtmánek for guiding me through the process of creating this work. I would also like to thank my family and friends for being by my side, providing support, laughs and overall a nice environment to be in. Lastly I would like to thank my parents for supporting me throughout my whole life and giving me the opportunity to study at a university. ii Abstract In this thesis I have created a filesystem benchmark tool that com- bines best features of already existing tools. It can measure read/write speeds as well as speed of metadata operations. It can run on multi- ple threads and on multiple network connected nodes. I have then used my benchmark tool to compare performance of different storage devices and file systems. iii Keywords benchmark, file, system, iozone, fio, bonnie++ iv Contents Introduction 1 1 Existing benchmarks 3 1.1 IOzone ............................. 3 1.2 Fio ............................... 5 1.3 Bonnie++ ........................... 6 1.4 Comparison of features provided by different benchmarks .. 7 2 My benchmark 8 2.1 Used libraries ......................... 8 2.1.1 LibSSH . 8 2.2 How it works ......................... 9 2.2.1 User input . 10 2.2.2 Reporting to user . 10 2.2.3 Multinode communication . 11 2.2.4 Performing a benchmark . 12 2.2.5 Benchmarks . 14 3 Using the software 16 3.1 Comparison of different benchmarks in read/write measure- ments ............................. 16 3.2 Comparison of different file systems using my benchmark .. 18 3.3 Comparison of HDD vs SSD performance .......... 20 4 Future work 23 5 Conclusion 24 Bibliography 25 v Introduction Everyone who uses a computer also uses storage devices. Whether it be flash drives, hard drives or cloud, we expect them to workand be reasonably fast when it comes to read/write speeds. Read speeds meaning how fast a file can be read by the computer and write speeds meaning how fast it can be written to. The average user can look at the speeds advertised by the manu- facturer and expect the storage device to operate more or less at that speed. Unlike these users, system administrators cannot just look at the box their hard drive came in and accept the speeds written there. They might put the drives in RAID arrays1, use a different file sys- tem than the manufacturer, or have multiple machines connected to it at the same time. All of these practices might have an impact on the storage device’s performance. You also cannot entirely trust the man- ufacturer with the hardware speeds, they usually test performance in a laboratory with perfect conditions, so it is almost impossible to achieve same results in real world environments. System administra- tors need to know exactly what performance they can expect from their machines, which is why benchmarks2 exist. Goal of my thesis is to create a benchmarking tool that combines best parts of already existing benchmarking solutions. My benchmark can measure read/write speeds as well as speed of metadata opera- tions3. The software is also able to run on multiple network connected computers simultaneously to test the performance of storage space which is connected to multiple computers at once. All parameters (file size, file count, number of threads and number of connected comput- ers to run on) are configurable by the user. 1. RAID is short for redundant array of independent disks. Originally, the term RAID was defined as redundant array of inexpensive disks, but now it usually refers to a redundant array of independent disks. RAID storage uses multiple disks in order to provide fault tolerance, to improve overall performance, and to increase storage capacity in a system. This is in contrast with older storage devices that used only a single disk drive to store data. [1] 2. In computing, a benchmark is the act of running a computer program, a set of programs, or other operations, in order to assess the relative performance of an object, normally by running a number of standard tests and trials against it. [2] 3. Speed of operations move, delete, create. 1 I have divided my thesis into 4 main chapters. In the first chapter I write about existing benchmarks and how mine is different. In the second chapter I go into more detail about my implementation. In the third chapter I have compiled results from different measurements of storage performance and wrote how different strategies of storage management impact usability. In the last chapter I talk a bit about what could be improved upon in my software. 2 1 Existing benchmarks There are of course existing solutions for benchmarking file system performance. I will introduce 3 well known benchmark tools for Unix- like operating systems1. The most commonly used feature of these benchmarks is measuring read/write performance, which is a func- tionality all of these solutions provide. Not all of them however pro- vide the option to measure speed of metadata operations, which can be also very useful to know. 1.1 IOzone IOzone can measure the following tasks: read, write, re-read, re-write, read backwards, read strided, random read/write, read/write with offset. I will focus only on read and write because my benchmark does not implement the other tests. Read measures speed of reading data from a file with specified block size2. Write measures speed of writing data to a file with specified block size. It can also run these benchmarks on multiple threads and nodes. IOzone uses only one file per thread and must be run with the number of threads equal to or greater than the number of nodes the benchmark is run on. This benchmark tool is written in ANSII C and uses POSIX3 stan- dards, so it is possible to run it on just about anything. It is considered one of the best open source file system benchmarks. 1. The term Unix-like is widely used to describe operating systems that share many of the characteristics of the original UNIX, which was written in 1969 by Ken Thompson at Bell Labs, and its early successors. [3] These include Linux, BSD and MacOS. 2. Block size means the size of data that can be read from/written to a file at one time. 3. POSIX is an acronym for Portable Operating System Interface for UNIX, a set of IEEE and ISO standards that define an interface between programs and operating systems. [4] 3 1. Existing benchmarks Other useful features include export of results into Excel importable file, possibility of async4and DIRECT5 I/O operations, whether to include close() and fsync() into the measurement and so on. [6] Of course it is also possible to specify desired file size and block size, however it is not possible to specify number of files to be used, that is set to one file per thread. IOzone uses RSH to connect to network clients and execute com- mands by default, but can be configured to use SSH. For network communication to work, connections must not prompt for password when connecting via RSH/SSH. Via this connection benchmarks are not just started, but synchronized as well, ensuring that every bench- mark starts on all nodes at the same time. Multithreaded benchmarking is managed by using POSIX thread library pthread. Since IOzone uses POSIX library, standard open(), write() and read() functions are used to work with files. DIRECT I/O is accomplished by passing O_DIRECT flag when opening a file descriptor. DIRECT I/O is a way of accessing storage device directly, without use of cache. This can be useful when you want to measure perfor- mance when cache runs out or if you use direct access by default on your server. Direct access can be useful when storage device is faster than system RAM. This situation can happen when you have thou- sands of hard drives in a RAID array (provided your RAID controller is fast enough), or more recently even by having only a few NVMe SSDs in RAID 0. ASYNC I/O is done by calling functions aio_write and aio_read which are both defined in standard header aio.h. These functions create a queue of I/O operations with possibility of specifying impor- tance of each operation. This queue is then processed in the background and the main program can find out if/which have been completed when it needs to. [7] 4. Async I/O means the I/O operation is run asynchronously, meaning it does not have to wait for the program to tell it what to do. The I/O operation is run “in the background” while the main program continues. The program can then ask if the operation has been completed before continuing. 5. DIRECT I/O operations write directly to the disk without utilizing RAM as cache. [5] 4 1. Existing benchmarks IOzone is written mainly in C and is distributed under its own open license.