Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Liu Bo <bo.li.liu@oracle.com>
To: "P. Remek" <p.remek1@googlemail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs performance, sudden drop to 0 IOPs
Date: Fri, 13 Feb 2015 22:08:42 +0800	[thread overview]
Message-ID: <20150213140842.GE25697@localhost.localdomain> (raw)
In-Reply-To: <CABdHLQ5JwhizkAPA8GUFf_hBH4_LO4yJV5qkf+sRiNFG90oMGg@mail.gmail.com>

On Fri, Feb 13, 2015 at 02:06:27PM +0100, P. Remek wrote:
> > I'd use a blktrace based tool like iowatcher or seekwatcher to see
> > what's really happening on the performance drops.
> 
> So I used this command to see if there are any outstanding requests in
> the I/O scheduler queue when the performance drops to 0 IOPs
> root@lab1:/# iostat -c -d -x -t -m /dev/sdi 1 10000
> 
> The output is:
> 
> Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s
> avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
> 
> sdi               0.00     0.00    0.00    0.00     0.00     0.00
> 0.00     0.00    0.00    0.00    0.00   0.00   0.00
> 
> "avgqu-sz" gives the queue length (1 second avarage). So really it
> seems that the system is not stuck in the Block I/O layer but in upper
> layer instead (most likely filesystem layer).
> 
> I also created ext4 filesystem on another pair of disks - so I was
> able to run simultaneous benchmark - one for ext4 and one for btrfs
> (each having 4 SSDs assigned) and when btrfs went down to 0 IOPs the
> ext4 fio benchmark kept generating high IOPs.
> 
> I also tried to mount the system with nodatacow:
> 
> /dev/sdi on /mnt/btrfs type btrfs (rw,nodatacow)
> 
> It didn't help with the performance drops.

It's just weird since 10s is too much for filesystems, I don't know
what's happening and didn't have such an experience in my tests,

Perhaps Try "perf record -a -g" to see magic.

Thanks,

-liubo

      reply	other threads:[~2015-02-13 14:08 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
2015-02-12  4:59 ` Liu Bo
2015-02-13 13:06   ` P. Remek
2015-02-13 14:08     ` Liu Bo [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=20150213140842.GE25697@localhost.localdomain \
    --to=bo.li.liu@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox