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

Technology