Re: Oracle on Windows Vs. Linux
- From: Nuno Souto <dbvision@xxxxxxxxxxxx>
- Date: Sat, 20 May 2006 21:39:50 +1000
Kevin Closson wrote,on my timestamp of 20/05/2006 3:28 PM:
The post you are responding to had to do with Jared's
point about atime updates. Async or not, direct I/O
is what circumvents mtime/atime updates.
didn't say it wasn't, Kevin. But it's not the be-all,
end-all of efficient IO in Linux. And dio does circumvent
mtime/atime updates but it's not what does it exclusively:
if one selects noatime, one doesn't get dio.
What I am alerting to is that it's not only just turning
these options on or off: the patch levels have to be checked as
well and Metalink has to be scoured for any bugs. It's the case
with 10gr1 and it certainly and most absolutely was the case with
9i and below:
I do recall the umpteen times folks reported here and elsewhere no
change or incoherent results in their cooked/dio/aio testing and
the problem was, in almost all cases, OS and/or Oracle incorrectly
or incompletely patched!
And where it was incompletely patched, it was in most cases due to
the sheer lack of information on this subject from both Oracle
and Linux support, at the time of 9i and before. Even today it
STILL is not easy to find: one has to dig long and hard for
the correct combination of search words in Metaclick to get the
juicy bits. It shouldn't be like that, but it is.
Yes, I know: Oracle claims that 10gr2 "has no bugs". But then
again they claimed the same for 10g, 9ir2, etc, ad nauseum and we all
know the stacks of "unpublished" bugs that await those who try to push
the envelope in those versions. Wait for 11 and the stack of bugs
on 10gr2 that will suddenly show up in Metalink as "only fixed in
11, upgrade or else...".
So: caveat emptor and test,test,test - and search Metalink.
Of course - not you: those listening in.
BTW, neither direct, nor async make I/O "faster". The DMA transfer
takes as long as the I/O subsystem will facilitate. However,
direct and/or async usually handles the same amount of I/O
with improved processor efficiency...and that, generally improves
overall system throughput.
Exactly. The various types of IO do little in terms of
the disk or transfer speeds, if anything, as you well say.
But I'd still carefully check native disks with hdparm: some Linux
ports do stupid things to obvious options in modern disks. Our test
servers areu standard blades with native controllers/disks and
particularly with SATA hardware things can go awfully "clunk"...
> Oracle Disk Manager is about the
most efficient I/O library for Oracle...should be, Oracle
defined the library...but I digress.
It might be what Oracle thinks of IO, not what the OS
thinks of IO. Namely and as an example: there is a world
of difference on how Linux 2.4 and 2.6 perform disk IO at the
low level SIO/queueing, OS interrupt handling level and its
impact on the scheduler. All 3rd party IO libraries use that code
no matter what else they might do. All potentially do benefit
from running in 2.6 as opposed to 2.4, even if it's the highly
patched - and efficient - RHEL3-Upd6.
Still early days in 2.6 but there might be one or two file
systems getting into that game as well. My bet is on
ReiserFS and XFS. I think IBM has completely dropped the ball
with JFS on Linux. One of the latest Linux Journal editions has
some interesting reading on all the above.
I'm flashing back now..uh, right, it was 6.0.27 on Sequent
DYNIX/ptx where we implemented direct+async I/O on filesystem
files for the first time... ah, the good old days
Great work and badly needed at the time. But Linux is far behind
modern Unix in many areas, as Mladen correctly pointed out a while
ago. It's quite interesting to watch the evolution, deja vu.
Like Linus himself said not too long ago: "most of the OS
theoretical research was done in the 70s and 80s, there has been
nothing fundamentally new since then".
--
Cheers
Nuno Souto
in rainy Sydney, Australia
dbvision@xxxxxxxxxxxx
--
//www.freelists.org/webpage/oracle-l
Other related posts:
