Re: Raw Devices: Increased Performance?

thank you for the very good explanation of how the fileystem works.

pzola_at_us.oracle.com (Paul Zola ) wrote:

>In <$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
>} >

 [snip]
>} >(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??
 
>Flippant answer: Trying to reduce expected disk read times by
> reducing the number of memory copies is like trying to optimize a
> program by moving code from the initialization modules into the
> main loop.

This sentence made the point. If one is going to raw devices, without reallocating memory from the (now unused) file system cache to the database, performance will simply go much worse.

>How much time did this take to complete? Well, since raw device
>accesses are scheduled in the order in which they occur, this disk had
>to seek almost from one end to the other 8 times, for a total of 800
>ms.

You talked about the UNIX kernal, which is optimizing I/O. Is there no optimization for raw devices, only for filesystems ?

Oracle also schedules multiple read/writes on one raw device - why should these be served sequentially ?

>Now, let's consider the same access pattern on a filesystem file, using
>the buffer cache. Assuming that these accesses came pretty quickly,
>they could all be handled in 3 scans of the request queue (2 going up,
>2 going down) for a total of 300 ms. (Note that since UNIX has a
>write-back cache, the final write didn't necessarily force a write to
>disk: yet another optimization made possible by using filesystem
>files.)
 

>Result? Filesytem wins by more than 100% over raw device.

This is only true watching accesses for one single disk drive. If a system constantly has this type of I/O, then one should consider to spread I/Os across several disks.

>But we've just seen that it is. Let me emphasize: whether raw or
>filesystem devices will be faster depends DIRECTLY on the disk access
>patterns of *your* *specific* *application*. The exact same schema
>could be faster on one or the other, depending on what your users are
>doing with it.

As you say, it depends on the application. Your statements are correct, especially if only the database is running on the machine, serving clients.

If you also have apllication code running on the machine, then the situation is totally different. You also have to consider the load (and type of load) the programs and users put on the system - if they use the filesystem heavily, the cache "competes" between user-files and database-files.

>This is not to say that using raw devices will always be slower. But
>they are far from the "magic bullet" that lots of DBAs seem to think
>they are.
 

>And I'll say it again:
 

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

>==============================================================================
>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.
Willy Klotz

Willy Klotz

Willys Mail     FidoNet   2:2474/117  2:2474/118  
                Mailbox: analog 06297 95035
                         ISDN   06297 910105
                Internet: willyk_at_t-online.de                
                ->   No Request from 06.00 to 08.00 <-
======================================================================