[lkml]   [2001]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2x Oracle slowdown from 2.2.16 to 2.4.4

    On Fri, Jul 13, 2001 at 08:36:01AM -0700, Jeffrey W. Baker wrote:

    > > files O_SYNC. Journal size was 400 megs, mount options `data=journal'
    > >
    > > ext2: Throughput 2.71849 MB/sec (NB=3.39812 MB/sec 27.1849 MBit/sec)
    > > ext3: Throughput 12.3623 MB/sec (NB=15.4529 MB/sec 123.623 MBit/sec)
    > >
    > > The difference will be less dramatic with large, individual writes.
    > This is a totally transient effect, right? The journal acts as a faster
    > buffer, but if programs are writing a lot of data to the disk for a very
    > long time, the throughput will eventually be throttled by writing the
    > journal back into the filesystem.

    Not for O_SYNC. For ext2, *every* O_SYNC append to a file involves
    seeking between inodes and indirect blocks and data blocks. With ext3
    with data journaling enabled, the synchronous part of the IO is a
    single sequential write to the journal. The async writeback will
    affect throughput, yes, but since it is done in the background, it can
    do tons of optimisations: if you extend a file a hundred times with
    O_SYNC, then you are forced to journal the inode update a hundred
    times but the writeback which occurs later need only be done once.

    For async traffic, you're quite correct. For synchronous traffic, the
    writeback later on is still async, and the synchronous costs really do
    often dominate, so the net effect over time is still a big win.

    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 12:57    [W:0.023 / U:15.660 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site