Hardware Notes: Hard Drive Benchmarking With iozone - page 2
Modern machines: clockspeed is only part of the picture
In the case of iozone, you can do a broad range of testing by specifying command-line options. After building iozone (cd to the src/current directory, then "make linux"), you should run the command "iozone -h", and read over the supported options. It's quite a list, and I won't begin to cover them all here, especially since they're detailed in the documentation, which is available in Acrobat/PDF, PostScript, nroff, and MS Word (gasp!) formats. But note that you can specify the size of the test file iozone reads from and writes to, the size of the records read and written, the kind of I/O operation to perform (more on this below), whether you want the results reported in throughput or disk operations per second, where to place the data file, and whether to create output in the form of a Microsoft Excel spreadsheet.
If you want to measure the raw disk performance, then the primary thing you have to contend with is disk caching. As an example, I performed an intentionally naï¿½ve iozone run on one of my test rigs running a stock install of Red Hat Linux 6.2, with the following command:
iozone -s 2048 -r 1 -i0 -i1Which translates to 2,048K test file size, record size of 1K, run tests 0 (write and rewrite) and 1 (read and reread). This told me that the bargain-basement EIDE drive in this system managed:
Pretty impressive, right? Well, it would be if it were accurate. Let's see what happens when we rerun that command and bump the data file size by a factor of 10 (change the -s option from 2048 to 20480). This time we get:
The read/reread numbers were virtually the same, but the write/rewrite numbers came down considerably, to much more reasonable numbers. The huge difference between read and write performance is easy to explain--on this system configuration and with this test, Linux's disk caching had less of an impact on the writes than it did on the reads as the data set increased. Bumping the data file size by another order of magnitude (-s 204800), shows:
Now we're getting somewhere, as we're exhausting the cache effects, particularly on read operations, not to mention our patience in waiting for this long test to complete. But again, this all comes back to the "what do you want to measure" issue. If you're most concerned about the raw disk performance, you want to factor out the effects of the OS as much as possible; if you're concerned with real world numbers, you want to use iozone to mimic your applications, in which case that amazing performance boost from caching might be a perfectly legitimate part of the results.
You can also use iozone to run other tests than the two mentioned above, the write/rewrite and read/reread operations. It also supports random reads and writes, which is an excellent way to simulate database activity and stress test your drive's actuator arm, and "stride reads", which cause iozone to read every Nth record (and yes, you can specify what N is through yet another command-line option).
- Skip Ahead
- 1. Modern machines: clockspeed is only part of the picture
- 2. Modern machines: clockspeed is only part of the picture
- 3. Modern machines: clockspeed is only part of the picture
- 1Linux Top 3: Fedora 24, Peppermint 7 and Solus 1.2
- 2Linux Top 3: Alpine Linux 3.4, deepin 15.2 and Linux Lite 3.0
- 3Linux 4.7 Set to Boost Live Patching, Security and Power Management
- 4Linux 4.6 Charred Weasel adds USB 3.1 Support
- 5Linux Top 3: OpenIndiana 2016.04, Ubuntu 16.04 and Debian's New Leader