[lkml]   [2003]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: statfs() / statvfs() syscall ballsup...
    On Monday 13 October 2003 10:45, Helge Hafting wrote:
    > Greg Stark wrote:
    > [...]
    > > In reality there is no time pressure on the vacuum at all. As long as it
    > > completes faster than dead records can pile up it's fast enough. The
    > > transactions on the other hand must complete as fast as possible.
    > This seems almost trivial. If the vacuum job runs too much,
    > overusing disk bandwith - throttle it!

    If you are using regular read/write syscalls and not too big chunks --> trivial.
    If you mmap you database --> harder.

    If you would like to tell the kernel, that this should not be treated
    like a sequential read --> fadvise/madvise.

    > This is easier than trying to tell the kernel that the job is
    > less important, that goes wrong wether the job runs too much
    > or too little. Let that job sleep a little when its services
    > aren't needed, or when you need the disk bandwith elsewhere.

    Here I agree as this seems like a solution.

    The problem is, that you sometimes need low latency for your
    transactions and then you cannot start throttling a heavy IO process,
    whose IO is already issued and who is basically just waiting for disk
    eating its bandwidth.

    The questions are: How IO-intensive vacuum? How fast can a throttling
    free disk bandwidth (and memory)?


    Ingo Oeser

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:49    [W:0.030 / U:83.668 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site