Messages in this thread |  | | | Subject | cooked and raw files (was: Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)) | | Date | Thu, 6 Aug 1998 14:03:55 -0400 (EDT) | | From | Jeff Garzik <> |
| |
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.
Jeff
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 http://www.spinne.com/usenet/ News tuning and consulting
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
|  |