[Top] [All Lists]

Re: Many-metadata performance still at a loss

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Many-metadata performance still at a loss
From: Jan Engelhardt <jengelh@xxxxxxxxxx>
Date: Fri, 11 Mar 2011 02:56:05 +0100 (CET)
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20110311011024.GB15097@dastard>
References: <alpine.LNX.2.01.1103101507120.5379@xxxxxxxxxxxxxxx> <20110311011024.GB15097@dastard>
User-agent: Alpine 2.01 (LNX 1266 2009-07-14)
On Friday 2011-03-11 02:10, Dave Chinner wrote:
>On Thu, Mar 10, 2011 at 03:14:34PM +0100, Jan Engelhardt wrote:
>> Was there something I missed?
>> # xfs_info /
>> meta-data=/dev/md3               isize=256    agcount=32, 
>> agsize=11429117 blks
>>          =                       sectsz=512   attr=2
>> data     =                       bsize=4096   blocks=365731739, 
>> imaxpct=5
>>          =                       sunit=0      swidth=0 blks
>> naming   =version 2              bsize=4096   ascii-ci=0
>> log      =internal               bsize=4096   blocks=32768, version=2
>>          =                       sectsz=512   sunit=0 blks, lazy-count=0
>                                                              ^^^^^^^^^^^^
>> realtime =none                   extsz=4096   blocks=0, rtextents=0
>You're using an old mkfs?

As mentioned, this is a preexisting fs. This was created in August 2009
using xfsprogs 2.10.1.

>At minimum, this should have lazy-count=1.
>I'm also wondering about the fact this is a MD device but there is
>no sunit/swidth set,
>Further - what is your storage configuration (e.g. what type of MD
>raid are you using) and is the filesystem correctly aligned to the
>storage? If you get these wrong, then nothing else you do will
>improve performance.

mdraid1 over two dumb SATA disks.

>and the agcount of 32 is not a default value,

Right. xfsprogs had just switched from agcount=16 to agcount=4
for its default value, which at that time seemed a little
uncomforting, given disks grow in size. So as much as I can recall,
I only set the agcount manually to 32 (1.5T/32=46G) for
when I once (like, 2007 or so) created an xfs it used 16

>What are your mount options - perhaps you've missed the fact that
>the new functionality requires the "delaylog" mount option to be

Per /proc/mounts:
/dev/md3 / xfs rw,relatime,attr2,nobarrier,noquota 0 0

>Mind you, that is not a magic bullet - if the operation is
>single threaded and CPU bound, delaylog makes  no difference to
>performance, and with lazy-count=0 then the superblock will still be
>a major contention point and probably nullify any improvement
>delaylog could provide..

The question is.. is the writeout single-threaded?
Judging from there being only one xfs thread per block device,
that may seem to hold.

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