mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: Nikita Danilov <Nikita@Namesys.COM>
Cc: "E. Gryaznova" <grev@Namesys.COM>, linux-kernel@vger.kernel.org
Subject: Re: Can dbench be used for benchmarking fs?
Date: Tue, 7 Oct 2003 09:59:37 -0600	[thread overview]
Message-ID: <20031007095937.A1593@schatzie.adilger.int> (raw)
In-Reply-To: <16258.53615.17755.970961@laputa.namesys.com>; from Nikita@Namesys.COM on Tue, Oct 07, 2003 at 06:45:03PM +0400

On Oct 07, 2003  18:45 +0400, Nikita Danilov wrote:
> Andreas Dilger writes:
>  > On Oct 07, 2003  16:42 +0400, E. Gryaznova wrote:
>  > > I use dbench for benchmarking the file systems and some results are
>  > > suspicious for me.
>  > > :
>  > > :
>  > > :
>  > > As the result: the measuring deviation is equal = 23.4062 - 15.7005 =
>  > > 7.7057 or about ~38% from average value.
>  > > 
>  > > So, I have 2 questions :
>  > > 1. Is there a way to avoid such big deviations on measuring a file
>  > > systems throughput and to get more stable results?
>  > > 2. Can dbench be used for benchmarking the file systems and if it is so
>  > > -- what is the predictable error on the measuring?
>  > 
>  > Dbench is not a good filesystem benchmark, because it deletes all of the
>  > files at the end.  Use something else for the filesystem benchmark - there
> 
> Err... What is wrong with deleting all files at the end? Or do you mean
> it should mix file operations during run?
> 
>  > are lots of them (bonnie, iozone, mongo, etc).
> 
> But why variance is so large?

Dbench is a bad filesystem benchmark because if all (or some large part)
of the files are deleted before the VM flushes them to disk, then you are
not really testing filesystem performance very much.  If you have enough
RAM in your system and a fast enough CPU you could complete the entire
dbench run without ever writing any data to disk.  There is some filesystem
activity (you need to create files and map pages), but it isn't a good test
of filesystem throughput.

The reason there is so much variability in the tests is that if the test
takes even a small amount more time to run this means more data gets flushed
to disk by the VM (instead of being deleted and never written), making the
test run longer and even _more_ data needs to get written, etc.

Dbench is a good multi-threaded filesystem stress program, but it isn't
a good benchmark.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/


      reply	other threads:[~2003-10-07 16:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-07 12:42 E. Gryaznova
2003-10-07 14:29 ` Andreas Dilger
2003-10-07 14:45   ` Nikita Danilov
2003-10-07 15:59     ` Andreas Dilger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031007095937.A1593@schatzie.adilger.int \
    --to=adilger@clusterfs.com \
    --cc=Nikita@Namesys.COM \
    --cc=grev@Namesys.COM \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®