April 25, 2019

Hardware Notes: Hard Drive Benchmarking With iozone - page 2

Modern machines: clockspeed is only part of the picture

  • February 22, 2001
  • By Lou Grinzo

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 -i1
Which 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:

writes: 72MB/sec
rewrite: 80MB/sec
reads: 61MB/sec
rereads: 170MB/sec.

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:

writes: 9.2MB/sec
rewrite: 13MB/sec
reads: 59MB/sec
rereads: 174MB/sec.

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:

writes: 5.5MB/sec
rewrite: 4.3MB/sec
reads: 6.7MB/sec
rereads: 4.4MB/sec.

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).

Most Popular LinuxPlanet Stories