VDbench: The Amazing Swiss Army Knife of Benchmarks
Posted on February 21, 2010
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.