lkml.org 
[lkml]   [2009]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Linux 2.6.29
    From
    On Mon, Mar 23, 2009 at 11:19 PM, Jesper Krogh <jesper@krogh.cc> wrote:
    > I know this has been discussed before:
    >
    > [129401.996244] INFO: task updatedb.mlocat:31092 blocked for more than 480
    > seconds.

    Ouch - 480 seconds, how much memory is in that machine, and how slow
    are the disks? What's your vm.dirty_background_ratio and
    vm.dirty_ratio set to?

    > Consensus seems to be something with large memory machines, lots of dirty
    > pages and a long writeout time due to ext3.

    All filesystems seem to suffer from this issue to some degree. I
    posted to the list earlier trying to see if there was anything that
    could be done to help my specific case. I've got a system where if
    someone starts writing out a large file, it kills client NFS writes.
    Makes the system unusable:
    http://marc.info/?l=linux-kernel&m=123732127919368&w=2

    Only workaround I've found is to reduce dirty_background_ratio and
    dirty_ratio to tiny levels. Or throw good SSDs and/or a fast RAID
    array at it so that large writes complete faster. Have you tried the
    new vm_dirty_bytes in 2.6.29?

    > At the moment this the largest "usabillity" issue in the serversetup I'm
    > working with. Can there be done something to "autotune" it .. or perhaps
    > even fix it? .. or is it just to shift to xfs or wait for ext4?

    Everyone seems to agree that "autotuning" it is the way to go. But no
    one seems willing to step up and try to do it. Probably because it's
    hard to get right!

    -Dave


    \
     
     \ /
      Last update: 2009-03-24 07:49    [W:0.021 / U:0.832 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site