VDbench (so named for its creator, Henk Vandenbergh of Sun Microsystems, formerly StorageTek) is a truly incredible enterprise grade storage benchmark that is free and open source. In celebration of vdbench 5.02’s release I thought it time we discuss it.

One of the things I love about VDbench is that its implemented in Java. Its extremely portable (Windows, Solaris, Linux, AIX, OS/X and HP/UX) and includes a both GUI and CLI interfaces. For tools like this I love having a nice soft GUI to help get your feet wet and then a CLI for the real work… makes learning so much easier.

The GUI is accessed using the “-gui” argument (ie: vdbench -gui). Its use simplistic but helps you grasp the essentials. That is, you select some storage device to benchmark, then you modify a workload/run definition which describes what work will be preformed and how, and finally you execute a run.

The CLI is similar conceptually, you create a configuration file in which you define storage devices, workloads and run definitions. To execute the run you pass the config to “vdbench” and away it goes.

Lets start with a super simple config:

*Example 1: Single run, one raw disk

*SD:    Storage Definition
*WD:    Workload Definition
*RD:    Run Definition
*
sd=sd1,lun=/dev/rdsk/c0t0d0s0
wd=wd1,sd=sd1,xfersize=4096,rdpct=100
rd=run1,wd=wd1,iorate=100,elapsed=10,interval=1

First notice that we can insert comments with an asterisk. Next, we have 3 lines here:

• sd: Storage Device, this maps a name to a given physical device
• wd: Workload Definition, this describes the workload (read/write/block size/etc) and maps to one or more SD’s
• rd: Run Definition, this describes the run itself, mapping to a workload and describing how it run, such as interval, total length of the run, IOrate constraints, etc.

For simple configurations like that above you’ll likely only have these 3 lines, but as you get more complex you’ll add them. Try this bigger configuration on for size:

sd=sd1,lun=/dev/rdsk/c0t1d0s0
sd=sd2,lun=/dev/rdsk/c3t0d0s0

wd=randomWrite,sd=sd*,readpct=0,rhpct=0,seekpct=100         
wd=seqWrite,sd=sd*,readpct=0,rhpct=0,seekpct=0
wd=randomRead,sd=sd*,readpct=100,rhpct=0,seekpct=100
wd=seqRead,sd=sd*,readpct=100,rhpct=0,seekpct=0
wd=randomRW,sd=sd*,readpct=50,rhpct=0,seekpct=100

rd=default

* Random Performance Tests
rd=default,el=1m,in=6,forx=(4K),forth=(32),io=max,pause=20
rd=run1_randomReads,wd=randomRead
rd=run2_randomWries,wd=randomWrite
rd=run3_randomMix,wd=randomRW

* Sequential Performance Tests
rd=default,el=1m,in=6,forx=(512K),forth=(32),io=max,pause=20
rd=run4_seqReads,wd=seqRead
rd=run5_seqWrites,wd=seqWrite

Here we use 2 disks instead of one, and we have multiple runs defined. The result is each run going sequentially till its done. So first my random read test goes, when its done my random write test goes, and so on until all 5 runs are done.

Lets look closer at the workloads which may be confusing at first. Consider this: “readpct=100,seekpct=100” This says 100% Read and 100% Random (seek). So that’s a random read test. Whats strange at first is how you describe a sequential write test: “readpct=0,seekpct=0”. See where you could get confused? There is no “writepct” or “seqpct”. This may be odd but has advantages, for instance if you wanted a 60/40 R/W workload which is 50% random it would simply be: “readpct=60,seekpct=50”.

Here is a view of the output you’ll expect:

# ./vdbench.bash -f benr1 

Vdbench distribution: vdbench501fix1
For documentation, see 'vdbench.pdf'.
                                     
17:24:39.168 input argument scanned: '-fbenr1'
17:24:39.304 Starting slave      
17:24:39.616 All slaves are now connected
17:24:43.007 Starting RD=rd_rg-1; I/O rate: Uncontrolled MAX; Elapsed=10; For loops: threads=64
                                                                                               
Jan 26, 2010 interval        i/o   MB/sec   bytes   read     resp     resp     resp    cpu%  cpu%
                            rate  1024**2     i/o    pct     time      max   stddev sys+usr   sys
17:24:44.070        1   18382.00   143.61    8192  69.87    3.237  311.373   14.003    61.5  57.8
17:24:45.043        2   16803.00   131.27    8192  70.07    3.399  192.972   13.894    67.3  64.8
17:24:46.042        3   18560.00   145.00    8192  69.68    3.599  207.747   14.271    71.9  69.6
17:24:47.033        4   17956.00   140.28    8192  69.67    3.315  194.255   12.589    72.7  70.6
17:24:48.017        5   19263.00   150.49    8192  69.89    3.346  294.203   13.374    73.6  71.2
17:24:49.023        6   17014.00   132.92    8192  69.72    3.502  220.248   13.466    68.7  66.7
17:24:50.041        7   19367.00   151.30    8192  69.49    3.453  301.330   14.010    72.2  70.0
17:24:51.039        8   15713.00   122.76    8192  69.74    4.011  279.812   16.980    61.0  59.2
17:24:52.039        9   18643.00   145.65    8192  70.44    3.230  226.911   13.323    70.8  68.9
17:24:53.021       10   16376.00   127.94    8192  69.82    3.940  224.594   14.232    69.5  67.2
17:24:53.032 avg_2-10   17743.89   138.62    8192  69.84    3.520  301.330   14.015    69.7  67.6
17:24:53.663 Slave localhost-0 terminated                                                        
17:24:53.697 Vdbench execution completed successfully. Output directory: /root/VD/output

In addition to doing raw tests it can also preform filesystem based workloads (similar but more primitive than Filebench in this respect). Using its sister-application “SWAT” you can trace I/O and replay it through vdbench. And all sorts of other crazy fun things. Best of all is that it has a fantastic PDF manual to help you understand all the essentials.

Over the last year or so I’ve become a huge fan of the tool. Particularly for testing raw storage, its simply awesome to get reliable and repeatable results for device capabilities which can then be used for math in architecting solutions. When you pair up this tool with FileBench you can build a very fine-grained and realistic testbed.