Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?)

[Stan Hoeppner <stan@hardwarefreak.com>]

On 4/10/2012 3:43 PM, Stefan Ring wrote:
> I don’t want to be expected to hand-tune every damn thing.

You don't.

>> $ mkfs.xfs -d agcount=3 /dev/[device]

> With a nice and tidy fresh XFS file system, performance is indeed
> impressive – about 16 sec for the same task that would take 2 min 25
> before.

9x improvement in your workload.  First problem down.  What was the
runtime for EXT4 here?  Less than 16 seconds?

>>> and doesn’t seem to cope well with fragmented free space (which
>>> is what this entire thread is really about),

>> Did you retest fragmented freespace writes

> Yes, I did this. It performed very well. Only slightly slower than on
> a completely empty file system.

2nd problem down.  So the concat is your solution, no?  If not, what's
still missing?

BTW, concats don't have parity thus no RMW, so with the concat setup you
should set 100% of the P400 cache to writes.  The 25% you had for reads
definitely helps RAID6 RMW, but yields no benefit for concat.  Bump
write cache to 100% and you'll gain a little more XFS concat
performance.  And if by chance there is some weird logic in the P400
firmware, dedicating 100% to write cache may magically blow the doors
off.  I'm guessing I'm not the only one here to have seen odd magical
settings values like this at least once, though not necessarily with
RAID cache.

Even if not magical, in addition to increasing write cache size by 25%,
you will also increase write cache bandwidth with your high allocation
workload, as metadata free space lookups won't get cached by the
controller.  And given that sector write ordering is an apparent problem
currently, having this extra size and bandwidth may put you over the top.

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs