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:

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