All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: "P. Remek" <p.remek1@googlemail.com>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs performance, sudden drop to 0 IOPs
Date: Wed, 11 Feb 2015 07:40:24 -0500	[thread overview]
Message-ID: <54DB4DB8.2020705@gmail.com> (raw)
In-Reply-To: <CABdHLQ7QPjUbzqNdzCfR0QxC-0coYs0dofuFvsROYXy-M9u4ig@mail.gmail.com>

On 2015-02-09 12:26, P. Remek wrote:
> Hello,
>
> I am benchmarking Btrfs and when benchmarking random writes with fio
> utility, I noticed following two things:
>
Based on what I know about BTRFS, I think that these issues actually 
have distinct causes.
> 1) On first run when target file doesn't exist yet, perfromance is
> about 8000 IOPs. On second, and every other run, performance goes up
> to 70000 IOPs. Its massive difference. The target file is the one
> created during the first run.
I've noticed that almost always, file creation on BTRFS is slower than 
file re-writes.  This seems to especially be the case when using AIO 
and/or O_DIRECT (although O_DIRECT on a COW filesystem is _really_ 
complicated to get right).  I don't know that there is really any way 
currently to solve this, although it would be interesting to see if 
fallocat'ing the files prior to the initial run would have any 
significant performance impact.
>
> 2) There are windows during the test where IOPs drop to 0 and stay 0
> about 10 seconds and then it goes back again, and after couple of
> seconds again to 0. This is reproducible 100% times.
I've seen this same behavior on a number of filesystems (not just BTRFS) 
when using the default I/O scheduler with it's default parameters, 
especially on systems with high performance storage.  IIRC, Ubuntu 13.10 
switched from using the upstream default I/O scheduler (CFQ) to using 
the Deadline I/O scheduler because it has better performance (and is 
more deterministic) on most cheap commodity desktop/laptop hardware. 
I've found however that the Deadline scheduler actually tends to perform 
worse than CFQ when used on higher-end server systems and/or SSD's, 
although CFQ with default parameters only does marginally better.  I'd 
suggest experimenting with some of the parameters under /sys/block 
(check the files in the Documentation/block directory of the Linux 
kernel sources for information about what (almost) everything there does).


  parent reply	other threads:[~2015-02-11 12:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-09 17:26 btrfs performance, sudden drop to 0 IOPs P. Remek
2015-02-09 19:56 ` Kai Krakow
2015-02-09 22:21   ` P. Remek
2015-02-10  6:58     ` Kai Krakow
2015-02-10  4:42 ` Duncan
2015-02-10 17:44   ` P. Remek
2015-02-12  2:10     ` Duncan
2015-02-12  4:33       ` Kai Krakow
2015-02-12 12:21         ` Austin S Hemmelgarn
2015-02-12 19:42           ` Kai Krakow
2015-02-13 13:16             ` P. Remek
2015-02-13 18:26               ` Kai Krakow
2015-02-13 13:08           ` P. Remek
2015-02-13  2:46         ` Liu Bo
2015-02-13  3:55           ` Wang Shilong
2015-02-13 13:18             ` P. Remek
2015-02-11 12:40 ` Austin S Hemmelgarn [this message]
2015-02-12  4:59 ` Liu Bo
2015-02-13 13:06   ` P. Remek
2015-02-13 14:08     ` Liu Bo

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=54DB4DB8.2020705@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=p.remek1@googlemail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.