[lkml]   [1998]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectcooked and raw files (was: Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???))
    On Wed, 5 Aug 1998, Terry L Ridder wrote:
    > I agree, both Oracle & Informix recommend that the database be on a raw
    > disk partition for optimal performance. That being said there are however
    > several instances where a "quick and dirty" "cooked" file database are
    > required/wanted/desired/needed/etc. It is in those cases where >2GB
    > files are needed.

    Check yur fax... Oracle does NOT recommend cooked nor raw files. In
    _ORACLE for Sun Performance Tuning Tips_ manual, it lists the tradeoffs
    between the two issues. I summarize that below.

    *All* high-capacity production Oracle databases I've worked with have
    been stored on a cooked fs. And believe me I've setup and/or fixed some
    really hairy Oracle7/8 configs. :) The ease of maintenance on a cooked
    fs always outweighted the performance gain on a raw fs.

    It is *much* cheaper to buy new hardware to support a cooked fs when it
    gets loaded, than it is to pay an admin to support and maintain an
    Oracle db on one or more raw partitions.


    Paraphrased excerpts from _ORACLE for Sun Performance Tuning Tips_:

    Tip No. 1: Use async I/O (AIO)

    Presumably under Linux this would be the threaded POSIX libaio

    Tip No. 2: Use a Logical Volume Manager (LVM)

    Here it refers to Online DiskSuite, which is the same as
    Linux's md driver.

    Tip No. 3: Use readv()

    Manual notes that readv() on raw partitions is slower than
    on cooked fs's.

    Tip No. 5: Use RAID

    Manual notes RAID5 enhances read performance, penalizes
    write performance. (no surprises there)

    Tip No. 7: Using UFS vs. Raw Partitions

    Advantages of UFS [cooked]:

    * Easier to use from operational perspective
    * Sequential reads benefit substantially on lighter-load systems, because
    * fs read-ahead kicks in when it detects large seq reads
    * data ends up in kernel buffer cache
    * fs blocksize can be chosen to match Oracle block size

    Disadvantages of UFS:

    * extra buffer copies. This becomes very evident under high load
    * under heavy load, contention for buffers ends up becoming the
    main bottleneck
    * more work to be done by the pagedaemon that flushes data to fs
    * more memory sacrificed to the buffer cache

    Tip No. 8: Using direct I/O

    Manual notes solaris 2.4 doesn't implement this.

    [interesting non disk-related tips follow; gives us an idea of where
    Linux should be, what it should do....]

    Tip No. 9: Use processor affinity/binding on SMP systems

    Tip No. 10: Tune spin count on SMP to reduce latch contention

    Tip No. 11: Use Real-time scheduling

    Tip No. 17: Using Intimate Shared MEmory (ISM)

    Manual notes Sun's Intimate Shared Memory feature allows
    idfferent processes attaching to the same shared memory address
    to share the same page table. This avoids page table steealing
    and threading and thus enhances db performance.

    Tip No. 21: Use out-of-band breaks with SQL*Net TCP/IP

    Tip No. 23: TCP/IP Performance issues

    Packet size used internally by SQL*Net v2 is 2K.

    Jeff Garzik Typhoon, Cyclone, Diablo, and INN News tuning and consulting

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

     \ /
      Last update: 2005-03-22 13:43    [W:0.021 / U:4.308 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site