[Top] [All Lists]

Re: xfs: very slow after mount, very slow at umount

To: Mark Lord <kernel@xxxxxxxxxxxx>
Subject: Re: xfs: very slow after mount, very slow at umount
From: David Rees <drees76@xxxxxxxxx>
Date: Thu, 27 Jan 2011 20:14:50 -0800
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>, Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Alex Elder <aelder@xxxxxxx>, Linux Kernel <linux-kernel@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=wta27aUpl7oCsQAnUEKYO9oB2XeGsLjqMVCz7WNLflo=; b=tWck0BcGfhkWjzHhDmtGwr4qQqPxXptSHgnAfipaztHlSoHhZaEnkcCitH6fHd30oa Ov4OwO8y+COwH0KBO66iSyZDslmhyGJYcMFLLCrTRXDY4UaRD+3y8mNjo4BCWDdpabn3 FFJhUdPGF/z53v6B/E6U89E//76G9p3Lf4ZL8=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=g7lwR7UJeRSj2LiLDJK30UZY4nG4GVSAB14d2EOrfUxkCEypv7x9MLlIhOqA+IqQUP +qIG8juurdAaH0t6SuZRGw9wypKTD8H/8s8+k00v7w25q30PWsdbSYuBmW8yWnj8QiU7 Yc5OY2sl2SGHIk6IloMM1UgNq52YMn6XIINcs=
In-reply-to: <4D421A68.9000607@xxxxxxxxxxxx>
References: <4D40C8D1.8090202@xxxxxxxxxxxx> <20110127033011.GH21311@dastard> <4D40EB2F.2050809@xxxxxxxxxxxx> <4D418B57.1000501@xxxxxxxxxxxx> <alpine.DEB.2.00.1101271040000.31246@xxxxxxxxxxxxxxxx> <4D419765.4070805@xxxxxxxxxxxx> <4D41CA16.8070001@xxxxxxxxxxxxxxxxx> <4D41EA04.7010506@xxxxxxxxxxxx> <20110128001735.GO21311@dastard> <4D421A68.9000607@xxxxxxxxxxxx>
On Thu, Jan 27, 2011 at 5:22 PM, Mark Lord <kernel@xxxxxxxxxxxx> wrote:
> But I just don't know.  My working theory, likely entirely wrong,
> is that if I have N streams active, odds are that each of those
> streams might get assigned to different AGs, given sufficient AGs >= N.
> Since the box often has 3-7 recording streams active,
> I'm trying it out with 8 AGs now.

As suggested before - why are you messing with AGs instead of allocsize?

I suspect that with the default configuration, XFS was trying to
maximize throughput by reducing seeks with multiple processes writing

But now, you're telling XFS that it's OK to write in up to 8 different
locations on the disk without worrying about seek performance.

I think this is likely to result in overall worse performance at the
worst time - under write load.

If you are trying to optimize single thread read performance by
minimizing file fragments, why don't you simply figure out at what
point increasing allocsize stops increasing read performance?

I suspect that the the defaults do good job because even if your file
are fragmented in 64MB chunks because you have multiple streams
writing, those chunks are very likely to be very close together so
there isn't much of a seek penalty.


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