Re: agsize and performance

From: Matthias Schniedermeyer <ms@citd.de>
To: K T <mailkarthikt@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: agsize and performance
Date: Wed, 30 Oct 2013 16:27:52 +0100	[thread overview]
Message-ID: <20131030152752.GA26172@citd.de> (raw)
In-Reply-To: <CALtWs494cAew-SxMZqZecA+RHSOpAxhQpps-o6Cbe5Qj1GybFw@mail.gmail.com>

On 30.10.2013 10:46, K T wrote:
> I meant sync not fsync(O_SYNC flag).

What kind of workloads needs sync I/O?

> My main question is why there is better throughput when I make the agsize
> smaller?

Unfortunatly i can't help you here, i'm no expert in things XFS.
I thought you didn't really meant to use sync I/O.

> On Wed, Oct 30, 2013 at 5:59 AM, Matthias Schniedermeyer <ms@citd.de> wrote:
> 
> > 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
> >

-- 

Matthias

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