xfs
[Top] [All Lists]

Re: agsize and performance

To: K T <mailkarthikt@xxxxxxxxx>
Subject: Re: agsize and performance
From: Matthias Schniedermeyer <ms@xxxxxxx>
Date: Wed, 30 Oct 2013 10:59:03 +0100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CALtWs4-q==CXVZ=jjRnrZGANP98y2Gyot_DV_hGTgxQoRF25UA@xxxxxxxxxxxxxx>
References: <CALtWs4-q==CXVZ=jjRnrZGANP98y2Gyot_DV_hGTgxQoRF25UA@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On 29.10.2013 18:10, K T wrote:
> Hi,
> 
> I have a 1 TB SATA disk(WD1003FBYX) with XFS. In my tests, I preallocate a
> bunch of 10GB files and write data to the files one at a time. I have
> observed that the default mkfs setting(4 AGs) gives very low throughput.
> When I reformat the disk with a agsize of 256mb(agcount=3726), I see better
> throughput. I thought with a bigger agsize, the files will be made of fewer
> extents and hence perform better(due to lesser entries in the extent map
> getting updated). But, according to my tests, the opposite seems to be
> true. Can you please explain why this the case? Am I missing something?
> 
> My test parameters:
> 
> mkfs.xfs -f /dev/sdbf1
> mount  -o inode64 /dev/sdbf1 /mnt/test
> fallocate -l 10G fname
> dd if=/dev/zero of=fname bs=2M count=64 oflag=direct,sync conv=notrunc seek=0

I get the same bad performance with your dd statement.

fallocate -l 10G fname
time dd if=/dev/zero of=fname bs=2M count=64 oflag=direct,sync conv=notrunc 
seek=0
64+0 records in
64+0 records out
134217728 bytes (134 MB) copied, 4,24088 s, 31,6 MB/s

After pondering the really hard to read dd-man-page.
Sync is for 'synchronized' I/O. aka REALLY BAD PERFORMANCE. And i assume 
you don't really that.

I think what you meant is fsync. (a.k.a. File (and Metadata) has hit 
stable-storage before dd exits).
That is: conv=fsync

So:
time dd if=/dev/zero of=fname bs=2M count=64 oflag=direct conv=notrunc,fsync 
seek=0
64+0 records in
64+0 records out
134217728 bytes (134 MB) copied, 1,44088 s, 93,2 MB/s

That gets much better performance, and in my case it can't get any 
better because the HDD (and encryption) just can't go any faster.




-- 

Matthias

<Prev in Thread] Current Thread [Next in Thread>