Re: Raw Devices: Increased Performance?

In article <4rpsh3$s99_at_inet-nntp-gw-1.us.oracle.com>, Paul Zola <pzola_at_us.oracle.com> writes
>
>} >joelga_at_rossinc.com (Joel Garry) writes:
>} >
>} >>There was a thread on this a while ago, with some folks claiming minimal
>} >>increase, while others claimed up to 300%.
>
>Let me paraphrase from Cary Millsap's paper "The OFA Standard Oracle7
>for Open Systems", (part number A19308) which everyone in this thread
>should read before posting anything on this subject.
>
>(1) If disk I/O is not the bottleneck, then going to raw devices will
> have *no* *performance* *impact* *at* *all*.

  Correct

>(2) If disk I/O is the bottleneck, then going to raw devices may
> sometimes gain up to a 10% performance improvement relative to
> the same database using filesystem files.

   Agreed

>(3) Under very common circumstances, going to raw devices can actually
> *decrease* database performance.

   ??? Explain - Not going with the UNIX buffer cache and also copying    (DMAing) directly into user space rather than via kernel space i.e.    one memory write rather than a memory write and a memory copy is    SLOWER??
>(4) Anyone contemplating going to raw devices should benchmark their
> application on both raw and filesystem devices to see if there is
> a significant performance increase in using raw devices.
  

   Not sure it's neccessary.

>(5) Anyone who does not have the time, expertise, or resources to
> perform the raw-vs-filesystem benchmark *should* *not* *consider*
> using raw devices.
>
>Finally: a word about those 300% speedups that people report. Often,
>when you look at the changes that they've made to go to raw devices
>you'll find that they have done one of:
> (1) Export/Import the database, and thereby remove fragmentation;
> (2) Move control or redo log files onto separate devices or
> controllers;
> (3) Move database files onto separate devices or controllers.
>
>If you adjust for all of the performance improvements that they've
>gotten from all the other optimizations, then you'll see that *just*
>going raw hasn't really bought them that much. Defragmenting, in
>particular, can buy you a *lot* of speed.
>
>Of course, they could always have made the same performance
>improvements without going raw, and gotten most, if not all, of the
>performance gains that they're attributing to raw devices.
>

   Agreed - fragmentation does decrease performance dramtically but how    can filesystems be faster - loading inodes into memory and    following inodes means more seeking since inodes as not that close to    the data even with cylinder groups in use. You would expect at least    one seek from inode table to the data which is not required when    using raw devices.

   The inode table is deliberately storing control i.e. disk layout    information away from (in a separate cylinder) to data.

    How can it be faster???
> -p
>
>==============================================================================
>Paul Zola Technical Specialist World-Wide Technical Support
>------------------------------------------------------------------------------
>GCS H--- s:++ g++ au+ !a w+ v++ C+++ UAV++$ UUOC+++$ UHS++++$ P+>++ E-- N++ n+
> W+(++)$ M+ V- po- Y+ !5 !j R- G? !tv b++(+++) !D B-- e++ u** h f-->+ r*
>==============================================================================
>Disclaimer: Opinions and statements are mine, and do not necessarily
> reflect the opinions of Oracle Corporation.
 

-- 
David Williams