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
prev parent 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