dbench

How to install dbench

  1. Clone dbench from its git repo

    1
    # git clone git://git.samba.org/sahlberg/dbench.git dbench
  2. Compiling

    1
    2
    3
    4
    5
    # cd dbench
    # ./autogen.sh
    # ./configure
    # make
    # make install

And that should be it. You should now have dbench installed on your system.

Features and Functions

  • Reading SMBTORTURE BENCH-NBENCH loadfiles and emulating this workload as posix calls to a local filesystem
  • NFS style loadfiles which allows DBENCH to mimic the i/o pattern of a real application doing real i/o to a real server.
  • iSCSI support and iSCSI style loadfiles.

DBENCH is a tool to generate I/O workloads to either a filesystem or to a networked CIFS or NFS server. It can even talk to an iSCSI target. DBENCH can be used to stress a filesystem or a server to see which workload it becomes saturated and can also be used for preditcion analysis to determine “How many concurrent clients/applications performing this workload can my server handle before response starts to lag?”

DBENCH provides a similar benchmarking and client emulation that is implemented in SMBTORTURE using the BENCH-NBENCH test for CIFS, but DBENCH can play these loadfiles onto a local filesystem instead of to a CIFS server. Using a different type of loadfiles DBENCH can also generate and measure latency for NFS.

Load files

At the heart of DBENCH is the concept of a “loadfile”. A loadfile is a sequence of operations to be performed once statement at a time. This could be operations such as “Open file XYZ”, “Read 5 bytes from offset ABC”, “Close the file”, etc etc.

By carefully crafting a loadfile it is possible to describe an I/O pattern that almost exactly matches what a particular application performs. While cumbersome to produce, such a loadfile it does allow you to describe exactly how/what an application performs and “replay” this sequence of operations any time you want.

Each line in the DBENCH loadfile contain a timestamp for the operation. This is used by DBENCH to try to keep the same rate of operations as the original application. This is very useful since this allows to perform accurate scalability predictions based on the exact application we are interested in. and not an artificial benchmark which may or may not be relevant to our particular applications workload pattern.

At https://dbench.samba.org/web/index.html you can find three loadfile template to use:

  • pNFS-Loadfiles - used to stress the NFS server.
  • SMB-Loadfiles - used to stress the SMB server.
  • iSCSI-Loadfiles - used to stress the iSCSI server.

How to use dbench

The following command should be OK for most of the testing situations(run dbench for 10 hours):

1
# dbench -c /usr/share/dbench/client.txt -D ./ -t 36000 10

Note:
This command stress the local filesystem, if you want to stress a NFS/SMB/iSCSI server, please learn more about dbench.

Results analysis

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
# dbench -c /usr/share/dbench/client.txt -D ./ -t 10 100
dbench version 4.00 - Copyright Andrew Tridgell 1999-2004

Running for 10 seconds with load '/usr/share/dbench/client.txt' and minimum warmup 2 secs
98 of 100 processes prepared for launch 0 sec
100 of 100 processes prepared for launch 0 sec
releasing clients
100 459 1293.98 MB/sec warmup 1 sec latency 527.022 ms
100 495 38.88 MB/sec execute 1 sec latency 1261.032 ms
100 509 36.37 MB/sec execute 2 sec latency 750.145 ms
100 521 33.32 MB/sec execute 3 sec latency 496.452 ms
100 545 35.34 MB/sec execute 4 sec latency 604.592 ms
100 660 43.13 MB/sec execute 5 sec latency 402.810 ms
100 744 43.04 MB/sec execute 6 sec latency 407.184 ms
100 764 40.13 MB/sec execute 7 sec latency 1061.093 ms
100 797 38.65 MB/sec execute 8 sec latency 2061.173 ms
100 820 36.10 MB/sec execute 9 sec latency 2152.252 ms
100 cleanup 10 sec
26 cleanup 11 sec
20 cleanup 12 sec
18 cleanup 13 sec
11 cleanup 14 sec
0 cleanup 15 sec

Operation Count AvgLat MaxLat
--------------------------------------------------
Flush 710 219.169 2152.244
Close 5848 0.003 2.262
LockX 4 0.004 0.009
Rename 284 0.048 3.412
ReadX 7792 0.106 178.973
WriteX 7966 106.556 783.949
Unlink 671 1.879 129.409
UnlockX 4 0.002 0.003
FIND_FIRST 1991 0.026 4.002
SET_FILE_INFORMATION 869 8.582 481.309
QUERY_FILE_INFORMATION 2099 0.002 0.089
QUERY_PATH_INFORMATION 5677 0.021 69.872
QUERY_FS_INFORMATION 835 0.003 0.020
NTCreateX 6822 1.191 200.957

Throughput 36.0963 MB/sec 100 clients 100 procs max_latency=2152.252 ms

It gives out four numbers like this (this is from a 100 client run on fedora22 host):
`sh Throughput 36.0963 MB/sec 100 clients 100 procs max_latency=2152.252 ms

The first is the true throughput as seen by dbench, the larger the batter. The last is the I/O latency, the smaller the better.

Note:
One question some people may ask is whether the above represents a realistic load on a fileserver. It doesn’t. Nearly 90% of the read/write IO operations in netbench are writes whereas in a “normal” office load reads dominate. Also, the load is much higher than a normal office PC would put on a server. There aren’t many office PCs that write over a hundred megabytes of data to a server in a few minutes, unless maybe they are copying a CD.

That doesn’t mean the benchmark is useless, it just means you shouldn’t use this for purchasing decisions unless you really understand the results and how they relate to your environment.

The main parameters

  • -c - Use this as the full path name of the client.txt file (the default is /usr/share/dbench/client.txt).
  • -s - Use synchronous file IO on all file operations(O_SYNC).
  • -t TIME - set the runtime of the benchmark in seconds (default 600).
  • -D DIR - set the base directory to run the filesystem operations in.
  • -S - Use synchronous IO for all directory operations (unlink, rmdir, mkdir and rename).
  • -F - fsync on write
  • -B BACKEND - dbench backend (fileio, sockio, nfs, scsi, iscsi, smb)

Reference