Re: Raw Devices: Increased Performance?

In article <$x2BSJAQKW4xEwZw_at_smooth1.demon.co.uk> David Williams <djw_at_smooth1.demon.co.uk> writes:
>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

Agree, just curious how often in the real world it isn't the bottleneck. I have seen people make ridiculous attempts to use underpowered boxes, but... well, I guess you can't a priori tell what is wrong.

>
>>(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??
Perhaps we are now getting into the area of placement of the files on disk and so forth.

>
>>(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.

A stress test may show the OS vendor's more complicated handling of file I/O may stand up better (or fall down more gracefully) than Oracles. Since I've been burned on several platforms with DBWR pulling its dress over its head, I don't quite trust Oracle as much as the OS. Maybe that's unfair. But if you care about 10% performance, you may have some capacity planning issues to address.

>
>>(5) Anyone who does not have the time, expertise, or resources to
>> perform the raw-vs-filesystem benchmark *should* *not* *consider*
>> using raw devices.

I shoulda said that. But if it's a "free" 10%, why not? (For those who are confused now, I had said the possible administrative problems make a small gain not worth it, this is mild sarcasm).

>>
>>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.

I had those thoughts about the person who claimed that, as well as that he might have changed hardware.

>>
>>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.
>

Assuming Oracle doesn't do the same things... and if it doesn't, how do we know things won't get corrupted in a crash? Assuming everything Oracle does is as good as could be done is a mistake. At least with fsck you might figure out what happened...

> 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

-- 
Joel Garry               joelga_at_rossinc.com               Compuserve 70661,1534
These are my opinions, not necessarily those of Ross Systems, Inc.   <> <>
%DCL-W-SOFTONEDGEDONTPUSH, Software On Edge - Don't Push.            \ V /
panic: ifree: freeing free inodes...                                   O