Stan,
Thanks for the reply.
My fragmentation is:
[root@AP-FS1 ~]# xfs_db -c frag -r /dev/xvdb1
actual 10470159, ideal 10409782, fragmentation factor 0.58%
xfs_db> freesp
from to extents blocks pct
1 1 52343 52343 0.08
2 3 34774 86290 0.13
4 7 122028 732886 1.08
8 15 182345 1898531 2.80
16 31 147747 3300501 4.87
32 63 111134 4981898 7.35
64 127 93359 8475962 12.50
128 255 51914 9069884 13.38
256 511 25548 9200077 13.57
512 1023 23027 17482586 25.79
1024 2047 8662 10600931 15.64
2048 4095 808 1915158 2.82
The volume is 57% full.
I have removed allocsize=64m from the fstab and rebooted. These are not
large files and this could definitely cause issues.
Would copying them to new folder and renaming the folder back help?
This is running virtualized, definitely not a rust bucket. It's x5570 cpus
with MD3200 Array with light I/O.
Seems like i/o wait is not problem, system% is problem. Is this the OS
trying to find spot for these files?
Thanks
-----Original Message-----
From: Stan Hoeppner [mailto:stan@xxxxxxxxxxxxxxxxx]
Sent: Thursday, September 26, 2013 8:07 AM
To: Ronnie Tartar
Cc: xfs@xxxxxxxxxxx
Subject: Re: Issues and new to the group
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@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
