From: Stan Hoeppner <stan@hardwarefreak.com>
To: Ronnie Tartar <rtartar@host2max.com>
Cc: xfs@oss.sgi.com
Subject: Re: Issues and new to the group
Date: Thu, 26 Sep 2013 07:06:37 -0500 [thread overview]
Message-ID: <5244234D.1010603@hardwarefreak.com> (raw)
In-Reply-To: <0e4201cebaae$24873680$6d95a380$@host2max.com>
On 9/26/2013 6:47 AM, Ronnie Tartar wrote:
> I have a 600GB xfs file system mounted that suddenly started running slow on
> writes. It takes about 2.5 to 3.5 seconds to write a single file. Some
This typically occurs when the filesystem gets near full and free space
is heavily fragmented. Writing to these free space fragments requires
lots of seeking. Seeking causes latency. I assume your storage device
is spinning rust, yes?
> folders (with less number of files) work well. But it will copy fast, then
> slow for long periods of time.
Some allocation groups may have less fragmented free space than others.
Put another way, they may have more contiguous free space. Thus less
seeking.
> This is a virtualized CentOS 5.9 64 bit box
> on Citrix Xenserver 5.6SP2. Doesn't seem to be a load i/o issue as most of
> the load is system%. My fragmentation is less than 1 %. Any help would
> be greatly appreciated. I was looking to see if there was a better way to
> mount this partition or allocate more memory, whatever it takes. The
> folders are image folders that have anywhere between 5 to 10 million images
> in each folder.
> Fstab mount is:
> /dev/xvdb1 /images xfs
> defaults,nodiratime,nosuid,nodev,allocsize=64m 1 1
^^^^^^^^^^^^^
This tells XFS to allocate 64MB of free space at the end of each file
being allocated. If free space is heavily fragmented and the fragments
are all small, this will exacerbate the seek problem. Given the 64MB
allocsize, I assume these image files are quite large. If this is
correct, writing them over scattered small free space fragments also
requires seeking. Thus, I'd guess you're seeking your disk, or array,
to death.
How full is the XFS volume, and what does your free space fragmentation
map look like?
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-09-26 12:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-26 11:47 Issues and new to the group Ronnie Tartar
2013-09-26 12:06 ` Stan Hoeppner [this message]
2013-09-26 13:12 ` Ronnie Tartar
2013-09-26 13:30 ` Ronnie Tartar
2013-09-26 14:23 ` Eric Sandeen
2013-09-26 23:46 ` Stan Hoeppner
2013-09-26 14:59 ` Joe Landman
2013-09-26 15:26 ` Jay Ashworth
2013-09-26 22:47 ` Dave Chinner
2013-09-26 22:16 ` Dave Chinner
2013-09-27 2:17 ` Joe Landman
2013-09-27 2:39 ` Stan Hoeppner
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=5244234D.1010603@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=rtartar@host2max.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox