Re: aio on sun ufs problem

  • From: Tim Johnston <tjohnston@xxxxxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Wed, 05 May 2004 15:26:10 -0400

I also did some research on this recently...  The paper the original 
poster discusses was published by Sun and, in my opinion, is really 
geared to telling you how wonderful their ufs is and why you should run 
it...  However, it is of limited value if you are on vxfs...  Steve 
Adams has some excellent information on this subject...

A basic discussion of async io:  
http://www.ixora.com.au/notes/asynchronous_io.htm

Kernalized async io:  http://www.ixora.com.au/notes/raw_asynchronous_io.htm

Threaded async io:  http://www.ixora.com.au/notes/fs_asynchronous_io.htm

On Solaris, kernalized async io is only available if you are using raw 
or quick i/o files...  Therefore,  if you are using vxfs, threaded async 
io is your only async option...

Based on this, I decided to run with disk_async_io=false and multiple 
dbwr_io_slaves...

However, I recently ran into an article on Steve Adams site about this...

http://www.ixora.com.au/tips/use_asynchronous_io.htm

The item that really caught my eye is:

"The availability of asynchronous I/O to datafiles affects DBWn's 
ability to make use of the hardware I/O bandwidth, *and it affects the 
the prefetching of data for sequential reads by foregrounds*. 
Prefetching has an obvious performance impact that is particularly 
important in environments like data warehouses."

He then discusses a twist on the disk_async_io=false/multiple 
dbwr_io_slaves...

"Alternatively, asynchronous I/O can be disabled for DBWn only using the 
/_dbwr_async_io/ parameter, and explicit I/O slave processes can be 
configured instead using the /dbwr_io_slaves/ parameter. These options 
are preferable to disabling asynchronous I/O entirely using 
/disk_asynch_io/ or just threaded asynchronous I/O using 
/_filesystemio_options/, because the ability to use asynchronous I/O 
against raw files and for asynchronous prefetching from filesystem based 
datafiles is preserved. Unfortunately, the physical write bandwidth may 
not be fully used if DBWn's write bandwidth has to be constrained."

This has me very interested but I haven't yet had time to 
investigate...  Has anyone run with this config?

Tim

David Green wrote:

>I tried to generate discussion on this list regarding this topic before,
>but it did'nt go anywhere.  There is very little documenation and
>discussion out there that discusses db_writer_process vs dbwr_io_slaves in
>conjunction with weighing the kaio and aio pros and cons/issues as well.
>
>I have only performed these tests and eval in terms of 8i!
>
>I have done some measurements and quite a bit of reaading on this.  In
>many ways I found and in others ways I believe that dbwr_io_slaves(with
>disk_aysnch_io=flase) performs better than 1 db_writer_process(with
>disk_asycnh_io=true).
>
>In Oracle8i, the DBWR_IO_SLAVES parameter determines the number of IO
>slaves for LGWR and ARCH. If DBWR_IO_SLAVES is set to a value greater than
>0, then  LGWR and ARCH have a default value of 4.  dbwr_io_slaves can
>simulate asycnh io for LGWR, ARCH, DBWR and RMAN.
>
>9i disk_asynch_io ref note:
>DISK_ASYNCH_IO controls whether I/O to datafiles, control files, and
>logfiles is asynchronous (that is, whether parallel server processes can
>overlap I/O requests with CPU processing during table scans). If your
>platform supports asynchronous I/O to disk, Oracle Corporation recommends
>that you leave this parameter set to its default value. However, if the
>asynchronous I/O implementation is not stable, you can set this parameter
>to false to disable asynchronous I/O. If your platform does not support
>asynchronous I/O to disk, this parameter has no effect.
>
>If you set DISK_ASYNCH_IO to false, then you should also set
>DBWR_IO_SLAVES to a value other than its default of zero in order to
>simulate asynchronous I/O.
>---
>From that, I belive that dbwr_io_slaves are more roust in terms of
>simulating IO for RMAN operations and arch, where as aio/kaio at the OS
>level only performs aio for lgwr and dbwr.
>
>There is a great deal more that can be covered or further tested in this
>discussion, but I must run for now...I belive reads do benefit from aio or
>io_slaves.
>
>In terms of db_writer_processes vs dbwr_io_slaves the general
>recommendation is:
>Should you use DB_WRITER_PROCESSES or DBWR_IO_SLAVES?
>=====================================================
>
>Although both implementations of DBWR processes may be beneficial, the
>general
>rule, on which option to use, depends on the following :
>1) the amount write activity;
>2) the number of CPUs (the number of CPUs is also indirectly related to
>the number LRU latch sets);
>3) the size of the buffer cache;
>4) the availability of asynchronous  I/O (from the OS).
>
>There is NOT a definite answer to this question but here are some
>considerations to have when making your choice.  Please note that it is
>recommended to try BOTH (not simultaneously) against your system to
>determine which best fits the environment.
>
>-- If the buffer cache is very large (100,000 buffers and up) and the
> application is write intensive, then db_writer_processes may be
>beneficial.   Note, the number of writer processes should not exceed the
>number of CPUs.
>
>-- If the application is not very write intensive (or even a DSS system)
>and async I/O is available, then consider a single DBWR writer process; If
>async I/O is not available then use dbwr_io_slaves.
>
>-- If the system is a uniprocessor(1 CPU) then implement may want to use
> dbwr_io_slaves.
>
>Implementing db_io_slaves or db_writer_processes comes with some overhead
>cost.  Multiple writer processes and IO slaves are advanced features,
>meant for high IO throughput.   Implement this feature only if the
>database environment requires such IO throughput.  In some cases, it may
>be acceptable to disable I/O slaves and run with a single DBWR process.
>
>
>-----Original Message-----
>Subject:       Re: aio on sun ufs problem
>
>
>That is the point. The cost and benefit of using lwp based aio on
>filesystem, is it worthy or not.
>I saw note saying the cost of thread management and context switch is big,
>using LWP based AIO. Does any has measured the cost? 
>(http://www.ixora.com.au/q+a/0011/14171201.htm)
>Another question, does aio only means asynch write(non-blocking write), is
>there concept like asynch read? I did a test doing a full table scan on a
>table which is a raw device. The os is doing pread os call, not
>kaio(aioread...).
>If only write benefit from asynch IO, then only dbwr/lgwr will benefit
>from KAIO. So when dbwr and lwgr can catch up clean the dirty buffer,
>whether to using aio does not matters.As server process only does read on
>datafile, and server process used most of system resource on a big
>system.(server process does write only during direct read/write and
>creating tablespace,as far as I know).
>Just some thought and questions about this topic.
>Regards
>Zhu Chao.
>
>----------------------------------------------------------------
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>----------------------------------------------------------------
>To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
>put 'unsubscribe' in the subject line.
>--
>Archives are at //www.freelists.org/archives/oracle-l/
>FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
>-----------------------------------------------------------------
>  
>

-- 
Regards,
Tim Johnston
Tel: 978-322-4226
Fax: 978-322-4100


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: