[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.063 / U:0.704 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site