473,883 Members | 2,607 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

The old raw devices chestnut.

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 "performanc e 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
--
Jim Smith
Because of their persistent net abuse, I ignore mail from
these domains (among others) .yahoo.com .hotmail.com .kr .cn .tw
For an explanation see <http://www.jimsmith.de mon.co.uk/spam>
Nov 12 '05
42 4705
Niall Litchfield wrote:
"Andrew Hamm" <ah***@mail.com > wrote in message
news:c5******** ****@ID-79573.news.uni-berlin.de...
Further (with Informix, once again) the engine can use KAIO, and with the
architecture of Informix, this can lead to further significant

improvements.
It all adds up. Why do you think F1 now make their pedals out of carbon
fibre? And they *still* drill 'em out for extra lightness. An Informix
engine using raw with KAIO and a decent layout of spaces on the disk can
feel very spiffy indeed even compared to one that merely drops KAIO and

raw.

A dangerous analogy, the formula 1 one. An F1 Car is made to last a
weekend - used to be a race - and to be rebuilt after that. This is not a
desirable* thing in a database. Robustness and reliability are important
as well as performance - probably more so.


I am thinking extra performance for no loss relaibility is also good, no?
KAIO not make database less relaible.

--
Enor
Nov 12 '05 #41
"Paul Watson" <pa**@oninit.co m> wrote in message
news:40******** *******@oninit. com...
Absolutely not. Cache access is faster. And it has nothing to do
with fs or raw I/O. You get EXACTLY the same speed regardless
of where you got the data from. [cutting]

But if the cache is too small or being turned over very quickly the
cache will be slower 'cos you to copy from disk to cache and then
copy from cache to the app.


Disagree. The cache access from a given db process will still be at the same
speed: it's a memory-to-memory copy, the cache size means nothing in that
context.

Of course, the db processes MAY have to wait for real I/O to fill up the cache.
But that doesn't mean "the cache is slower".
Interestingly on the bigger Sun servers the absolute bandwidth to
disk is significantly larger than the bandwidth to memory so, in
theory, you can the data from disk faster than from memory - I remain
unconvinced:-)


Yup! :)
I'd guess what they mean is the overall *aggregate* I/O bandwidth is
faster than memory access speed. This because in some of the 64 CPU boxes,
it may actually be quite slower for a given CPU to access memory belonging
to another CPU quad card. While the I/O speed stays the same as it goes
directly to each quad CPU/memory card as requested.

Still, a strange claim by any standard. I've worked with a 64CPU ES10K Sun
and its I/O speed for single disk access was nothing to write home about...

--
Cheers
Nuno Souto
wi*******@yahoo .com.au.nospam

Nov 12 '05 #42
"Niall Litchfield" <ni************ **@dial.pipex.c om> wrote in message news:<40******* *************** *@news-text.dial.pipex .com>...
"Andrew Hamm" <ah***@mail.com > wrote in message
news:c5******** ****@ID-79573.news.uni-berlin.de...
Further (with Informix, once again) the engine can use KAIO, and with the
architecture of Informix, this can lead to further significant improvements.
It all adds up. Why do you think F1 now make their pedals out of carbon
fibre? And they *still* drill 'em out for extra lightness. An Informix
engine using raw with KAIO and a decent layout of spaces on the disk can
feel very spiffy indeed even compared to one that merely drops KAIO and

raw.

A dangerous analogy, the formula 1 one. An F1 Car is made to last a
weekend - used to be a race - and to be rebuilt after that. This is not a
desirable* thing in a database. Robustness and reliability are important as
well as performance - probably more so.


Good point, Niall (especially the *). I think the better analogy
might be fuel injection v. carburetors. Better performance AND gas
mileage AND reliability eventually takes over the consumer market and
the racing market (with some notable exceptions). So if raw is a
nearly-free 20% performance gain, especially during month-end serial
processing when people with purse strings are tapping their fingers on
their desks, then it's likely to take over. And in a way it is, with
the newfangled filesystems. But managing raw filesystems manually is
like mulitple carburetors - great performance if you have the right
tools, risky if you don't. Ever hear a six-carb V12? Hooo-mama.


--
Niall Litchfield
Oracle DBA
Audit Commission UK
http://www.niall.litchfield.dial.pipex.com
*************** *************** ***********
Please include version and platform
and SQL where applicable
It makes life easier and increases the
likelihood of a good answer
*************** *************** ************

*actually it is desirable in one situation - when running a TPC or similar
benchmark. Again you engineer the product to last pretty much for the life
of the performance test and sacrifice everything else for speed.


jg
--
@home.com is bogus.
http://www.forbes.com/2002/08/13/0813vow.html
Nov 12 '05 #43

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.