lkml.org 
[lkml]   [2011]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: xfs: very slow after mount, very slow at umount
    On Thu, Jan 27, 2011 at 5:22 PM, Mark Lord <kernel@teksavvy.com> 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
    streams.

    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.

    -Dave
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-01-28 05:17    [W:0.022 / U:152.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site