The old raw devices chestnut.
12/03/2018 11:47
Note the cross-posting - but no flame wars please.

This question was prompted by a thread on the a postgres mailing list during which someone (Gregory Williamson) claimed <quote>raw devices, at least on Solaris, are about 10 times as fast as cooked file systems for Informix.

<quote> This made me think about the old arguments, and I wondered about the current state of thinking. Some of my knowledge will be a bit out of date.

Oracle: (my main experience)At various times Oracle have claimed (talking to consultants, not marketers) that raw devices are 5-20% faster than filesystems. This may vary on the current state of the oracle code and/or the filesystem being compared against. Veritas seem to agree by producing QuickIO for Oracle, claiming performance of raw with the management of filesystem.

I have never been sufficiently convinced to implement a major system with raw.

Sybase: (some experience)Sybase claim filesystems are faster, because of OS buffering, but unsafe for the same reason. They only ever suggest filesystem for tempdb. They don't seem to have heard of fsync()[1] DB2: No idea Informix: No idea beyond the claim which started this off.

What is the latest thinking, both in terms of vendor claims and practical experience? [1] or whatever system call forces write-through caching

Source is Usenet: comp.databases.oracle.server
Sign in to add a comment

Answer score: 5
12/03/2018 11:47 - Sorry, I meant to/from db buffer cache.


Source is Usenet: comp.databases.oracle.server
Sign in to add a comment

Answer score: 5
12/03/2018 11:47 - Jim Smith <jim@jimsmith.demon.co.uk> wrote in messagenews:hq7AQQApjAfAFwlb@jimsmith.demon.co.uk...

Nope. That has nothing to do with I/O speed.

Absolutely not. Cache access is faster. And it has nothing to dowith fs or raw I/O. You get EXACTLY the same speed regardlessof where you got the data from.

Depends on what the OS can do. Some don't work all that well atdoing direct I/O to/from buffer cache. And if they copy from anotherbuffer, you end up with CPU use instead of I/O use.


Source is Usenet: comp.databases.oracle.server
Sign in to add a comment

Answer score: 5
12/03/2018 11:47 - Jim Smith <jim@jimsmith.demon.co.uk> wrote in messagenews:dS4PuczgskeAFwJq@jimsmith.demon.co.uk...

Let's see first if we can all understand what the heckis meant by faster? Is it faster I/O requests?Or faster I/O overall?Or less CPU used? Here is IME: 1- Raw does not make for faster I/O. I/O speed is defined byyour hardware (disk + controller) and raw or cooked means nothingin that context.

2- Raw produces overall faster I/O response, all else being equal.

3- However, this can be MUCH faster, or slightly faster.

Explain: If db is reading off the file system buffer cache, then it iseminently STUPID to claim file system I/O is faster: there isno I/O in that case, just in-memory access! If db is reading from disk to fs cache and then copying from thereto db cache then raw will be faster: it doesn't need to copy into the fscache, I/O goes directly to the db cache. In such cases one noticesa marked drop in CPU use(!) rather than I/O use by switching to raw: the block/page copy doesn't come cheap or free.

If the fs cache allows for referencing via pointers from the db processes,then the fs I/O will be almost same speed as raw but CPU use will be alittle higher: use of indirect addressing (via pointers) is slightlyheavier on resources than direct addressing (via segment addressing).

However a fs cache will be servicing requests from the ENTIRE system, not justthe database hardware. So the potential for heavy interference with thedb I/O activity is there. As such if the system is not a dedicated db server,one can see some wild variations in I/O response times with varying systemloads.

It all depends on what is being measured, and when and how.


Source is Usenet: comp.databases.oracle.server
Sign in to add a comment

Answer score: 5
12/03/2018 11:47 - In message <407a7113$0$4574$afc38c87@news.optusnet.com.au>, Noons <wizofoz2k@yahoo.com.au> writes None of the above. A faster response and or throughput from a user point of view.

But it will give a faster response therefore file systems are faster.

But, database blocks will often be buffered in the db buffer cache so the file system buffer may be irrelevant or even an overhead. I vaguely remember on VMS it was recommended you disable disk caching and used oracle's buffer cache.


Source is Usenet: comp.databases.oracle.server
Sign in to add a comment

eDiscover
Helpforce eDiscover provides technical articles updated each dayHelpforce eDiscover RSS feed contains the latest technical articles in RSS
Click the logo to go back to the main page
Search eDiscover
  
Categories

Click an icon to go to that category

Helpforce eDiscover contains articles about Microsoft Windows Helpforce eDiscover contains articles about Apple products and MacOS Helpforce eDiscover contains articles about Linux and POSIX operating systems Helpforce eDiscover contains articles about Helpforce Helpforce has a large variety of technical information and articles for you to read Helpforce eDiscover contains articles about databases, MYSQL, SQL Server Oracle Helpforce eDiscover contains articles about Java, JVM and the JRE Helpforce eDiscover contains articles about the QNX operating system Helpforce eDiscover contains articles about Oracle Solaris and Open Solaris Helpforce eDiscover contains articles about RISC OS, Acorn and the BBC Micro Helpforce eDiscover contains articles about Amiga and AmigaOS

Type your comment into the box below