From: Stan Hoeppner <stan@hardwarefreak.com>
To: Brian Cain <brian.cain@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: Consistent throughput challenge -- fragmentation?
Date: Mon, 25 Feb 2013 15:39:54 -0600 [thread overview]
Message-ID: <512BDA2A.5050600@hardwarefreak.com> (raw)
In-Reply-To: <CAEWpfG_DKJt1MmWS1tARH4OmYwpSt=A-DzwKkGcD67LuR6k=Bg@mail.gmail.com>
On 2/25/2013 10:01 AM, Brian Cain wrote:
> All,
>
> I have been observing some odd behavior regarding write throughput to an
> XFS partition (the baseline kernel version is 2.6.32.27). I see
> consistently high write throughput (close to the performance of the raw
> block device) to the filesystem immediately after a mkfs, but after a few
> test cycles, there is sporadic poor performance.
>
> The test mechanism is like so:
>
> [mkfs.xfs <blockdev>] (no flags/options, xfsprogs ver 3.1.1-0.1.36)
> ...
> 1. remove a previous test cycle's directory
> 2. create a new directory
> 3. open/write/close a small file (4kb) in this directory
> 4. open/read/close this same small file (by the local NFS server)
> 5. open[O_DIRECT]/write/write/write/.../close a large file (anywhere from
> ~100MB to 200GB)
>
> Step #5 contains the high-throughput metrics which becomes an order of
> magnitude worse several test cycles after a mkfs. Omitting steps 1-3 does
> not show the poor performance behavior.
>
> Can anyone provide any suggestions as to an explanation for the behavior or
> a way to mitigate it? Running xfs_fsr didn't seem to improve the results.
The usual cause of such aged filesystem low performance is free space
fragmentation. xfs_fsr will defragment files, but in doing so it
*increases* free space fragmentation, thus won't help the situation.
> I'm happy to share benchmarks, specific results data, or describe the
> hardware being used for the measurements if it's helpful.
Paste the output of 'xfs_db -r -c freesp /dev/[device]' just before you
do the large file write. This will show us the free space distribution
histogram.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-02-25 21:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-25 16:01 Consistent throughput challenge -- fragmentation? Brian Cain
2013-02-25 21:39 ` Stan Hoeppner [this message]
2013-02-25 22:06 ` Brian Cain
2013-02-25 22:38 ` Brian Cain
2013-02-25 22:16 ` Dave Chinner
2013-02-25 22:18 ` Brian Cain
2013-02-25 22:23 ` Brian Cain
2013-02-25 23:46 ` Dave Chinner
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=512BDA2A.5050600@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=brian.cain@gmail.com \
--cc=xfs@oss.sgi.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.