Dang Luong

Tips for Simplifying Performance Tests with vdbench

Blog Post created by Dang Luong on Jun 18, 2015

Vdbench is my favorite performance benchmark tool for very good reasons. The Performance Team uses it extensively for their testing. We use it as much as possible on PoCs, especially when customers don’t have a preference. I’d like to share with you some features of vdbench that make it such a handy tool.

 

The version I use is 5.04.01. It is available for free on the Oracle Technology Network at http://www.oracle.com/technetwork/server-storage/vdbench-downloads-1901681.html. If you are using an older version, please be aware that some features might not be available.


Deduplication & Compression

Vdbench can generate datasets with a specific amount of de-duplicable and/or compressible percentage. This is useful if you need to validate a solution’s deduplication or compression capability. Another bonus is that vdbench can do this against raw devices or file systems.

 

Here’s a run file that includes 20% deduplication and 10% compression.

 

compratio=10

dedupratio=20

 

sd=default,threads=1,openflags=o_direct,size=1048575m

sd=sd1,lun=/dev/mapper/vol1p1

 

wd=wd1,sd=*,rdpct=0,xfersize=512k,seekpct=0

 

rd=rd1,wd=wd1,iorate=max,elapsed=10m,interval=5

 

Please note that these parameters are run-wide, meaning deduplication and compression can’t be targeted to some devices and not others nor some workloads and not others.

 

Flexible Units

Vdbench automatically converts different units for capacity and time. If you wanted to specify the size parameter for an 1TB device, any of these values will work:

 

  • size = 1099511627776 (Default unit for capacity is bytes so if no suffix is specified, vdbench will assume bytes)
  • size = 1073741824k
  • size = 1048576m
  • size = 1024g
  • size = 1t

 

For time, vdbench understands seconds (default), minutes, and hours. The following options are all the same:

 

  • elapsed = 3600
  • elapsed = 60m
  • elapsed = 1h

 

A pretty simple feature but it can help make run files easier to understand at a glance.

 

For Loops

A common request on performance PoCs is to run a workload with multiple iterations where a parameter changes on each iteration. For example, a customer wants to find out an array’s performance characteristics at 25% read, 50% read, 75%, and 100% read. We could create four separate run files to do this. However, the more efficient way is to take advantage of the forrdpct parameter.

 

To accomplish the goal above, you could use this run file:

 

sd=default,threads=1,openflags=o_direct,size=1048575m

sd=sd1,lun=/dev/mapper/vol1p1

 

wd=wd1,sd=*,rdpct=0,xfersize=512k,seekpct=0

 

rd=rd1,wd=wd1,iorate=max,forrdpct=(25-100,25),elapsed=60m,interval=5,pause=5m

 

This tells vdbench to start the first run with 25% read, run it for 60minutes, pause for 5 minutes. Then in subsequent runs, increase the read amount with another 25%. After the 100% read case completes, the whole test run concludes.

 

Note that in the example above, the rdpct parameter in the Workload Definition is ignored. The “for” parameters will override the equivalent parameters defined in SD or WD.

 

There are other “for” parameters that could be used well: forxfersize, forthreads, fordpct, forrhpct, etc… If there are more than one “for” used in a RD, vdbench treats them as nested loops. The order that they are listed in the RD is the nesting order.

 

Take this RD for example:

 

rd=rd1,wd=wd1,iorate=max,forxfersize=(64k,128k,256k),forrdpct=(25-100,25),elapsed=60m,interval=5,pause=5m

 

The run sequence will be as follow:

 

  1. 64k transfer size & 25% read
  2. 64k transfer size & 50% read
  3. 64k transfer size & 75% read
  4. 64k transfer size & 100% read
  5. 128k transfer size & 25% read
  6. 128k transfer size & 50% read
  7. 128k transfer size & 75% read
  8. 128k transfer size & 100% read
  9. 256k transfer size & 25% read
  10. 256k transfer size & 50% read
  11. 256k transfer size & 75% read
  12. 256k transfer size & 100% read

 

Wildcards

This is another feature that makes for easier to read run files. Here are some examples on how to use wildcards.

 

Example 1) Run workload to all devices

 

sd=default,threads=1,openflags=o_direct,size=1048575m

sd=sd1,lun=/dev/mapper/vol1p1

sd=sd2,lun=/dev/mapper/vol2p1

sd=sd3,lun=/dev/mapper/vol3p1

sd=sd4,lun=/dev/mapper/vol4p1

 

wd=wd1,sd=*,rdpct=0,xfersize=512k,seekpct=0

 

rd=rd1,wd=wd1,iorate=max,elapsed=60m,interval=5,pause=5m

 

In the WD section, I used “sd=*” instead of “sd=(sd1-sd4)” or “sd=(sd1,sd2,sd3,sd4)”.

 

If there were multiple WDs and I wanted to run them all at once, I could use this RD as well:

 

rd=rd1,wd=*,iorate=max,elapsed=60m,interval=5,pause=5m

 

Example 2) Create sequence of devices

 

sd=default,threads=1,openflags=o_direct,size=1048575m

sd=sd,lun=/dev/mapper/vol*p1,count=(1,5)

 

wd=wd1,sd=*,rdpct=0,xfersize=512k,seekpct=0

 

rd=rd1,wd=wd1,iorate=max,elapsed=60m,interval=5,pause=5m

 

Rather than manually defining SDs for each device, I used a wildcard and the count parameter to automate it. Note that this will create up max (as defined in the count parameter) minus 1. My example will create four SDs: sd1, sd2, sd3, and sd4.

 

Default Definitions

All vdbench definitions, e.g. HD, SD, WD, can have a default set of parameters. The advantages of this feature are: 1) cleaner run files and 2) single place to change parameters for multiple objects.

 

The following is a run file for a multi-host test:

 

hd=default,vdbench=/opt/vdbench50401/,shell=ssh,user=root

hd=host1,system=172.17.100.26

hd=host2,system=172.17.100.27

hd=host3,system=172.17.100.28

 

sd=default,threads=8,openflags=o_direct,size=1023g

sd=sd,lun=/dev/mapper/vol*p1,count=(1,12)

 

wd=wd1,sd=*,rdpct=100,xfersize=55k,rhpct=80,skew=60

wd=wd2,sd=*,rdpct=0,xfersize=27k,whpct=80,skew=40

 

rd=rd1,wd=*,iorate=max,elapsed=1800,forseekpct=(30,40,50,60,70,80,90),interval=1,pause=60

 

There are 3 test hosts. Everything about them is the same except for their IP address so I specified a default HD for the common values. The IP addresses, which are unique, are the only parameters specified in the individual HDs. The same is true with the devices being tested. With the default SD, I could change the thread count, size, or any other SD parameter in a single place.

 

Specify Output at Run Time

Take advantage of the run time switch “-o” to save the output to a different directory each time. By default, vdbench will save the output to a subfolder called “output”. Any content in there will be overwritten. I have gotten into the habit of simply appending “-o /data/testX” to every test. Now I don’t have to worry about overwriting existing test results or finding data after a while because I know exactly where they went.

 

Conclusion

Vdbench is a very flexible and powerful tool. Even after several years, I am still finding new tricks every time I use it on a project. I am sure there are many more cool things that vdbench could do that I haven’t discovered. If you have your own vdbench tips, please do share!

Outcomes