Re: aio on sun ufs problem

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_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------